Abstract: A system and method for controlling deployment of one or more changes to one or more applications of a computer system based upon an application reliability analysis. The system collects information related to one or more applications deployed on a system which require changes from one or more resources; generates a change risk score for each application based at least in part on a weighted average of one or more parameters affecting system quality, a weighted average of one or more parameters affecting system performance, and a weighted average of one or more parameters affecting system stability, and determines whether to perform an automated deployment process or prevent the deployment of application changes for each application.

Abstract: A method and system of managing incidents in a system by employing preemptive incident prevention and self-healing processing. The method detects potential incidents and actual incidents in the system and performs self-healing prevention actions for any detected potential incidents and performs self-healing actions for any detected or notified incidents. The system performs an automated root cause analysis for event notifications related to an incident.

Abstract: A technique, comprising: identifying, at a node forming part of a group of nodes operating a distributed ledger comprising a block chain, a decision to retrospectively change a first smart contract prescribing one or more changes in the ledger already recorded in one or more existing blocks of the blockchain; and, without changing any existing blocks of the blockchain, updating the ledger by adding to the current end of the blockchain a new block indicating a new state of the ledger determined by a re-execution of all operations, according to the first smart contract and one or more other smart contracts, recorded in one or more blocks of the blockchain after a block recording an operation of the first smart contract, while taking into account the change to the first smart contract.

Abstract: A system for triage and response to a second system's malfunction is disclosed. The system determines a possible present or future disruption to a service provided by the second system; automatically searches historical records regarding similar disruptions; and provides an interactive, aggregated user interface comprising many tools to display results of the search, log actions already taken, and receive commands from human operators for seamless intervention in cloud-based or on-premises systems. The determination may be based on a statistical anomaly in the performance of the second system, or alternatively may be based on input from a human user, whose communication undergoes text analysis to determine possible matches.

Abstract: A technique, comprising: identifying, at a node forming part of a group of nodes operating a distributed ledger comprising a block chain, a decision to retrospectively change a first smart contract prescribing one or more changes in the ledger already recorded in one or more existing blocks of the blockchain; and, without changing any existing blocks of the blockchain, updating the ledger by adding to the current end of the blockchain a new block indicating a new state of the ledger determined by a re-execution of all operations, according to the first smart contract and one or more other smart contracts, recorded in one or more blocks of the blockchain after a block recording an operation of the first smart contract, while taking into account the change to the first smart contract.

Abstract: In one embodiment, a system for the realization of operational risk in a network includes an interface to receive a change request to update a network application, the network application utilizes a network device. The system may then use a processor communicatively coupled to the interface to generate a change risk score associated with the change request, wherein the change risk score includes a service tier risk score, a time risk score, a day risk score, a security risk score, and a mobile device risk score. The processor may determine whether the change risk score is within a high-risk level, and if so, implement a change counter measure.

Abstract: In one embodiment, a system for the realization of operational risk in a network includes an interface to receive a change request to update a network application, the network application utilizes a network device. The system may then use a processor communicatively coupled to the interface to generate a change risk score associated with the change request, wherein the change risk score includes a service tier risk score, a time risk score, a day risk score, a security risk score, and a mobile device risk score. The processor may determine whether the change risk score is within a high-risk level, and if so, implement a change counter measure.

Abstract: Manufacturing a virtual information handling system (IHS) includes creating a virtual IHS including a component identifier. A boot process is then begun for the virtual IHS. A manufacturing operating system is then retrieved for the virtual IHS using the component identifier. The manufacturing operating system is then installed on the virtual IHS. Manufacturing a virtual IHS may also include determining a common operating system and a common software subset among a plurality of to-be-manufactured virtual IHSs. A first virtual IHS may then be created and the common operating system may be configured on the first virtual IHS. At least a portion of a first virtual IHS software may also be configured on the first virtual IHS. The configuration of the first virtual IHS software on the first virtual IHS is stopped when the common software subset is configured on the first virtual IHS. The first virtual IHS may then be cloned to create a cloned virtual IHS.

Abstract: Manufacturing a virtual information handling system (IHS) includes creating a virtual IHS including a component identifier. A boot process is then begun for the virtual IHS. A manufacturing operating system is then retrieved for the virtual IHS using the component identifier. The manufacturing operating system is then installed on the virtual IHS. Manufacturing a virtual IHS may also include determining a common operating system and a common software subset among a plurality of to-be-manufactured virtual IHSs. A first virtual IHS may then be created and the common operating system may be configured on the first virtual IHS. At least a portion of a first virtual IHS software may also be configured on the first virtual IHS. The configuration of the first virtual IHS software on the first virtual IHS is stopped when the common software subset is configured on the first virtual IHS. The first virtual IHS may then be cloned to create a cloned virtual IHS.

Abstract: Manufacturing a virtual information handling system (IHS) includes creating a virtual IHS including a component identifier. A boot process is then started for the virtual IHS. A manufacturing operating system is retrieved for the virtual IHS using the component identifier. The manufacturing operating system is installed on the virtual IHS. Manufacturing a virtual IHS may also include determining a common operating system and a common software subset among a plurality of to-be-manufactured virtual IHSs. A first virtual IHS may be created and the common operating system may be configured on the first virtual IHS. At least a portion of a first virtual IHS software may also be configured on the first virtual IHS. The configuration of the first virtual IHS software on the first virtual IHS is stopped when the common software subset is configured on the first virtual IHS. The first virtual IHS may then be cloned to create a cloned virtual IHS.

Abstract: Manufacturing a virtual information handling system (IHS) includes creating a virtual IHS including a component identifier. A boot process is then begun for the virtual IHS. A manufacturing operating system is then retrieved for the virtual IHS using the component identifier. The manufacturing operating system is then installed on the virtual IHS. Manufacturing a virtual IHS may also include determining a common operating system and a common software subset among a plurality of to-be-manufactured virtual IHSs. A first virtual IHS may then be created and the common operating system may be configured on the first virtual IHS. At least a portion of a first virtual IHS software may also be configured on the first virtual IHS. The configuration of the first virtual IHS software on the first virtual IHS is stopped when the common software subset is configured on the first virtual IHS. The first virtual IHS may then be cloned to create a cloned virtual IHS.

Abstract: An orientation maneuver for a bias momentum stabilized spacecraft is carried out on a spacecraft initially spinning about a minimum moment of inertia axis. With the spacecraft spinning about that axis, it is precessed until the angular momentum vector points to the south along the orbit normal. The spin rate is then reduced until the angular momentum remaining in the spacecraft is substantially equal to the nominal angular momentum of the momentum wheel in an in-orbit operation. The momentum wheel is then energized and gradually spun up until it contains its nominal angular momentum. As the wheel accelerates, the angular momentum will be redistributed between the wheel and the body, with the total system angular momentum remaining constant. When the wheel has reached its final speed, the spacecraft will have re-oriented itself such that the body of the spacecraft is spinning about the positive pitch axis, coning about the angular momentum vector in a nutational motion.