信息系统故障头号“杀手”

在日常IT运维管理中，变更与事件之间存在密切联系。变更旨在解决问题或优化系统性能，但不当变更也可能引发新事件，因此变更管理和事件管理是IT服务管理中不可或缺的两部分。

据Uptime Institute《2023年度故障分析》报告，64%的IT系统事件与配置和变更管理相关。一方面，有观点认为运维的目标是保障系统的稳定性，应避免频繁升级；另一方面，也有声音指出，通过变更是为了使系统更加稳定，提高IT的价值，主张进行升级。今天我们来聊聊IT运维过程中的变更管理流程和案例。

一、事件变更案例

2018年9月左右，公司业务部门反馈核心业务系统无法访问。经过十多分钟的排查，发现超融合架构中的一台服务器节点离线，导致该节点上的虚拟机宕机。同时，由于集群资源占用率超过90%，无法进行节点漂移，业务无法快速恢复。随即，服务器工程师进行了故障服务器的硬件重启，集群逐步恢复正常。最终，在厂商的协助下，事故原因被定位为服务器CPU微码存在漏洞，需要进行升级，否则后续可能还会出现整体集群宕机的情况。经过推进二十多台服务器的微码变更升级，后续未再出现此类问题。

经过组织事件复盘确认，公司此前已购买了服务器及超融合架构的每季度巡检服务，但由于运维工程师的经验判断，认为硬件一般不会出现问题，因此未进行相关巡检，也没有评估是否存在漏洞，最终导致了此次事件的发生。此次事件明确了一项重要要求：运维的主要职责是保障软硬件平台的稳定，任何升级或变更都需经过评估后再确定方案，避免未做评估出现问题后就以保障稳定性为借口推卸责任。评估的记录不仅是保障系统稳定的依据，也是维护运维专业度的重要凭证。

二、变更和变更管理

变更指的是“添加、修改或删除任何可能对服务产生直接或间接影响的内容”。简单来说，对组织的IT基础设施所做的任何可能影响组织操作的更改都称为IT变更。这包括但不限于更换打印机、投影仪、服务器等设备，以及软件更新、配置调整、网络优化等。

IT变更管理是指对IT基础设施或服务的任何修改进行控制和管理的过程，以确保这些修改能够平稳且安全地实施，同时最小化对业务运营的影响。变更管理的目标是通过规范化的流程，控制变更的风险，减少服务中断，提高IT服务的稳定性和可靠性。

三、事件、问题、变更关系

四、为什么要做变更管理

1. 控制风险

• 评估风险：变更管理通过评估变更的风险和潜在影响，确保变更的安全性和可靠性。
• 预防问题：通过风险评估和预防措施，减少变更过程中可能出现的问题和意外情况。

2. 减少中断

• 快速恢复：通过预先制定的回滚计划，确保在变更失败时能够迅速恢复，减少业务中断时间。
• 最小化影响：通过在非高峰时段进行变更，减少对业务的影响。

3. 提高服务质量

• 优化系统：变更管理不仅解决现有问题，还可以优化系统性能，提高系统的稳定性和可靠性。
• 持续改进：通过定期的变更，引入新技术和新功能，提升服务质量，满足业务发展的需求。

4. 确保合规性

• 符合法规：金融行业有严格的法规和标准要求，变更管理可以帮助组织确保变更过程符合这些要求。
• 审计和记录：详细的变更记录和文档可以用于审计和合规性检查，提供透明和可追溯的证据。

5. 提高透明度和沟通

• 信息共享：变更管理确保所有相关方（如用户、技术支持人员、管理层等）都了解变更的时间表和可能的影响，提高透明度。
• 协调合作：通过变更管理流程，促进不同部门之间的协调和合作，确保变更的顺利实施。

6. 优化资源利用

• 合理分配资源：变更管理通过合理的资源分配和调度，确保变更的高效实施，避免资源浪费。
• 优先级管理：通过优先级划分，确保重要的变更优先处理，提高资源利用效率。

五、变更管理流程

1. 变更请求（Change Request）

• 发起变更：当需要对现有的IT环境进行任何更改时，比如更新软件版本、硬件升级等，都会发起一个变更请求。
• 记录变更：详细记录变更的目的、影响范围、预期结果等信息。

2. 变更评估（Change Assessment）

• 影响分析：评估变更可能带来的正面和负面影响，包括对业务的影响。
• 风险评估：识别变更过程中可能出现的风险，并制定相应的缓解措施。
• 资源评估：确定完成变更所需的人力、物力资源。

3. 变更审批（Change Approval）

• 审批决策：根据变更的影响和风险评估，由变更管理委员会（Change Advisory Board, CAB）或指定人员进行审批。
• 授权执行：一旦变更获得批准，将正式授权变更团队执行变更计划。

4. 变更实施（Change Implementation）

