故障解剖 · 栏目说明

故障复盘最容易写成两句话：几点几分发生了什么，谁操作失误。这样的复盘解决不了问题，因为下一次换个人、换个系统，同样的坑还会再踩一遍。

这个栏目想做的，是把故障拆开看。

解剖框架

每篇解剖尽量覆盖六个部分：

1. 影响面：影响了哪些用户、哪些业务、多长时间，损失如何量化。
2. 时间线：从第一个异常信号到完全恢复，关键节点精确到分钟，包括误判和走弯路的阶段。
3. 触发链：直接触发因素是什么，前置条件是什么，哪些环节本来可以拦住它。
4. 放大因素：为什么一个小问题会变成大故障，是重试风暴、雪崩、配置扩散，还是容量不足。
5. 处置过程：谁在什么信息下做了什么决定，哪些有效，哪些无效。
6. 改进项：分为立即修复、短期加固、长期治理三类，并明确负责人和验证方式。

写作原则

• 不把根因简单归结为「操作失误」。人会失误是常态，系统应该假设人会失误。
• 区分「触发因素」和「系统性缺陷」。前者是导火索，后者才是反复出问题的原因。
• 改进项必须可验证。没有验证方式的改进项，等于没有改进。
• 涉及真实系统的内容做脱敏处理，但保留技术细节和判断过程。

适合谁看

负责生产稳定性的 SRE、运维、研发负责人，以及需要做故障复盘和应急预案的团队。

更新计划

每月至少一篇完整解剖，遇到典型故障随时加更。欢迎提供脱敏后的案例线索。