Methods for determining the potential impact of software upgrades on computing devices, computer programs, and update-recommended computer servers (software upgrade stability recommendations)

Abstract

To provide a method and system for determining a potential impact from software upgrades on a computing device.SOLUTION: A determination is made as to whether the software application upgrade will potentially cause a failure in a first computing device based on a history of operating behavior associated with the software application upgrade and based on a state of similarity between the analyzed profile for each of the other computing devices and the profile of the first computing device. An end user is presented with a risk-based recommendation.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates generally to networking systems, and more particularly to a system and method for software upgrade stability recommendations. [Background technology]

[0002] [Description of Related Art] Software upgrades are necessary to maintain system security and stability, but they are rarely immune to failure. This is one of the main reasons why users avoid going ahead with software upgrades when they become available. Upgrades can behave unexpectedly and cause unplanned delays, which can cause instability and reduced productivity for primary users of affected devices.

[0003] Users have reasonable expectations that device software upgrades will proceed smoothly. While developers understand the compatibility, dependencies, and defects of their own products, they are often unaware of incompatibilities involving libraries, drivers, operating systems, and hardware components not developed by their own company. Incompatibilities may not be apparent until an upgrade is attempted. Upgrade checks almost always consider only packages managed by the same package management system or source company. Upgrade checks may not consider the uniqueness of custom packages or environmental components that are specially configured, built from source code, or by external package management systems. In some cases, a completely out-of-band solution might be the missing element (e.g., a system reboot) that stabilizes the system but is not documented in the developer documentation. Incompatibilities may only become apparent through trial and error. For this reason, reading entire forum discussions can be beneficial, but it also requires a little luck and extensive and thorough searching for relevant but not directly related information. Summary of the Invention [Problem to be solved by the invention]

[0004] Within an enterprise, it is already possible to gain insights from the experience of others through automation and software monitoring agents. Agents collect data for audit purposes, to verify secure configurations or versions, or to generate statistical reports. However, monitoring agents do not coordinate or understand software upgrade issues across similar systems that affect stability.

[0005] There may be several methods for generating upgrade risk maps to assess the likelihood of a successful upgrade of a particular software package, but these methods may not consider the stability of other software packages in the same system that are not necessarily related to the software upgrade. [Means for solving the problem]

[0006] According to one embodiment of the present disclosure, a method for determining the potential impact of a software upgrade on a computing device is provided. The method includes recording profiles of software and hardware elements currently present on each computing device in a network including a plurality of computing devices. A query for a software application upgrade for a software application resident on a first computing device is received. A device configuration of the first computing device is identified based on the software and hardware elements currently present on the first computing device. Other computing devices in the network that have installed the software application upgrade are identified. Historical operational behavior associated with the software application upgrade on the identified other computing devices is obtained. Profiles of each of the other computing devices are obtained. The profiles of each of the other computing devices are analyzed for hardware or software conflicts with the software application. Based on the historical operational behavior associated with the software application upgrade on the identified other computing devices and based on the state of similarity between the analyzed profiles of each of the other computing devices and the profile of the first computing device, a determination is made as to whether the software application upgrade is likely to cause a failure in a software or hardware element currently present on the first computing device. Further, a risk-based recommendation of whether to install the software upgrade on the first computing device based on the determination is presented to an end user of the first computing device.

[0007] In one embodiment, a method includes identifying a second computing device, the second computing device exhibiting a stable operating configuration. Attributes related to failure events associated with software upgrades at each other computing device are identified. Differences between the configuration of the second computing device and the configurations of each other computing device involved in the failure events associated with the software upgrades are analyzed. Further, differences between the configuration of the second computing device and the configurations of each other computing device are identified, and a risk-based recommendation is based on the identified configuration differences.

[0008] According to one embodiment of the present disclosure, a computer program product for determining the potential impact of a software upgrade on a computing device is provided. The computer program product includes one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media. The program instructions include recording a profile of software and hardware elements currently present on each computing device in a network including a plurality of computing devices. A query for a software application upgrade for a software application resident on a first computing device is received. A device configuration of the first computing device is identified based on the software and hardware elements currently present on the first computing device. Other computing devices in the network that have installed the software application upgrade are identified. Historical operational behavior associated with the software application upgrade on the identified other computing devices is obtained. Profiles of each of the other computing devices are obtained. The profiles of each of the other computing devices are analyzed for hardware or software conflicts with the software application. Based on the historical operational behavior associated with the software application upgrade on the identified other computing devices, and based on the state of similarity between the analyzed profiles of each of the other computing devices and the profile of the first computing device, a determination is made as to whether the software application upgrade is likely to cause a failure in a software or hardware element currently present on the first computing device.Additionally, a risk-based recommendation based on the determination as to whether to install the software upgrade on the first computing device is presented to an end user of the first computing device.

[0009] According to one embodiment, the program instructions further include recording a profile on the first computing device immediately before or immediately after installing the software application upgrade on the first computing device.

