游戏日

在 staging 注入失败的游戏日，在真实宕机前练事件响应。

为什么

某人首次当事件指挥官不应是真实 SEV1 时 — 他们会在收入降时学角色，这是最坏学时。游戏日在 staging 注入计划失败（杀 DB、饱和缓存、部署坏版本）并跑全事件响应：IC 指定、作战室、通讯、回滚、复盘。这训 IC 肌肉、测 runbook（回滚真工作吗？）、并在安全环境揭监控或工具缺口。跑季度游戏日的团队报真实事件 MTTR 快 50% 因响应被排练，且在真实宕机依赖前抓 runbook 腐（3 月前坏的回滚脚本）。

何时使用

Tier 1 服务季度、大发布前、新值班工程师加入轮换时。

如何做

1. 选与你 top 风险相关的失败场景
   - 单 DB 则"DB 主挂"；多区域则"区域挂"；常发布则"坏部署"
   - 场景应合理 — 你在为真实宕机排练非科幻边界

2. 排定时间在 staging 注入失败
   - 用混沌工具（ChaosMesh、Gremlin）或手动：杀 pod、饱和缓存、部署坏分支
   - 通知团队："游戏日开始，staging 结账将挂约 30m"

3. 真跑全事件响应
   - 指 IC、开作战室、跑通讯、跟 runbook、试回滚
   - 与真实事件唯一差是 staging 且排定 — 其他都真

4. 立即复盘
   - 告警触发了吗？runbook 工作吗？回滚成功吗？响应何处停？
   - 捕行动项："runbook 步 3 错"、"告警 8m 未触发"、"IC 不知 SME 是谁"

5. 像复盘项跟踪游戏日行动项
   - 修 runbook、修告警、训 IC — 这些是真可靠性赢非练习
   - 找到 3 坏 runbook 的游戏日是大成功；找不到的是担忧

示例

# 游戏日：结账服务"DB 主挂"（staging）
13:55  引导者："5m 后游戏日开始。场景：DB 主故障。
       IC 将是 @new-oncall-engineer（首次当 IC）。仅 staging。"
14:00  引导者在 staging 杀 DB 主（ChaosMesh pod-kill）
14:02  告警触发（DbPrimaryDown）→ 值班确认，开 #gameday
14:03  新 IC："我是 IC。@debugger 查 DB 故障转移 runbook。
       @comms 草拟状态页更新（staging）。"
14:08  调试者："runbook 步 3 说'提升副本'但命令错 —
       标志是 --promote 非 --take-over。runbook 过期。"
14:10  IC："决策：内联修 runbook 命令，继续故障转移。"
14:15  故障转移完，staging 结账恢复。
14:20  复盘：
       - 行动 1：修 runbook 步 3 命令（负责人：@debugger，到期：1w）
       - 行动 2：告警 2m 触发 — 好，无行动
       - 行动 3：IC 首次干得好；IC 清单加"谁是 SME"
# 20 分钟在 staging 找到过期 runbook，零用户影响。

常见问题

⚠游戏日场景太温 — "重启 pod"测无物；选在 prod 真是 SEV1 的失败。
⚠团队当演习非真事件 — 无 IC、无作战室、无通讯；真实事件揭响应未排练。
⚠无复盘或行动项 — 游戏日跑了但找到的过期 runbook 仍过期，下次真实宕机撞同缺口。
⚠只跑一次 — 游戏日须季度（至少）使新值班工程师在真实 SEV1 前得 IC 肌肉。

最佳实践

✓选合理 SEV1 场景（DB 故障、区域挂、坏部署）并在 staging 跑全事件响应 — IC、作战室、通讯、回滚。
✓立即复盘并像复盘项跟踪行动项（过期 runbook、缺告警、IC 缺口）— 游戏日价值是它产的修复。
✓Tier 1 服务季度跑且新值班加入时；某人首次当 IC 应是游戏日非真实 SEV1。
✓找到 3 坏 runbook 的游戏日是成功；找不到的是担忧 — 你要么注入不够硬要么看不够近。