角色与宣布

一句话总结

重大事故中最先崩溃的不是服务器，而是“现在谁在做什么”。划分角色、尽早宣布、 为每个决定确定负责人，这些才能守住秩序。

为什么需要它

假设凌晨响起了支付错误告警。频道里进来了五个人，个个能干，个个都在做正确的事。一个人 开始回滚，另一个人在同一时刻重启同一台服务器，第三个人问要不要清缓存，却没有人回答。 客服中心不知道发生了什么，只能反复说“正在确认中”。Google SRE 一书第 14 章（Managing Incidents）展示的第一个场景正是这种 “未受管理的事故”——让事故扩大的不是个人能力，而是协调的缺失。

推迟宣布也出自同一根源。人们会因为“说不定没什么事，怕小题大做”而推迟。可宣布的代价只是一个频道和 三个角色，而宣布太晚的代价，是在此期间无人通告、无人指挥的全部时间。

它如何工作

基本角色有三个（规模变大时，再加上计划和记录负责人）。

角色	做的事	不做的事
IC（指挥）	优先级、决定、角色分配、掌握局势	亲自动手修——手一忙，指挥就空了
Ops（运维）	实际改动系统的那双手	独自判断、扩大范围
Comms（通告）	按固定间隔向外部通告情况	发布推测的数字

有几条规则支撑着这张表。角色要明确地交接——必须连同“IC 交给你了”一起留下记录，下一个人才会知道。 决定要有负责人——没有负责人的决定，要么两个人同时做，要么没人做。动手之前先告知“我现在正在做这件事”， 重叠的工作就会消失。许多团队用聊天机器人命令（/declare、/role、/own 之类）把这些记录下来。

宣布标准要事先定好：能看到用户受影响、没有把握独自在 30 分钟内解决、需要两个以上的团队——只要满足 其中之一就宣布。还要计时：首次告警 → 首次响应（ack）→ 宣布 → 缓解 → 结束。这些间隔就是下一次改进的出发点。

情况通告是有格式的：什么受到了多大（数字）影响、从何时开始、谁在指挥、下一次通告在何时。 数字必须是从数据中数出来的值，而不是“很多”；下一次通告时间要遵守按严重程度规定的间隔。遵守间隔 有时比数字更重要——“尚不清楚原因，30 分钟后再通告”也是通告，而沉默不是通告。

频道记录就是这样留下来的。有了机器人命令，事后就能机械地重新统计谁在何时负责了什么。

13:04:47 jun     결제 오류 경보 받았습니다. 보는 중이에요
13:17:12 jun     /declare sev2 결제 실패 증가        ← 첫 경보에서 13분
13:17:54 alex    /role ic @alex
13:18:56 alex    /role comms @blake
13:27:05 alex    /decide D1 결제 v2 기능 플래그 끄기  ← 주인(/own)이 없다
13:28:05 casey   /doing D1
13:29:04 drew    /doing D1                         ← 앞사람이 끝내기 전 — 겹쳤다
13:35:52 alex    /role ic @erin                    ← IC 를 넘겼다. 이 뒤의 alex 는 손이다

最后是呼叫。指挥要从呼叫触达人开始。呼叫服务用路由规则把告警名称接到团队，按该团队的 升级策略逐级推进，每一级都找出那个时刻的值班人（轮换表优先于值班表），用那个人的联系方式 呼叫他。这条链上只要断了一环，第一级就会悄无声息地失败，而下一级（通常是团队负责人）要 15 或 20 分钟后才会响。 升级是安全网，不是首次响应。

现场遇到的情形

最常见的失败是 IC 亲自动手。最懂回滚的人担任了 IC，又亲自做回滚，于是 30 分钟里没有人 通告，其他决定也停滞了。所以，交出 IC 之后再动手是可以的，但以 IC 身份动手，必须在记录中 显现出来。第二常见的是呼叫根本没有触达。新来的人联系方式为空、休假替班 指向离职者、告警名称改了与路由规则不符，指挥就连开始都做不到。指挥从呼叫触达的那一刻开始。

这类缺陷要出了事故才会暴露，所以成熟的团队会在事故之间检查。把一周的值班表放进模拟器，预先跑一跑 “在任意时刻响起会由谁接”，并每个季度统计宣布所需时间和 IC 动手的次数。有了数字，才能说下个 季度是否有了进步。

接下来的实验要做什么

展开支付事故的频道记录（聊天、呼叫、订单），用数据找出宣布所需的时间、角色交接的流程、IC 动手的决定、没有负责人的决定以及 重叠的工作，并用算出的数字按固定格式撰写情况通告。最后，从呼叫配置中找出三个团队的呼叫为什么 20 分钟 都没有触达任何人，并修好。