2. 变更风险基础：风险定义、风险三要素与变更风险分类
在平台工程中，每一次变更都伴随着不确定性。理解风险的本质是进行有效风险评估与冻结窗口决策的前提。本节将系统梳理风险的核心定义、构成要素以及变更场景下的风险分类体系。
2.1 风险定义：从不确定性到损失
在 IT 运维与平台工程语境下，风险是指一个威胁利用系统脆弱性，对业务或平台造成影响的可能性与后果的组合。它不是单纯的“可能出问题”，而是包含概率与损失两个维度的量化或半量化度量。
核心公式： 风险 = 威胁 × 脆弱性 × 影响。三者缺一不可，任何一项为零，风险即不存在。
| 维度 | 定义 | 平台工程示例 |
|---|---|---|
| 威胁 | 可能导致负面事件的外部或内部因素 | 恶意攻击、误操作、配置漂移、依赖服务故障 |
| 脆弱性 | 系统内部存在的可被利用的弱点或缺陷 | 未打补丁的组件、权限过度开放、无回滚机制 |
| 影响 | 负面事件发生后对业务或平台造成的损失 | 服务中断、数据丢失、SLO 违约、合规罚款 |
2.2 风险三要素深度解析
三个要素共同决定了变更的风险等级。在冻结窗口测试验证中，我们通常通过降低脆弱性或控制影响范围来管理风险。
2.2.1 威胁（Threat）
威胁是风险的源头。在变更场景中，威胁可能来自：
- 人为因素： 操作失误、配置错误、未遵循变更流程。
- 技术因素： 软件缺陷、兼容性问题、资源耗尽。
- 环境因素： 网络分区、硬件故障、第三方 API 变更。
2.2.2 脆弱性（Vulnerability）
脆弱性是系统内部的薄弱环节。常见的平台脆弱性包括：
- 架构脆弱性： 单点故障、紧耦合、无容错设计。
- 配置脆弱性： 硬编码密钥、宽松的防火墙规则、未审计的 RBAC。
- 流程脆弱性： 缺乏变更审批、无自动化测试、回滚方案缺失。
2.2.3 影响（Impact）
影响是风险最终造成的业务损失。通常从以下维度评估：
- 可用性： 服务不可用时长、错误率上升。
- 性能： 延迟增加、吞吐量下降。
- 数据： 数据丢失、数据不一致、数据泄露。
- 成本： 额外资源消耗、罚款、品牌声誉损失。
实践要点： 在变更风险评估表中，威胁、脆弱性、影响应分别打分（如 1-5 分），三者乘积作为风险等级。风险等级 ≥ 20 的变更应强制进入冻结窗口或需要高级审批。
2.3 变更风险分类
在平台工程中，变更风险可按来源、影响范围和可逆性进行分类。合理的分类有助于制定差异化的审批流程和冻结窗口策略。
2.3.1 按风险来源分类
| 风险类别 | 典型场景 | 风险等级（示例） |
|---|---|---|
| 配置变更风险 | 修改 DNS 记录、调整负载均衡策略、更新环境变量 | 中～高 |
| 代码变更风险 | 服务版本升级、Bug 修复、新功能上线 | 中～极高 |
| 基础设施变更风险 | 扩缩容、更换实例类型、网络拓扑调整 | 高～极高 |
| 依赖变更风险 | 数据库版本升级、缓存集群扩容、第三方 SDK 更新 | 高 |
| 安全变更风险 | 证书轮换、防火墙规则更新、IAM 策略修改 | 极高 |
2.3.2 按影响范围分类
- 全局风险： 影响所有用户或核心服务，如全局 DNS 变更、核心数据库迁移。
- 局部风险： 影响特定服务或区域，如单个微服务版本更新、某可用区扩容。
- 单实例风险： 仅影响单个实例或 Pod，如调试日志级别调整。
2.3.3 按可逆性分类
- 可逆变更： 可通过回滚或快速恢复的变更，如应用版本发布（有蓝绿部署）。
- 不可逆变更： 一旦执行难以回退的变更，如数据库 schema 迁移、证书过期。
- 半可逆变更： 回滚成本高或需要数据修复的变更，如大表索引重建。
⚠️ 冻结窗口重点关注： 全局风险 + 不可逆变更的组合是冻结窗口的核心管控对象。此类变更必须经过完整的风险评估、测试验证和高级审批，且原则上禁止在冻结窗口内执行。
2.4 风险分类在冻结窗口中的应用
基于上述分类，平台工程团队可以制定差异化的变更管控策略：
- 高风险变更（全局 + 不可逆）： 必须提前 72 小时提交变更申请，强制进入冻结窗口评估，需 C-level 审批。
- 中风险变更（局部 + 半可逆）： 需提前 24 小时申请，需技术主管审批，建议在窗口外执行。
- 低风险变更（单实例 + 可逆）： 可走简化流程，但需记录变更日志，窗口内可执行但需监控。