出事了打给谁，跟他说什么

在事故进行中写出来的升级路径，本质上是一场谈判，而最怕损失的那个人会赢。所以它要在平静的那一周写好、书面确认，并放在值班的人凌晨两点不用问任何人就能找到的地方。

四级，按后果定义

按时间定义级别没什么用：一份内部报表停五分钟，和一条支付链路停五分钟，不是同一件事。按后果定级，时间自然跟着来。

级别	触发条件	打给谁	响应预期
L1	功能降级，工作可继续	值班 FDE	当天
L2	一组用户的业务流程被卡住	FDE + 客户流程负责人	一小时内
L3	影响钱、安全或受监管记录	双方负责人，书面	立即，电话
L4	数据丢失、泄露或公众影响	双方高管、安全、法务	立即，不等诊断

两条规则让这张表成立。第一，客户方的流程负责人要有名字——不是「业务方」，是一个人，一个被拨通过的号码。第二，任何人都可以往上多升一级，多余的升级代价是一场对话，不是一次责备。一个怕把人叫醒的组织，发现事故总是偏晚。

每次更新说什么

每次都是同样的两个句子加一个时间：现在确认的是这些，接下来我们做什么，下次什么时候给你消息。 除此之外不说，直到真的有了别的。

三样东西不进更新。未确认的原因——第一个版本的故事会成为官方版本，而它通常是错的。承诺的修复时间——除非你知道原因。以及任何带有归责意味的措辞，包括那些温和的形式（「某操作员录入了……」），因为归责会让行为往隐藏信息的方向走。

FDE 可以承诺什么

这个岗位的权限在第一次事故里通常模糊，事后就清楚了。提前定好：什么可以自己决定（回滚到上一个已知正常版本、关掉一个功能、从备份恢复），什么需要客户点头（碰到他们的数据或他们其它系统的事），什么永远不是现场决定（改合同、承诺赔偿、跟他们的监管方说话）。

最有用的一条预先授权，是关掉已部署的功能。一个关不掉的部署不是部署，是一个等着日期的故障。

七天后的复盘

不是当周。修的人还累着，被影响的人还气着，两边产出的都是叙事，不是结论。

产出是一份文档：一条时间线（观察与推断分开，见现场排障）、一到三个原因、一到三个变更，带负责人和日期。以「以后更小心」结尾的复盘什么都没产出，因为小心不是一种控制。

判断复盘是不是真的，三个测试：

• 明天同样的事还会再发生吗？会，就是没有变更。
• 变更落在系统里（一个检查、一道守卫、一条告警），还是落在人的记忆里？
• 事故组之外，有谁读过它？

这件事对生意的意义

部署是在事故里丢的，而丢的原因往往不是停机本身，是停机周围的那片沉默。在客户发现之前就打电话过去的供应商，会被记很多年；自己发现的客户，会准确而糟糕地描述你。

同一份复盘清单也喂给四周法则：一个造成过 L2 及以上、现在停用率超过三成的功能，不算活着，诚实的做法是把它拿掉，而不是留着当纪念碑。至于整个部署最后留下什么、按什么条件留，由日落条款决定。