Determining the impact of a component failure on one or more services

• US 7,509,518 B2
• Filed: 12/16/2004
• Issued: 03/24/2009
• Est. Priority Date: 12/16/2003
• Status: Expired due to Fees

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Bailey, Daniel, Tinsley, Andrew, Perks, Maurice James, Tongue, Melissa Jane, Noble, Gary Paul, Newton, Charlotte
• Primary Examiner(s): Mofiz; Apu M
• Assistant Examiner(s): Le; Hung D
• Application Number:
  US11/014,310
• Publication Number:
  US 20050144188A1
• Time in Patent Office: 1,559 Days
• Field of Search: None
• US Class Current: 714/1
• CPC Class Codes: G06F 11/008 Reliability or availability analysis
• CPC Class Codes: G06Q 10/0639 Performance analysis of employees; Performance analysis of enterprise or organisation operations
• CPC Class Codes: H04L 41/046 comprising network management agents or mobile agents therefor
• CPC Class Codes: H04L 41/0681 Configuration of triggering conditions
• CPC Class Codes: H04L 41/0853 by actively collecting configuration information or by backing up configuration information
• CPC Class Codes: H04L 41/22 comprising specially adapted graphical user interfaces [GUI]
• CPC Class Codes: H04L 41/5003 Managing SLA; Interaction between SLA and QoS
• CPC Class Codes: H04L 41/5016 based on statistics of service availability, e.g. in percentage or over a given time
• CPC Class Codes: H04L 41/5061 characterised by the interaction between service providers and their network customers, e.g. customer relationship management
• CPC Class Codes: H04L 43/0817 by checking functioning
• CPC Class Codes: H04L 43/091 Measuring contribution of individual network components to actual service level
• CPC Class Codes: Y10S 707/99942 Manipulating data structure, e.g. compression, compaction, compilation
• CPC Class Codes: Y10S 707/99953 Recoverability

Abstract

The invention provides a method for determining the impact of a failure of a component on one or more services that the component is supporting. The method receiving a data feed from a processing node, the data feed containing data indicative of the identity and system status of a component running on the processing node; in response to the identity of the component, first determining if the component supports one or more services; identifying the temporal activity of the one or more services and, in dependence on the determining step, second determining the impact of the system status on the one or more services.

Claims

1. A method for determining the impact of a failure of a component for one or more services that the component is supporting, the method comprising the steps of:

receiving a data feed from a processing node, the data feed comprising data indicative of an identity and system status of a component running on the processing node, wherein the system status of the component identifies whether the component has failed or is active, wherein the system status of the component identifies that the component has failed at a failure time, and wherein the method further comprises identifying the failed component in a table consisting of 3 rows and 3 columns, wherein the three rows consist of a first row, a second row, and a third row, wherein the 3 columns consist of a first column, a second column, and a third column, wherein all data in the 3 rows and the 3 columns pertain to the failure time, wherein the first column identifies components that have failed, wherein the second column identifies components impacted by the failed components in the first column, wherein the third column identifies components that are running but may be subsequently impacted by the failed components in the first column, wherein the first row identifies components that must run, wherein the second row identifies components that should run, wherein the third row identifies components that are not needed, wherein the failed component whose system status has been identified is listed in a cell of the table defined by the first column and a pertinent row selected from the group consisting of the first row and the second row, wherein an impacted component that is impacted by the failed component is listed in a cell of the table defined by the second column and the pertinent row, and wherein a running component that is running at the failure time and may be subsequently impacted by the failed component is listed in a cell of the table defined by the third column and the pertinent row;

mapping the one or more services into a calendar function;

first determining that the component supports the one or more services, wherein said first determining further comprises performing a lookup in the calendar function to identify a temporal activity and a level of criticality of each service of the one or more services, and wherein the temporal activity identified by the calendar function comprises for each service of the one or more services;

(1) minutes of each day of each week of each year that each service should run or must run, and (2) a level of criticality associated with each service with respect to the minutes of each day of each week of each year that each service should run or must run;

