« Version 4.1 - 7.7 Risk Assessment | Main | Version 4.1 - 7.9 Incident Response Framework »

Version 4.1 - 7.8 Change management process

This is something that I know I won't have any trouble with in any way, shape or form. Since I have worked on a number of enterprise networks, I am very familiar with the change management process. I have also used a number of different software systems to monitor and document changes.

Regardless of system, it starts with someone needing to change a configuration or system. Changes are generated by multiple sources: troubleshooting, audit findings and project implementations are just a few examples. Once you know you need to change something, you put in a change ticket. The ticket should say what you want to change (affected systems), when you want to implement the change, implementation steps, backout steps (if needed), and expected outage time (when applicable). The change is at that point a "proposed" change. On a regular basis (usually weekly), the Change Approval Board meets to review upcoming changes. The changes are presented and most are approved. Changes can be denied based on scheduling conflicts, impact to other systems or the need for more "socialization" of the change (impacted users/teams need to know and evaluate any impacts). Once your change is approved, it is implemented at the scheduled date/time. Once the change has been completed successfully, it should be marked as implemented or closed (based on your system). If the change was not completed successfully, it should be backed out (if possible). Change management is normally tightly integrated with Incident Management - since changes can cause incidents (unplanned outages).

Any change that does not have an associated change ticket is an unauthorized change. Depending on your environment, that can be something that could get you fired. If you perform an unauthorized change and it creates a major outage - update your resume. However, you may find that you will perform an unauthorized change because of a major outage.

There are various types of changes:
Normal changes - one that goes through the approval process mentioned above
Routine/Standard changes - sometimes CM notes that there are routine MACD changes that have proven to not be risky (repeated successfully multiple times).
Emergency changes - ones that are related to an incident and need to be approved immediately to restore service (sometimes these can be approved by Incident Management and documented after service is restored)

Changes can also be categorized based on risk. The implementation of "no shut" or vlan assignment for an access port has a much different risk than the upgrade of IOS on a switch connecting to multiple server farms. Often the software accounts for some type of Risk Matrix to categorize the change level. A category 1 risk (could affect multiple services/large amount of users) may be more scrutinized during the approval process - whereas a category 4 risk (routine) may be a change that is merely documented (automatic approval). A "change window" is the scheduled start and stop time of a change.


Powered by
Movable Type 3.2