4. 失败变更分类标准：按故障等级、变更类型与影响范围划分
在服务画像工程中，统一且可量化的失败变更分类标准是计算变更失败率（Change Failure Rate, CFR）的前提。不同组织对“失败”的定义差异巨大——一次导致P0级故障的配置推送与一次仅影响内部监控的代码回滚，在CFR计算中权重应如何体现？本章建立三维分类模型，确保CFR指标既能反映严重性，又能指导改进方向。
核心原则：失败变更分类必须满足 MECE（Mutually Exclusive, Collectively Exhaustive）原则——每个维度内类别互斥，三个维度共同覆盖所有失败场景。
4.1 按故障等级划分：P0/P1/P2
故障等级是衡量变更失败严重性的首要维度。参考业界通用分级（Google SRE、AWS Well-Architected），结合服务画像工程实践，定义三级故障标准：
| 等级 | 定义 | 典型表现 | CFR权重建议 |
|---|---|---|---|
| P0 | 核心服务完全不可用，或影响全部用户的核心功能 | 登录/支付/搜索完全中断；SLA违约；收入损失 | 1.0（全量计入） |
| P1 | 核心服务严重降级，或影响大量用户的关键功能 | 响应延迟>5s；部分用户无法下单；数据不一致 | 0.5（半量计入） |
| P2 | 非核心功能受损，或影响少量用户的次要功能 | 管理后台报错；非关键报表延迟；单用户配置异常 | 0.1（轻量计入） |
实践要点：CFR计算时建议采用加权失败计数，而非简单二值（成功/失败）。例如：一次P0失败变更 = 1.0次失败；一次P2失败变更 = 0.1次失败。这能避免大量低严重性变更稀释CFR的预警能力。
4.2 按变更类型划分：配置、代码、基础设施
不同变更类型的失败模式、恢复手段、检测方式差异显著。分类统计CFR有助于精准定位薄弱环节。
- 配置变更：修改服务配置、特性开关、路由规则、限流阈值等。特点：生效快、回滚简单、但易因人为疏忽导致全局影响。典型失败：错误的白名单IP导致服务拒绝所有请求。
- 代码变更：提交代码、合并PR、发布新版本。特点：影响面广、需经过CI/CD流水线、回滚成本较高。典型失败：空指针异常导致接口500错误。
- 基础设施变更：扩缩容、网络策略、存储迁移、K8s集群升级。特点：变更周期长、依赖底层组件、失败恢复时间（MTTR）通常最长。典型失败：错误的Ingress配置导致流量无法路由。
| 变更类型 | 检测手段 | 回滚策略 | 典型MTTR |
|---|---|---|---|
| 配置变更 | 配置校验、金丝雀发布、实时监控 | 一键回滚配置版本 | <5分钟 |
| 代码变更 | 单元测试、集成测试、灰度发布 | 回滚代码版本 + 重新部署 | 10~30分钟 |
| 基础设施变更 | 基础设施即代码（IaC）预检、Dry Run | IaC状态回滚 / 手动恢复 | 30分钟~2小时 |
4.3 按影响范围划分
影响范围决定了变更失败的爆炸半径。按影响范围分类有助于制定差异化的回滚策略和告警阈值。
- 单实例/单Pod：仅影响一个副本。通常由资源耗尽、配置错误导致。影响最小，自动恢复概率高。
- 单可用区（AZ）：影响同一可用区内的所有实例。常见于网络分区、AZ级基础设施变更失败。
- 单集群/单Region：影响整个K8s集群或单个Region。通常由控制面变更、全局配置错误引发。
- 全局/多Region：影响所有用户和所有Region。最严重，通常由DNS变更、全局路由策略、核心服务降级导致。
| 影响范围 | 用户感知 | 恢复优先级 | 典型告警响应时间 |
|---|---|---|---|
| 单实例 | 无感知（自动重试） | 低 | <5分钟 |
| 单可用区 | 部分用户延迟增加 | 中 | <10分钟 |
| 单集群/Region | 区域用户服务不可用 | 高 | <5分钟 |
| 全局/多Region | 所有用户完全不可用 | 最高 | 即时（1分钟内） |
4.4 三维分类矩阵：综合判定失败变更
实际生产环境中，一次失败变更同时具备三个维度的属性。建议在变更事件记录中采用三维标签，便于后续聚合分析。
标签示例：
failure_type: "P1:代码变更:单集群"failure_type: "P0:配置变更:全局"failure_type: "P2:基础设施变更:单实例"
通过三维分类，SRE团队可以快速回答以下问题：
- 哪类变更的P0级失败最多？→ 优先改进该变更类型的防护措施。
- 全局影响范围的失败是否主要由配置变更导致？→ 加强配置变更的审批与金丝雀流程。
- 基础设施变更的P2级失败是否集中在单实例范围？→ 可能是个别节点硬件问题，而非变更流程缺陷。
避坑提示：不要将“影响范围”与“故障等级”混淆。例如：一次P2级故障（非核心功能受损）可能影响全局（所有用户的管理后台报错）。两个维度独立记录，不可合并。
4.5 分类标准在服务画像中的落地
在服务画像工程中，上述分类标准将直接映射为Metric Design中的标签（Labels/Tags）。推荐的数据模型如下：
# 变更事件数据结构示例（Prometheus Metrics风格）
change_failure_total{
service="payment-service",
severity="P1",
change_type="code",
blast_radius="single_cluster",
team="payment-sre"
} 1
# 用于计算加权CFR的PromQL示例
sum(
change_failure_total{severity="P0"} * 1.0
or
change_failure_total{severity="P1"} * 0.5
or
change_failure_total{severity="P2"} * 0.1
) / sum(change_total) * 100
通过统一的分类标准，不同服务、不同团队的CFR数据具备可比性，为服务画像的成熟度评级提供量化依据。