[0010] According to one embodiment of the present disclosure, a computer server is disclosed. The computer server includes a network connection, one or more computer-readable storage media, a processor coupled to the network connection and coupled to the one or more computer-readable storage media, and a computer program product including program instructions collectively stored on the one or more computer-readable storage media. The program instructions include recording a profile of software and hardware elements currently present on each computing device in a network including a plurality of computing devices. A query for a software application upgrade for a software application resident on a first computing device is received. A device configuration of the first computing device is identified based on the software and hardware elements currently present on the first computing device. Other computing devices in the network that have installed the software application upgrade are identified. Historical operational behavior associated with the software application upgrade on the identified other computing devices is obtained. Profiles of each of the other computing devices are obtained. The profiles of each of the other computing devices are analyzed for hardware or software conflicts with the software application. Based on the historical operational behavior associated with the software application upgrade on the identified other computing devices, and based on the state of similarity between the analyzed profiles of each of the other computing devices and the profile of the first computing device, a determination is made as to whether the software application upgrade is likely to cause a failure in a software or hardware element currently present on the first computing device.Additionally, a risk-based recommendation based on the determination as to whether to install the software upgrade on the first computing device is presented to an end user of the first computing device.

[0011] According to one embodiment, the program instructions for the computer server further include receiving a weighting value and associating the weighting value with the software application, wherein the recommendation of whether to install the software upgrade on the first computing device is further based on the weighting value of the software application.

[0012] The techniques described herein may be implemented in a number of ways. An example implementation is shown below with reference to the following figure. [Brief explanation of the drawings]

[0013] The drawings are of exemplary embodiments. The drawings do not depict every embodiment. Other embodiments may be used in addition or instead. Details that may be obvious or unnecessary may be omitted to save space or for a more effective illustration. Some embodiments may be practiced with additional components or steps, or without all of the components or steps shown, or both. When the same numeral appears in different drawings, it refers to the same or similar components or steps.

[0014] [Figure 1] FIG. 1 is a block diagram of an architecture for software upgrade stability recommendation and scheduling, according to one embodiment. [Figure 2] 1 is a block diagram of a system for determining software upgrade stability recommendations, according to some embodiments. [Figure 3]1 is a flow diagram of a method for identifying stability consequences and sources of instability of a software upgrade to a computing device, according to one embodiment. [Figure 4] 1 is a flow diagram of a method for assessing the risk impact of a software upgrade on a computing device, according to one embodiment. [Figure 5] FIG. 1 is a functional block diagram of a computer hardware platform capable of communicating with various networked components. [Figure 6] FIG. 1 illustrates a cloud computing environment consistent with exemplary embodiments. [Figure 7] FIG. 1 illustrates abstraction model layers consistent with an exemplary embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0015] [overview] In the following detailed description, by way of example, numerous specific details are set forth in order to provide a thorough understanding of the relevant teachings. However, it will be apparent that the present teachings may be practiced without such details. In other instances, well-known methods, procedures, components, or circuits, or combinations thereof, have been described in relatively broad terms and without detail in order to avoid unnecessarily obscuring aspects of the present teachings.

[0016] The present disclosure generally relates to systems and methods for assessing the risk of success of a system software upgrade and its impact on system stability using insights gleaned from observed conditions and experience from a collection of similar devices. Generally, embodiments may be practiced in the field of computers and computer networks.

[0017] In the following disclosure, embodiments propose a software upgrade assistant system and process that leverages insights generated by analyzing the current environment of end-user systems (e.g., company employees) with combinations of hardware components and various versions of software. Embodiments may include a knowledge base of other systems with various combinations of hardware components and various versions of software. The technology can analyze the history of successful and failed software upgrades and the stability of other systems that have undergone the same software upgrade to advise against problematic upgrades in terms of target versions or expected package mismatches. Embodiments may analyze the history of stable upgrades identified from collected data and use that analysis to provide confidence score recommendations when a user is notified about a potential upgrade. Aspects of the present disclosure improve the functionality of computing devices by learning which hardware / software factors may conflict with a software upgrade and predicting the likelihood of failure in a computing device when the device installs one or more software upgrades. [Architecture example]

[0018] 1 illustrates an exemplary architecture 100 for software upgrade stability recommendation and scheduling. The architecture 100 includes a network 106 that enables various computing devices 102(1)-102(N) to communicate with each other and with other elements connected to the network 106, such as an update data source 112, an update recommendation server 116, and a cloud 120.

[0019] The network 106 may be, but is not limited to, a local area network ("LAN"), a virtual private network ("VPN"), a cellular network, the Internet, or a combination thereof. For example, the network 106 may include a mobile network communicatively coupled to a private network, sometimes referred to as an intranet, that provides various auxiliary services, such as communication with various application stores, libraries, and the Internet. The network 106 enables the update recommendation engine 110, a software program executing on the update recommendation server 116, to communicate with the update data source 112, the computing devices 102(1)-102(N), and the cloud 120 to provide data processing. The update data source 112 may provide software update data that is processed under one or more techniques described herein. The software update data may include new or upgraded versions of software applications resident in firmware within memory / data storage elements or hardware components of the computing devices. In one embodiment, the data processing is performed at least partially on the cloud 120.

[0020] For purposes of discussion below, several user devices are shown in the figures to represent some example computing devices that may be sources of data analyzed in response to a selected task. Aspects of the symbolic sequence data (e.g., 103(1) and 103(N)) may be communicated over network 106 to update recommendation engine 110 of update recommendation server 116. Today, user devices typically take the form of handset devices, smartphones, tablet computers, personal digital assistants (PDAs), and smart watches, but may also be implemented in other form factors, including consumer and business electronic devices.

