2. 变更管理基础：ITIL变更管理流程、变更类型与变更生命周期
在自动化门禁体系中，变更管理是控制风险、保障服务连续性的核心流程。本章基于ITIL最佳实践，系统梳理变更管理的三大支柱：流程框架、变更类型与生命周期，为后续自动化测试验证与部署门禁设计奠定理论基础。
2.1 ITIL变更管理流程
ITIL（Information Technology Infrastructure Library）定义的变更管理流程包含以下关键步骤，每个步骤都对应明确的角色与审批节点：
| 步骤 | 活动描述 | 关键角色 | 产出物 |
|---|---|---|---|
| 1. 创建与记录 | 提交变更请求（RFC），记录变更描述、原因、影响范围 | 变更发起人 | RFC工单 |
| 2. 分类与优先级 | 根据影响度、紧急度确定变更类型与优先级 | 变更经理 | 分类标签 |
| 3. 评估与审批 | 技术评审、风险分析、资源评估，提交变更咨询委员会（CAB）审批 | CAB / 变更经理 | 审批决议 |
| 4. 构建与测试 | 开发变更内容，在测试环境执行验证（含自动化门禁测试） | 开发/测试团队 | 测试报告 |
| 5. 实施与部署 | 按计划将变更推送到生产环境，执行回滚预案 | 运维团队 | 部署记录 |
| 6. 评审与关闭 | 变更后评审（PIR），确认变更达成目标，关闭工单 | 变更经理 | PIR报告 |
自动化门禁切入点：在“构建与测试”步骤中，自动化测试门禁作为质量闸门，自动拦截未通过验证的变更，确保只有经过充分测试的代码才能进入部署环节。
2.2 变更类型：标准 / 紧急 / 正常
ITIL将变更分为三种类型，每种类型对应不同的审批流程、风险等级与自动化策略：
| 变更类型 | 定义 | 风险等级 | 审批流程 | 自动化门禁策略 |
|---|---|---|---|---|
| 标准变更 | 预授权、低风险、重复执行的变更（如补丁更新、配置参数调整） | 低 | 无需CAB审批，按预定义流程执行 | 全自动门禁，仅需通过预置测试套件 |
| 紧急变更 | 需立即修复的严重故障或安全漏洞（如生产环境宕机、数据泄露） | 高 | 紧急CAB（ECAB）快速审批，可事后补录 | 简化门禁，仅执行关键安全与可用性测试 |
| 正常变更 | 非标准、非紧急的常规变更（如功能上线、架构调整） | 中/高 | 标准CAB审批，需完整评估与测试 | 全量门禁，包含功能、性能、安全、兼容性测试 |
常见误区：将紧急变更当作“快速通道”滥用，会导致门禁失效、风险失控。紧急变更必须严格限定在“服务中断”或“安全事件”场景，且事后必须补全测试与评审记录。
2.3 变更生命周期
变更生命周期覆盖从提出到关闭的完整过程，是自动化门禁设计的时间轴参考。下图展示了变更生命周期的核心阶段与状态转换：
2.4 变更生命周期中的关键状态
在自动化门禁系统中，变更工单的状态流转是触发测试与部署动作的信号。以下是标准状态机定义：
- 草稿（Draft）：变更发起人正在填写RFC，尚未提交。
- 已提交（Submitted）：RFC正式提交，进入分类与评估队列。
- 已审批（Approved）：CAB或变更经理批准变更，允许进入构建阶段。
- 测试中（Testing）：自动化门禁正在执行测试套件，状态为“进行中”。
- 测试通过（Passed）：所有门禁测试通过，变更可进入部署。
- 测试失败（Failed）：至少一项门禁测试未通过，变更被阻塞，需回退修改。
- 已部署（Deployed）：变更已推送到生产环境。
- 已关闭（Closed）：变更后评审完成，工单关闭。
自动化门禁设计要点：在“测试中”状态，系统应自动触发CI/CD流水线中的测试任务，并将结果回写至变更工单。测试失败时，自动发送通知并锁定部署权限，直至问题修复并重新通过门禁。
2.5 变更类型与门禁策略映射
不同类型的变更对应不同的门禁策略，确保风险与测试成本平衡：
| 变更类型 | 门禁测试范围 | 门禁执行方式 | 失败处理策略 |
|---|---|---|---|
| 标准变更 | 单元测试 + 静态代码扫描 | 全自动，无人工干预 | 自动回退，通知变更经理 |
| 紧急变更 | 关键功能测试 + 安全扫描 | 自动执行，允许人工跳过（需事后审批） | 跳过门禁需ECAB授权，事后补测 |
| 正常变更 | 全量测试（功能、性能、安全、集成、回归） | 自动执行 + 人工审批门禁报告 | 必须修复后重新通过门禁 |
通过上述映射，自动化门禁系统能够根据变更类型动态调整测试深度与审批流程，在保障质量的同时提升交付效率。