Runbook 测试

在 staging 定期测 runbook 使真实事件中首次执行非首次测。

为什么

未测 runbook 是假设 — 它看着对、命令写时可能工作，但 6 月系统变静默坏它：服务改名、DB 迁移、kubectl 插件删。你首次发现是真实事件中，值班跑 runbook 得错误，现须调试 runbook 和事件。在 staging 季度测 runbook（过步骤或跑脚本 --apply）在真实事件依赖前抓腐。这与测代码同洞见：未测代码在 prod 坏，未测 runbook 在事件中坏。季度 runbook 测试成本 30 分钟；SEV1 中坏 runbook 成本 15 分钟困惑调试加使事件更糟的风险。

何时使用

所有 runbook 季度、影响它们的系统变后立即、高风险发布前。

如何做

1. 排季度 runbook 测试日
   - 同游戏日节奏；可合（游戏日在场景中测 runbook）
   - 每 runbook：15-30 分钟在 staging 过

2. 文档 runbook：在 staging 手动过步骤
   - 复制粘贴每命令；成功？输出匹配预期？
   - 点每链接；解析？仪表盘显示 runbook 说的？
   - 跑验证；它真确认解决？

3. 可执行 runbook：在 staging 跑脚本 --apply
   - 在 staging 注入失败（混沌工具），再跑脚本
   - 它检测问题？执行修复？验证解决？
   - 记结果：过/失败、什么坏了

4. 修或删失败 runbook
   - 坏 runbook 比无 runbook 更糟（误导值班）
   - 修小 → 同会话修；大 → 工单和负责人

5. 跟踪通过率作指标
   - "staging 测试过 runbook / 总数" — 目标 >90%
   - 通过率降 → 系统变超 runbook 更新

示例

# 季度 runbook 测试（staging）
# runbook/checkout-slo-burn.md — 在 staging 过：
1. 注入失败：部署坏版本到 staging 结账
2. 告警在 staging 触发（或手动触发）
3. 开 runbook：https://rb/checkout-slo-burn
4. 步 1：kubectl rollout history → ✅ 显示坏部署
5. 步 2：kubectl rollout undo → ✅ "deployment rolled back"
6. 验证：错误率 <0.1% 持续 5m → ✅ 确认
7. 结果：过

# runbook/db-failover.md — 过：
1. 杀 staging DB 主（ChaosMesh）
2. 步 1：提升副本 → ❌ 命令是 --promote，runbook 说 --take-over
3. 结果：失败 — runbook 过期
4. 行动：工单"修 db-failover.md 步 1 命令"（负责人：@team-platform，到期：1w）

# 指标：过 runbook / 总数 = 18/20 = 90% ✅（目标 >90%）
# 失败的 2 个已开工单将在下季前修

常见问题

⚠无匹配 prod 的 staging 环境 — runbook 在 staging 测过在 prod 失因配置、规模或依赖异。
⚠测试是一次性努力 — runbook 写时过但数月内随系统变腐；测试须季度。
⚠仅测快乐路径 — runbook 在失败如所述时工作但真实事件有变；也测边界。
⚠无通过率跟踪 — 无指标则 runbook 腐到真实事件才见，这是最坏发现时。

最佳实践

✓季度在 staging 测每 runbook；过步骤（文档）或跑脚本 --apply（可执行）并记过/失败。
✓保持 staging 近 prod（配置、规模、依赖）使 staging 过的 runbook 在 prod 过。
✓同会话修或删失败 runbook；坏 runbook 比无 runbook 更糟因误导值班。
✓跟踪"staging 测试过 runbook / 总数"作指标；目标 >90%，降时调查 — 系统变超更新。