[0021] For example, a computing device (e.g., 102(N)) may send a request 103(N) to the update recommendation engine 110 to identify software versions stored on the computing device 102(N).

[0022] While update data source 112 and update recommendation engine 110 are shown by way of example as being on different platforms, it will be appreciated that in various embodiments, update data source 112 and update recommendation server 116 may be combined. In other embodiments, these computing platforms may be implemented by virtual computing devices in the form of virtual machines or software containers hosted on cloud 120, thereby providing a flexible architecture for processing and storage.

[0023] Reference is now made to FIG. 2, which illustrates an architecture 200 for determining software upgrade stability recommendations and scheduling, according to one embodiment. The architecture 200 may generally include an analyzer module 210 that communicates with one or more computing devices (designated by device A, B, C, ... N). In some embodiments, the software implemented by the underlying method may include a scheduling module (labeled "agent" in the drawings) that resides on the computing device. The scheduling module may be a software module that monitors the current operating state of the hardware and software on the computing device and schedules logging of the current operating state. The scheduling module may communicate with the analyzer module 210 to provide information related to the computing device's current hardware characteristics and currently active software application versions. In some embodiments, the scheduling module may generate a system profile of the computing device. The profile may include, for example, current software packages installed, hardware components installed or connected to the device, installed certificates, power events (e.g., sleep, hibernate, shutdown, and reboot logs), update attempts, successes, or failures logs, stability / instability behavior markers, security compliance, running processes and services, and resource utilization (e.g., memory usage, CPU usage, disk space, inodes, and sockets).

[0024] The scheduling module may periodically take snapshots of the computing device profile. The snapshots may include the current state of libraries, packages, and logged events. The scheduling module may send snapshot reports to the analyzer module 210. Snapshots are symbolically represented by a circle contained within each scheduling module box. In some embodiments, the scheduling module may record a snapshot in response to the occurrence of a software upgrade or some other change in the computing device that triggers a call to the analyzer module 210 to evaluate the current state of the device. For example, snapshots may be captured by the scheduling module immediately before and after the upgrade. After the upgrade, the scheduling module may: Antivirus is running, Wi-Fi® is working, VPN is working, Crashplan is working, The Docker engine is running, Mini-kube is running, etc. Successful benchmark testing may be initiated, which may include validation of the

[0025] The success criteria for the benchmark may be set by the administrator. For example, success may be based on comparing pre-upgrade and post-upgrade snapshots and examining the occurrence of failures for one or more other software applications or hardware operations. The stability of the upgrade may be based on a subsequent period after the upgrade during which the device's software or hardware does not experience any failures. In some embodiments, the user may also specify additional, customized success criteria (which may override those defined by the administrator for the corporate network system). For example, a developer within a company may add an additional command to examine the running of a specific program (such as ssh) required for daily operations. The additional command may be a shell script, a Python script, or an executable program that examines the stability of a specific program and inserts its status into the stability benchmark report.

[0026] As an illustrative example, a snapshot may be determined to indicate one of three states: a stable system, a successful upgrade event, or an unstable system. The recorded time series of snapshots may be stored in the database 240. The snapshot history and their contents may be analyzed by the correlation module 220 to determine the underlying factors that indicated stability or instability in the computing device. The underlying factors may include the behavioral history of software applications and / or attributes associated with the hardware and software elements present on the device. In operation, the analyzer module 210 ingests reports from the scheduling module. For each device, a time series of system states is generated, capturing the state of the computing device system over time, with a focus on maintaining a continuous state of stability or functionality. The time series may be represented and processed as a graph. Snapshots may be represented and processed as a dictionary, such as a key-value pair. The analyzer module 210 may correlate and identify devices with similar configuration states based on the device's configuration, taking into account factors important to the upgrade outcome. The similarity between devices may be based on the hardware devices present, the firmware version used on the hardware, the software applications enabled, the software version in use, and the operating system in use. The analyzer module 210 may generate the following exemplary statistics based on the data captured from the samples: The chances of the upgrade being successful, the likelihood that the system will remain stable, Factors associated with a failed upgrade, and Factors associated with successful upgrades may be provided.

[0027] The statistics of the analyzer module 210 may be used by the scheduling module to communicate recommendations to the user via the recommendation module 230.

[0028] If the upgrade fails, the analyzer module 210 may perform a subsequent analysis to identify likely factors related to the failure and possible remediation courses.

[0029] In block diagram 200, each device illustrates a different scenario that may occur under embodiments of the present disclosure. While four scenarios are shown, it is understood that other scenarios are contemplated. For example, device A illustrates a time series of snapshots showing a stable system, then a successful upgrade, a stable system, and then an unstable system. This scenario may represent a user upgrading their software when they have no known experience with upgrades. If the upgrade is successful, the scheduling module reports the pre-upgrade and post-upgrade conditions. The scheduling module also monitors the continued functionality of the system based on acceptance criteria stored in the knowledge base as indicators of stability.

