知识卡片
事后总结的量化触发标准
内容
不是每次故障都值得投入时间写事后总结——书写本身要消耗团队精力，所以触发条件要提前定好、 客观且可执行：用户可见的宕机或降级达到一定程度、发生任何数据丢失、需要人工介入（回滚、切 流量）、问题解决耗时超过上限，或问题是靠人工而非监控报警发现的。提前定义标准的价值在于事故 发生时每个参与者都能立刻判断”这次要不要写”。发散：最后一条把”监控没能及时报警”本身也纳入 了复盘范畴，是更高一层的自我审视。
参考来源
- 位置：《SRE：Google运维解密》第15章《事后总结：从失败中学习》"Google的事后总结哲学"一节（源文件：_epub-src/OEBPS/Text/0009_0006.xhtml）
- 结论依据：原文列出五条"基本的事后总结条件"：用户可见宕机/降级程度、数据丢失、人工介入、耗时超限、"监控问题（预示着问题是由人工发现的，而非报警系统）"，并说明"在事故发生前定义好事后总结的标准是很重要的，这样每个参与事故处理的人都知道是否应该书写书面报告"。
- 原始内容：●用户可见的宕机时间或者服务质量降级程度达到一定标准。●任何类型的数据丢失。●on-call工程师需要人工介入的事故……●问题解决耗时超过一定限制。●监控问题（预示着问题是由人工发现的，而非报警系统）。