4. 多层级SLO体系：构建服务级、产品级、用户级SLO的层次结构，以及Error Budget的继承与分解
单一层级的SLO无法覆盖现代微服务架构的复杂性。一个用户请求往往跨越多个服务，而每个服务的可靠性表现会最终叠加为产品的用户体验。因此，需要建立服务级 → 产品级 → 用户级的三层SLO体系，并定义Error Budget在层级间的继承与分解规则。
4.1 三层SLO层次结构定义
下表清晰定义了每一层级的关注对象、典型指标与核心用途：
| 层级 | 关注对象 | 典型指标示例 | 核心用途 |
|---|---|---|---|
| 用户级 (User-Level) | 最终用户体验、业务KPI | 登录成功率 ≥ 99.9%，下单P99延迟 ≤ 2s | 对外承诺、SLA依据、产品健康度仪表盘 |
| 产品级 (Product-Level) | 核心功能链路、微服务聚合 | 购物车可用性 ≥ 99.95%，支付成功率 ≥ 99.99% | 产品团队OKR、跨服务协调、容量规划 |
| 服务级 (Service-Level) | 单个微服务、基础设施组件 | 订单服务可用性 ≥ 99.99%，数据库P99延迟 ≤ 50ms | 研发团队日常排障、变更发布、容量伸缩 |
设计原则：用户级SLO是“对外脸面”，必须严格守护；服务级SLO是“内部工程基线”，允许更频繁的调整与优化。产品级SLO起到承上启下的桥梁作用。
4.2 Error Budget的继承与分解机制
Error Budget的流动方向是自上而下继承，自下而上汇聚。用户级Error Budget最宝贵，服务级Error Budget最充裕但约束也最严格。
4.2.1 自上而下的继承（分解）
用户级Error Budget按请求比例或关键路径权重向下分解到产品级，产品级再进一步分解到服务级。分解公式如下：
# 假设用户级SLO为 99.9%，Error Budget = 0.1%
# 产品级A承担用户请求中60%的流量权重
产品级A_Error_Budget = 0.1% × 60% = 0.06%
# 服务级B是产品级A内部的关键依赖，承担80%的内部调用
服务级B_Error_Budget = 0.06% × 80% = 0.048%
注意：分解时必须保留一定的“安全缓冲”（Buffer），避免下层Error Budget被完全耗尽导致上层无任何容错空间。通常建议每层保留10%~20%的未分配预算作为应急储备。
4.2.2 自下而上的汇聚（燃烧速率）
当服务级Error Budget快速燃烧时，需要立即计算对产品级和用户级的影响。汇聚规则如下：
- 线性汇聚：如果服务级B的Error Budget消耗速率超过阈值（如日均消耗 > 预算的25%），则产品级A的剩余预算按比例同步缩减。
- 非线性汇聚：如果多个服务级同时燃烧，产品级Error Budget的消耗速率呈指数级增长，触发更高级别的告警。
4.3 多层级SLO架构图
下图展示了用户级、产品级、服务级SLO的层次关系，以及Error Budget的分解与汇聚路径：
4.4 层级间Error Budget的调度策略
当某一层级的Error Budget告急时，需要触发跨层级的调度动作，避免局部故障扩散为全局事故。调度策略如下：
| 触发条件 | 调度动作 | 影响范围 |
|---|---|---|
| 服务级EB消耗 > 70% | 自动降级非核心功能、限制该服务变更发布 | 仅影响该服务 |
| 产品级EB消耗 > 50% | 启动跨服务熔断、拒绝低优先级流量 | 影响产品内多个服务 |
| 用户级EB消耗 > 30% | 全局限流、紧急回滚、通知业务方 | 影响所有用户 |
最佳实践：在服务级保留“快速恢复通道”。当服务级Error Budget耗尽时，允许通过紧急变更（Hotfix）快速恢复，但必须经过产品级SRE审批，且该变更不计入常规Error Budget消耗统计。
4.5 多层级SLO的监控与告警设计
每一层级的SLO都需要独立的监控仪表盘和告警规则，同时建立层级间的关联告警：
- 服务级告警：基于SLI（如请求延迟、错误率）的实时阈值告警，响应时间 < 5分钟。
- 产品级告警：基于Error Budget消耗速率的窗口告警（如1小时消耗 > 10%），响应时间 < 15分钟。
- 用户级告警：基于业务KPI的复合告警（如登录成功率 + 下单成功率同时下降），响应时间 < 30分钟。
通过这种层次化结构，SRE团队可以从用户视角发现问题，从服务视角定位根因，从产品视角协调恢复，实现Error Budget的精细化调度与全链路可靠性治理。