[0030] Device B showed a stable system snapshot, then successive snapshots of an unstable system profile, and then a successful upgrade. It's possible that the user upgraded their software when they had no known experience with upgrades. The software upgrade resulted in a failure, causing further system instability (e.g., Wi-Fi stopping working, application crashes). The scheduling module may report the pre-upgrade and post-upgrade conditions, and such metadata may be processed in the remote stability analyzer module 210 to identify correlations that may point to the cause.

[0031] Device C showed three consecutive snapshots of a stable system, followed by a snapshot of an unstable system. It's possible that the user attempted to upgrade their software when they had known experience with upgrades. The scheduling module could report the probability of success or failure based on their known experience and potentially warn against the upgrade in the first place.

[0032] Device N showed a stable system, a successful upgrade profile, and continued stability in the next two snapshots. The user may have attempted to upgrade their software when the scheduling module reported a low likelihood of success due to previous negative experiences. The attempt is successful! The scheduling module reports the results to the analyzer module 210, and the empirical data is modified so that potential false positives are identified. The user may also have attempted preventative steps (e.g., installing or removing packages, reconfiguring). The preventative actions may be recorded by the scheduling module as it captures the pre-upgrade and post-upgrade states. The preventative steps may be integrated into the recording of the empirical data. [Example of methodology]

[0033] Referring now to FIG. 3, a method 300 for identifying stability consequences and causes of instability of a software upgrade on a computing device is shown, according to an example embodiment. Method 300 may be triggered in response to one or more computing devices registering an attempt 310 to upgrade a software application. Method 300 may determine whether the upgrade attempt was successful (320). A failed attempt may be flagged as a failed upgrade attempt (325). In the case of a successfully installed upgrade, the method may monitor the stability of the computing device (or multiple devices, in the case of a multi-device upgrade) (330). The monitoring step 330 may occur at an interval after the upgrade is installed, which interval may be end-user or administrator-configurable in some embodiments. Stability may be based on the end device operating without interruption. For example, computing device instability registering a failure flag may be based on software other than the upgraded application experiencing a failure (e.g., a crash) or hardware experiencing a failure within the same computing device on which the software upgrade was installed. The failure event may be logged (340). Method 300 may analyze (350) which attributes within the computing device's environment may have contributed to the failure. Attributes may include software upgrades, conflicts with other software applications within the computing device, and hardware that does not respond as expected to the upgraded software. In some embodiments, stability benchmark attributes may be categorized into three major groups that, in their simplest form, have binary (true / false) values. Stability criteria may also include numeric or string values ​​with thresholds or sets of allowed values.

[0034] 1. Basic stability attributes across the enterprise: WLAN is working, VPN is working, certificates are installed, system crashes exceed thresholds over a time frame, email is working, etc.

[0035] 2. Stability attributes based on user / employee job role: Customer support needs access to the support ticket system, developers need access to Git repositories, cloud platform dashboards, etc.

[0036] 3. Employee-defined custom attributes: Developers may define additional success criteria, such as specific applications on their machines, such as the graphical Git client or Microsoft® Office® programs, working after the upgrade. These employee-defined success criteria may then be automatically recommended to other employees with similar job responsibilities.

[0037] The failure criteria for each attribute can be a Boolean value (false), a number below a threshold (1, threshold: 3), or an acceptable string value ("required": "1.0.1", "found": "0.11.0").

[0038] A successful upgrade may be logged 360. Attributes associated with the successful upgrade may be identified 370.

[0039] In an exemplary embodiment, method 300 can compare attributes associated with a failed upgrade attempt with attributes associated with a successful upgrade attempt and analyze (380) the differences in the attributes to identify causes of success and failure. The results of the analysis can be used to predict the likelihood of success or upgrade on other computing devices that will be upgrading the same software application. Method 300 can also include generating (390) a recommendation for installing a software upgrade on the computing device based on the results of the analysis of the differences. In some embodiments, a user of a computing device presented with a choice to install a software upgrade may be presented with a recommendation based on the same software upgrade version installed on another computing device with a similar profile. For example, if a computing device has one or more software applications (Software A and Software B) and the software applications conflict with an upgrade of a different software application (Software C) on a different computing device that also has Software A and Software B, the recommendation may present a risk level associated with installing the software upgrade. There may also be other underlying factors in the device's profile that could increase or decrease the risk level.

[0040] Referring now to FIG. 4, a method for assessing the risk impact of software upgrades on a computing device is illustrated, according to an example embodiment. Method 400 generally includes assessing the current operating state of the computing device. The method may begin by identifying (410) the device's current stability period. An update recommendation engine may periodically analyze (420) the computing device's current profile. Current software applications (and their latest versions) resident on the computing device may be identified (430). Some embodiments may receive, from an end user of the computing device, a weighting value that prioritizes the importance of software applications on the device. The update recommendation engine may identify (440) a weight to assign to the software being analyzed.

