演练报告写得很漂亮：注入成功、降级生效、恢复按计划完成。三个月后真实故障，群里同时出现五个人下指令，一个人在等"领导说怎么办"，客服在对外承诺一个没人确认过的时间点。
技术面演练得很好，组织面从没演练过。组织面只需预先定四件事：谁导演、谁踩刹车、谁判定通过、谁对外沟通。没写下来，演练只是一次受控的性能测试。
1. 演练考的是系统，暴露的是指挥结构
技术面的失败是可见的：告警、报错、超时。组织面的失败没有报错，只有一个安静的空档——没人下令，或者三个人同时下令。
| 层次 | 演练通常覆盖 | 真实故障时暴露的缺口 |
|---|---|---|
| 技术面 | 注入、降级、回滚、恢复 | 系统行为是否可控 |
| 组织面 | 不覆盖 | 谁下令、谁的话被执行、谁有权否决 |
| 授权面 | 不覆盖 | 谁能停机、谁改配置、谁对外说话 |
技术面靠工具提升；组织面只能靠把指挥链走一遍来发现，尤其是哪一步要等一个不在场的人。
2. 开演前必须写下的四行
| 位置 | 写成什么 | 没写的后果 |
|---|---|---|
| 导演 | 具名的人 + 备份人 | 现场没人推进节奏，讨论被嗓门带走 |
| 刹车 | 谁能停、按什么停、停完谁确认 | 出事时互相看，没人敢停 |
| 判定 | 谁宣布通过、依据哪几条 | 结论退化成"基本符合预期" |
| 对外 | 谁说话、说什么、对谁说 | 客服、销售、值班各有一套说法 |
─── 演练组织卡（占位，贴在演练单第一屏）
drill: DRILL_2311
director: ROLE_A // 出题与控场，不操作
director_backup: ROLE_B
brake: { who: [ROLE_C], auto: [error_rate, p99, queue_depth] }
verdict: { who: ROLE_D, criteria: [暴露未知, 刹车可用, 手册被改] }
spokesperson: ROLE_E // 对外唯一出口
audience: [internal] // 影响档位，决定谁要事先知情
最容易漏的是"判定人不能是导演"：导演知道题目，倾向证明题目设计得好。
3. 导演与演员必须分离
自己给自己出题等于没有演练：你只会考自己已经会的东西，还会在关键处不自觉给提示——"这里看看下游"。
| 分离程度 | 形态 | 收益 | 代价 |
|---|---|---|---|
| 同组不同角色 | 组长导演、组员执行 | 成本最低 | 出题会绕开组长的盲区 |
| 跨组导演 | 邻组 owner 或 SRE 出题 | 盲区互补，接近真实未知 | 需先交接结构，题目可能失真 |
| 外部导演 | 平台方统一出题 | 最接近"没人知道会发生什么" | 不了解业务约束，题容易空 |
导演的职责是出题、控场、记判定依据；不操作、不当值班主力、不在中途给答案。
4. 刹车权的三种设计
| 设计 | 触发方式 | 适用 | 失效模式 |
|---|---|---|---|
| 预设阈值自动停 | 指标越界即中止 | 指标本身可信 | 指标正是演练对象时刹车一起坏；阈值紧则频繁误停 |
| 观察者手动停 | 具名观察员喊停即停 | 无可靠指标、有经验的人在场 | 观察者级别低于执行者时喊不停 |
| 双人确认 | 两人同意才停 | 影响真实用户、风险高 | 决策变慢，紧急时两人互相等 |
关键是喊停之后不需要先解释：需要先说服别人再停的刹车等于没有刹车。刹车还必须能停任何动作，包括导演安排的下一步——设计成"不可中断"的那一步就不该出现。
─── 刹车判据（占位，写进演练单，不写在人脑子里）
auto_stop:
- p99 > BASELINE * 1.5 持续 3 分钟
manual_stop: 任何具名观察员，一句话即生效
after_stop: 导演确认状态 → 对外口径同步 → 30 分钟内不复演
5. "成功"与"失败"的定义
| 判据 | 说明 | 反面信号 |
|---|---|---|
| 暴露了未知 | 出现"我们以为会…其实不会"的结论 | 全程按剧本走完 |
| 刹车被用过 | 有人真的按了，或至少认真考虑过 | 没人想过要停 |
| 手册被改 | 至少一条真实路径与手册不一致被发现 | 手册被演练迁就 |
| 有人拒绝执行 | 执行者说"这一步我不确认，先停" | 没人质疑任何指令 |
"演练成功"常被写成"系统未出问题、按计划完成"，这恰恰说明题目太简单。中途被叫停并暴露两处"我们不知道"，是成功的一次；失败的含义是：没拿到新信息，也没人产生犹豫。
6. 范围的组织约束：不是能承受多少，是谁知情
| 影响档位 | 组织前置 | 签字人 | 代价 |
|---|---|---|---|
| 仅内部 | 通知当班值班人 | 团队负责人 | 低，随时可做 |
| 少量真实用户 | 客服知情、口径统一、回滚路径确认 | 业务负责人 | 中，需排期 |
| 生产核心 | 法务与客服知情、对外预案 | 业务 + 运维双签 | 高，按季度做 |
法务与客服是否知情，决定演练出事时它是"计划内"还是"事故"；知情不等于批准，它的价值是让口径不必现场编。
7. 名单：谁必须在、谁不该在场
─── 名单（占位，写进演练单）
在场: 导演 ROLE_A + 备份 ROLE_B / 执行者 / 观察员 ROLE_C（具名）
建议在: 客服或业务代表 // 影响判断与对外口径
不在场: 全部真值班人 // 演练期间仍要有人接真实告警
可选: 高层 // 在场会改变所有人的语气，发言靠后
另设: 演练外值班线 ROLE_F // 开始前口头宣布它存在
"全员参演"最危险：演练与真实故障同时发生，没人分得清哪个告警是真的。
8. 观察员记什么：不记步骤，记判断
| 记录项 | 例子 | 用途 |
|---|---|---|
| 判断点 | "看到 X 后决定先扩容" | 判据是否存在、唯一 |
| 犹豫时长 | 发现到第一个动作的间隔 | 信息缺口可量化 |
| 信息缺口 | "不知道下游超时在哪看" | 监控改动的来源 |
| 未经确认的动作 | 有人跳过手册某一步 | 手册与现实的偏差 |
操作步骤日志里有，不需要观察员。犹豫点比错误更值钱：错误只说明结果，犹豫说明缺哪条判据。
─── 观察记录模板（占位，一人一页，按时间顺序）
[T+00:00] 现象：ALERT_X 出现
[T+01:10] 犹豫：40 秒，问"这个算不算异常？"
[T+01:20] 缺口：无阈值定义，只有历史曲线
[T+01:35] 口头约定："先扩容吧"（未走变更单）
9. 与变更冻结的关系
| 情形 | 能不能演练 | 注意 |
|---|---|---|
| 冻结期内、不产生变更 | 可以 | 确认"中止"本身不触发变更流程 |
| 需改配置/切流量 | 视为变更，走分级 | 冻结期内通常只剩只读演练 |
| 与真实发布同窗口 | 不宜 | 出问题无法区分因果 |
演练本身就是一次变更。把它排除在变更管理之外是最常见的漏洞：不受分级约束、不留记录，出事时既不算变更事故也不算演练事故。
10. 结果的三个去向
| 去向 | 载体 | owner | 验证方式 |
|---|---|---|---|
| 改手册 | runbook / 操作卡 | 值班负责人 | 新人按新手册独立走一遍 |
| 改监控 | 指标、告警、面板 | 服务 owner | 可重复地让阈值被触发 |
| 改权限 | 权限矩阵、审批链 | 平台或安全 | 下一个需要它的人能自己完成 |
三样东西进三个仓库；全写在报告里等于都没做——报告是归档，不是待办。
─── 去向登记（占位）
- from: DRILL_2311
finding: "中止判据无阈值，只能靠人感觉"
to: monitoring // 三选一：runbook / monitoring / permission
owner: ROLE_A
due: 2026-12-05
verify: "阈值可被一次可重复的注入触发"
11. 频率与疲劳
频率跟随变更密度，不跟随日历：变更频繁期低频但贴近真实，稳定期定期小范围，连续多次后停一段。
疲劳信号只有流程被压缩——观察员取消、时长减半、"按上次的流程走"；判断标准只有一条：有没有产生一条改变行为的结论。
12. 度量：四个能改变决策的数
| 指标 | 口径 | 用来决定什么 |
|---|---|---|
| 缺口数/次 | 每次演练发现的未知假设数 | 题目是否还有难度、是否该换导演 |
| 刹车触发次数 | 手动 + 自动，含"差点要按" | 刹车判据是否可执行 |
| 手册修订数 | 演练后两周内落到 runbook 的条数 | 产出是否真的落地 |
| 参与者覆盖 | 近 12 个月参与过的人 / 应参与的人 | 是否只有少数人在练 |
演练期间真实告警转人工的次数单独记：不是失败的证据，是余量证明。
13. 排错：演练开得下去、但没作用的六种现场
| 现象 | 真实成因 | 处理方向 |
|---|---|---|
| 演练很顺，事后没人记得谁指挥 | 指挥链从未被显式走过 | 组织卡前置，导演具名 |
| 全程没人提"要不要停" | 刹车权归属不清或需先解释 | 具名观察员，一句话生效 |
| 观察记录写成操作日志 | 模板以步骤为纲 | 改以判断点与犹豫为纲 |
| 结论是"下次注意" | 判定标准缺可验证改动 | 判定人必须签一条改动项 |
| 真值班人被拉进演练 | 名单未区分参演与值守 | 显式保留演练外值班线 |
| 演练正常，真故障仍乱 | 只练技术路径，没练授权 | 走通一次"谁有权停机" |
最后一条是最常见的错觉：系统被验证过，"谁有权按下去"没有。
14. 边界：这些情况下组织面演练的收益很低
| 场景 | 为什么收益低 | 可替代做法 |
|---|---|---|
| 系统极简（单体 + 一个库） | 指挥链只有两三个人 | 约定"谁在线谁处理"，写进值班表 |
| 无外部用户（内部工具） | 影响面与对外口径都不存在 | 只验证恢复路径 |
| 刚发生过真实事故 | 真实故障已暴露组织缺口 | 先改完上次的改动项 |
| 团队 ≤ 3 人 | 导演与演员无法分离 | 与邻组互换导演，或只做桌面推演 |
| 无可观测性 | 观察员记不到判断点，只剩猜 | 先补指标，再谈组织面 |
价值来自"有人可能在真实故障里不知道该听谁的"；前提不存在时，走一遍流程就够。
15. 自测
- 演练报告只写"按计划完成、系统未异常"，缺了哪个关键判定？
- 为什么判定人不能是导演？
- 三种刹车设计各自的失效模式分别是什么？
- "真值班人不能全在演练里"防范的是哪种具体场景？
- 观察员为什么不该记录操作步骤？
- 什么情况下，组织面演练的收益低于它的组织成本？