# 事故头五分钟：先保现场，再下结论

---
![14号workbuddy开发者沙龙相关事宜沟通 (3).jpg](https://developer.qcloudimg.com/http-save/yehe-11546919/41b2c6a6e9df72b052bf79dd16279870.jpg)
凌晨两点十七分，电话响。你摸到手机，屏幕上是一串监控推送。

打开工作群，九十九条未读。翻上去，三个人已经在猜原因了：一个说「是不是昨晚那个发布」，一个说「肯定是连接数打满了」，还有一个直接 @ 你：「要不要先重启？」

这时候最危险的不是故障本身，是**这九十九条消息里，没有一条是事实**。

我说的「头五分钟」，不是掐着秒表算的五分钟，是一段节奏——从你被叫醒，到你开始动手之间的那一段。这段节奏走对了，后面几小时都顺；走错了，你会用一整晚来还。

## 一、第一件事不是修，是「别把现场弄丢」

新手最容易犯的错，我当年也犯过：上来就重启。

重启有奇效——服务起来了，页面能打开了，群里开始刷「恢复了」。然后呢？日志被截断，连接全断了，内存里的现场没了，`kill -9` 之后那个进程死无对证。第二天复盘，你手里只有一句「重启后恢复」，等于什么都没学到。**下一次同样的故障，你还得再重启一次。**

所以头五分钟的第一条纪律，反人性但必须守：

> **先保现场，再动手。能不重启就不重启，非重启不可，先取证。**

取证这件事没那么玄，就是几样东西先落盘：

- 进程在不在、状态是什么（`ps`、`systemctl status`）
- 当前连接/会话在干什么（谁在等、谁在跑、等了多久）
- 最近一段日志（**先复制出去**，别让它被轮转掉）
- 关键资源瞬时值（内存、磁盘、句柄数）
- 故障时间点前后有没有变更（发布、配置、定时任务）

这些东西不占几分钟，但它们决定了你今晚是「救火」还是「破案」。

**一个很实在的判断标准**：如果你重启完，说不出「它为什么会挂」，那你只是把火盖住了，没灭。

## 二、第二件事：定影响面，别定原因

头五分钟里，唯一有资格下结论的人是「事实」，而事实通常还没到。

但有一件事现在就能确定：**影响面**。谁受影响、影响到什么程度、还在不在扩大。这三个问题比「为什么」重要得多，因为对外沟通、要不要上报、要不要降级，全靠它。

我习惯用三句话把影响面说清楚：

1. **谁**：哪些业务、哪些用户在受影响（全部还是部分）
2. **多严重**：不可用、变慢、还是只影响某个功能
3. **在扩大还是在收敛**：现在比五分钟前更糟，还是已经稳住

这三句话能说清楚，指挥的人就知道该干什么；说不清楚，所有人都会开始猜原因——而猜测一旦开始，群里就会迅速变成辩论赛。

## 三、第三件事：给「下结论」上把锁

我得说句得罪人的话：**事故现场最没用的东西，是没验证过的判断。**

「我觉得是索引问题」「我怀疑是网络抖动」「上次也是这样」——这些话在群里一出现，就会有人顺着它去查，然后半小时过去了，方向是错的。

所以我的规矩是：**结论必须带证据，没证据的只能叫「假设」，而且要明确说「我去验证」，不能是「我觉得」。**

一句话的差别，决定了后面半小时是往前走还是在原地打转：

- ❌「应该是连接数满了」——所有人开始调连接数
- ✅「连接数现在是 X，上限是 Y，我先确认是不是打满了」——有人去查，有人继续看别的

前者是猜，后者是活。

## 四、四个角色，人少也得点明白

人一多，事故现场最容易变成「围观现场」。我见过最典型的画面：七八个人同时操作，一个在重启，一个在看日志，一个在改配置，谁也不知道别人干了什么。

人手足的时候分四个角色，人少就兼任，但**必须当场说清楚谁是谁**：

| 角色 | 干什么 | 不干什么 |
|---|---|---|
| 指挥 | 定优先级、拍板降级还是继续查、对外说话 | 不亲自敲命令 |
| 操作 | 只执行指挥确认过的动作 | 不自己发挥 |
| 记录 | 记时间线、记谁做了什么 | 不参与排查 |
| 沟通 | 对业务方/领导同步影响面和下一步 | 不解释未验证的原因 |

最反直觉的一条是「指挥不亲自敲命令」。因为一个人一旦开始敲命令，注意力就陷进细节里了，没人再看全局。**事故里最贵的资源不是技术，是有人始终抬着头看路。**

人少的时候怎么办？比如就你一个人值班。那就自己分时：**先花两分钟记录，再动手。** 记录不需要别人，几张便签就行——时间、动作、结果。事后你会感谢那个坚持记录的你。

## 五、记录：一句话一条，别写作文

时间线是复盘的唯一原料，但它也是最容易被省略的一步，因为「忙着救火哪有空记」。

所以记录要简单到不占脑子。格式就三样：

```
02:17 收到磁盘告警，根分区 100%
02:19 登录，df 确认，日志目录占大头
02:24 停止日志采集（指挥确认）
02:26 清理三天前归档，空间回到 62%
02:31 业务确认恢复
```

一句话一条，只写「几点、做了什么、结果怎样」。**不要写分析、不要写心情、不要写「可能是」**——分析留到复盘，心情留到朋友圈。

这份时间线后面有三个用处：复盘靠它、事故报告靠它、下次同类故障靠它（你会发现自己上次是怎么绕过去的）。

## 六、对外说话：只给影响面和下一步

故障期间对业务方说话，我只有一个原则：**不确定的，一个字都不说。**

能说的是三句：

- 现在影响什么（事实）
- 我们在做什么（动作）
- 下次同步是什么时候（预期）

不能说的是：「应该是 XX 导致的」「马上就好」。「马上」这两个字，是事故沟通里最贵的谎话——你说一次，下次你说话就没人信了。

## 七、复盘：复盘流程，不追人

事故过去，最难的一步是复盘。我见过两种翻车方式：一种是把复盘开成批斗会，从此没人敢说真话；另一种是开成表彰会，「大家反应迅速，处置得当」，等于没开。

我的做法是只问三个问题：

1. **这次是靠什么发现的？**（如果是靠用户投诉，说明监控有洞）
2. **头五分钟我们做对了什么、做错了什么？**（对着时间线看，不凭记忆）
3. **下次同样的故障，哪一步可以提前？**（落到具体动作，不落到「加强意识」）

第三个问题的答案必须是能写进清单的动作。「加强监控意识」不是答案，「磁盘 85% 加一条告警，负责人写我」才是。

## 八、可抄的结论 3 条

1. **先保现场，再动手**：能不重启就不重启；非重启不可，先把日志、会话、资源瞬时值落盘。重启完说不出「为什么挂」，等于没修。
2. **头五分钟只定影响面，不定原因**：谁受影响、多严重、在扩大还是收敛，这三句比「我觉得是 XX」值钱一百倍。
3. **结论必须带证据，假设必须带行动**：「我去验证」是推进，「应该是」是打转；事故里最贵的资源是有人一直抬着头看路。

---

*这一组三篇到这儿闭环了：巡检是「我去看」，告警是「它来说」，事故现场是「出事了怎么站住」。三件都立住，值班才睡得着。*


打开工作群，九十九条未读。翻上去，三个人已经在猜原因了：一个说「是不是昨晚那个发布」，一个说「肯定是连接数打满了」，还有一个直接 @ 你：「要不要先重启？」

事故头五分钟：先保现场，再下结论

领域：值班与事故纪律（台账空白领域）· 建议下周发 ⚠️ 口径说明：文中「五分钟」是一段节奏的代称，不是秒表实测；全文不出现任何未核实的故障时长、影响面数字。

运维工程师

数据库

事故头五分钟：先保现场，再定影响面，别急着下结论。重启前先取证，记录日志和资源，用事实代替猜测。结论必须带证据，假设明确去验证。按时间线记录，对外只给影响面和下一步，复盘流程不追人。记住：重启说不出原因，等于没修。

代码解释

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

事故头五分钟：先保现场，再下结论-腾讯云开发者社区-腾讯云

事故头五分钟：先保现场，再下结论

事故头五分钟：先保现场，再下结论

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