[0041] In some embodiments, a system administrator may assign weight values ​​to software used on computing devices in the network. The update recommendation engine may determine the weight value assigned by the administrator for each software application (450). In assessing the risk associated with a software upgrade, the update recommendation engine may identify computing devices in the network that have the same software upgrade installed (460). Device profiles of identified computing devices with the same upgrade may be obtained (470). In some embodiments, warning messages logged by the identified devices may be obtained (480). Some embodiments may include obtaining error messages logged by the identified devices (490). The device profiles, warning messages, and / or error messages may be used to determine the likelihood that the software upgrade will affect another computing device. For example, a history of warning and error messages associated with the software upgrade being analyzed on other computing devices (which may be more prevalent on devices with similar configurations to the computing device being analyzed) may indicate a higher probability that installing the software upgrade will cause failure or instability. Embodiments may include identifying an upgrade profile for the computing device that may be upgrading the software application being analyzed for impact on the computing device (495). [Examples of criteria for identifying instability or risk]

[0042] With continued reference to Figure 4, the following draft formulation briefly demonstrates how upgrade recommendations may be generated according to an exemplary embodiment. Assume the following: t time is the required stabilization time, a profile of a particular device, describing the hardware and software components on the device, their versions, and upgrade and installation history data; S={s1,s2,..sn} is the software products or applications that are important to the user and their current version numbers. W={w1,w2,..wn} is the corresponding weight of the priority set by the user for each software application, A={A1,A2,..An} is the corresponding weight set by the corporate network administrator for each software application in the network. Given a specific intended upgrade action U(s) for software s, the recommendation module (see Figure 2) considers the following data set: Device profiles for devices that have undergone the same upgrade U to find devices similar to the target device; For all devices with similar profiles, warning messages logged since the same upgrade was run on another device; Similarly, error messages Analysis may be performed on

[0043] The recommendation module as a function f(t, S, W, A, U(s)) generates recommendations (R, R') for the analyzed historical data, with values ​​indicating the recommendation of an upgrade U(s) by increasing magnitude, for example, using a weighted arithmetic mean for a given software product or application. The recommendation module may generate an upgrade profile, which may be a tuple (R, R').

[0044] R is the final recommendation value indicating the magnitude of the upgrade recommendation. For example, 1.0 can be an absolute recommendation to apply upgrade U(s), and 0.0 can be an absolute recommendation to the opposite.

[0045] R'={r1,r2,..rn} is the scoring of the recommendation units, and r corresponding to software s is a measure of the predicted stability of software s after applying upgrade U(s).

[0046] For example, consider a device with a pending software update, where S = {Software A version 1089, Software B} is the set of only two software products on the device. If you request a prediction for applying upgrade U (Software A version 1099) and assume W = A = {1.0, 1.0}, and both the user and the company administrator assign equal weights to the two software products, the results might be R = 0.9 and R' = {1.0, 0.8}.

[0047] The R' result shows that the recommender measured perfect stability for software A and less perfect stability for software B after upgrading to version 1099. In this case, a weighted average of 0.9 was assigned to the final recommendation R, but it is up to the user to determine if this is good enough. Further queries to the recommender module may reveal how long previous devices on the same upgrade path were stable (must have met threshold t), and how many similar devices were considered for the data used in the recommendation. [Example of a computer platform]

[0048] As described above, the functionality associated with interpretable modeling of the present disclosure may be performed using one or more computing devices connected for data communication via wireless or wired communication, as shown in Figure 1. Figure 5 is a functional block diagram of a computer hardware platform capable of communicating with various networked components, such as training input data sources, the cloud, etc. Specifically, Figure 5 illustrates a network or host computer platform 500 that may be used to implement a server, such as update recommendation server 116 of Figure 1.

[0049] The computer platform 500 may include a central processing unit (CPU) 504, a hard disk drive (HDD) 506, a random access memory (RAM) and / or read-only memory (ROM) 508, a keyboard 510, a mouse 512, a display 514, and a communication interface 516 connected to a system bus 502.

[0050] In one embodiment, HDD 506 has functionality that includes storing programs capable of executing various processes, such as update recommendation engine 540, in the manner described herein. Generally, update recommendation engine 540 may be configured to analyze a computing device for predicted stability after a software upgrade under the above-described embodiments. Update recommendation engine 540 may have various modules configured to perform different functions. In some embodiments, update recommendation engine 540 may include sub-modules, such as device profile analyzer 542, warning message log analyzer 544, error message log analyzer 546, and weighting value module 548.

[0051] In one embodiment, HDD 506 may store executable applications including one or more library software modules, such as those for a Java® Runtime Environment program for implementing a JVM (Java® Virtual Machine).

[0052] In another embodiment, computer platform 500 may represent an end-user computer (e.g., computing devices 102(1)-102(N)). In this context, various end-user computer platforms 500 may include mixed configurations of hardware elements and software packages. As will be appreciated, aspects of the present disclosure analyze variations in the hardware / software elements present on each computer platform 500 for their contribution to compatibility with software upgrades. Thus, a software upgrade on one computer platform 500 may be stable when considering the software versions and hardware of the applications present. Yet another computer platform 500 may include hardware or software elements not accounted for by the software upgrade. As a result, the operation of one or more computer platform elements may become unstable or fail. [Cloud Platform Example]

[0053] As noted above, functionality associated with analyzing the impact of software upgrades on computing devices may include cloud 120 (see FIG. 1). While this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings described herein is not limited to a cloud computing environment. Rather, embodiments of the present disclosure may be implemented in conjunction with any other type of computing environment not currently known or later developed.

