Information technology service management

A desired instance of a service model is stored, and an observed instance of the service model is provided. Inconsistencies between the desired instance and the observed instance may be detected based on a comparison between the desired instance and the observed instance.

BACKGROUND

An information technology (IT) service is composed of a set of hardware and software artifacts deployed in one or more data centers. Availability and performance of such artifacts vary greatly over time. For example, changes can range from reconfiguration of service attributes to upgrade and downgrade, as well as migration, scale out, etc. Typically, these changes are accomplished manually, resulting in unsatisfactory repeatability, speed of execution, cost efficiency, etc.

The Information Technology Infrastructure Library (ITIL) provides a framework for service support. A configuration management is an example of the service support. The configuration management refers to a process for recognizing a configuration item targeted for IT service management to keep, update, confirm, and audit information about the configuration item. The configuration item represents resources targeted for configuration. The configuration item includes not only system resources inclusive of hardware and software but also facilities necessary for providing an IT service, documents such as a description about how to provide IT services, an operating procedure, and a diagram, hardware or software maintenance services, processes, etc.

Some systems provide for IT systems monitoring, but IT systems modeling is less advanced. The Configuration Management Database (CMDB) attempts to capture IT service model instances. However, the CMDB typically is used to store the output of monitoring systems to capture the state of the IT service “as is” in the data center. In other cases, the CMDB is used to store model instances that represent only what the desired IT service should look like.

DETAILED DESCRIPTION

In the following detailed description, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration specific implementations. It is to be understood that other implementations may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of this disclosure is defined by the appended claims.

FIG. 1illustrates a block diagram of an example of a computer system100. The computer system100includes a processor110coupled to a memory120. The memory120can be operable to store program instructions122that are executable by the processor110to perform one or more functions. It should be understood that “computer system” can be intended to encompass any device having a processor that can be capable of executing program instructions from a memory medium. In a particular implementation, the various functions, processes, methods, and operations described herein may be implemented using the computer system100.

The various functions, processes, methods, and operations performed or executed by the system100can be implemented as the program instructions122(also referred to as software or simply programs) that are executable by the processor110and various types of computer processors, controllers, central processing units, microprocessors, digital signal processors, state machines, programmable logic arrays, and the like. In some implementations, the computer system100may be networked (using wired or wireless networks) with other computer systems, and the various components of the system100may be local to the processor110or coupled thereto via a network.

In various implementations the program instructions122may be stored on the memory120or any non-transient computer-readable medium for use by or in connection with any computer-related system or method. A computer-readable medium can be an electronic, magnetic, optical, or other physical device or means that can contain or store a computer program for use by or in connection with a computer-related system, method, process, or procedure. Programs can be embodied in a computer-readable medium for use by or in connection with an instruction execution system, device, component, element, or apparatus, such as a system based on a computer or processor, or other system that can fetch instructions from an instruction memory or storage of any appropriate type. A computer-readable medium can be any structure, device, component, product, or other means that can store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

Implementations of the disclosed IT systems and methods involve desired and observed states in management systems, formalizing the relationship between the characterization of what a model instance is desired to be—the desired state, and what an instance is—the observed state. This two state approach is particularly important in a model based system. A model as used herein generally refers to a representation of the design, characteristics and behavior of a system, element, solution, or service. The model can be a declarative specification of the structural, functional, non-functional, and runtime characteristics of the IT system, element, solution, or service. The instantiation of a model creates a model instance, which is stored as a representation of the model in memory, such as the memory120.

A service as used herein generally refers a utility or benefit provided by a provider to a consumer. The provider and the consumer may vary by application and may include an enterprise, a business unit, a business process, an application, a third party, an individual, and similar others. Enterprise services may be provided in the course of conducting the enterprise business. IT services generally refer to any application that enables the enterprise to provide utility or benefit by adding functionality to the IT infrastructure.

The model captures the design of a particular IT element or solution, e.g., IT services captured as a service model, defining the externally visible description, behavior, state, and operations available from a service to other services. Thus, the instantiation of a model results in a generation of a virtual runtime object, e.g., the model instance, and also results in a generation of a real, tangible IT artifact in an IT infrastructure, which, for example, could be a data center that includes hardware, software, communications, applications, services and similar other components to provide IT functions.

As illustrated inFIG. 2, the theory behind this concept is that an instance of an IT Service exists in two states simultaneously: the desired state201and the observed state202. The observed state is often determined by monitoring systems that continuously observe the IT artifact that is associated with the instance. The desired state is defined when the instance is created and through subsequent changes.

By checking consistency between the desired and observed states, it is possible to detect anomalous IT artifacts. Suppose that a system is characterized by the attribute memoryUtilization defined as being below 95%. The constraint memoryUtilization<95% represents the desired state. Suppose a monitoring probe is deployed to collect memory utilization data at regular intervals and an associated monitoring system updates the observed state with those values. Now suppose at some point in time, the observed state is determined and expressed as memoryUtilization=20%. Clearly, this observed state is consistent with the constraint characterization in the desired state (memoryUtilization<95%). If, at a later time, the observed state changes to memoryUtilization=98%, the desired and observed states clearly are not consistent and will require further actions so that the observed state is returned to a consistent value with the desired state.