after said first determining, second determining an impact of the system status of the component on the one or more services from analysis of the identified temporal activity and the identified level of criticality of the one or more services determined from said performing the lookup in the calendar function.

2. The method of claim 1, wherein the calendar function is represented in a table.

3. The method of claim 2, wherein the level of criticality of each service is color coded such that each different level of criticality is displayed in the table as a different color.

4. The method of claim 1, wherein said first determining has determined that the component supports a first service of the one or more services, wherein the data in the received data feed indicates that the component has the system status of having failed at a first time, wherein said second determining has determined from the identified temporal activity and the identified level of criticality of the first service that the system status of the component having failed at the first time does not affect the first service between the first time and a second time that is later than the first time and that the level of criticality of the first service at the second time is a critical level, and wherein the method further comprises:

displaying a first color between the first time and the second time until the second time is approached, said first color being indicative of the first service not being affected by the system status of the component having failed; and

displaying a second color differing from the first color when the second time is approached, said second color being indicative of the first service having the level of criticality at the critical level and thus being affected at the critical level by the system status of the component having failed.

5. The method of claim 1, wherein said first determining has determined that the component supports a first service of the one or more services, wherein the data in the received data feed indicates that the component has the system status of having failed, wherein the impact on the first service due to the component having the system status of having failed results in a first impact on a first company and a second impact on a second company, and wherein the second impact differs from the first impact.

6. The method of claim 1, wherein a first service of the one or more services mapped into the calendar function is identified by the calendar function as comprising a first level of criticality during first identified minutes of each day of each week of each year, wherein a second service of the one or more services mapped into the calendar function is identified by the calendar function as comprising a second level of criticality during second identified minutes of each day of each week of each year, wherein the first level of criticality and the second level of criticality are different levels of criticality, and wherein the first identified minutes and the second identified minutes are not identical to each other.

7. The method of claim 6, wherein a third service of the one or more services mapped into the calendar function is identified by the calendar function as comprising the first level of criticality during third identified minutes of each day of each week of each year, wherein a fourth service of the one or more services mapped into the calendar function is identified by the calendar function as comprising the second level of criticality during fourth identified minutes of each day of each week of each year, and wherein the first identified minutes, the second identified minutes, the third identified minutes, and the fourth identified minutes are not identical to one another.

8. A method for determining the impact of a failure of a component for one or more services that the component is supporting, the method comprising the steps of:

receiving a data feed from a processing node, the data feed containing data indicative of the identity and system status of a component running on the processing node, wherein the system status of the component identifies that the component has failed at a failure time, and wherein the method further comprises identifying the failed component in a table consisting of 3 rows and 3 columns, wherein the three rows consist of a first row, a second row, and a third row, wherein the 3 columns consist of a first column, a second column, and a third column, wherein all data in the 3 rows and the 3 columns pertain to the failure time, wherein the first column identifies components that have failed, wherein the second column identifies components impacted by the failed components in the first column, wherein the third column identifies components that are running but may be subsequently impacted by the failed components in the first column, wherein the first row identifies components that must run, wherein the second row identifies components that should run, wherein the third row identifies components that are not needed, wherein the failed component whose system status has been identified is listed in a cell of the table defined by the first column and a pertinent row selected from the group consisting of the first row and the second row, wherein an impacted component that is impacted by the failed component is listed in a cell of the table defined by the second column and the pertinent row, and wherein a running component that is running at the failure time and may be subsequently impacted by the failed component is listed in a cell of the table defined by the third column and the pertinent row; and

in response to the identity of the component, first determining if the component supports one or more services and if so,

identifying the temporal activity of the one or more services and, in dependence on the first determining step, second determining the impact of the system status on the one or more services, wherein the system status of a component identifies whether the component has failed or is active, and wherein in response to identifying that a component has failed, determining the length of time that it will take to rectify the fault and the time in which the component must start to be recovered in order support a scheduled service.

9. A method as claimed in claim 8, wherein the result of the second determining step produces a list of results identifying each component that has failed and the time period in which each failed component must be recovered.