[0054] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with a service provider. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0055] The features are as follows:

[0056] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time and network storage, automatically as needed, without the need for human interaction with the service provider.

[0057] Broad network access: Functionality is available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0058] Resource Pooling: Provider computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated according to demand. There is location independence in that consumers generally have no control or knowledge over the exact location of the resources provided, but may specify a location at a higher level of abstraction (e.g., country, state, or data center).

[0059] Rapid Flexibility: Capabilities can be rapidly and flexibly, sometimes automatically, provisioned to quickly scale out and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear unlimited and can be purchased at any time and in any quantity.

[0060] Service Metering: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a certain level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of the services they utilize.

[0061] The service model is as follows:

[0062] Software as a Service (SaaS): The functionality offered to the consumer is the use of the provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). With the expected exception of limited user-specific application configuration settings, the consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application features.

[0063] Platform as a Service (PaaS): The capability offered to the consumer is the deployment on a cloud infrastructure of consumer-generated or acquired applications created using programming languages ​​and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does control the deployed applications and, in some cases, the environment configuration that hosts the applications.

[0064] Infrastructure as a Service (IaaS): The capability offered to consumers is to provision processing, storage, network, and other basic computing resources on which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does control the operating systems, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0065] The deployment model is as follows:

[0066] Private Cloud: Cloud infrastructure is operated exclusively for an organization. This cloud infrastructure may be managed by the organization or a third party and may exist on-premise or off-premise.

[0067] Community Cloud: Cloud infrastructure is shared among multiple organizations to support a specific community of shared interests (e.g., mission, security requirements, policies, and compliance considerations). This cloud infrastructure may be managed by the organization or a third party and may exist on-premises or off-premises.

[0068] Public Cloud: Cloud infrastructure is made available to the general public or large industry groups and is owned by organizations that sell cloud services.

[0069] Hybrid Cloud: A cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are tied together by standardized or proprietary technologies that allow for data and application portability (e.g., cloud bursting for load balancing between clouds).

[0070] Cloud computing environments are service-oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0071] Referring now to FIG. 6, an exemplary cloud computing environment 600 is shown. As shown, the cloud computing environment 600 includes one or more cloud computing nodes 610 with which local computing devices used by cloud consumers, such as, for example, a personal digital assistant (PDA) or mobile phone 654A, a desktop computer 654B, a laptop computer 654C, or an automobile computer system 654N, or combinations thereof, can communicate. The nodes 610 may also communicate with each other. The nodes 610 may be physically or virtually grouped in one or more networks (not shown), such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or combinations thereof, as described herein above. This enables the cloud computing environment 650 to provide infrastructure, platform, and / or software as a service without requiring cloud consumers to maintain resources on their local computing devices. It will be understood that the types of computing devices 654A-654N shown in FIG. 6 are intended to be illustrative only, and that computing node 610 and cloud computing environment 650 can communicate with any type of computerized device over any type of network and / or network-addressable connection (e.g., using a web browser).

[0072] Referring now to Figure 7, a set of functional abstraction layers provided by cloud computing environment 650 (Figure 6) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 7 are intended to be illustrative only, and embodiments of the present disclosure are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0073] Hardware and software layer 760 includes hardware and software components. Examples of hardware components include mainframes 761, RISC (reduced instruction set computer) architecture-based servers 762, servers 763, blade servers 764, storage devices 765, and networks and networking components 766. In some embodiments, software components include network application server software 767 and database software 768.

[0074] The virtualization layer 770 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 771, virtual storage 772, virtual networks including virtual private networks 773, virtual applications and operating systems 774, and virtual clients 775.

[0075] In one example, the management layer 780 may provide the following functions: Resource provisioning 781 provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 782 provides cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal 783 provides consumers and system administrators with access to the cloud computing environment. Service level management 784 provides allocation and management of cloud computing resources to ensure requested service levels are met. Service level agreement (SLA) planning and fulfillment 785 provides pre-allocation and procurement of cloud computing resources anticipated to be required in the future according to SLAs.

[0076] Workload tier 790 provides examples of functions for which a cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this tier include mapping and navigation 791, software development and lifecycle management 792, virtual classroom instruction delivery 793, data analytics processing 794, transaction processing 795, and software recommendation services 796 as described herein. [Conclusion]

[0077] The description of various embodiments of the present teachings has been presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications, or technical improvements beyond those found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0078] While the above describes what is believed to be the best mode and / or other examples, it is understood that various modifications can be made therein, that the subject matter disclosed herein can be embodied in various forms and examples, and that the teachings can be applied to many applications, only some of which are described herein. It is intended that the following claims claim all such applications, modifications, and variations that are within the true scope of the present teachings.

[0079] The components, steps, features, objects, benefits, and advantages described herein are merely exemplary. None of them, nor the descriptions associated therewith, are intended to limit the scope of protection. While various advantages have been described herein, it will be understood that not all embodiments necessarily include all advantages. Unless otherwise specified, all measurements, values, ratings, positions, dimensions, sizes, and other specifications described herein, including the following claims, are approximate and not exact. They are intended to have a reasonable range consistent with the functions to which they pertain and that which is customary in the art to which they pertain.

