114 lines
4.4 KiB
Markdown
114 lines
4.4 KiB
Markdown
---
|
||
tags: [sre, error-budget, budget-allocation, sre-alerting]
|
||
create time: 2026-05-18 00:50
|
||
---
|
||
|
||
# Error Budget 深度解析 — 稳定性与速度的平衡杠杆
|
||
|
||
## 概述
|
||
|
||
Error Budget（错误预算）是 SRE 体系中最具实操价值的概念之一。它将抽象的"SLO 目标"转化为具体的可消耗量，为产品迭代的快慢提供量化依据。更多背景见 [[../04-SRE实践/01-SLI-SLO-SLA详解]]。
|
||
|
||
## 计算方式
|
||
|
||
```
|
||
可用率 = (总时间 - 故障时间) / 总时间 × 100%
|
||
错误预算 = 1 - SLO
|
||
|
||
SLO = 99.9% → 错误预算 = 0.001
|
||
每月可容忍故障 = 30 × 24 × 60 × 0.001 = 43.2 分钟
|
||
每周可容忍故障 = 7 × 24 × 60 × 0.001 = 10.1 分钟
|
||
|
||
SLO = 99.99% → 错误预算 = 0.0001
|
||
每月可容忍故障 ≈ 4.3 分钟
|
||
```
|
||
|
||
> [!tip] 理解错误预算的本质
|
||
>
|
||
> 错误预算不是"允许出错的额度"，而是"**允许不完美的空间**"。它回答了一个关键问题：在当前的可靠性要求下，团队还能冒多大的风险？
|
||
|
||
## 基于错误预算的决策矩阵
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
Ratio["错误预算使用率 = 已消耗 / 总预算"]
|
||
|
||
Ratio -- "< 50%" --> Green["🟢 绿灯阶段<br/>预算充足: 可以大胆发布<br/>新功能、尝试激进方案<br/>常规发布节奏"]
|
||
Ratio -- "50~90%" --> Yellow["🟡 黄灯阶段<br/>预算紧张: 收紧发布频率<br/>增加人工审查<br/>暂停非关键功能开发"]
|
||
Ratio -- "\> 90%" --> Orange["🟠 橙灯阶段<br/>严重不足: 冻结发布<br/>专注稳定性修复<br/>全员 On-Call"]
|
||
Ratio -- "\> 100%" --> Red["🔴 红灯阶段<br/>预算耗尽: 禁止所有<br/>功能性变更<br/>SLO 事故复盘"]
|
||
|
||
style Green fill:#c8e6c9
|
||
style Yellow fill:#fff9c4
|
||
style Orange fill:#ffe0b2
|
||
style Red fill:#ffcdd2
|
||
```
|
||
|
||
### 各阶段的典型行动清单
|
||
|
||
| 阶段 | 功能发布 | 技术债处理 | 人员安排 |
|
||
|------|---------|-----------|---------|
|
||
| 🟢 绿灯 | 正常节奏 | 按计划推进 | 按需 On-Call |
|
||
| 🟡 黄灯 | 减少 50%，需额外审批 | 启动专项清理 | 增加第二响应人 |
|
||
| 🟠 橙灯 | 冻结（仅 Hotfix） | 全员投入修复 | 负责人值班 |
|
||
| 🔴 红灯 | 全面冻结 | Postmortem + 专项改进 | 全员待命 |
|
||
|
||
## 错误预算告警联动
|
||
|
||
```yaml
|
||
# Prometheus 告警规则示例
|
||
groups:
|
||
- name: error-budget
|
||
rules:
|
||
- alert: ErrorBudgetBurnRateHigh
|
||
expr: |
|
||
sum(rate(http_requests_total{status=~"5.."}[1h])) /
|
||
sum(rate(http_requests_total[1h])) > 0.001
|
||
for: 1h
|
||
labels:
|
||
severity: warning
|
||
budget_phase: yellow
|
||
annotations:
|
||
summary: "错误预算消耗加速"
|
||
message: "当前错误率 {{ $value }}% > SLO 阈值 0.1%"
|
||
|
||
- alert: ErrorBudgetExhausted
|
||
expr: |
|
||
(sum(rate(http_requests_total{status=~"5.."}[24h])) /
|
||
sum(rate(http_requests_total[24h]))) >= 0.001
|
||
labels:
|
||
severity: critical
|
||
budget_phase: red
|
||
annotations:
|
||
summary: "错误预算已耗尽！"
|
||
message: "本月 SLO 已破线，冻结非紧急变更"
|
||
```
|
||
|
||
> [!info] Multi-window Burn Rate Alerting
|
||
>
|
||
> Google SRE 推荐的做法是使用**两个窗口**来检测预算消耗速度：
|
||
> - **短窗口（1h/5m）**：检测突发大量错误的情况（立即触发黄灯）
|
||
> - **长窗口（半天/一天）**：检测慢性缓慢泄漏的情况（防止温水煮青蛙）
|
||
>
|
||
> 只有当两个窗口同时超限时才亮红灯，这样可以避免误报导致的警报疲劳。
|
||
|
||
## 补充：多服务 Error Budget 管理策略
|
||
|
||
当集群中有几十上百个服务时，不能把所有预算分配给同一个 SLO。推荐分层策略：
|
||
|
||
| 层级 | 示例 | 预算分配 |
|
||
|------|------|---------|
|
||
| P0 核心链路 | 支付、登录 | 99.99% → 极低容错 |
|
||
| P1 重要服务 | 订单、搜索 | 99.95% → 中等容错 |
|
||
| P2 一般服务 | 后台管理、报表 | 99.9% → 较高容错 |
|
||
|
||
> [!tip] Error Budget 分配实战技巧
|
||
>
|
||
> 将月度预算**均匀摊分到每周**作为基线。例如月预算 43 分钟 → 每周预算约 10 分钟。这比月末一次性清算更有操作性——你可以在周报中直接看到本周预算余量。
|
||
|
||
## 关联笔记
|
||
|
||
- [[../04-SRE实践/01-SLI-SLO-SLA详解]] — SLI/SLO/SLA 三层模型基础
|
||
- [[../04-SRE实践/03-SRE心法与事故复盘]] — Blameless Postmortem 模板
|
||
- [[../hhs/MS/05-部署运维/02-Kubernetes]] — K8s HPA 弹性伸缩支撑 SLO 保障
|