6.4. SRE 与事件响应：SLO、值班、复盘与混沌
SRE 的核心不是「会修 Kubernetes」，而是用可量化的可靠性目标管理风险：什么必须稳定、什么可以降级、出了事谁指挥、事后如何避免重复。它把 DevOps 的反馈闭环落到可执行的指标与流程上。
- 层级:
L4 · 实战
- 难度:
进阶
- 预计:
50 分钟
- 前置:
可观测性、Kubernetes、发布流程
6.4.1. SLI、SLO 与错误预算
SLI：可测量的指标，如请求成功率、P95 延迟、新鲜度。
SLO：SLI 的目标，如「30 天成功率 ≥ 99.9%」。
错误预算：
1 - SLO，如 0.1% 的失败额度；用完就冻结高风险发布。
服务 |
SLI |
SLO |
错误预算 |
|---|---|---|---|
API |
成功率 |
99.9%/30d |
43m 12s |
订单 |
P95 延迟 |
< 300ms |
5% 请求可超 |
日志 |
采集延迟 |
< 60s |
1% 数据可丢 |
SLO 不是越高越好。99.99% 意味着更贵的冗余与更慢的发布；先和业务确认「可接受的失败」。
6.4.2. 告警设计
症状告警：错误率、延迟、饱和度；直接对应用户影响。
原因告警：CPU 高、磁盘满、证书过期；用于提前发现。
避免：每个 Pod 都告警、无 runbook 的告警、长期不处理的告警。
告警要带：影响范围、当前值、阈值、runbook 链接、最近变更。没有 runbook 的告警等于噪音。
6.4.3. 事件响应
Incident Commander（IC）：负责决策与协调，不亲自修。
Ops Lead：执行技术操作。
Comms Lead：对外沟通与状态更新。
Scribe：记录时间线、假设、操作。
分级：SEV1 全站不可用、SEV2 核心功能受损、SEV3 局部/有绕行、SEV4 无用户影响。分级决定召集谁、多久更新一次。
6.4.4. 值班与 runbook
值班表提前排，避免疲劳；一线/二线升级路径明确。
每个告警有 runbook：检查项、命令、回滚、升级联系人。
值班交接写清未完成事项与风险。
用「错误预算」决定是否暂停发布，而不是拍脑袋。
6.4.5. 复盘（Postmortem）
复盘对事不对人，输出：
时间线（检测、响应、恢复）。
影响（用户、时长、数据）。
根因（技术 + 流程）。
做对了什么、做错了什么。
改进项（负责人 + 截止时间）。
避免「人为失误」作为根因；继续问「为什么这个操作会导致事故」「为什么没有拦住」。
6.4.6. 容量与混沌
容量：按峰值 + 余量规划，定期压测；节点池留 burst。
混沌：主动注入 Pod/节点/网络/依赖故障，验证告警、切换与 runbook。
游戏日：团队一起演练一次真实故障，记录响应时间。
混沌实验要先有稳态指标与回滚开关，不要在生产直接随机杀节点。
6.4.7. 实验：定义 SLO 并演练一次告警
给一个服务定义成功率 SLI 与 99.9% SLO。
用 Prometheus 规则计算 30 天错误预算。
配置 Alertmanager：预算消耗 > 50% 发 warning，> 80% 发 critical。
注入 5% 错误，观察告警与 runbook。
写一份 1 页复盘。
6.4.8. 验证清单
每个核心服务有 SLI/SLO 与错误预算。
告警是症状型、可执行、带 runbook。
事件分级与 IC/Comms/Ops 角色明确。
值班表与升级路径可用。
复盘有改进项与截止时间。
至少每季度一次混沌/游戏日演练。
6.4.9. 排错表
现象 |
原因 |
处理 |
|---|---|---|
告警太多 |
阈值太敏感/无去重 |
聚合、抑制、只保留症状告警 |
告警没人处理 |
无 owner/runbook |
补 owner、值班表、升级路径 |
SLO 一直达标但用户不满 |
SLI 选错 |
用用户路径/业务指标重定义 |
复盘无改进 |
没有跟踪 |
改进项进工单，定期回顾 |
故障恢复慢 |
没有演练 |
游戏日、runbook、自动化切换 |
6.4.10. 进阶挑战
给一个 API 定义 SLO，并用 Pyrra/Sloth 生成告警。
写一份 SEV2 事件响应 runbook。
做一次 Pod 故障注入，记录检测到恢复的时间线。
用错误预算决定一次发布是否继续。
6.4.11. 小结
SRE 用 SLO/错误预算管理可靠性，不追求 100%。
告警要症状型、可执行、有 runbook。
事件响应要角色清晰、沟通节奏稳定。
复盘要落到改进项，混沌要可回滚。