[0080] Many other embodiments are also contemplated, including those having fewer, additional, or different or combinations of components, steps, features, objects, benefits, and advantages, including those in which the components and / or steps are configured and / or ordered differently.

[0081] Aspects of the present disclosure are described herein with reference to call flow diagrams and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It will be understood that each step in the flow diagrams and / or block diagrams, and combinations of blocks in the call flow diagrams and / or block diagrams, can be implemented by computer-readable program instructions.

[0082] These computer-readable program instructions may be provided to a processor of a computer, special purpose computer, or other programmable data processing apparatus to create a machine, such that the instructions, when executed by the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the call flow processes and / or block diagrams.The computer-readable program instructions may also be stored on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the call flow diagrams and / or block diagrams.

[0083] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device, such that the instructions, which execute on the computer, other programmable apparatus, or other device, perform the functions / acts specified in one or more blocks of the call flow process and / or block diagram, to create a computer-implemented process.

[0084] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block of a call flow process or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may even be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or call flow diagrams, and combinations of blocks in the block diagrams and / or call flow diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or a combination of dedicated hardware and computer instructions.

[0085] While the foregoing has been described in conjunction with exemplary embodiments, it is understood that the term "exemplary" is intended to mean merely an example, not best or optimal. Except as noted immediately above, nothing described or illustrated is intended to, and should be construed as, providing the public with any component, step, feature, object, benefit, advantage, or equivalent, whether claimed or not.

[0086] It will be understood that the terms and expressions used herein have the ordinary meanings ascribed to such terms and expressions with respect to their respective fields of study and research, unless a specific meaning is otherwise stated herein. Relative terms such as first and second may be used solely to distinguish one entity or action from another, without necessarily requiring or implying an actual relationship or order between the entities or actions. The terms "comprises," "comprising," or other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements does not include only those elements, but may include other elements not inherent in or explicitly listed within such process, method, article, or apparatus. An element preceded by "a" or "an" does not, in the absence of further constraints, exclude the presence of additional identical elements in a process, method, article, or apparatus that includes that element.

[0087] An Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. It can also be seen that in the foregoing Detailed Description, various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Accordingly, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as separately claimed subject matter.

Claims

1. 1. A computer-implemented method for determining the potential impact of a software upgrade on a computing device, comprising: the computer recording a profile of software and hardware elements currently present on each computing device in a network including a plurality of computing devices; receiving, by the computer, a query for a software application upgrade for a software application resident on a first computing device; the computer identifying a device configuration of the first computing device based on the software and hardware elements currently present on the first computing device; the computer identifying other computing devices in the network that have installed the software application upgrade; the computer obtaining a history of operational behavior associated with the software application upgrade on the identified other computing devices; said computer obtaining said profile of each of said other computing devices; the computer analyzing the profile of each of the other computing devices for hardware or software conflicts with the software application; determining, by the computer, whether the software application upgrade is likely to cause a failure in the software or hardware elements currently present on the first computing device based on the history of the operational behavior associated with the software application upgrade on the identified other computing devices and based on a state of similarity between the analyzed profile of each of the other computing devices and the profile of the first computing device; and presenting, to an end user of the first computing device, a risk-based recommendation based on the determination as to whether to install the software upgrade on the first computing device. A method comprising:

2. A method of implementing a system, comprising: the computer identifying a second computing device, the second computing device exhibiting a stable operating configuration; and the computer identifying attributes related to failure events associated with the software upgrade at each of the other computing devices; analyzing, by the computer, differences between a configuration of the second computing device and a configuration of each of the other computing devices involved in a failure event associated with the software upgrade; the computer identifying the differences between the configuration of the second computing device and the configuration of each of the other computing devices, the risk-based recommendation being based on the identified configuration differences; The method of claim 1 further comprising:

3. 3. The method of claim 2, wherein the identified attributes include content of the installed software application upgrade, conflicts with other software applications in each of the other computing devices, and hardware in each of the other computing devices that does not respond as expected to the software-upgraded software application.

4. The method of claim 1, further comprising a step in which the computer records the profile on the first computing device immediately before or immediately after installing the software application upgrade on the first computing device.

5. The method of claim 1, further comprising: receiving, by said computer, weighted values ​​from said end users; said computer associating said weighting value with said software application; Furthermore, the recommendation of whether to install the software upgrade on the first computing device is further based on the weighted value of the software application. The method of claim 1.

6. The method of claim 1, further comprising: receiving weighting values ​​from a system administrator; said computer associating said weighting value with said software application; Furthermore, the recommendation of whether to install the software upgrade on the first computing device is further based on the weighted value of the software application. The method of claim 1.

7. The method of claim 6, wherein said computer logs error messages and / or warning messages from said other computing devices on which said software application upgrade has been installed. Furthermore, the determination of whether the software application upgrade is likely to cause a failure in the software or hardware elements currently present on the first computing device is based on a history of the logged error messages and / or warning messages from the other computing devices in the network that have installed the software application upgrade; The method of claim 1.

