> **本文是「架构实战·第二季」第 57 篇**。SLO 不是"目标"——是"约束"。Error Budget 用完了，团队必须停止新功能开发，专注于稳定性。这篇文章把 SLO 设计、Error Budget 计算、发布门禁、Alert on SLO 等工程实践讲清楚。

---

## 引子：那年为了赶工耗尽 Error Budget 的悲剧

2022 年双 11 准备期，我们核心订单服务的 SLO 是 99.95%（月可用性）。

按月算 30 天 × 24 小时 × 60 分 = 43200 分钟，允许不可用 = 21.6 分钟。

**10 月 1 日到 10 月 28 日**：

- 已经消耗 Error Budget 18 分钟
- 还剩 3.6 分钟
- 离双 11 还有 14 天

**10 月 29 日**，业务方紧急要求发一个"提前购"功能：

- 开发："5 个服务改动，3 天能上线"
- 测试："需要 5 天测试"
- 业务："10 月 31 日必须上"

我们加班加点 3 天上线，10 月 31 日上线。

**当天晚上 8 点**（峰值时段）：

- 新代码引入一个 N+1 查询 bug
- 订单服务 P99 延迟从 200ms 飙到 3 秒
- SLO 一分钟内消耗 0.5 分钟
- 紧急回滚

**那次事故**：

- Error Budget 一次性消耗 5 分钟
- **超支**
- 11 月 1 日到 11 月 11 日，**禁止再发版**
- 业务方上诉到 CTO
- CTO 仲裁："SRE 严格按 SLO 流程，业务方也别再要求冒险发版"

**最终代价**：一个核心功能推迟 3 周上线。

那次之后，公司全员对"Error Budget"有了敬畏。

---

## 一、SRE 的核心理念

### 1.1 SLO 是什么

> **SLO（Service Level Objective）** = 服务可用性目标

最常见：

```
99.9%  (三 9) = 月 43.2 分钟不可用
99.95% (三 9 五) = 月 21.6 分钟不可用
99.99% (四 9) = 月 4.32 分钟不可用
99.999% (五 9) = 月 0.432 分钟不可用
```

### 1.2 SLI 是什么

> **SLI（Service Level Indicator）** = 衡量 SLO 的具体指标

| 业务 | SLI |
|------|-----|
| API 服务 | 成功请求比例 |
| 延迟敏感服务 | P99 延迟达标比例 |
| 数据处理 | 任务按时完成比例 |

### 1.3 SLA 是什么

> **SLA（Service Level Agreement）** = 与客户/业务方的合同承诺

```
"SLA 99.9%，未达标赔款 10%"
```

**SLO ≥ SLA**——SLO 内部目标比对外承诺更严格。

### 1.4 Error Budget 是什么

> **Error Budget = 1 - SLO** = 允许的失败量

```
SLO 99.95% → Error Budget = 0.05% = 月 21.6 分钟不可用
```

**核心理念**：

- 100% 不可用 = 不可能
- Error Budget 是**允许的失败额度**
- 用完就必须停止新功能，专注稳定性

---

## 二、SLI 的设计

### 2.1 SLI 的四大类

#### 可用性 SLI

```promql
# 成功请求数 / 总请求数
sum(rate(http_requests_total{status!~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
```

#### 延迟 SLI

```promql
# P99 延迟 < 阈值的请求比例
sum(rate(http_request_duration_seconds_bucket{le="0.5"}[5m]))
/
sum(rate(http_request_duration_seconds_count[5m]))
```

#### 吞吐 SLI

```promql
# 实际 QPS / 目标 QPS
min(1, sum(rate(http_requests_total[5m])) / 1000)
```

#### 正确性 SLI

```promql
# 业务正确率（如下单成功数 / 下单总数）
sum(rate(order_create_success_total[5m]))
/
sum(rate(order_create_total[5m]))
```

### 2.2 SLI 的"事件分布"

**问题**：用"所有时间"的 SLI 不能反映"关键时刻"的问题。

**解决**：分时段计算。

```promql
# 工作时间 9-18 点的 SLI
sum(rate(http_requests_total{status!~"5..", hour="9-18"}[5m]))
/
sum(rate(http_requests_total{hour="9-18"}[5m]))
```

**业务关键时段**：

- 电商：双 11、618
- 金融：开盘、收盘
- 游戏：周末晚高峰

**关键时段的 SLO 要更严**：

```yaml
slo:
  default:
    availability: 99.9
  critical_periods:
    - period: "双 11 当天 0-2 点"
      availability: 99.99
```

### 2.3 SLI 的"剔除规则"