Instead of maintaining two representations of an instance, each with one state as shown inFIG. 2, in some implementations a single model instance representation203is maintained having two states (i.e. a desired state and an observed state) as illustrated inFIG. 3. In such implementations, model instance elements receive two values, tagged with either a desired (D) or an observed (O) label, the observed value being a refinement of the desired value as illustrated inFIG. 4, where the memory120stores the tagged values210,212.

Over the course of its lifetime, an IT Service will typically change multiple times. Changes can occur in the observed state (degradation of performance, system failure, etc) or can occur in the desired state. Transitions between observed states reflect changes in the real world. When such a change occurs, a consistency check will verify the correctness of the newly observed states as illustrated inFIG. 5. The desired state201is compared to the first observed state202. Over time, the observed state transitions to the second observed state202′, which is compared to the desired state201to verify continued consistency.

In contrast, changes in the desired state201reflect a conscious decision by an administrator, customer, management system, etc. to alter the IT Service.FIG. 6illustrates such a change, where the transition from the first desired state201to the second, or new desired state201′ is taken first. This transition means that changes in the IT system will be made, resulting in the newly observed state202′. The two new states201′ and202′ are then checked for consistency.

FIG. 7illustrates a closed loop IT service management system and method in accordance with disclosed implementations. Aspects of the system300could be implemented with, for example, the computer system100illustrated inFIG. 1. The system300includes a Configuration Management System (CMS)310that stores a desired instance or state201and an observed instance or state202of a service model for an IT system302. In some implementations, two representations of the model instances are stored: the desired and observed instances, and in other implementations a single model instance representation is stored having the two states. As noted above, with this arrangement model instance elements receive two values tagged as either desired or observed.

The model instance(s) and associated desired and observed states are stored, for example in the memory120illustrated inFIG. 1. A monitoring service304monitors the IT system302and reports the observed state202of the IT system302to the CMS310. The CMS310compares the observed state202to the desired state201, and if these states are inconsistent, the CMS310detects the inconsistency between the desired instance and the observed instance based on the comparison. If an inconsistency is detected, the system300can modify one or both of the desired state201and/or the observed state202.

In the illustrated implementation, upon detection of an inconsistency the CMS310notifies a Watchdog Service312. The watchdog service312is responsible for determining whether a detected inconsistency should be dealt with or not. For example, assuming that the service is exhibiting inconsistency because of high load, an operation to remedy could be one or more of the following:A change to the service configuration to reduce or throttle or redirect demand;A change to the service's desired state to tolerate higher threshold(s);A change to the service to add resources to the service to service demand faster. Among others, this could take the form of adding CPU percentage to a virtual machine, or could take the form of adding another node to a tier.

In some implementations the default situation has the watchdog service312overseeing all of the CMS instances. However, it is also possible to configure the watchdog service312to ignore specific instances, in effect deactivating the closed loop. A “healthy” instance in the CMS310is in the lifecycle state Grounded and has its consistency state set to true. Upon inconsistency detection, the consistency state is updated to false and a notification sent to the watchdog service312. The watchdog service312can decide to ignore the notification, record it but take no action, move the lifecycle state of the instance in the Watched state and take no further action or notifying a Repair Service314.

The Watched state is a probation state in which the instance is deemed usable (an inconsistency has been detected) but under scrutiny. When moving an instance to the Watched state, the watchdog service312can trigger changes in the monitoring services such as requiring the deployment of complementary probes, changing the data collection frequency, etc. In some implementations, the CMS310not only notifies the watchdog service312when an inconsistency is detected, but also when an observed state returns to a consistent state.FIG. 8is a simple table illustrating an example of when notifications are sent by the watchdog service312, taken into consideration, whether an instance is being watched or not in one implementation.

Various control algorithms can be applied to determine when to move from the Watch state back to the Grounded state or to transition to the Repair state. For instance, a simple approach based on time would determine how long the instance was in the Watch state. If the instance spent “too long” in the Watch state then the repair service314gets notified. When being watched, it is possible that the instance returns to a consistent state without the need of repair action. In that case the watchdog service312would be notified and could decide to move back the instance to Grounded or keep it in a Watch state.

In some implementations, the Watched state is a global state that applies to an instance and not to instance elements. For example, an instance could have two attributes: responseTime and threadCount. A state inconsistency in responseTime might move the instance to the Watched state. Later, a threadCount inconsistency would also result in the notification. However, the CMS310does not record why the instance is in the Watched state (originally because of the responseTime), rather, this is done by the watchdog service312.

Whereas Watched instances are still valid from the point of view of the binding process, the CMS312may prefer Grounded instances over Watched instances when ranking possible candidates. When the repair service314gets notified, it automatically moves the state of the instance to Repair. The instance is added to the list of instances to ignore by the watchdog service312so that further notifications are not received.

It is the responsibility of the repair service314to determine how to restore the state consistency. This can include determining the set of operations316to invoke in order to bring about this state. In some implementations, an operation declares a set of effects. Those effects are associated with changes in desired state201. Therefore, when an operation316is invoked, the CMS310will first set the desired state201associated with the operation invoked in the target instance. It will then trigger the execution of the operation316. If the operation invocation is successful, the instance is removed from the list of ignored instances in the watchdog312. The close loop system is activated.

As the operation316is performed in the data center, changes will be made to the service. When the closed loop system is reactivated for that instance, new observed state202information is fed to the CMS310from the monitoring service312. The operation316is successful if the observed state202is consistent with the desired state201. If it is not, then the system will detect the inconsistency and will signal the watchdog312.