事故指挥与沟通结构：多人同时改系统为什么更危险
消息积压且数据库锁等待，A 扩 worker、B 减连接、C 重启 consumer——三项变更互相抵消后无人能解释结果。本页定义事故角色、止损优先于根因的原则、沟通结构与可执行的桌面演练。Runbook 的执行细节见Runbook、演练和复盘；告警触发与恢复信号见从遥测语义到可操作告警。
角色与事实时间线
事故响应需要明确事件负责人、技术负责人、沟通负责人和执行者，避免多人同时更改系统或让唯一操作员还承担全部沟通。Google事故管理提供角色和协作经验，组织规模不同可合并角色但责任不能消失。事故中先指定指挥、操作、沟通与记录角色，建立一条事实时间线；并不禁止并行调查，而是让有副作用操作有协调与可回退记录。
操作指挥需维护当前假设、证据、动作、结果和待验证项。清晰记录可避免重复操作并支持后续复盘。初期目标通常是确认用户影响、控制风险、恢复关键服务，再调查完整根因。
止损先于完整根因
止损可能是限制流量、回滚、关闭非核心功能、隔离租户或冻结数据变更；每个动作都需记录影响和回退条件。模型接口429时继续重试会放大负载，先限并发、关可选分支、保护关键租户，再定位配额或下游故障。账务正确性异常需冻结受影响写域，而不是以重试提高成功率。止损也有风险，应记录影响、授权域、退出条件与对照信号。
发现2分钟、决策3分钟、执行2分钟、验证3分钟，用户恢复至少10分钟；只报告"重启用了30秒"掩盖组织流程。演练可用相同时序比较角色不清与明确指挥的差别，但不能把一次演练当固定普遍改善比例。
沟通：说影响，不猜根因
内部状态页和用户沟通要表达已知影响、正在采取的动作、下次更新时间与不确定性，不应猜测根因或过早承诺恢复。初始通报说明已知影响、开始时刻、已采取措施、未知范围和下次更新时间；技术调查给出假设、所需证据和能推翻它的现象；业务沟通用结果与风险，不倾倒线程栈。
恢复需要业务终态与积压检查，不能只看基础设施绿色。交班传递未解决问题、当前主权、变更记录和回滚禁区，避免下班后重新执行危险动作。
可执行桌面演练
给团队按分钟发注入：CPU正常但积压年龄升；渠道429；有一租户成功率归零；一次配置发布与故障同窗。每轮只能按已有证据提出操作，记录谁批准、谁执行、如何回退。评审看是否保护用户与不变量、是否避免冲突变更、是否定时更新事实。桌面演练是角色与决策训练，不证明网络分区协议正确（见故障域、RTORPO 和切换的演练分层）。
止损与降级的操作矩阵
本页前面讲了"止损先于完整根因"，但止损动作本身可能造成二次损失：删队列、重启全部节点、清缓存都是不可逆或高影响动作。事故指挥需要的是一张按"影响面 × 可逆性"排好的操作矩阵，而不是临场拍脑袋。
矩阵两维：影响面（单租户 / 单区域 / 全站）与可逆性（可回退 / 需授权 / 不可逆）。规则很简单：可回退的动作可以由技术负责人直接执行并记录；需要授权的动作要写明批准人、影响范围与回退证明；不可逆动作默认禁止，只有在业务负责人书面接受后果、且已确认没有更小的替代动作时才允许。
用本页的错误示范对号入座："扩 worker""减连接""重启 consumer"三项并发变更互相抵消——它们都是可回退动作，但并发执行让事实时间线无法解释。矩阵不禁止并行调查，它约束的是并行执行：同一时刻只允许一个改变系统行为的动作组，其他动作排队并标注理由。
矩阵还要绑定观测项：每个动作执行后必须在固定窗口内看到可预期的信号变化（如"总到达率下降""连接等待回落""最老任务年龄开始下降"）；若窗口内没有变化，动作视为无效，按回退条件撤销而不是叠加第二个动作。
执行 python3 labs/observability_models.py stop_loss_matrix：模型把四个动作分为可直接执行与需授权两组，预期 allowed_now 含"限制新写入"与"关闭推荐"，requires_authorization 含"删除积压"与"重启全部节点"，规则字段写明不可逆动作需要具名负责人、回退证明与业务签署。脚本只做分类，不执行真实变更。
两个合理选择：A 只允许指挥者执行动作，最安全但恢复慢、单点瓶颈；B 可回退动作授权给技术负责人并行执行、不可逆动作集中审批。本例选 B，并保留一条硬规则：任何动作执行前必须写下"预期信号、观察窗口、回退条件"三行，写不出来就不执行。
架构师变化条件
跨时区团队交班：主权交接记录要含未完成操作、回滚禁区与"谁在改什么"的实时变更锁，否则接班人重放危险动作。多租户事故中止损从"全局限流"细化为"隔离问题租户"：隔离动作本身要有回退条件与误伤评估。若事故指挥工具链本身不可用（依赖同一故障域），需要降级沟通渠道与离线预案。每次变化重画角色矩阵与止损选项表。
闭卷验收
本页 8 道闭卷题收进了下方自测面板：先回忆，再展开参考答案与评分点，最后给三档自评。