2. 影响评估核心概念
影响评估是变更管理流程中承上启下的关键环节。它并非简单的“会不会出问题”判断，而是一个系统化的分析过程，旨在量化变更对现有环境、业务流程、成本结构及组织风险敞口的综合影响。评估结论直接决定变更的优先级、回退方案设计及审批层级。
2.1 影响评估的定义
影响评估（Impact Assessment, IA）是指在变更申请（RFC）提交后、实施前，由变更经理或指定评估团队对变更所引发的预期变化与潜在后果进行的结构化分析。其核心输出是一份影响评估报告，该报告需明确回答以下三个问题：
- 变更了什么？ —— 配置项（CI）的增、删、改状态。
- 谁会被影响？ —— 关联的IT服务、用户群体、下游系统。
- 影响有多大？ —— 服务中断时长、数据一致性风险、合规偏离度。
关键原则： 影响评估必须基于证据，而非直觉。谈判记录、历史故障工单、监控数据是三大核心证据来源。缺乏证据的评估结论在故障排查中不具备可追溯性。
2.2 评估四维度模型
一个完整的影响评估应覆盖以下四个维度。任何维度的缺失都可能导致评估结论片面，进而引发变更故障。
| 维度 | 核心关注点 | 典型评估指标 | 证据来源示例 |
|---|---|---|---|
| 技术 | 变更对IT基础设施、应用架构、网络拓扑的直接影响 | 配置项依赖数、接口兼容性、版本回退复杂度 | CMDB关系图谱、架构设计文档 |
| 业务 | 变更对业务流程连续性、用户体验、SLA达成率的影响 | 受影响用户数、关键业务时段、功能可用性百分比 | 业务影响分析（BIA）报告、用户投诉记录 |
| 成本 | 变更实施与回退所消耗的人力、时间、许可及硬件资源 | 实施工时、回退预算、额外软件许可费用 | 财务审批单、供应商报价、谈判记录中的成本条款 |
| 风险 | 变更失败的概率、潜在安全漏洞、合规违规可能性 | 风险等级（高/中/低）、已知错误关联数、审计合规项 | 风险登记册、安全扫描报告、历史变更故障复盘 |
实战提示： 在故障排查场景中，技术维度和业务维度的冲突最为常见。例如，技术团队认为“仅重启服务，影响极小”，但业务方可能因该服务处于月末结算高峰期而判定为“重大影响”。此时，谈判记录中的业务窗口协商结论是裁定冲突的关键证据。
2.3 评估时机：何时做？做几次？
影响评估并非一次性活动。在变更的生命周期中，至少存在三个关键的评估节点。错过任何一个节点，都可能导致故障排查时证据链断裂。
- 初始评估（RFC 提交时）
- 由变更申请人完成初步影响判断，用于确定变更类别（标准/正常/紧急）。
- 输出：变更类别建议 + 初步影响范围。
- 深度评估（变更审批前）
- 由变更经理组织 CAB（变更咨询委员会）或技术专家进行四维度全面分析。
- 此阶段必须引入谈判记录作为证据，验证业务窗口、回退时限、资源承诺等关键条款。
- 输出：正式影响评估报告 + 审批决策建议。
- 实施后评估（变更关闭前）
- 对比实际影响与评估预期，识别偏差并记录为组织过程资产。
- 若发生故障，此阶段的评估数据是根因分析的核心输入。
- 输出：变更后审查报告 + 改进项。
常见陷阱： 许多组织只做“初始评估”，将深度评估流于形式，导致变更实施后才发现影响范围远超预期。在故障排查中，若缺失深度评估阶段的谈判记录，将无法追溯“是谁同意了在业务高峰期实施变更”这一关键决策，从而陷入责任推诿。
2.4 影响评估与故障排查的关联
在变更故障排查中，影响评估报告是第一手侦查资料。排查人员通过对比“评估时预测的影响”与“实际发生的影响”，可以快速定位偏差点，从而缩小排查范围。
- 若实际影响 > 评估影响：说明评估时遗漏了关键依赖项或业务场景。排查重点应转向未被评估的配置项。
- 若实际影响 < 评估影响：说明评估时过于保守，或变更实施过程中采取了额外的缓解措施。排查重点应转向缓解措施是否失效。
- 若影响类型与评估完全不符：例如评估为“性能影响”，实际却出现“数据丢失”。这通常意味着变更内容与RFC描述不一致，需立即审查变更实施脚本与谈判记录中的实施步骤。
证据链闭环： 谈判记录 → 影响评估报告 → 变更实施计划 → 故障排查日志。这四个文档构成了变更故障排查的完整证据链。任何一个环节的缺失或矛盾，都会导致排查效率急剧下降。