Change Management
Changes have become the largest source of IT incidents. In cloud and virtualization environments, major incidents caused by infrastructure anomalies are becoming rarer, while the complex composition of information systems makes change risk and impact scope increasingly difficult to assess. The core goal of change management is to ensure changes meet business needs while minimizing change risk. NI-System v7.0 identifies change impact scope through CMDB, establishes a multi-dimensional risk assessment model, and embeds key change process control points to effectively control change risk.
Change Classification: Risk-Based Tiered Control
Not all changes can be required to undergo testing and risk assessment uniformly, or management costs would be too high. The system designs four types of changes by risk severity, each with differentiated control strategies.
| Change Type | Characteristics | Key Control Points | Authorization |
|---|---|---|---|
| Standard Change | Frequent, low risk and low cost. E.g., VM requests, scaling, port opening, device replacement | Business review, compliance check, post-change security check | Technical Lead |
| Normal Change | Infrequent, uncertain risk. E.g., business system upgrades, core device replacement, WAN circuit changes | Technical testing, risk assessment, CAB meeting, implementation, change review | Change Advisory Board (CAB) |
| Emergency Change | Changes needed to fix critical business impact, e.g., emergency security patching | Verbal authorization for quick implementation, change record supplemented afterward | CAB |
| Latent Change | Changes that occurred without authorization | Recording & traceability | — |
Standard Changes: Menu-Based, Template-Based, Process-Driven
Standard changes are frequent, pre-definable, and low in risk and cost. The key to standard changes is not additional risk assessment, but embedding control points through processes to ensure compliance and security.
- Menu-Based: Defines typical daily changes as a "standard change" menu for users to select on demand
- Template-Based: Defines fields for each type of standard change through ticket templates, and the data linkage between these fields and CMDB, improving CMDB data reuse while maintaining and revising CMDB data through standard change execution
- Process-Driven: Controls standard change compliance through processes, embedding basic security checks, resource request rationality, and resource recovery mechanisms
Standard changes fall into two categories: those under "service request" management (initiated by business users, handled by service desk, e.g., terminal, account, permission requests), and those under "standard change" management (initiated by internal or external IT personnel, not through the service desk). It is recommended to gradually classify frequent low-risk daily changes as standard changes to continuously improve change management efficiency.
Normal Changes: Five-Step Control Process
For normal changes with significant impact and uncertain risk, more thorough planning and assessment, as well as more formal authorization and post-review, are required. The system establishes a change management process consisting of five steps: technical testing and solution validation, risk assessment, change advisory board meeting, implementation, and change review.
1. Technical Testing & Solution Validation
The object of risk assessment is the "Implementation Plan," so it is necessary to ensure the plan has been tested and validated by more than one technical person.
- Lists change-related systems and owners through CMDB, requiring relevant system owners to provide test feedback
- Pre-builds technical implementation experience into a series of "Implementation Plans," forming continuous deposition of specific change experience
2. Risk Assessment
Risk assessment is the basis for approval authorization. Two problems must be solved: first, accurately identify change impact scope through CMDB to define risk assessment participants; second, establish a unified, multi-dimensional, weighted risk assessment method to avoid missing fundamental risk aspects.
Risk Assessment Personnel Composition: Standing risk assessment team (business system lead, infrastructure ops lead, core business system owner, security lead, technical expert) + dynamic risk assessment members (identified via CMDB as owners of other business systems with call relationships to the change object).
Multi-Dimensional Risk Assessment Model: The system establishes a unified risk assessment method covering five dimensions: change object, change impact, unknown risk, risk control, and abnormal impact, with an overall risk value calculated through weighting.
| Level | Risk Description | Assessment Mechanism |
|---|---|---|
| Level 1 | Very High Risk | On-site authorization at risk assessment meeting |
| Level 2 | High Risk | On-site authorization at risk assessment meeting |
| Level 3 | Moderate Risk | Online authorization by all leads |
| Level 4 | Low Risk | Online authorization by lead |
| Level 5 | Very Low Risk | Online authorization by lead |
3. Change Advisory Board Meeting
For high-risk changes, necessary on-site solution analysis meetings are required. Change plans are submitted online as data-driven, shareable plans, distributed to all CAB members for pre-meeting review. Changes with very high risk, those failing to obtain online approval, or those requiring short-notice deployment without timely online CAB approval require an offline meeting as soon as possible.
4. Implementation
Execute the change, with the system automatically sending pre- and post-implementation notifications. Change plans must be compared against maintenance windows to ensure execution within appropriate time windows.
5. Change Review
30 days after change implementation, review the change's effectiveness and whether any incidents occurred.
- Internal Check: IT department checks whether the change achieved its effect and whether any incidents occurred
- External Evaluation: Business stakeholders evaluate whether the change achieved its effect and whether it brought additional costs or adverse effects
Change Plan: Foundation of Risk Assessment
The change plan is the foundation for ensuring change success and risk assessment. To ensure all necessary personnel are available when needed, the team knows tasks and execution times in advance, not just before deployment.
- Downtime Schedule: Key information for comparing plans against release windows
- Planned Time: Planned start and end times, compared against release windows
- Deployment Tasks: Lists the work tasks and software requirements involved in this change for easy assessment and progress tracking
- Required Documents: Operation plan, rollback plan, test documentation, validation plan
Untested programs should not appear in production. The system distinguishes development, testing, and production environments. The test lead installs code into the test environment and notifies key business users for acceptance testing until approval is obtained.
CMDB & Change Management Integration
Without accurately grasping the composition of information systems, it is impossible to determine the impact scope of each change or define the appropriate risk assessment participants. Through the CMDB, the system automatically identifies the potential impact scope of change objects, helping identify risk assessment participants.
- Automatically identifies business systems and owners associated with the change object, adding them to risk assessment participants
- Compares planned times in the change plan against business system release windows
- Centrally displays all changes scheduled at the same time to avoid change plan conflicts
- Automatically identifies system call relationships, new VMs, and other potential changes