• 计划制定：基于审批通过的变更请求，制定详细的实施计划，包括时间表、步骤、回滚计划等。
• 实施变更：按照计划执行变更，通常在非工作时间以减少对用户的影响。
• 监控执行：在变更实施过程中持续监控，确保变更按计划顺利进行。

5. 变更验证与关闭（Change Verification and Closure）

• 效果验证：变更完成后，进行测试以验证变更是否达到预期效果，没有引入新的问题。
• 文档更新：更新相关文档，如配置管理数据库（Configuration Management Database, CMDB），以反映最新的IT环境状态。
• 变更关闭：确认变更成功后，正式关闭变更请求。

6. 回顾与改进（Review and Improvement）

• 变更回顾：定期回顾变更管理过程，总结经验教训，识别可以改进的地方。
• 持续优化：基于回顾的结果，不断优化变更管理流程，提高效率和效果。

六、变更类型

1. 标准变更（Standard Changes）

• 定义：这些变更是预定义的、低风险且频繁发生的变更，通常有标准化的流程和已知的成功模式。
• 特点
• 预先经过详细评估和批准。
• 具有明确的文档和操作指南。
• 可以由一线技术支持人员或自动化工具直接执行。
• 不需要每次变更都进行单独审批。
• 示例：常规备份、标准配置更新等。

2. 正常变更（Normal Changes）

• 定义：这是最常见的变更类型，涉及中等风险和复杂度的变更。
• 特点
• 需要经过详细的评估、规划和审批。
• 通常需要变更管理委员会（CAB）的审批。
• 实施前需要制定详细的实施计划和回滚方案。
• 需要进行充分的测试和验证。
• 示例：应用程序升级、服务器硬件更换、网络设备配置修改等。

3. 紧急变更（Emergency Changes）

• 定义：这些变更是为了应对紧急情况或解决严重问题而立即实施的变更。
• 特点
• 高风险、高优先级。
• 需要在最短时间内实施，以恢复服务或防止进一步的损害。
• 通常需要快速审批流程，有时甚至需要绕过常规的审批程序。
• 事后需要进行详细的回顾和记录。
• 示例：修复安全漏洞、恢复服务中断、应对自然灾害等。

4. 非紧急重大变更（Non-Emergency Major Changes）

• 定义：这些变更是涉及重大技术或业务影响的变更，但不是紧急情况。
• 特点
• 高风险、高复杂度。
• 需要详细的规划、多部门协作和高级管理层的审批。
• 实施前需要进行全面的测试和验证。
• 通常需要详细的回滚计划和应急响应方案。
• 示例：数据中心迁移、核心系统升级、大规模网络架构调整等。

七、变更角色

在IT运维变更管理中，不同角色承担着不同的职责和任务，确保变更过程的顺利进行和变更目标的实现。以下是常见的变更管理角色及其职责：

1. 变更请求者（Change Requester）

• 职责
• 发起变更请求，提供变更的背景、目的和预期效果。
• 提供必要的技术细节和支持文档。
• 跟踪变更的审批和实施进度。

2. 变更经理（Change Manager）

• 职责
• 负责整个变更管理流程的协调和监督。
• 组织和主持变更管理委员会（CAB）会议。
• 审批变更请求，确保变更符合组织的政策和标准。
• 确保变更过程中的沟通和协调。
• 定期回顾变更管理过程，总结经验教训。
• 识别可以改进的地方，提出改进建议。
• 确保变更管理流程的持续优化。

3. 变更顾问委员会（Change Advisory Board, CAB）

• 成员
• IT部门的代表。
• 业务部门的代表。
• 安全专家。
• 项目管理人员。
• 职责
• 评估变更的风险和影响。
• 提供专业意见和建议。
• 审批或拒绝变更请求。
• 确保变更符合业务和技术要求。

4. 变更实施者（Change Implementer）

• 职责
• 负责具体实施变更。
• 制定详细的实施计划和回滚方案。
• 执行变更操作并记录实施过程。
• 确保变更按计划进行，及时报告任何问题。

5. 变更验证者（Change Verifier）

• 职责
• 验证变更是否按预期生效。
• 进行测试和验证，确保变更没有引入新的问题。
• 记录验证结果，提供反馈。

6. 变更审批者（Change Approver）

• 职责
• 审核变更请求，确保变更的必要性和合理性。
• 批准或拒绝变更请求。
• 确保变更符合组织的政策和标准。

7. 服务台/帮助台（Service Desk/Help Desk）

• 职责
• 接收和记录变更请求。
• 将变更请求转发给相应的变更经理或实施者。
• 跟踪变更的进展，及时向请求者反馈。

8. 项目经理（Project Manager）

• 职责
• 对于涉及项目的变更，负责项目的整体管理和协调。
• 确保变更与项目目标一致。
• 协调资源，确保变更按时完成。

9. 配置管理员（Configuration Manager）

