This article describes the process that is used for managing implementation of change to infrastructure including hardware, software, services or related documentation. The Change Management process is in place to minimize risk (including security risk) and disruption to IT infrastructure caused by change.

A change request may be a result one of the following events or processes:

  • Incident Management
  • Problem Management
  • Release Management
  • Availability Management
  • Capacity Management

This process does not apply to hosting partners which are required to maintain their own change a management process for hardware, network and operating system level change management activities.

Audience

All developers and data center ops staffs.

Purpose

This article describes a best practices approach to change management.

Definitions

  • Incident – An incident occurs when a system is not functioning as expected or a system’s parameters are not within a specified range. It may be a result of a hardware/software failure or mis-configuration.
  • Problem – An occurrence of a same/similar incident multiple times or an incident affecting many users/systems, a result of alert or diagnostic indicating that a system is not operating in an expected way.
  • Configuration Item – Configuration items (CIs) are the various components of the infrastructure that make up the whole, including associated items such as documentation, user guides, procedures and licenses.
  • Business Services – These are business functions (e.g. Email delivery) that are performed by one or more CIs that are being impacted by a proposed change.
  • Release – The process of deploying new software and/or hardware.
  • Availability – The process of performing actions that will increase MTBF (mean-time between failures).
  • Capacity – The process of adding additional system resources to address performance or scalability issues.
  • Change Management Database (CMDB) – A central repository for managing all change requests.

Roles

  • Originator – Person who submits the Change Request (this can be on behalf of an external party)
  • Initial Approver – Usually a manager that approves whether or not the change request should be performed.
  • Peer Reviewer – A technical person who vets the change from a technical perspective.
  • Final Approver – Person who has the authority to approve the execution of the requested changes.
  • Implementer – Person responsible for implementing the requested changes
  • Verifier – Person who is responsible for verifying that the change has been made correctly. Verifies changes for quality and compliance purposes.

Process

  1. Request Submitted – A Change Request can be a result of a customer enhancement request, an Incident such as an internet outage, a identified security flaw. A Change Request may also be the result of strategic planning decision such as adding capacity (e.g. adding memory or storage). Jira (by Atlassian) is used as the CMDB.
  2. Once the Change Request form has been submitted, it must be approved by management (e.g. software development manager or IT manager). Change requests can be deferred or declined based on management’s perogative.
  3. Approved requests are prioritized and assigned to an implementer. Management is responsible for tracking change requests to completion (on an ongoing basis).
  4. The implementer much follow the Patch Management Process when implementing a change. This includes scheduling when and how the change will be implemented (e.g. included in a product release or implemented after hours).
  5. For complex changes, a peer reviewer may be assigned by management to review a proposed approach, to assist with testing or to review a change made to a production environment.
  6. The workflow for a change request varies based on the nature of the task (multiple workflows have been defined in Jira). For example, software enhancements may flow from the development team to the quality assurance team.
  7. The CMDB must be updated as change request progresses (for example, a one workflow that is used is submit->approve->open->in progress->complete->verified->closed). The final step in the process is to pass the Change Request to a Verifier. This ensures that a change occurred according to plan. Once the Change Request has been verified it can be marked as closed.