第 6 章 · 故障演练基础
本章目标：通过 注入故障 → 发现 → 定位 → 恢复 → 复盘 验证监控与 SOP；在 staging 完成 4 类剧本；为 ch14 综合演练日 打基础。
学时建议：2.5～3 小时（含 2 小时组队跟练）
前置：ops-deploy ch04 回滚；ch05 SOP；ch07 告警（可先配基础规则再练）。
安全声明：仅在 staging-app 或授权测试环境演练；禁止未审批对 prod 注入故障。
6.1 场景说明
| 项目 | 内容 |
|---|---|
| 背景 | demo-mall 监控已部署，但团队从未验证「告警能否叫醒人、回滚能否 15min 内完成」 |
| 你的角色 | 演练参与者：注入员 / On-call / 记录员（轮换） |
| 本章任务 | 完成剧本一（Pod 崩溃）、剧本二（错误配置）各一次；提交故障报告 |
| 约束 | 演练前通知相关方；T+30min 必须恢复 staging 基线 |
| 成功标准 | MTTR 有记录；改进项 ≥2 条写入 backlog |
6.2 学完你能
| 能力 | 验收标准 |
|---|---|
| 演练分类 | 技术/流程/红蓝三类及频率 |
| 执行剧本 | Pod 删除、错配置、依赖超时至少 2 个 |
| 记录时间线 | 故障报告含发现时间、MTTR |
| 验证监控 | 告警是否在预期时间内触发 |
| 复盘改进 | 输出 2 条可执行改进项 |
| 角色协作 | 注入/on-call/复核分工清晰 |
6.3 演练价值与类型
| 类型 | 目的 | 建议频率 |
|---|---|---|
| 技术演练 | 验证回滚、扩容、备份 | 每月 |
| 流程演练 | 验证 On-call、升级、沟通 | 每季 |
| 红蓝对抗 | 安全/混沌工程 | 每年 |
| 收益 | 说明 |
|---|---|
| 验证告警 | 规则非「摆设」 |
| 熟练回滚 | 压力下仍能操作 应用部署 → 回滚 |
| 完善 SOP | 发现 ch05 文档缺口 |
| 合规 | 等保「应急预案演练」佐证 |
6.4 演练前检查（全员）
- [ ] 已通知 staging 使用方（研发/测试）
- [ ] 运维 → 监控告警 Dashboard 就绪
- [ ] 回滚命令预演：
kubectl rollout undo ... -n staging-app - [ ] 确认当前 Namespace = staging-app（非 prod）
- [ ] 记录员打开故障报告模板
- [ ] 设定演练硬停止时间 T+30min
6.5 逐步跟练 · 剧本一：Pod 崩溃与自愈（约 40 分钟）
注入（注入员执行）：
kubectl delete pod -l app=demo-api -n staging-app --force --grace-period=0On-call 预期动作：
- 收到副本数下降 / Pod 不可用告警（若未告警 → 改进 ch07）
- 系统容器 确认新 Pod 创建中
- 若 2min 未恢复，查 Events；必要时 应用部署 看 Deployment
- 一般 无需人工干预，Kubernetes 控制器重建 Pod
预期时间线：
| 时间 | 事件 |
|---|---|
| T+0 | Pod Terminating |
| T+30s | 副本数下降告警 |
| T+1m | 新 Pod Pending/Running |
| T+2m | readiness 通过，流量恢复 |
你应该看到：应用部署 Available 短暂下降后恢复；MTTR 通常 < 3min。
记录字段：发现时间、是否告警、MTTR、根因（预期内自愈）。
6.6 逐步跟练 · 剧本二：错误配置上线（约 50 分钟）
注入：修改 staging ConfigMap DB_HOST 为无效值，滚动重启 demo-api（衔接 ch02 故意犯错）。
On-call 预期动作：
- 新 Pod readiness 失败 → 旧 Pod 仍服务（若 maxSurge 允许）
- 或错误率上升告警
- 决策：回滚 ConfigMap 或
kubectl rollout undo - 验证
/health与下单冒烟
你应该看到：
- 若 readiness 正确：流量不伤及全量用户
- 若 readiness 缺失：502 告警 → 必须 ch04 补探针
改进项示例：
- CI 增加 env 校验（dev 分支不得含 prod hostname）
- staging 强制 readiness 检查本地
/ready