2. 风险评估基础：风险因子识别、风险等级定义、变更影响范围分析
在自助服务变更场景中，风险评估是编排引擎的“第一道安全闸门”。其核心目标是在变更执行前，通过结构化方法识别潜在故障源、量化风险等级、划定影响边界，从而决定是否允许变更进入执行阶段。本章围绕三个核心环节展开：风险因子识别、风险等级定义、变更影响范围分析。
2.1 风险因子识别
风险因子是导致变更失败或引发生产事件的独立变量。根据SRE实践经验，可将风险因子归纳为以下六大类：
| 类别 | 典型因子 | 说明 |
|---|---|---|
| 变更对象 | 配置项类型、版本跨度、依赖深度 | 核心服务 vs 边缘服务；大版本跳跃 vs 小补丁 |
| 变更操作 | 操作类型（增/删/改/重启）、执行时长、幂等性 | 删除操作风险最高；非幂等操作需额外防护 |
| 变更窗口 | 业务高峰/低谷、节假日、大促期 | 窗口内并发流量越大，风险系数越高 |
| 历史数据 | 同类变更失败率、回滚频率、告警关联度 | 历史失败率 > 5% 的变更类型自动标记高风险 |
| 环境状态 | 目标集群健康度、资源水位、依赖服务可用性 | CPU/内存超阈值时，变更风险自动升级 |
| 合规与权限 | 审批链完整性、变更人权限等级、审计追踪 | 缺少二级审批的变更直接拦截 |
实践建议：风险因子应支持动态扩展。建议在编排引擎中设计因子注册表，允许团队通过配置中心新增自定义因子（如“是否涉及数据库Schema变更”），无需修改核心代码。
2.2 风险等级定义
风险等级是编排引擎执行“放行/拦截/人工审批”决策的依据。采用加权评分法，将每个风险因子映射为数值分数，最终汇总得到综合风险指数。等级定义如下：
| 风险等级 | 综合指数范围 | 编排决策 | 典型场景 |
|---|---|---|---|
| 低风险 | 0 – 20 | 自动执行，无需审批 | 非核心服务配置参数修改、日志级别调整 |
| 中风险 | 21 – 50 | 自动执行 + 事后通知 | 灰度发布、缓存刷新、非关键依赖升级 |
| 高风险 | 51 – 80 | 需人工审批 + 强制灰度 | 核心服务版本升级、数据库索引变更 |
| 严重风险 | 81 – 100 | 拦截，需变更管理委员会评审 | 全量流量切换、跨机房架构调整、删除生产数据 |
关键指标：风险等级阈值必须可配置。生产环境建议将“高风险”阈值设为 50，而预发环境可放宽至 70，避免过度拦截影响变更效率。
2.3 变更影响范围分析
影响范围分析旨在回答三个问题：“改了什么？”、“影响了谁？”、“波及多广？”。分析过程分为以下步骤：
- 静态依赖分析：基于CMDB和服务拓扑图，识别变更对象的直接依赖与间接依赖。例如，修改A服务的配置，需检查A的下游消费者B、C，以及B的消费者D。
- 动态调用链分析：结合APM系统，获取变更对象在近24小时内的实时调用链，识别当前活跃的调用方与被调用方。
- 数据流影响评估：若变更涉及数据库或消息队列，需分析数据流向，判断是否会导致数据不一致、延迟增加或死锁。
- 用户影响面量化：统计受影响服务的QPS、P99延迟、错误率，以及关联的用户会话数。例如，影响范围包括“3个核心API，影响约12%的活跃用户”。
避坑提醒：静态依赖分析容易遗漏“间接依赖”和“运行时动态路由”。务必结合动态调用链数据，否则影响范围可能被低估50%以上。
2.4 风险因子权重与评分示例
为便于编排引擎计算，每个风险因子需分配权重和评分函数。以下是一个简化的评分示例：
| 风险因子 | 权重 | 评分条件 | 得分 |
|---|---|---|---|
| 变更对象层级 | 0.3 | 核心服务=80，非核心=10 | 80 × 0.3 = 24 |
| 操作类型 | 0.25 | 删除=90，修改=30，新增=20 | 90 × 0.25 = 22.5 |
| 历史失败率 | 0.2 | >10%=70，5%-10%=40，<5%=10 | 40 × 0.2 = 8 |
| 集群健康度 | 0.15 | 异常=60，警告=30，正常=0 | 30 × 0.15 = 4.5 |
| 变更窗口 | 0.1 | 业务高峰=50，低谷=5 | 5 × 0.1 = 0.5 |
| 综合指数 | 1.0 | 59.5（高风险） |
关键指标：权重总和必须为1.0。评分函数建议使用分段线性函数，避免极端值导致指数失真。生产环境中，建议将“变更对象层级”和“操作类型”的权重设为最高。
2.5 影响范围分析输出物
影响范围分析完成后，编排引擎应输出结构化的影响报告，供后续决策和回滚预案使用。标准输出物包括：
- 影响服务列表：直接服务、间接服务、依赖服务，附带QPS和延迟基线。
- 影响数据资产：涉及的表、队列、缓存键前缀，以及数据一致性风险描述。
- 影响用户画像：受影响用户数、用户分布（地域/会员等级）、预期体验降级程度。
- 回滚复杂度评估：回滚时长、回滚操作步骤数、是否需要人工介入。
避坑提醒：影响范围分析不能只做“一次快照”。在变更执行过程中，依赖关系可能动态变化（如服务自动扩缩容）。建议在变更执行前和执行中分别做一次影响范围分析，对比差异。
通过以上三个环节的紧密配合，风险评估模块能够为编排引擎提供可靠的决策依据，在保障系统稳定性的同时，最大化变更效率。