 |
CHAnge Management with Planning and Scheduling (CHAMPS)
What is CHAMPS?
CHAMPS is a research project at the IBM T.J. Watson Research Center that aims at reducing the
complexity of IT Change and Configuration Management through
automation.
The CHAMPS system is our implementation of a schedule-optimizing
Change Manager based on automated workflow creation and mathematical
scheduling theory. This page provides information on:
Many details on the design and implementation of the CHAMPS system have
been published in various refereed papers and presentations, which are
available from the CHAMPS Publications
page.
Problem Statement: IT Change Management is complex, costly and error-prone
IT Change Management is a process by which IT systems are modified to
accommodate considerations such as software fixes, hardware upgrades
and performance enhancements. Change Management has become one of the
most complex, labor-intensive and time-consuming activities in Service
Management. A detailed study shows that operator errors (such as
mis-configurations) account for the largest fraction of failures of
Internet services and hence properly managing changes is critical to
availability of IT services. IT organizations of enterprises and
service providers are therefore eager to automate the change
management process in order to realize significant complexity and
labor cost reductions.
CHAMPS Vision: Reducing Change and Configuration Complexity through Automation
One approach to reducing the human cost of configuration is through
automation, as in IBM's
Autonomic Computing initiative; another is to improve the tools
used by human system administrators. An example of an
automation-based approach is the CHAMPS system, which formulates IT
Change Management (comprising the provisioning, deployment,
installation and configuration steps) as an optimization problem and
automatically generates - based on administrator-defined policies -
change management workflows from dependency models. Subsequently,
these workflows are executed by a common-off-the-shelf provisioning
system.
The goal of CHAMPS is to reduce the possibility of human errors
during the change management process as much as possible. This is
accomplished by
- automatically matching the pre-requisites and requirements against
the capabilities of software packages (where each software package may
have many dozens of configuration parameters), and
- by determining the proper order in which changes need to be
carried out so that a change results in a workable system.
CHAMPS relies on an explicit representation of the dependencies
between components subject to a change. In contrast, today's systems
expect an administrator to provide such insights, which is often not
the case.
On the other hand, past experience shows that administrators are unlikely
to trust a fully automated system that performs critical
activities. In order to address the requirement of having
administrators take the final decision, the CHAMPS system has been
designed so that the output data of each of its process steps is
described in a common format (e.g., a general-purpose workflow
language) so that an administrator can customize and modify the
data before it is consumed by the next activity in the change management
process.
Relationship of CHAMPS to the ITIL Change
Management Best Practice
The IT Infrastructure Library (ITIL)
defines the goal of Change Management as to ensure that
standardized methods and procedures are used for efficient and prompt
handling of all changes, in order to minimize the impact of
change-related incidents upon service quality. Change Management
is central to ensuring the availability, reliability, and quality of
information technology (IT) services and processes. ITIL identifies
the key major change management activities, the roles and stakeholders
that perform them and input/output data that are either consumed or
produced by the various activities in the change management process.
The change management process starts with the submission of a Request
for Change (RFC); many RFCs may be submitted concurrently. Other
important inputs the change management process needs to consider are
Service Level Agreements, Policies and best practices. Underlying the
whole process is the Configuration Management Database (CMDB), a
conceptual repository that holds the various change management
artifacts and additional context information to provide, among other,
a change audit trail. The CMDB also serves as the integration point of
change management with other ITIL disciplines, in particular
configuration management and release management.
The CHAMPS system implements the first three activities of the ITIL Change
Management Process: It accepts a newly submitted request for change,
assesses its impact on the distributed environment, and - once the
necessary approvals are obtained - schedules the change by computing a
Forward Schedule of Change (aka Change Plan). Service Level Agreements
as well as administrator policies and best practices are needed to
guide the task-to-resource assignments CHAMPS performs. For example,
the cost of the downtime that results from deploying, installing and
configuring of a server (which can be derived from SLAs) needs to be
taken into account by CHAMPS so that the best possible server is
assigned to fulfilling a new request for change. In addition, CHAMPS
must know whether the administrator prefers rather to minimize the
downtime of a server or maximizing the overall profit. These policies
influence the process of assigning tasks to resources.
Distributing and installing changes (also referred to as
Provisioning), the fourth activity in an ITIL-conformant change management
process, is done by leveraging common-off-the-shelf provisioning
systems. CHAMPS uses IBM
Tivoli Provisioning Manager (TPM) to perform this activity. In
order to facilitate the execution of WS-BPEL workflows that CHAMPS
generates by Tivoli Provisioning Manager, we have integrated IBM WebSphere Process Choreographer,
a general-purpose workflow engine capable of interpreting WS-BPEL,
into TPM.
The CHAMPS Approach: Change Management in 4 Steps
Step 1: From Dependency Models to Workflows
The automation provided by CHAMPS relies on an explicit representation
of the dependencies between components subject to a change. More
specifically, CHAMPS uses the Solution Installation
(SI) XML Schema to provide this explicit representation. SI is a
recent technology whose goal is to facilitate the provisioning and
change management of multi-tiered application systems. In SI,
solutions comprise multiple levels of potentially nested Installable
Units (IU). Each IU has an associated deployment descriptor, an XML
file that describes the content of an installable unit, its checks
(required system resources, prerequisites), its dependencies and its
(configuration) actions. The XML Schema for the deployment descriptors
was initially called Installable Unit Deployment Descriptor (IUDD) and
has been re-labeled to Solution Deployment Descriptor (SDD) when work
on Solution
Deployment Descriptors started in OASIS.
This dependency model, expressed in one or more SDDs, is input to the
CHAMPS Task Graph Builder, which generates a provisioning
workflow to carry out the change. To do so, it performs the necessary
requirement checks, evaluates the dependencies, derives the proper
order in which change management operations need to be carried out,
and executes them on the target systems. Based on the dependencies (or
lack thereof), the Task Graph Builder is able to determine the order
in which provisioning activities need to be carried out, and whether
activities may happen concurrently.
Step 2: Reuse and late-binding of Change Management Workflows
Once a Task Graph has been computed, it is stored in the Task Graph
Library for further reuse: The information stored within a task
graph is specific to a given combination of software artifacts, but
completely decoupled from the target systems and their characteristics
(e.g., CPU speed, RAM, total/available diskspace). Consequently, Task
Graphs can be subsequently reused, modified and aggregated by an
administrator using common off-the-shelf workflow editors.
Step 3: Schedule-optimized Change Management
The purpose of the Planner & Scheduler, the second major component of the
CHAMPS system, is to assign tasks to available resources, according to
additional monetary and technical constraints, such as Service Level
Agreements (SLAs) and Policies. To do so, it computes (according to
various administrator-defined criteria) a Forward Schedule of Change
(aka Change Plan) that includes deadlines and maximizes the degree of
parallelism for tasks according to precedence and location constraints
expressed in the Task Graphs. Again, the WS-BPEL workflow language is
used to express the Forward Schedule of Change.
The goal of creating a Forward Schedule of Change is to maximize the
profits associated with performing the jobs associated with a selected
subset of RFCs. The profit for each RFC can be expressed as the value
of performing the job minus the associated costs. The generic nature
of our objective function incorporates a large number of practical
variants as special cases. In addition, the Planner & Scheduler is required
to obey a variety of realistic temporal, location-specific and other
types of constraints. This formulation is mathematically intractable
in the sense that it is effectively impossible for our (or any other)
algorithm to find an exact optimal solution in a reasonable amount of
time. The optimization techniques we employ allow us to come up with a
very hiqh quality solution in a time which scales nicely with the
problem size.
Step 4: Workflow-driven Provisioning
Once the Change Plan has been computed by the Planner & Scheduler, it
is input to a workflow engine that we have integrated into Tivoli
Provisioning Manager, which then retrieves the required software
packages from a Package Repository, and rolls out the requested
changes to the targets in the order specified in the Forward Schedule
of Change. An important part of this process is the ability of the
provisioning system to keep track of how well the roll-out of changes
progresses on the targets, and to feed this status information back
into the Planner & Scheduler. Being aware of the current status of the
provisioning process enables the Planner & Scheduler to track the
actual progress against the plan and perform on-line plan adjustment
(by re-computing the change plan) in case the process runs behind
schedule. In addition, such a feedback mechanism can be used to gain
an understanding on how long it takes to complete a task.
Disclaimer:
ITIL ® is a Registered Trade Marks of the Office of Government Commerce.
SPECjAppServer2004 ® is a registered trademark of the Standard Performance Evaluation Corporation.
|
United States
