运维
运维相关知识和内容
SRE实战：如何用SLO驱动团队建立可靠性文化并落地故障演练
SRE实战：如何用SLO驱动团队建立可靠性文化并落地故障演练
# SRE实战：如何用SLO驱动团队建立可靠性文化并落地故障演练
## 摘要
SLO不只是数字，更是团队对用户的可靠性承诺。很多团队制定了SLO却无法落地，根因在于缺少从SLO制定、错误预算消耗、告警触发到故障演练的完整闭环。
## 一、SLO体系全景
### 1.1 核心概念关系
```
SLI（指标）→ SLO（目标）→ SLA（合同）
│ │ │
可测量 可承诺 可赔偿
"延迟P99=2.3s" "P99<3s" "P99>5s赔款"
```
### 1.2 SLO制定的三条原则
1. **用户视角**：SLO应反映用户体验，而非系统内部指标
2. **少而精**：3-5个核心SLO足够，过多则无法聚焦
3. **可操作性**：每个SLO必须有对应的告警和响应预案
## 二、实战：电商系统SLO设计
### 2.1 识别关键用户旅程
| 旅程 | 占比 | 重要性 |
|------|------|--------|
| 商品浏览 | 60% | 高 |
| 下单支付 | 25% | 极高 |
| 搜索 | 10% | 高 |
| 退货 | 5% | 中 |
### 2.2 SLI指标选择
```python
# 基于OpenTelemetry的SLI指标采集
from opentelemetry import metrics
meter = metrics.get_meter("sli-collector")
# SLI 1: 可用性 - 成功请求比例
availability_counter = meter.create_counter(
name="sli.availability",
description="请求成功/失败计数",
)
# SLI 2: 延迟 - 请求处理时间
latency_histogram = meter.create_histogram(
name="sli.latency",
description="请求延迟分布",
unit="ms",
)
# SLI 3: 正确性 - 业务逻辑正确率
correctness_counter = meter.create_counter(
name="sli.correctness",
description="业务正确/错误计数",
)
```
### 2.3 SLO定义与错误预算
```yaml
# slo-rules.yaml - Prometheus规则
groups:
- name: slo-availability
rules:
# 30天滚动窗口的可用性SLO
- record: slo:availability:ratio
expr: |
sum(rate(http_requests_total{code!~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
- record: slo:availability:error_budget:remaining
expr: |
1 - (1 - slo:availability:ratio) / (1 - 0.999)
# 0.999 = 99.9%可用性SLO
# 错误预算 = 1 - 99.9% = 0.1% = 43.2分钟/月
- alert: SLOErrorBudgetLow
expr: slo:availability:error_budget:remaining < 0.2
for: 1h
labels:
severity: warning
annotations:
summary: "错误预算剩余不足20%"
- alert: SLOErrorBudgetExhausted
expr: slo:availability:error_budget:remaining < 0
for: 5m
labels:
severity: critical
annotations:
summary: "错误预算已耗尽！"
- name: slo-latency
rules:
- record: slo:latency:p99:ratio
expr: |
histogram_quantile(0.99,
sum(rate(http_request_duration_seconds_bucket[5m]))
by (le)
)
- alert: SLOLatencyBreached
expr: slo:latency:p99:ratio > 3 # P99超过3秒
for: 10m
labels:
severity: warning
```
### 2.4 错误预算策略
| 预算状态 | 团队行动 |
|---------|---------|
| 剩余 > 50% | 正常迭代，发布新功能 |
| 20% < 剩余 < 50% | 谨慎发布，加强测试 |
| 剩余 < 20% | 暂停功能开发，专注可靠性 |
| 剩余 < 0% | 冻结发布，全团队扑在可靠性上 |
## 三、告警设计：从SLO到 actionable alert
### 3.1 告警分级
```python
class AlertPriority:
P1 = "SLO违反 + 用户影响大 → 立即响应（5分钟内）"
P2 = "SLO接近违反 → 30分钟内响应"
P3 = "趋势预警 → 当日内处理"
P4 = "信息通知 → 下个Sprint处理"
# 告警路由配置
ALERT_ROUTING = {
"P1": ["oncall-phone", "slack-incident", "pagerduty"],
"P2": ["oncall-slack", "pagerduty-low"],
"P3": ["slack-sre-channel"],
"P4": ["slack-monitoring"],
}
```
### 3.2 多烧速率告警（Multi-burn-rate）
```yaml
# 短窗口高烧速率 → 快速发现突发故障
# 长窗口低烧速率 → 发现慢性退化
groups:
- name: multi-burn-rate
rules:
- alert: HighBurnRate-Short
expr: |
(
1 - sum(rate(http_requests_total{code!~"5.."}[1h]))
/ sum(rate(http_requests_total[1h]))
) > (14.4 * (1 - 0.999))
for: 5m
labels:
severity: critical
window: short
- alert: HighBurnRate-Long
expr: |
(
1 - sum(rate(http_requests_total{code!~"5.."}[6h]))
/ sum(rate(http_requests_total[6h]))
) > (6 * (1 - 0.999))
for: 30m
labels:
severity: warning
window: long
```
## 四、故障演练（Chaos Engineering）
### 4.1 演练原则
1. **在稳态下进行**：先确认系统正常运行
2. **假设控制组**：明确"正常行为"是什么
3. **引入变量**：注入故障
4. **观察差异**：系统行为是否符合预期
5. **记录改进**：发现的问题必须进入改进计划
### 4.2 Chaos Mesh实战
```yaml
# 网络延迟注入
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
name: payment-latency
namespace: chaos-testing
spec:
action: delay
mode: one
selector:
namespaces: ["production"]
labelSelectors:
app: "payment-service"
delay:
latency: "2000ms" # 注入2秒延迟
jitter: "500ms"
duration: "10m"
```
```yaml
# Pod故障注入
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
name: db-pod-kill
namespace: chaos-testing
spec:
action: pod-kill
mode: one
selector:
namespaces: ["production"]
labelSelectors:
app: "mysql-primary"
scheduler:
cron: "@every 30m" # 每30分钟杀一次
duration: "5m"
```
### 4.3 演练场景设计
| 场景 | 注入故障 | 观察指标 | 预期结果 |
|------|---------|---------|---------|
| 支付服务延迟 | 2s网络延迟 | 下单成功率、P99延迟 | 降级但不熔断 |
| DB主节点宕机 | Pod Kill | 主从切换时间、数据一致性 | 30秒内切换 |
| 缓存集群不可用 | 网络分区 | 请求成功率、响应时间 | 降级兜底可用 |
| 可用区故障 | 整区网络断开 | 跨区切换时间 | 60秒内恢复 |
### 4.4 演练报告模板
```markdown
# 故障演练报告
## 基本信息
- 日期：2026-05-05
- 场景：支付服务网络延迟
- SLO：可用性99.9%，P99<3s
## 结果
| 指标 | 演练前 | 演练中 | 是否符合预期 |
|------|--------|--------|------------|
| 可用性 | 99.95% | 99.1% | ❌ 低于SLO |
| P99延迟 | 1.2s | 4.8s | ❌ 超过3s |
| 下单成功率 | 99.8% | 95.2% | ❌ 低于预期 |
## 发现的问题
1. 支付服务未配置超时降级，导致请求堆积
2. 重试策略过于激进，加剧了延迟
3. 缓存兜底策略未生效
## 改进计划
1. 配置支付服务2s超时 + 降级 → 负责人：张三 → 截止：2026-05-10
2. 调整重试策略为指数退避 → 负责人：李四 → 截止：2026-05-08
3. 修复缓存兜底逻辑 → 负责人：王五 → 截止：2026-05-07
```
## 五、SLO文化落地checklist
- [ ] 每个关键用户旅程有对应的SLO
- [ ] SLO仪表盘实时展示错误预算
- [ ] 告警与SLO直接关联，非SLO告警降级
- [ ] 错误预算策略写入发布流程
- [ ] 每月进行故障演练并出报告
- [ ] 季度回顾SLO是否需要调整
- [ ] 事故复盘结果关联SLO改进
## 总结
SLO体系的核心不是数字，而是团队对可靠性的共同承诺。从SLI采集、SLO定义、错误预算管理到故障演练验证，形成完整闭环，才能真正将可靠性文化融入团队DNA。
---
*本文由北科信息日采集系统自动生成，发布日期：2026-05-05*