你的生产网站刚刚宕机了。你会怎么处理？

Question

你的生产网站刚刚宕机了。你会怎么处理？

Accepted Answer

首要任务是**先恢复服务，再找原因** —— 缓解先于诊断。我会宣布一个 incident，分配清晰的角色，朝着最快的安全恢复推进，并全程沟通。

## 先稳住

- **宣布 incident**，开一个统一的频道（war room / Slack thread），这样协调就不会四散。
- **分配角色**：一个 **Incident Commander** 负责拍板，一个 **comms owner** 负责向 stakeholder 通报，以及负责排查的 **responders**。作为 Tech Lead，我经常担任 IC，好让工程师专注于问题本身。
- **采用最快的可逆修复。** 如果某次 deploy 与宕机相关，先 **rollback**，问题之后再问 —— 恢复用户比证明自己正确更重要。

## 并行诊断

- 检查**明显的信号**：仪表盘、错误率、最近的 deploy、基础设施变更、流量激增、过期证书。
- 形成一个假设，先验证成本最低的那个，**避免一次改五样东西** —— 否则你不知道是哪个起了作用。

## 持续沟通

沉默会滋生恐慌。即便没有新消息，我也按稳定的节奏发更新：

```
[14:05] 排查中 —— checkout 宕机，约 40% 用户受影响。下次更新 14:20。
[14:20] 已定位：一次错误的 deploy。正在 rollback。预计 10 分钟。
[14:35] 服务已恢复。监控中。postmortem 随后跟进。
```

## 恢复之后

- 确认是完全恢复，而不只是“看起来好些了”。
- 在几天内运行一次**无指责的 postmortem**：时间线、根因、是什么让它难以发现/修复，以及**带负责人的具体行动项**。
- 产出是系统性改进（更好的告警、护栏、rollback 自动化）—— 而不是一个用来背锅的名字。

## 陷阱

- 在用户受苦时**先调试再缓解**。
- **没有单一决策者**，于是五个人并行地猜。
- 对 stakeholder **失联**。
- **指责个人**，这会扼杀未来 incident 所依赖的诚实。

## 为什么这很重要

宕机不可避免；你如何应对它定义了团队信任和客户信心。冷静的、基于角色的协调，加上无指责的后续跟进，能把糟糕的一天变成更强的系统 —— 同时向你的工程师传递一个信号：可以放心快速行动，因为失败是被当作一个流程来处理的，而不是一场猎巫行动。