Abstract:
A system and associated method for determining an incident of a resource in a computing environment. An event pertaining to the resource is processed by a system automation module. The event is represented as an associated event data having parameters of a target state, a target state prior to the event, a current state, and a current state prior to the event. First, the target state is compared to the target state prior to the event to assure that the target state is steady. Wherein a determination that the event is an incident cannot be made after comparing the target state and the current state, the system automation module compares the current state to the current state prior to the event. Upon determining that the event is an incident, the event data is marked and stored in a repository.

Description:
CROSS REFERENCES TO RELATED INVENTIONS 
       [0001]    This invention is related to U.S. patent application Ser. No. ______ (Attorney Docket No. DE920080075US1) entitled “SYSTEM AND METHOD FOR DETERMINING RECOVERY TIME FOR INTERDEPENDENT RESOURCES IN HETEROGENEOUS COMPUTING ENVIRONMENT”, filed on even date herewith. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The present invention discloses a system and associated method for determining accurate availability parameters of hardware and/or software resources in heterogeneous computing environments. 
       BACKGROUND OF THE INVENTION 
       [0003]    Conventional methods for measuring availability of a computing resource do not provide meaningful distinction between planned and unplanned downtimes. Because the planned downtimes for management purposes and the unplanned downtimes caused by failures affects the availability differently, without a well-defined distinction between planned downtimes and unplanned downtimes, availability measurement is not accurate and has no informative value. 
         [0004]    Thus, there is a need for a system and associated method that overcomes at least one of the preceding disadvantages of current methods and systems of determining availability parameters. 
       SUMMARY OF THE INVENTION 
       [0005]    The present invention provides a method for determining an incident of a resource in a computing environment, the method comprising: 
         [0006]    selecting a target state and a current state of the resource upon detecting an occurrence of an event of at least one event pertaining to the resource, the target state being a state which the resource is planned to be in, the current state being a state which the resource is actually in, wherein an event data of at least one event data is associated with the first event; 
         [0007]    determining that the first event occurred to the resource is incidental and instantiating the first event data accordingly; and 
         [0008]    storing the first event data in a data repository of the computing environment, 
         [0009]    wherein said selecting, said determining, and said storing are performed by a system automation module of the computing environment. 
         [0010]    The present invention provides a computer program product, comprising a computer usable storage medium having a computer readable program code embodied therein, said computer readable program code containing instructions that when executed by a processor of a computer system implement a method for determining an incident of a resource in a computing environment, the method comprising: 
         [0011]    selecting a target state and a current state of the resource upon detecting an occurrence of an event of at least one event pertaining to the resource, the target state being a state which the resource is planned to be in, the current state being a state which the resource is actually in, wherein an event data of at least one event data is associated with the first event; 
         [0012]    determining that the first event occurred to the resource is incidental and instantiating the first event data accordingly; and 
         [0013]    storing the first event data in a data repository of the computing environment, 
         [0014]    wherein said selecting, said determining, and said storing are performed by a system automation module of the computing environment. 
         [0015]    The present invention provides a computer system comprising a processor and a computer readable memory unit coupled to the processor, said memory unit containing instructions that when executed by the processor implement a method for determining an incident of a resource in a computing environment, the method comprising: 
         [0016]    selecting a target state and a current state of the resource upon detecting an occurrence of an event of at least one event pertaining to the resource, the target state being a state which the resource is planned to be in, the current state being a state which the resource is actually in, wherein an event data of at least one event data is associated with the first event; 
         [0017]    determining that the first event occurred to the resource is incidental and instantiating the first event data accordingly; and 
         [0018]    storing the first event data in a data repository of the computing environment, 
         [0019]    wherein said selecting, said determining, and said storing are performed by a system automation module of the computing environment. 
         [0020]    The present invention provides a method and system that overcomes at least one of the current disadvantages of conventional method and system for determining availability parameters of a computing resource. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0021]      FIG. 1  illustrates a system  100  for determining availability parameters of a resource in a heterogeneous computing environment, in accordance with embodiments of the present invention. 
           [0022]      FIG. 2  illustrates lifecycle events of a resource, in accordance with the embodiments of the present invention. 
           [0023]      FIG. 3  illustrates parameters of lifecycle event data of a resource as represented in a Central Data Repository (CDR), in accordance with the embodiments of the present invention. 
           [0024]      FIG. 4  is a flowchart for recording a lifecycle event of a resource in a Central Data Repository (CDR) by a CDR feeder associated with the resource, in accordance with the embodiments of the present invention. 
           [0025]      FIG. 5  is a flowchart for a report generator processing a request for a report on availability parameters of a resource, in accordance with the embodiments of the present invention. 
           [0026]      FIGS. 6A and 6B  illustrate values for the UNPLANNED parameter when the DESIRED_STATE is ONLINE, in accordance with the embodiments of the present invention. 
           [0027]      FIGS. 7A and 7B  illustrate values for the UNPLANNED parameter when the DESIRED_STATE is OFFLINE, in accordance with the embodiments of the present invention. 
           [0028]      FIG. 8  illustrates a first scenario wherein a resource starts up and shuts down as planned, in accordance with the embodiments of the present invention. 
           [0029]      FIG. 9  illustrates a second scenario wherein a resource goes through an unplanned incident, in accordance with the embodiments of the present invention. 
           [0030]      FIG. 10  illustrates a third scenario wherein a database is set up and goes through a failure during service, in accordance with the embodiments of the present invention. 
           [0031]      FIGS. 11A ,  11 B,  11 C,  11 D,  11 E, and  11 F illustrate an example of a report on availability and recovery of a selected resource, in accordance with embodiments of the present invention. 
           [0032]      FIG. 11G  illustrates an example of an availability report on unplanned outages of multiple resources, in accordance with embodiments of the present invention. 
           [0033]      FIG. 12  illustrates a computer system used for determining availability parameters of resource in heterogeneous computing environment, in accordance with embodiments of the present invention. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0034]      FIG. 1  illustrates a system  100  for determining availability parameters of a resource in a heterogeneous computing environment, in accordance with embodiments of the present invention. 
         [0035]    The system  100  comprises a server  110 , at least one resource, and a central data repository (CDR)  120 . The CDR  120  comprises lifecycle event data of said at least one resource. 
         [0036]    The server  110  comprises a user interface  111 , a report generator  112 , and a system automation module  113 . 
         [0037]    The user interface  111  receives a report request  160  on availability parameters of a resource K  150  of said at least one resource from a user  180 . The user interface  111  passes content of the report request  160  to the report generator  112  as an input. 
         [0038]    The resource K  150  is any hardware and/or software computing resource that may be, inter alia, a piece of data such as an Internet Protocol (IP) address, a software program, a server, a storage device, or any combination of multiple resources such as a cluster of servers installed with multiple software programs, an integrated development environment, a database management system, etc. 
         [0039]    The system automation module  113  processes a resource K lifecycle event data  125  stored in the CDR  120 , and provides a result to the report generator  112 . 
         [0040]    The resource K lifecycle event data  125  is recorded in the CDR  120  by a CDR feeder  155  in the system automation module  113  upon occurrence of each resource K lifecycle event that is predetermined to be recorded. See description of  FIG. 2 , infra, for events necessary to be stored in the CDR  120 . 
         [0041]    The CDR feeder  155  determines whether each resource K lifecycle event is planned or unplanned as storing the resource K lifecycle event data in the CDR  120 . See description of  FIG. 4 , infra, for details on operations of the CDR feeder  155 . 
         [0042]    The report generator  112  calculates availability parameters of Mean Time To Repair (MTTR) and Mean Time Between Failure (MTBF) of the resource K  150  with the lifecycle event data stored in the CDR  120 , creates an availability report  170  pursuant to the report request  160 , and returns the availability report  170  to the user  180 . Availability of a resource is calculated with a formula (MTBF/(MTBF+MTTR)). Consequently, a decision as to whether the resource K  150  is in OFFLINE state as a planned repair or as an unplanned incident is critical in obtaining an accurate availability ratio for the resource K  150 . See description of  FIGS. 4 and 5 , infra, for details on operations of the report generator  112 .// 
         [0043]    In one embodiment of the present invention, the server  110  is an IBM® Websphere Application Server with Tivoli® System Automation for Application Manager (SA AM) installed and the user interface  111  is a web application. The report generator  112  employs the IBM Business Intelligence and Reporting Tools/Tivoli® Common Reporting (BIRT/TCR) infrastructure based on Java® and the Java 2 Platform Enterprise Edition (J2EE®) in servicing resource clusters such as Linux® servers and/or z/OS® Sysplex servers. The CDR  120  is DB2® database system. (IBM, Tivoli, z/OS, and DB2 are registered trademarks of the International Business Machines, Inc., in the United States and/or other countries; Linux is a registered trademark of Linus Torvalds in the United States and/or other countries; and Java and J2EE are registered trademarks of the Sun Microsystems, Inc., in the United States and/or other countries.) 
         [0044]      FIG. 2  illustrates lifecycle events of a resource, in accordance with the embodiments of the present invention. 
         [0045]    The CDR feeder of the present invention records state transitions of the resource as lifecycle event data for the resource in the Central Data Repository (CDR). See description of  FIG. 3 , infra, for parameters of lifecycle event data. 
         [0046]    There are four state phases for the resource, which are {OFFLINE, STARTUP, ONLINE, SHUTDOWN}. OFFLINE is a state phase during which the resource is not active. ONLINE is a state phase during which the resource is actively running. STARTUP is a state phase during which the resource is moving from OFFLINE to ONLINE. SHUTDOWN is a state phase during which the resource is moving from ONLINE to OFFLINE. 
         [0047]    A period of time between t 0  and t 1  is a downtime of the resource. At time t 1 , the resource changes the state from OFFLINE to STARTUP as the resource is getting started. At time t 2 , the resource changes the state from STARTUP to ONLINE as the resource is fully started and actively running. At time t 3 , the resource changes the state from ONLINE to SHUTDOWN as the resource is stopping. At time t 4 , the resource changes the state from SHUTDOWN to OFFLINE as the resource completely stops and becomes inactive. 
         [0048]      FIG. 3  illustrates parameters of lifecycle event data of a resource as represented in the Central Data Repository (CDR), in accordance with the embodiments of the present invention. 
         [0049]    The parameters of lifecycle event data of the resource comprises a TIMESTAMP  131 , a RESOURCENAME  132 , a RESOURCECLASS  133 , a NODENAME  134 , a DOMAINNAME  135 , an OBSERVED_STATE  136 , an OBSERVED_STATE_PREVIOUS  137 , a DESIRED_STATE  138 , a DESIRED_STATE_PREVIOUS  139 , and an UNPLANNED  140 . 
         [0050]    The TIMESTAMP  131  is a point of time when a lifecycle event occurred. 
         [0051]    The RESOURCENAME  132  is a name of the resource wherein the lifecycle event occurred. The RESOURCECLASS  133  is a class to which the resource is a member. The NODENAME  134  denotes a node in which the resource is operating. The DOMAINNAME  135  is a name of a domain to which the resource is an element. The resource is identified by a combination of the RESOURCENAME  132 , the RESOURCECLASS  133 , the NODENAME  134 , and the DOMAINNAME  135 . 
         [0052]    The OBSERVED_STATE  136  is an actual state of the resource at the time when the lifecycle event occurs. The OBSERVED_STATE_PREVIOUS  137  is an actual state of the resource prior to the time when the lifecycle event occurs. The OBSERVED_STATE  136  and the OBSERVED_STATE_PREVIOUS  137  may have values of {OFFLINE, STARTUP, ONLINE, SHUTDOWN}. 
         [0053]    The DESIRED_STATE  138  is a target state of the resource at the time when the lifecycle event occurs. The DESIRED _STATE_PREVIOUS  139  is a target state of the resource prior to the time when the lifecycle event occurs. The DESIRED_STATE  138  and the DESIRED_STATE_PREVIOUS  139  may have values of {ONLINE, OFFLINE}. 
         [0054]    The UNPLANNED  140  indicates a determination as to whether the lifecycle event is unplanned. The UNPLANNED  140  may have values of {TRUE, FALSE} for an unplanned lifecycle event and a planned lifecycle event, respectively. See description of  FIG. 4 , infra, on how to determine a value of the UNPLANNED parameter. 
         [0055]      FIG. 4  is a flowchart for recording a lifecycle event of a resource in the Central Data Repository (CDR) by a CDR feeder associated with the resource, in accordance with the embodiments of the present invention. 
         [0056]    In step  410 , upon detecting occurrence of the lifecycle event, the CDR feeder determines a target state of the resource and sets the target state as a value for the DESIRED_STATE. The CDR feeder checks a current state of the resource and sets the current state as a value for the OBSERVED_STATE. 
         [0057]    The lifecycle event is defined as a change of either the target state or the current state, as represented in values of the DESIRED_STATE and the OBSERVED_STATE, respectively. The target state defines a plan for using the resource and changes in the target state are deemed planned and made automatically by a schedule or a program, or manually by an operator. The change of the target state is determined by comparing values of the DESIRED_STATE and the DESIRED_STATE_PREVIOUS. Wherein the target state changes, because the plan has changed, it is unnecessary to determine whether the current state has changed. The change of the current state is determined by comparing values of the OBSERVED_STATE and the OBSERVED_STATE_PREVIOUS. 
         [0058]    In step  420 , the CDR feeder determines whether the lifecycle event is either planned or unplanned by comparing the target state and the current state. If the CDR feeder determines that the lifecycle event is planned, the CDR feeder sets FALSE as a value of the UNPLANNED parameter. If the CDR feeder determines that the lifecycle event is unplanned, the CDR feeder sets TRUE as a value of the UNPLANNED parameter. 
         [0059]    If the current state progresses into a state farther from the target state, the lifecycle event is determined as unplanned. See description of  FIGS. 6A ,  6 B,  7 A, and  7 B, infra, on how to determine the UNPLANNED parameter value. In descriptions of  FIGS. 6A ,  6 B,  7 A, and  7 B, the DESIRED_STATE remains the same throughout the entire time determining each UNPLANNED parameter value. 
         [0060]    In step  430 , the CDR feeder stores the lifecycle event in the CDR as all parameters of the lifecycle event data are instantiated. 
         [0061]      FIG. 5  is a flowchart for a report generator processing a request for a report on availability parameters of a resource, in accordance with the embodiments of the present invention. 
         [0062]    In step  510 , the report generator receives the request for the report on availability parameters of the resource from a user through a user interface. The availability parameters to be reported to the user may include, inter alia, a number of unplanned outages for the resource, the Mean Time To Repair (MTTR), the Mean Time Between Failure (MTBF), etc. As aforementioned, availability of a resource is calculated with a formula (MTBF/(MTBF+MTTR)). 
         [0063]    In step  520 , the report generator retrieves lifecycle event data for the resource from the Central Data Repository (CDR). 
         [0064]    In step  530 , the report generator calculates availability parameters and generates the report. In calculating the MTTR and the MTBF, the report generator uses values of the TIMESTAMP parameter of retrieved lifecycle event data. 
         [0065]    In step  540 , the report generator returns the generated report on availability parameters to the user. 
         [0066]    In one embodiment of the present invention, a request for a report on unplanned outages of a DB2 database is received in step  510 . The report generator searches the CDR for all lifecycle event data having a value of the OBSERVED_STATE parameter of OFFLINE and a value of the UNPLANNED parameter of TRUE in step  520 . 
         [0067]      FIGS. 6A and 6B  illustrate values for an UNPLANNED parameter when a DESIRED_STATE is ONLINE, in accordance with the embodiments of the present invention. 
         [0068]      FIG. 6A  illustrates values for the UNPLANNED parameter by comparing the DESIRED_STATE with an OBSERVED_STATE, in accordance with the embodiments of the present invention. 
         [0069]    A respective lifecycle event, i.e., state transition, in a resource occurs at each time stamp t 601 , t 602 , t 603 , t 604 , and t 605 . 
         [0070]    At time t 601 , the OBSERVED_STATE is OFFLINE, which is the opposite of the DESIRED_STATE of ONLINE. Consequently the lifecycle event is unplanned and the UNPLANNED value of the lifecycle event data for the resource at time t 601  is TRUE. 
         [0071]    At time t 602 , the OBSERVED_STATE is STARTUP, which is different from the DESIRED_STATE of ONLINE. However, because STARTUP is a transitional state immediately prior to the DESIRED_STATE of ONLINE, an OBSERVED_STATE_PREVIOUS is looked into to determine the UNPLANNED value at time t 602 . See description of  FIG. 6B , infra, for details on interpreting values of the OBSERVED_STATE_PREVIOUS against the OBSERVED_STATE at time t 602 . 
         [0072]    At time t 603 , the OBSERVED_STATE is ONLINE, which is equal to the DESIRED_STATE of ONLINE. Consequently the lifecycle event is planned and the UNPLANNED value at time t 603  is FALSE. 
         [0073]    At time t 604 , the OBSERVED_STATE is SHUTDOWN, which is different from the DESIRED_STATE of ONLINE. The state SHUTDOWN is a state leading to OFFLINE that is the opposite of the DESIRED_STATE of ONLINE. Consequently the lifecycle event is unplanned and the UNPLANNED value at time t 604  is TRUE. 
         [0074]    At time t 605 , the OBSERVED_STATE cannot be determined. The UNPLANNED value at time t 605  is determined as FALSE to accurately count a number of failures in the resource as intended in the method of the present invention. In other embodiment, the UNPLANNED is set to TRUE wherein the OBSERVED_STATE cannot be determined, to count as many failures as possible. 
         [0075]      FIG. 6B  illustrates values for the UNPLANNED parameter by comparing the OBSERVED_STATE of STARTUP with the OBSERVED_STATE_PREVIOUS, in accordance with the embodiments of the present invention. 
         [0076]    In case of t 602 A, the OBSERVED_STATE_PREVIOUS is SHUTDOWN such that the resource changes the state from SHUTDOWN to STARTUP, which indicates the resource transits toward the DESIRED_STATE of ONLINE. Consequently, the lifecycle event is planned and the UNPLANNED value at time t 602  is FALSE. 
         [0077]    In case of t 602 B, the OBSERVED_STATE_PREVIOUS is OFFLINE such that the resource changes the state from OFFLINE to STARTUP, which indicates the resource transits toward the DESIRED_STATE of ONLINE. Consequently, the lifecycle event is planned and the UNPLANNED value at time t 602  is FALSE. 
         [0078]    In case of t 602 C, the OBSERVED_STATE_PREVIOUS is STARTUP such that the resource stays in the same state at a time when the OBSERVED_STATE_PREVIOUS is checked and at a time t 602 . Because STARUP is a state transiting toward the DESIRED_STATE of ONLINE, the lifecycle event is determined as planned and the UNPLANNED value at time t 602  is FALSE. 
         [0079]    In case of t 602 D, the OBSERVED_STATE_PREVIOUS is ONLINE such that the resource changes the state from ONLINE to STARTUP. The resource was in the DESIRED_STATE of ONLINE as recorded in the OBSERVED_STATE_PREVIOUS of ONLINE, and the resource changed the state from the DESIRED_STATE of ONLINE as shown in the OBSERVED_STATE of STARTUP. The state transition indicates that an unplanned incident had happened in between the times for the OBSERVED_STATE_PREVIOUS and the OBSERVED_STATE. Consequently, the lifecycle event is determined as unplanned and the UNPLANNED value at time t 602  is TRUE. 
         [0080]      FIGS. 7A and 7B  illustrate values for the UNPLANNED parameter when the DESIRED_STATE is OFFLINE, in accordance with the embodiments of the present invention. 
         [0081]      FIG. 7A  illustrates values for the UNPLANNED parameter by comparing the DESIRED_STATE with an OBSERVED_STATE, in accordance with the embodiments of the present invention. 
         [0082]    A respective lifecycle event, i.e., state transition, in a resource occurs at each time stamp t 701 , t 702 , t 703 , t 704 , and t 705 . 
         [0083]    At time t 701 , the OBSERVED_STATE is OFFLINE, which is equal to the DESIRED_STATE of OFFLINE. Consequently the lifecycle event is planned and the UNPLANNED value at time t 701  is FALSE. 
         [0084]    At time t 702 , the OBSERVED_STATE is STARTUP, which is different from the DESIRED_STATE of OFFLINE. The state STARTUP is a state leading to ONLINE that is the opposite of the DESIRED_STATE of OFFLINE. Consequently the lifecycle event is unplanned and the UNPLANNED value at time t 702  is TRUE. 
         [0085]    At time t 703 , the OBSERVED_STATE is ONLINE, which is the opposite of the DESIRED_STATE of OFFLINE. Consequently the lifecycle event is unplanned and the UNPLANNED value of the lifecycle event data for the resource at time t 703  is TRUE. 
         [0086]    At time t 704 , the OBSERVED_STATE is SHUTDOWN, which is different from the DESIRED_STATE of OFFLINE. However, because SHUTDOWN is a transitional state immediately prior to the DESIRED_STATE of OFFLINE, an OBSERVED_STATE_PREVIOUS is looked into to determine the UNPLANNED value at time t 704 . See description of  FIG. 7B , infra, for details on interpreting values of the OBSERVED_STATE_PREVIOUS against the OBSERVED_STATE at time t 704 . 
         [0087]    At time t 705 , the OBSERVED_STATE cannot be determined. The UNPLANNED value at time t 705  is determined as FALSE to accurately count a number of failures in the resource as intended in the method of the present invention. In other embodiment, the UNPLANNED is set to TRUE wherein the OBSERVED_STATE cannot be determined, to count as many failures as possible. 
         [0088]      FIG. 7B  illustrates values for the UNPLANNED parameter by comparing the OBSERVED_STATE of SHUTDOWN with the OBSERVED_STATE_PREVIOUS, in accordance with the embodiments of the present invention. 
         [0089]    In case of t 704 A, the OBSERVED_STATE_PREVIOUS is STARTUP such that the resource changes the state from STARTUP to SHUTDOWN, which indicates the resource transits toward the DESIRED_STATE of OFFLINE. Consequently, the lifecycle event at time t 704  is planned and the UNPLANNED value is FALSE. 
         [0090]    In case of t 704 B, the OBSERVED_STATE_PREVIOUS is ONLINE such that the resource changes the state from ONLINE to SHUTDOWN, which indicates the resource transits toward the DESIRED_STATE of OFFLINE. Consequently, the lifecycle event at time t 704  is planned and the UNPLANNED value is FALSE. 
         [0091]    In case of t 704 C, the OBSERVED_STATE_PREVIOUS is SHUTDOWN such that the resource stays in the same state at a time when the OBSERVED_STATE_PREVIOUS is checked and at a time t 704 . Because SHUTDOWN is a state transiting toward the DESIRED_STATE of OFFLINE, the lifecycle event at time t 704  is determined as planned and the UNPLANNED value is FALSE. 
         [0092]    In case of t 704 D, the OBSERVED_STATE_PREVIOUS is OFFLINE such that the resource changes the state from OFFLINE to SHUTDOWN. The resource was in the DESIRED_STATE of OFFLINE as recorded in the OBSERVED_STATE_PREVIOUS of OFFLINE, and the resource changed the state from the DESIRED_STATE of OFFLINE as shown in the OBSERVED_STATE of SHUTDOWN. The state transition indicates that an unplanned incident had happened in between the times for the OBSERVED_STATE_PREVIOUS and the OBSERVED_STATE. Consequently, the lifecycle event at time t 704  is determined as unplanned and the UNPLANNED value is TRUE. 
         [0093]      FIG. 8  illustrates a first scenario wherein a resource starts up and shuts down as planned, in accordance with the embodiments of the present invention. 
         [0094]    At time t 801 , a DESIRED_STATE of the resource is OFFLINE and an OBSERVED_STATE of the resource is OFFLINE. Because the OBSERVED_STATE is equal to the DESIRED_STATE of OFFLINE, a lifecycle event at time t 801  is determined as planned and the UNPLANNED value of the lifecycle event is FALSE. 
         [0095]    At time t 802 , the DESIRED_STATE is changed from ONLINE at time t 801  to OFFLINE at time t 802 , a lifecycle event at time t 802  is determined as planned and the UNPLANNED value of the lifecycle event is FALSE. 
         [0096]    At time t 803 , the DESIRED_STATE remains ONLINE and the OBSERVED_STATE is STARTUP. Because the resource transits toward the DESIRED_STATE of ONLINE, a lifecycle event at time t 803  is determined as planned and the UNPLANNED value of the lifecycle event is FALSE. 
         [0097]    At time t 804 , the DESIRED_STATE remains ONLINE and the OBSERVED_STATE is ONLINE. Because the OBSERVED_STATE is equal to the DESIRED_STATE of ONLINE, a lifecycle event at time t 804  is determined as planned and the UNPLANNED value of the lifecycle event is FALSE. 
         [0098]    At time t 805 , the DESIRED_STATE is changed from ONLINE at time t 804  to OFFLINE at time t 805 , a lifecycle event at time t 805  is determined as planned and the UNPLANNED value of the lifecycle event is FALSE. 
         [0099]    At time t 806 , the DESIRED_STATE remains OFFLINE and the OBSERVED_STATE is SHUTDOWN. Because the resource transits toward the DESIRED_STATE of OFFLINE, a lifecycle event at time t 806  is determined as planned and the UNPLANNED value of the lifecycle event is FALSE. 
         [0100]    At time t 807 , the DESIRED_STATE remains OFFLINE and the OBSERVED_STATE is OFFLINE. Because the OBSERVED_STATE is equal to the DESIRED_STATE of OFFLINE, a lifecycle event at time t 807  is determined as planned and the UNPLANNED value of the lifecycle event is FALSE. 
         [0101]      FIG. 9  illustrates a second scenario wherein a resource goes through an unplanned incident, in accordance with the embodiments of the present invention. 
         [0102]    At time t 901 , a DESIRED_STATE of the resource is ONLINE and an OBSERVED_STATE of the resource is ONLINE. Because the OBSERVED_STATE is equal to the DESIRED_STATE of ONLINE, a lifecycle event at time t 901  is determined as planned and the UNPLANNED value of the lifecycle event is FALSE. 
         [0103]    At time t 902 , the DESIRED_STATE remains ONLINE and the OBSERVED_STATE is SHUTDOWN. Because the resource transits away from the DESIRED_STATE of ONLINE, a lifecycle event at time t 902  is determined as unplanned and the UNPLANNED value of the lifecycle event is TRUE. 
         [0104]    At time t 903 , the DESIRED_STATE remains ONLINE and the OBSERVED_STATE is OFFLINE. Because the resource is in a state opposite of the DESIRED_STATE of ONLINE, a lifecycle event at time t 903  is determined as unplanned and the UNPLANNED value of the lifecycle event is TRUE. 
         [0105]      FIG. 10  illustrates a third scenario wherein a database is set up and goes through a failure during service, in accordance with the embodiments of the present invention. 
         [0106]    At time t 1001 , a DESIRED_STATE of the database is OFFLINE and an OBSERVED_STATE of the database is OFFLINE as the database is installed in a server. Because the OBSERVED_STATE is equal to the DESIRED_STATE of OFFLINE, a lifecycle event at time t 1001  is determined as planned and the UNPLANNED value of the lifecycle event is FALSE. 
         [0107]    At time t 1002 , the DESIRED_STATE is changed to ONLINE from OFFLINE as the database is started for service. Because the DESIRED_STATE is a plan, a lifecycle event at time t 1002  is determined as planned and the UNPLANNED value of the lifecycle event is FALSE. 
         [0108]    At time t 1003 , the DESIRED_STATE remains ONLINE and the OBSERVED_STATE is STARTUP as being started as planned. Because the database transits toward the DESIRED_STATE of ONLINE, a lifecycle event at time t 1003  is determined as planned and the UNPLANNED value of the lifecycle event is FALSE. 
         [0109]    At time t 1004 , the DESIRED_STATE remains ONLINE and the OBSERVED_STATE is ONLINE as the database is operating. Because the OBSERVED_STATE is equal to the DESIRED_STATE of ONLINE, a lifecycle event at time t 1004  is determined as planned and the UNPLANNED value of the lifecycle event is FALSE. 
         [0110]    At time t 1005 , the DESIRED_STATE remains ONLINE and the OBSERVED_STATE is OFFLINE as the database crashes due to a process failure. Because the database is in a state opposite of the DESIRED_STATE of ONLINE, a lifecycle event at time t 1005  is determined as unplanned and the UNPLANNED value of the lifecycle event is TRUE. 
         [0111]      FIGS. 11A ,  11 B,  11 C,  11 D,  11 E, and  11 F illustrate an example of a report on availability and recovery of a resource, in accordance with embodiments of the present invention. 
         [0112]    The report comprises a heading describing the resource, a summary, an availability overview, a downtime analysis, an unplanned downtimes in relation to planned availability, an overview of state transitions of the resource, unexpected outages and corresponding recovery times that features Mean Time To Failure (MTTR), Mean Time Between Failure (MTBF), Mean Time Between System Incidents (MTBSI) values. 
         [0113]      FIG. 11G  illustrates an example of an availability report on unplanned outages of multiple resources, in accordance with embodiments of the present invention. 
         [0114]      FIG. 12  illustrates a computer system  90  used for determining availability parameters of resource in heterogeneous computing environment, in accordance with embodiments of the present invention. 
         [0115]    The computer system  90  comprises a processor  91 , an input device  92  coupled to the processor  91 , an output device  93  coupled to the processor  91 , and memory devices  94  and  95  each coupled to the processor  91 . The input device  92  may be, inter alia, a keyboard, a mouse, a keypad, a touchscreen, a voice recognition device, a sensor, a network interface card (NIC), a Voice/video over Internet Protocol (VOIP) adapter, a wireless adapter, a telephone adapter, a dedicated circuit adapter, etc. The output device  93  may be, inter alia, a printer, a plotter, a computer screen, a magnetic tape, a removable hard disk, a floppy disk, a NIC, a VOIP adapter, a wireless adapter, a telephone adapter, a dedicated circuit adapter, an audio and/or visual signal generator, a light emitting diode (LED), etc. The memory devices  94  and  95  may be, inter alia, a cache, a dynamic random access memory (DRAM), a read-only memory (ROM), a hard disk, a floppy disk, a magnetic tape, an optical storage such as a compact disk (CD) or a digital video disk (DVD), etc. The memory device  95  includes a computer code  97  which is a computer program that comprises computer-executable instructions. The computer code  97  includes, inter alia, an algorithm used for determining availability parameters of resource in heterogeneous computing environment according to the present invention. The processor  91  executes the computer code  97 . The memory device  94  includes input data  96 . The input data  96  includes input required by the computer code  97 . The output device  93  displays output from the computer code  97 . Either or both memory devices  94  and  95  (or one or more additional memory devices not shown in  FIG. 12 ) may be used as a computer usable storage medium (or a computer readable storage medium or a program storage device) having a computer readable program embodied therein and/or having other data stored therein, wherein the computer readable program comprises the computer code  97 . Generally, a computer program product (or, alternatively, an article of manufacture) of the computer system  90  may comprise said computer usable storage medium (or said program storage device). 
         [0116]    While  FIG. 12  shows the computer system  90  as a particular configuration of hardware and software, any configuration of hardware and software, as would be known to a person of ordinary skill in the art, may be utilized for the purposes stated supra in conjunction with the particular computer system  90  of  FIG. 12 . For example, the memory devices  94  and  95  may be portions of a single memory device rather than separate memory devices. 
         [0117]    While particular embodiments of the present invention have been described herein for purposes of illustration, many modifications and changes will become apparent to those skilled in the art. Accordingly, the appended claims are intended to encompass all such modifications and changes as fall within the true spirit and scope of this invention.