• 职责
• 更新配置管理数据库（CMDB），记录变更后的配置信息。
• 确保配置信息的准确性和完整性。

10. 安全专家（Security Specialist）

• 职责
• 评估变更对安全的影响。
• 提供安全相关的建议和指导。
• 确保变更符合安全标准和合规要求。

11. 业务负责人（Business Analyst）

• 职责
• 评估变更对业务的影响。
• 提供业务方面的建议和指导。
• 确保变更符合业务需求和目标。

八、常见的变更管理挑战

1. 评估验证不充分，成功率低

评估验证不充分是变更管理中常见的挑战之一。变更前的风险评估和影响分析不够详细，未能预见潜在问题。此外，测试也不够全面，未能发现潜在的缺陷。实施后的验证过程不够严格，无法确保变更达到预期效果。这些问题会导致变更成功率低下，甚至引发新的问题，影响系统的稳定性和可靠性。

2. 未经授权的非法变更

未经授权的非法变更也是一个严重的挑战。这通常是由于变更管理流程不严格，审批权限分配不合理，或者员工对变更管理的重要性认识不足，擅自进行变更。这种行为不仅可能导致系统不稳定，还可能带来安全隐患。

3. 紧急变更过多

紧急变更过多是另一个常见的挑战。这通常是由于日常运维中缺乏有效的计划和预防措施，导致频繁出现需要立即处理的变更。紧急变更不仅占用大量资源，影响其他变更的实施和日常运维工作，还会增加团队的压力，影响士气和工作效率。

九、变更管理最佳实践

1. 建立标准化的变更管理流程

• 定义清晰的流程：制定详细的变更管理流程，包括变更请求、评估、审批、实施、验证和关闭等各个环节。
• 文档化流程：将变更管理流程文档化，确保所有相关人员都能理解和遵循。
• 持续优化：定期回顾和优化变更管理流程，确保其适应组织的变化和发展。

2. 进行详细的风险评估和影响分析

• 全面评估：在变更请求阶段，进行全面的风险评估和影响分析，考虑变更对技术、业务和安全的影响。
• 使用专业工具：利用专业的风险评估工具和技术，提高评估的准确性和可靠性。
• 多部门协作：邀请相关技术、业务和安全部门的专家参与评估，确保评估的全面性和专业性。

3. 实施严格的审批制度

• 多层次审批：建立多层次的审批制度，确保变更请求经过多个层级的审查和批准。
• 变更顾问委员会（CAB）：设立变更顾问委员会（CAB），由多部门代表组成，共同评估和审批变更请求。
• 明确审批权限：明确各级审批人员的权限和责任，确保审批过程的透明和高效。

4. 详细规划和测试

• 制定详细的实施计划：为每个变更制定详细的实施计划，包括时间表、步骤、责任人、回滚方案等。
• 全面测试：在变更实施前进行全面的测试，包括单元测试、集成测试和用户验收测试（UAT），确保变更在各种环境下都能正常运行。
• 模拟环境：使用模拟环境进行测试，避免对生产环境造成影响。

5. 严格的变更实施和监控

• 标准化操作：确保变更实施过程中的操作标准化，减少人为错误。
• 实时监控：在变更实施过程中进行实时监控，及时发现和解决问题。
• 记录详细日志：详细记录变更实施过程中的每一步操作，以便后续的审计和回顾。

6. 有效的验证和关闭

• 严格验证：变更实施后，进行严格的验证和测试，确保变更达到预期效果。
• 用户确认：获取用户的确认，确保变更满足业务需求。
• 正式关闭：在确认变更成功后，正式关闭变更请求，并更新相关文档和配置管理数据库（CMDB）。

7. 建立应急响应机制

• 回滚计划：在变更实施前制定详细的回滚计划，确保在出现问题时能够迅速恢复。
• 应急响应团队：建立应急响应团队，确保在紧急情况下能够迅速采取行动。
• 定期演练：定期进行应急响应演练，提高团队的应急处理能力。

8. 强化沟通和协作

• 建立沟通渠道：建立明确的沟通渠道和机制，确保信息的及时传递。
• 定期会议：定期召开变更管理委员会（CAB）会议，讨论和评估变更请求。
• 使用协作工具：使用项目管理工具和协作平台，提高透明度和协作效率。

9. 持续培训和教育

• 定期培训：定期对变更管理团队进行培训，提高他们的技术水平和知识水平。
• 知识分享：建立知识分享机制，确保团队成员可以互相学习和交流。
• 案例分析：定期进行变更管理案例分析，总结经验教训，提高团队的应对能力。

10. 定期回顾和持续改进

• 定期回顾：定期回顾变更管理过程，总结经验教训，识别可以改进的地方。
• 持续改进：根据回顾结果，持续优化变更管理流程，提高效率和效果。
• 绩效指标：设定变更管理的绩效指标，定期评估和改进。