8. 1. A computer program for determining the potential impact of a software upgrade on a computing device, said computer program comprising: comprising program instructions; The program instructions: In a network including a plurality of computing devices, recording a profile of software and hardware elements currently present on each computing device; receiving a query for a software application upgrade for a software application resident on a first computing device; identifying a device configuration of the first computing device based on the software and hardware elements currently present on the first computing device; identifying other computing devices in the network that have installed the software application upgrade; obtaining a history of operational behavior associated with the software application upgrade on the identified other computing devices; obtaining the profile of each of the other computing devices; analyzing the profile of each of the other computing devices for hardware or software conflicts with the software application; determining whether the software application upgrade is likely to cause a failure in the software or hardware elements currently present on the first computing device based on the history of the operational behavior associated with the software application upgrade on the identified other computing devices and based on a state of similarity between the analyzed profile of each of the other computing devices and the profile of the first computing device; presenting a risk-based recommendation to an end user of the first computing device regarding whether to install the software upgrade on the first computing device based on the determination; and Including, Computer program.

9. The program instructions: identifying a second computing device, the second computing device exhibiting a stable operating configuration; identifying attributes related to failure events associated with the software upgrade at each of the other computing devices; analyzing differences between a configuration of the second computing device and the configuration of each of the other computing devices involved in a failure event associated with the software upgrade; identifying the differences between the configuration of the second computing device and the configuration of each of the other computing devices, wherein the risk-based recommendation is based on the identified configuration differences; 9. The computer program of claim 8, further comprising:

10. 10. The computer program product of claim 9, wherein the identified attributes include content of the installed software application upgrade, conflicts with other software applications in each of the other computing devices, and hardware in each of the other computing devices that does not respond as expected to the software-upgraded software application.

11. 11. The computer program product of claim 8, wherein the program instructions further comprise recording the profile on the first computing device immediately before or immediately after installing the software application upgrade on the first computing device.

12. The program instructions: receiving a weighting value from the end user; associating said weighting value with said software application; further comprising the recommendation of whether to install the software upgrade on the first computing device is further based on the weighted value of the software application. A computer program according to any one of claims 8 to 11.

13. The program instructions: receiving weighting values ​​from a system administrator; associating said weighting value with said software application; further comprising the recommendation of whether to install the software upgrade on the first computing device is further based on the weighted value of the software application. A computer program according to any one of claims 8 to 12.

14. The program instructions: Logging error and / or warning messages from the other computing devices on which the software application upgrade is installed. further comprising the determination of whether the software application upgrade is likely to cause a failure in the software or hardware elements currently present on the first computing device is based on a history of the logged error messages and / or warning messages from the other computing devices in the network that have installed the software application upgrade; A computer program according to any one of claims 8 to 13.

15. an update recommendation computer server, Network connection and one or more computer-readable storage media; a processor coupled to the network connection and coupled to the one or more computer readable storage media; a computer program product including program instructions collectively stored on said one or more computer-readable storage media; Equipped with The program instructions: In a network including a plurality of computing devices, recording a profile of software and hardware elements currently present on each computing device; receiving a query for a software application upgrade for a software application resident on a first computing device; identifying a device configuration of the first computing device based on the software and hardware elements currently present on the first computing device; identifying other computing devices in the network that have installed the software application upgrade; obtaining a history of operational behavior associated with the software application upgrade on the identified other computing devices; obtaining the profile of each of the other computing devices; analyzing the profile of each of the other computing devices for hardware or software conflicts with the software application; determining whether the software application upgrade is likely to cause a failure in the software or hardware elements currently present on the first computing device based on the history of the operational behavior associated with the software application upgrade on the identified other computing devices and based on a state of similarity between the analyzed profile of each of the other computing devices and the profile of the first computing device; presenting a risk-based recommendation to an end user of the first computing device based on the determination as to whether to install the software application upgrade on the first computing device; and Including, Computer server.

16. The program instructions: identifying a second computing device, the second computing device exhibiting a stable operating configuration; identifying attributes related to failure events associated with the software application upgrade on each of the other computing devices; analyzing differences between a configuration of the second computing device and the configuration of each of the other computing devices involved in a failure event associated with the software application upgrade; identifying the differences between the configuration of the second computing device and the configuration of each of the other computing devices, wherein the risk-based recommendation is based on the identified configuration differences; 16. The computer server of claim 15, further comprising:

17. The program instructions: recording the profile on the first computing device immediately before or immediately after installing the software application upgrade on the first computing device; 17. The computer server of claim 15 or 16, further comprising:

18. The program instructions: receiving a weighting value from the end user; associating said weighting value with said software application; further comprising the recommendation of whether to install the software application upgrade on the first computing device is further based on the weighted value of the software application.

18. A computer server according to any one of claims 15 to 17.

19. The program instructions: receiving weighting values ​​from a system administrator; associating said weighting value with said software application; further comprising the recommendation of whether to install the software application upgrade on the first computing device is further based on the weighted value of the software application.

19. A computer server according to any one of claims 15 to 18.

20. The program instructions: Logging error and / or warning messages from the other computing devices on which the software application upgrade is installed. further comprising the determination of whether the software application upgrade is likely to cause a failure in the software or hardware elements currently present on the first computing device is based on a history of the logged error messages and / or warning messages from the other computing devices in the network that have installed the software application upgrade; 20. A computer server according to any one of claims 15 to 19.

Images