```yaml
sli_exclusions:
  # 1. 业务主动排除（业务方已知风险）
  - user_segments: [chaos-test, internal-test]
    exclude: true
    
  # 2. 已知故障（事故期间）
  - incidents: [INC-20240601-001]
    exclude: true
    reason: "已知事故，消耗 Error Budget 不公平"
    
  # 3. 第三方故障（不归我们管）
  - upstream_dependencies: ["external-payment-api"]
    exclude: true
    reason: "第三方问题"
```

**剔除必须谨慎**——"合理剔除"和"作弊剔除"很难界定。

---

## 三、SLO 的设计原则

### 3.1 不要定过高的 SLO

```
99%    = 月 432 分钟（很宽）
99.9%  = 月 43.2 分钟（合理）
99.95% = 月 21.6 分钟（紧）
99.99% = 月 4.32 分钟（很难）
99.999%= 月 25.8 秒（极难）
```

**经验**：

- 新服务：99.9%
- 核心服务：99.95%
- 旗舰服务：99.99%

**不要定比实际能力高 10 倍的 SLO**——会耗尽 Error Budget。

### 3.2 用户感知 + 业务影响

```yaml
# 不要"复制别人"的 SLO
# 要从用户感知推导
user_perception:
  api_response_time:
    excellent: < 100ms
    acceptable: < 300ms
    poor: < 1000ms
    terrible: > 1000ms
    
slo:
  # P99 < 300ms（用户可接受）
  p99_latency: 300ms
  # 99.9% 请求 < 300ms
  slo: 99.9%
```

### 3.3 SLO 评审

```yaml
slo_design_review:
  - 业务方确认：业务影响是什么
  - 历史数据：过去 6 个月的服务可用性是多少
  - 用户调研：用户对延迟的容忍度
  - 行业对标：竞争对手是什么水平
  - 成本评估：达到 SLO 需要多少投入
```

**SLO 不是 SRE 定的，是业务方 + SRE + 产品 共建的**。

---

## 四、Error Budget 的计算

### 4.1 计算公式

```
Error Budget = 1 - SLO
```

举例：

```
SLO = 99.95%
Error Budget = 0.05%
月度窗口：30 天
月度错误预算 = 30 × 24 × 60 × 0.05% = 21.6 分钟
```

### 4.2 多 SLI 的 Error Budget

```python
class ErrorBudgetCalculator:
    def __init__(self, slos):
        self.slos = slos  # {availability: 0.9995, latency: 0.99}
    
    def calculate(self, period_minutes=43200):
        budgets = {}
        for sli_name, slo in self.slos.items():
            budgets[sli_name] = {
                "total_minutes": period_minutes,
                "allowed_unhealthy_minutes": period_minutes * (1 - slo),
                "consumed_minutes": 0,
                "remaining_minutes": period_minutes * (1 - slo),
                "burn_rate": 0
            }
        return budgets
```

### 4.3 Error Budget 跟踪

```yaml
# 实时跟踪
error_budget_tracking:
  service: order-service
  period: 2026-10
  slos:
    availability:
      target: 99.95
      consumed: 18  # 分钟
      total: 21.6
      remaining: 3.6
      burn_rate: 1.2  # 当前消耗速度
      
    latency_p99_under_500ms:
      target: 99.0
      consumed: 50  # 分钟
      total: 432
      remaining: 382
      burn_rate: 0.8
```

**可视化**：

```
可用性 SLO Error Budget
████████████████░░░░ 92% remaining

延迟 SLO Error Budget
██████████████░░░░░░ 88% remaining
```

---

## 五、Burn Rate 与多窗口告警

### 5.1 Burn Rate 是什么

> **Burn Rate = 实际错误率 / 允许错误率**

```
SLO 99.9% → 允许错误率 0.1%
当前错误率 1% → Burn Rate = 1% / 0.1% = 10
```

意思是：**以 10 倍速度消耗 Error Budget**。

### 5.2 多窗口告警（Multi-Window Burn Rate）

Google SRE 推荐的告警策略：

```yaml
# 慢烧（温和告警）
- name: "SLO slow burn"
  burn_rate: 1       # 1 倍速度
  window: 1h         # 1 小时
  for: 5m            # 持续 5 分钟
  alert: "Error Budget 将在 X 天耗尽"

# 快烧（紧急告警）
- name: "SLO fast burn"
  burn_rate: 14.4    # 14.4 倍速度
  window: 5m         # 5 分钟
  for: 2m            # 持续 2 分钟
  alert: "SLO 严重事件，立即处理"
```

**核心思想**：

- 1h 内 1% 错误率 = Burn Rate 10 → 1.2 天耗尽预算
- 5m 内 5% 错误率 = Burn Rate 50 → 4 小时耗尽预算

### 5.3 实战：基于 SLO 的告警

