何时使用任何故障、事故、部署失败或系统意外变更的头十分钟——特别是即将有多人同时开始动手的时候。

系统崩了的时候

故障会在响应它的人身上制造一种特定的失效：所有人同时开始做事，最吵的问题而不是最大的问题获得注意力，头十分钟产出三份重复的排查。这套流程是给第一个到场的人用的八分钟排序，主要产出是一行书面文字，说明现在在做什么、由谁在做。

工作节奏 · 8 分钟 · 发布 2026 年 10 月 5 日 · The Calm Desk 撰写

流程步骤

1. 01

   把已知的事出声说一遍，只说一次

   60 s

   一分钟，由一个人说：什么坏了、从什么时候开始、影响谁、已经查过什么。要出声说，而不是打字，好让所有人在同一时间听到同一个版本。这一分钟里不要提猜测。

2. 02

   写一行字并把它固定住

   120 s

   用两分钟，把一行字放在所有人都看得见的地方：我们在处理什么、谁在处理、下次更新时间是几点。不是一份文档，也不是一个刷满消息的频道——就是一行，里面带一个时间。

3. 03

   把排查和沟通拆开

   90 s

   现在就决定谁不参与排查：由一个人负责对客户、客服和管理层的同步。用九十秒指定人选，并且从这一刻起他不再碰系统。故障中最常见的失误，就是那个唯一懂系统的人，同时也是唯一在回答问题的人。

4. 04

   一次一个假设，写下来

   150 s

   选最可能的原因，写下来，去验证，把结果写在旁边，然后再换下一个。每个假设两分半钟，不允许并行的、没有记录的排查——记录正是为了避免同一项检查被三个人各做一遍。

5. 05

   吃点东西，喝点水，定下下次同步

   60 s

   在第 8 分钟，用一分钟：喝水，并明确说出下次更新的时间，哪怕要在二十分钟之后。一个明确的时间点，才能让其他人停止不停刷新页面——这就是「持续两小时的故障」和「吃掉一整天的故障」之间的区别。

重复排查的问题

四个有能力的人同时开始处理一场故障，通常的结果是同样的三项检查被做了三遍，而第四项没人做。解决办法不是笼统的「加强协调」，而是一份书面记录，加上一条规则：没有先写下来的检查，不许做。写下来的假设也让事后复盘变得诚实——复盘读的是「当时相信的顺序」，而不是「事后看很明显的东西」。

把修的人和说的人分开

在小团队里，同一个人常常既是修的人也是说的人，而恰恰是在小团队里这一点的代价最大——因为每隔两分钟就会有人问一个合理的问题，而提问者看不到屏幕。指定一个沟通者只需要九十秒，却是头十分钟里杠杆最高的一项决定。如果只有两个人，沟通者应该是第二懂系统的那个人，而不是最闲的那个人。

明确的更新时间

「我们二十分钟后更新」比「我们尽快更新」更有价值，而且这与准确性无关——第二次更新时完全可以把时间往后挪。它的作用是给二十个人一个「可以不用盯着」的许可。一场没人知道下次消息什么时候来的故障，就是一场所有人都在刷新所有东西的故障，它会在原来那个问题之上，制造出第二个自己造成的负载问题。

环境调整

• 状态行只放一个地方——置顶消息、共享文档或实体白板。两个地方等于零个地方。
• 先通知客服，再通知客户；从客户那里才知道出了问题的客服团队，制造的噪音会比故障本身还多。
• 在故障期间把无关频道的通知静音，而不只是降低优先级。

常见问题

如果只有我一个人在呢？

那状态行和明确的更新时间就更重要，而不是更不重要；而最该先分出去的角色就是沟通者，哪怕接手的是一位完全不会修的人。一位只能说「我们知道了，正在处理，下次更新 14:20」的同事，不需要任何系统权限，就能消掉相当一部分打扰。

要不要立刻开个电话会？

当涉及三人以上，或问题不是所有人都能看到时，电话会有帮助。低于这个规模，一条书面状态行更快，因为它不需要任何人停下手上的事，还会留下记录。如果确实要开电话会，请在一开始就说明这是用来协调的，排查仍在并行进行。

这跟事后复盘怎么衔接？

写下来的假设和结果，就是复盘的大部分原料。靠回忆重建时间线的复盘，产出的往往是「某个人力挽狂澜」的故事；有记录的复盘，产出的则是一份清单——三项被重复做了两次的检查，以及一个没人负责的输入。后一种才能带来改变。

仅供信息参考。这是一种个人工作习惯，不是事故管理标准或安全流程。请遵守你所在组织自己的上报与通报要求。