Updated on 2026-06-23 GMT+08:00

Overview

Change management is the core module for ensuring secure and orderly O&M operations. Its core function is to build safe production capabilities covering the entire lifecycle of O&M operations. This module employs a systematic process design and a multi-layered risk control framework to proactively and accurately identify potential risks, enabling the timely development of targeted countermeasures. This approach significantly mitigates risks associated with change operations and provides robust assurance for the stable operation of the O&M system. This module manages the core services of the change process. It integrates key capabilities such as a change calendar, change center, change configuration, and change control. These capabilities work together to form a closed-loop change management system including planning, execution, configuration, and monitoring.

Prerequisites

You have enabled the Change Management package. For details about billing, see Billing Items.

Core Functions

Change calendar: You can check change ticket data based on the calendar view and change distribution based on different states (such as coloring and time windows).

Change center: You can manage change processes using change tickets, covering change ticket creation, review, and execution. Change operation and management personnel can realize a unified management using this function.

Change configurations: You can complete configurations for changes in the change center and use basic configuration change capabilities such as configuration review. You can specify reviewers and a review process for change tickets based on service requirements.

Change control: When changing resources, you can only execute scripts, jobs, or query accounts and passwords if you use a service ticket to request privilege escalation. This ensures that the operator and operation object of a change ticket match the actual resources you want to change, limiting the permissions of the operator for enhanced security.

Figure 1 Change risk control process

Change Management Introduction

Core Advantages

The change management module has multiple advantages due to its systematic design and flexible adaptability.

  • High risk controllability: This module includes risk identification, hierarchical review, and permission control throughout the entire process. It minimizes the potential risks of change operations, especially for frequent changes of core service systems, preventing service interruptions caused by misoperations or permission abuse.
  • High process standardization: The unified change ticket mode and standard operation nodes ensure that the change operations of different teams and personnel comply with the same standards, reduce process deviation caused by human factors, and improve O&M efficiency.
  • Flexible adaptation: The review process and permission rules can be specified based on the enterprise business scale, organizational structure, and management requirements. This meets the lightweight management requirements of small teams and adapts to complex multi-level review scenarios of large enterprises.
  • Complete traceability: All data records (such as change requests and execution results) generated during the process provide a clear basis for post-event audit and problem tracing, helping enterprises meet compliance requirements.

Benefits

COC change risk control management helps customers ensure secure service production and enhance their capabilities in change management compliance, security O&M practice, and risk prevention.

  • With SOPs and well-designed review processes, change solutions will be executed 100% by following the standard process.
  • The security operations are reliable during the change process, ensuring zero critical O&M incidents.
  • OREO's high-risk command detection algorithm intelligently intercepts 99% of high-risk commands, effectively preventing potential risks.

Typical Scenarios

The change management module plays a key role in various O&M scenarios. The following lists typical scenarios:

  • Routine system iteration: When the service system needs to be updated or parameters need to be optimized, you can submit a change ticket through the change center. After the technical owner reviews the ticket, you can execute the ticket in the regular time window planned in the change calendar. This ensures that the iteration process does not affect service continuity.
  • Emergency fault rectification: If a sudden fault occurs in the production environment, you can enable the emergency review process through change configuration and skip unnecessary nodes. In addition, change management is used to ensure that the permissions of emergency operations are compliant and services can be quickly restored.
  • Large-scale resource adjustment: For changes that involve multiple resources, such as server cluster capacity expansion and database migration, the change calendar clearly displays the time nodes and owners of each phase to avoid resource conflicts. The change center tracks the execution status of each step to ensure that the overall process is carried out in an orderly manner.
  • Cross-team collaboration change: When changes involve multiple teams, such as development, test, and O&M teams, you can specify multiple team review nodes through change configuration. The change center can synchronize information, reducing cross-department communication costs and improving collaboration efficiency.

Change Levels

Change level (with A-level risk being the highest, decreasing sequentially to D-level) is a common risk quantification grading logic in change management systems. The key is to match changes carrying different risk levels with control resources and review processes. This avoids insufficient control for high-risk changes or excessive control over low-risk changes.

The essence of change levels is to transform abstract risks into executable control standards. The level classification from A to D is not based solely on subjective judgment, but rather a quantitative assessment combining three core dimensions: scope of impact, probability of occurrence, and severity of consequences. The specific corresponding relationships can be referred to in the table below:

Table 1 Change levels

Change Level

Core Risk Feature (Quantitative Dimension)

Typical Risk Consequence

Level A (highest risk)

  • Impact scope: cross-department or all business lines
  • Probability of occurrence: medium-high
  • Severity of consequences: Services are interrupted, compliance violations occur, and huge economic losses are caused.

Services are interrupted, customers complain on a large scale, regulatory penalties are imposed, and huge economic losses are caused.

Level B (high risk)

  • Scope of impact: core services of a single department
  • Probability of occurrence: medium
  • Severity of consequences: Department-level efficiency decreases, and partial compliance risks exist.

Department work is delayed, there are minor compliance risks, and huge economic losses are caused.

Level C (medium risk)

  • Scope of impact: a single team or a single service phase
  • Probability of occurrence: low
  • Severity of consequences: Operations are inconvenient, and no direct economic loss is caused.

The team efficiency decreases slightly, and no additional cost is required for rectification.

Level D (lowest risk)

  • Scope of impact: individual operations or non-core phases
  • Probability of occurrence: extremely low
  • Severity of consequences: no substantial impact.

No negative consequences occur. The experience may even be optimized.