```python
# Prometheus alert rule
groups:
  - name: slo_alerts
    rules:
      # 1h 内消耗 1% 错误率
      - alert: ErrorBudgetBurnRateHigh
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[1h]))
            /
            sum(rate(http_requests_total[1h]))
          ) > (1 - 0.9995) * 10
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Error Budget 烧得太快"
          description: "{{ $labels.service }} 1h Burn Rate > 10"
          
      # 5m 内消耗 14.4 倍预算
      - alert: ErrorBudgetBurnRateCritical
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[5m]))
            /
            sum(rate(http_requests_total[5m]))
          ) > (1 - 0.9995) * 14.4
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "SLO 严重事件"
          description: "立即处理！"
```

### 5.4 多窗口组合

```yaml
# Google SRE 推荐的多窗口
multi_window_alerts:
  - burn_rate: 14.4
    window: 5m
    long_window: 1h
    severity: page
    # 5 分钟 OR 1 小时窗口任何一个超
    
  - burn_rate: 6
    window: 30m
    long_window: 6h
    severity: ticket
```

---

## 六、发布门禁（Release Gate）

### 6.1 门禁的核心

> **Error Budget 用完，禁止发新功能**。

```yaml
release_gate:
  service: order-service
  current_budget_remaining: 5%   # 剩余 5%
  status: locked                  # 锁定
  lock_reason: "Error Budget 仅剩 5%"
  unlock_at: 2026-11-01          # 11 月 1 日（下个周期）
  exception: emergency-only       # 只能紧急修复
```

### 6.2 门禁的执行

```yaml
# CI/CD 集成
ci_release_gate:
  pre_check:
    - name: "Error Budget 充足"
      condition: "budget_remaining > 20%"
      on_fail: "禁止发版"
      
    - name: "近 7 天 SLO 达标"
      condition: "recent_slo >= target_slo"
      on_fail: "需要 SRE Lead 审批"
      
    - name: "本周故障数"
      condition: "incident_count_week < 2"
      on_fail: "需要 SRE Lead 审批"
```

### 6.3 紧急情况的处理

```yaml
# 紧急情况（如安全漏洞）可以豁免
emergency_release:
  conditions:
    - "P0 安全漏洞"
    - "合规要求"
    - "用户数据泄露"
  process:
    - SRE Lead + 业务 VP 双签
    - 同步邮件给全公司
    - 24 小时内补上"事故复盘"
```

### 6.4 门禁失效的处理

```yaml
# 即使门禁开着，也要考虑：
# 1. 紧急修复
# 2. 跳过门禁的审批
# 3. 跨周期合并（用下月预算）
# 4. 业务方承担风险
```

---

## 七、Alert on SLO

### 7.1 不要 Alert on Error Rate

```yaml
# ❌ Alert on 错误率
- alert: HighErrorRate
  expr: error_rate > 0.05
```

**问题**：

- 错误率 5% 时，可能 SLO 还没破
- 错误率 1% 时，可能 SLO 已经在破

### 7.2 Alert on Error Budget

```yaml
# ✅ Alert on Error Budget 消耗速度
- alert: ErrorBudgetBurn
  expr: budget_burn_rate > 2
  for: 30m
```

**优点**：直接反映"对 SLO 的影响"。

### 7.3 Alert on SLO 预测

```yaml
# "按当前消耗速度，X 天后耗尽"
- alert: ErrorBudgetWillExhaust
  expr: budget_remaining_days < 7
  for: 1h
  # 提前 7 天告警，给团队反应时间
```

---

## 八、SLI/SLO 实施过程

### 8.1 四个阶段

**阶段 1：测量（Measure）**

- 接入监控
- 计算 SLI
- 收集 1-3 个月数据
- 看实际可用性是多少

**阶段 2：定标（Set）**

- 基于实际数据定 SLO
- 让业务方 review
- 让 SRE 评审

**阶段 3：跟踪（Track）**

- 持续监控 SLO
- 计算 Error Budget
- 告警 on Burn Rate

**阶段 4：执行（Enforce）**

- 实施发布门禁
- Error Budget 用完禁止发版
- 定期 review

### 8.2 推荐工具

| 工具 | 用途 |
|------|------|
| **Prometheus** | 采集 SLI |
| **Sloth** | 自动生成 SLO 规则 |
| **Grafana** | 可视化 SLO |
| **PromQL** | 计算 Error Budget |
| **Nobl9 / Pyrra** | SLO 平台 |

### 8.3 Sloth 自动生成规则

```yaml
# sloth-sli.yaml
service: order-service
description: "订单服务可用性"
sli:
  spec:
    events:
      - error_query: |
          sum(rate(http_requests_total{status=~"5.."}[{{.window}}]))
        total_query: |
          sum(rate(http_requests_total[{{.window}}]))
slo:
  spec:
    description: "订单服务 99.9% 可用"
    objectives:
      - displayName: "99.9%"
        target: 0.999
        window: 30d
    alerting:
      name: order-service-slo
      page_alert:
        labels:
          severity: critical
      ticket_alert:
        labels:
          severity: warning
```

