故障应急 = 不可避免的失效与最小化爆炸半径
解决什么问题：故障必然发生，关键是反应速度和恢复质量—— 故障应急不是避免故障，而是建立"快速检测 + 快速响应 + 快速恢复 + 持续改进"的闭环。
业务问题
真实场景
场景 1：故障发生时一团乱
- 早上 9 点：告警触发
- 9:05：客服开始接到用户投诉
- 9:10：工程师 A 看到告警，SSH 上去看
- 9:15：A 发现问题，但不知道是哪个版本引入的
- 9:20：B、C 加入讨论（无明确分工）
- 9:30：不知道是回滚还是修复
- 9:45：终于决定回滚，但回滚命令没文档
- 10:00：回滚完成，但用户受影响 1 小时
- 10:30：事后没人知道发生了什么
- 第二天：同样的问题再次发生失败模式
| 失败模式 | 后果 |
|---|---|
| 无 On-Call 轮值 | 故障无人响应 |
| 无 Runbook | 故障处理凭经验 |
| 无明确角色 | 多人抢着做或没人做 |
| 无 Postmortem | 同类故障反复发生 |
| 无 SLA 目标 | 不知道该多快恢复 |
| 无 Chaos 演练 | 真发生时手忙脚乱 |
控制论视角
Ch 4 §4.6："没有反馈，就没有自动控制" + Ch 18："自适应控制"
故障 = 控制律的暂时失效
- 检测 = 反馈环路（必须实时）
- 响应 = 中央协调（On-Call）
- 恢复 = 系统重建（回滚/重启/迁移）
- 改进 = 自适应（Postmortem）
MTTR（Mean Time To Recovery）：
- MTTD（检测时间）+ MTTA（响应时间）+ MTTF（修复时间）
- 目标是降低 MTTR，不是消除故障核心概念
故障应急 5 阶段
1. 检测（Detection）
- 监控告警（metrics / logs / traces）
- 用户反馈（投诉/异常行为）
- 主动巡检（synthetic monitoring）
2. 响应（Response）
- On-Call 工程师 5 分钟响应
- Incident Commander（IC）角色
- 通讯官（Comms）角色
- 工程师（Investigator）
3. 缓解（Mitigation）
- 立即止血（限流、回滚、熔断、隔离）
- 不是根本修复（先恢复服务）
- 持续监控
4. 恢复（Recovery）
- 修复根本原因
- 回归测试
- 部署 + 观察
5. 复盘（Postmortem）
- 无指责文化（blameless）
- 时间线还原
- 5 Why 分析
- Action ItemsSLO / SLA / Error Budget
SLO（Service Level Objective）：
- 服务可用性目标（如 99.9%）
- 性能目标（如 p99 < 200ms）
SLA（Service Level Agreement）：
- 对客户的承诺
- 不达标 = 赔偿
Error Budget（错误预算）：
- 允许的故障率（1 - SLO）
- 用完 = 暂停变更，专注稳定
- 用不完 = 可以承担更多风险关键角色
Incident Commander（IC）：
- 决策者（不是技术最强）
- 不动手，只指挥
- 5 分钟决策
Communications Lead（Comms）：
- 对内对外沟通
- 状态更新
- 文档记录
Subject Matter Expert（SME）：
- 实际动手的人
- 解决问题
Scribe（记录员）：
- 时间线记录
- 决策记录Runbook（应急手册）
每个服务都应：
- 健康检查端点（/health）
- 关键指标（metrics）
- 常见故障处理步骤
- 升级路径
- 相关人员联系Chaos Engineering
原则：
- 在生产环境主动注入故障
- 验证系统韧性
- 不破坏用户
- 持续演练
工具：
- Chaos Monkey（Netflix）
- Litmus（K8s）
- Gremlin（商业）工程实践
实战 1：On-Call 轮值
原则：
- 每周轮换
- 二线支持（escalation）
- 补偿（加班或调休）
- 工具齐全（手机、VPN、文档）
流程：
1. 收到告警 → 5 分钟响应
2. 评估严重度（P0/P1/P2）
3. P0/P1 → 启动 Incident
4. P2 → 记录在工作日处理实战 2：Postmortem 模板
markdown
# Postmortem: [事件标题]
## 概要
- **时间**：YYYY-MM-DD HH:MM ~ HH:MM
- **影响**：用户/服务/数据
- **严重度**：P0/P1/P2
- **检测时间**（MTTD）：5 min
- **响应时间**（MTTA）：5 min
- **恢复时间**（MTTR）：45 min
## 时间线
- HH:MM：发生
- HH:MM：检测到
- HH:MM：响应
- HH:MM：缓解
- HH:MM：恢复
## 根因
[5 Why 分析]
## 影响
[用户、业务、数据]
## 改进项
- [ ] Action 1（负责人，截止日期）
- [ ] Action 2
## 经验
[正面经验 + 教训]实战 3：Chaos 演练
场景 1：单个实例故障
- kill -9 一个 pod
- 验证自动重启 + 健康检查
场景 2：网络分区
- 用 iptables 切断部分流量
- 验证熔断 + 降级
场景 3：数据库慢查询
- 注入高延迟
- 验证超时 + 重试 + 隔离
场景 4：Region 故障
- 模拟 AWS Region 不可用
- 验证多 Region 切换反模式 vs 正模式
| 反模式 | 正模式 |
|---|---|
| 出问题就怪罪个人 | blameless postmortem |
| 故障时群里大讨论 | 明确 IC + 决策流程 |
| 没有 Runbook | 每个服务都有 |
| 隐瞒问题 | 公开 + 透明 |
| 演练太少 | 定期 Chaos |
性能指标
| 指标 | 衡量 | 健康值 |
|---|---|---|
| MTTD | 检测时间 | < 5 min |
| MTTA | 响应时间 | < 5 min |
| MTTR | 恢复时间 | < 1 hour |
| 可用性（SLO） | 服务可用率 | > 99.9% |
| Error Budget | 剩余预算 | > 50% |
| Postmortem 完成率 | P0/P1 复盘 | 100% |
边界判断
何时用 P0/P1/P2 分级
| 级别 | 影响 | 响应时间 | 处理流程 |
|---|---|---|---|
| P0 | 全部用户 | < 5 min | 启动 Incident |
| P1 | 部分用户 | < 15 min | 启动 Incident |
| P2 | 边缘用户 | < 1 hour | 工作日处理 |
| P3 | 内部问题 | < 1 day | 计划处理 |
何时用 Chaos
- 系统已经稳定
- 关键业务
- 团队有应急文化
- 有完整可观测性
何时升级
| 当前 | 升级到 | 触发条件 |
|---|---|---|
| 无 On-Call | 24/7 On-Call | 关键业务 |
| 无 Postmortem | blameless culture | 故障反复 |
| 无 Chaos | 定期演练 | 系统复杂 |
与 L 层对位
与四源对位
| 主题 | cybernetics | IDDD | Event-Driven | SE@G |
|---|---|---|---|---|
| 故障检测 | Ch 4 §4.6 反馈环路 | — | Ch 6 确定性 | Ch 14 监控 |
| 响应流程 | Ch 18 自适应 | — | Ch 8 Choreography | Ch 24 CD |
| Chaos 演练 | Ch 21 多级分散 | Ch 10 聚合边界 | — | Ch 22 LSC |
| Postmortem | Ch 18 自适应 | — | — | Ch 9 CR |
关键洞察
- 故障必然发生——目标是降低 MTTR，不是消除。
- 明确角色 > 技术能力——IC 不动手，只决策。
- Blameless Postmortem——找根因，不找人。
- Chaos 是必须的——演练过的故障 = 真正的稳定性。
- Error Budget = 风险管理——允许失败，但有边界。
- 与 cybernetics 同构：Ch 4 §4.6 反馈环路 = 检测；Ch 18 自适应 = 恢复 + 改进。
阅读路径
新手：
1. 故障应急 5 阶段（核心流程）
2. 角色与 Runbook（应急时怎么做）
深入：
3. SLO / Error Budget（如何衡量）
4. Chaos Engineering（如何演练）
实战：
5. Postmortem 模板（如何复盘）
6. On-Call 轮值（如何组织）