---

## 九、组织层面的 SLO 文化

### 9.1 SLO 是"产品决策"

SLO 不是 SRE 单方面定的：

```yaml
slo_definition_process:
  1. SRE 提供数据（实际可用性、技术能力）
  2. 业务方提供需求（业务影响、用户感知）
  3. 产品方提供权衡（新功能 vs 稳定性）
  4. 共建 SLO
```

### 9.2 Error Budget 耗尽的"应急响应"

```yaml
response_to_budget_exhausted:
  immediate:
    - 暂停所有非紧急发版
    - SRE 团队进入"稳定性模式"
    - 业务方被通知
    
  short_term:
    - 识别最不可靠的组件
    - 优先修复
    - 增加冗余
    
  long_term:
    - 容量评估
    - 架构优化
    - 团队培训
```

### 9.3 月度 SLO 评审

```yaml
monthly_slo_review:
  attendees: [SRE Lead, 业务方 Lead, 产品 Lead]
  agenda:
    - 1. 上月 SLO 达成情况
    - 2. Error Budget 消耗情况
    - 3. 主要事故复盘
    - 4. 下月目标调整
    - 5. 改进行动
```

---

## 十、踩坑提示

### 10.1 不要把 SLO 定的比 SLA 低

```
SLA 99.9% → SLO 必须 ≥ 99.9%
SLA 99.9% → SLO 99.95%（更严，留 buffer）
```

### 10.2 不要让"剔除规则"变成作弊

```yaml
# ❌ 大量剔除 → SLO 虚高
exclusions:
  - reason: "网络抖动"
    percent: 30    # 30% 请求被剔除了！
```

**正解**：

- 剔除 < 5%
- 每次剔除要写明原因
- 定期 review

### 10.3 不要只看 SLO 数字

```yaml
# ❌ SLO 99.95% 达标，但用户体验很差
# - P50 很好（5ms）
# - P99 很差（5 秒）
# - 但 99.95% 都是 P50，所以"达标"
```

**正解**：

- 多 SLI 组合
- 关注长尾
- 用户调研

### 10.4 不要让 SLO 成为 KPI 绑架

```
错误: "团队必须保证 SLO 99.999%"
结果: 团队不敢发版、不敢创新、防御性编程
```

**正解**：

- SLO 是约束，不是 KPI
- SLO 留出"创新空间"
- Error Budget 用完就接受

### 10.5 不要忽略 SLO 的"迁移成本"

```yaml
# SLO 从 99.9% 提到 99.95%
# 月度预算从 43 分钟降到 21 分钟
# 工程投入可能要 5 倍
```

**正解**：SLO 升级要做 ROI 分析。

---

## 本篇要点回顾

1. SLO 是约束，不是目标；Error Budget 是允许的失败额度
2. **SLI 必须从用户感知推导**，不能拍脑袋
3. Error Budget 耗完 = 停止新功能 = 专注稳定性
4. **告警 on Burn Rate，不告警 on Error Rate**
5. 发布门禁是 Error Budget 机制的核心执行
6. SLO 是产品决策，不是 SRE 单方面定
7. 多 SLI 组合，关注长尾用户体验

---

## 下篇预告

下一篇讲 **58-SLI 设计原则：可用性、延迟与吞吐的度量**。什么样的 SLI 才是"好"的？延迟 SLI 用平均还是 P99？吞吐 SLI 怎么定？正确性 SLI 怎么测？这篇文章把 SLI 的具体设计方法讲透。敬请期待。

本文是「架构实战·第二季」第 57 篇。SLO 不是"目标"——是"约束"。Error Budget 用完了，团队必须停止新功能开发，专注于稳定性。这篇文章把 SLO 设计、Error Budget 计算、发布门禁、Alert on SLO 等工程实践讲清楚。

【架构实战】SLO 工程：从 Error Budget 到发布门禁

研发部经理

架构设计

运维

后端

SLO是约束而非目标，ErrorBudget耗尽即停止新功能开发，专注稳定性。本文详解SLO设计、ErrorBudget计算、发布门禁与Alert on SLO实战，强调SLI从用户感知推导，告警基于BurnRate，并给出多窗口告警策略及组织落地文化。

腾讯云双十一大促

tcmg

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【架构实战】SLO 工程：从 Error Budget 到发布门禁-腾讯云开发者社区-腾讯云

【架构实战】SLO 工程：从 Error Budget 到发布门禁

【架构实战】SLO 工程：从 Error Budget 到发布门禁

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