上周三凌晨两点，故障运维群里跳出一条告警：订单服务响应时间从200ms飙到3.2秒。报告我爬起来打开电脑，模板翻了半小时日志才定位到问题——某个新上线的故障推荐接口在缓存失效时直接穿透打到了数据库。事后复盘，报告团队里有人说“写个故障报告吧”，模板结果交上来的故障文档全是套话，什么“加强监控”“优化架构”，报告看得人头疼。模板

故障报告不是故障检讨书，更不是报告八股文。它的模板唯一目的是让下次遇到同样问题时，任何人能在五分钟内看懂发生了什么、故障为什么发生、报告怎么修。模板我见过太多报告把关键信息埋在第三页的“根本原因分析”里，前面全是背景介绍和影响范围——等你读完，故障早扩散了。

先说结构。第一段必须写清楚三件事：什么时间、什么现象、影响了谁。别用“某日某时”这种模糊表述，精确到分钟。比如“2024年3月15日02:17，订单服务P99延迟超过3秒，持续23分钟，影响约1.2万笔支付请求”。现象要具体，别写“服务异常”，写“接口返回503错误，错误率从0.1%升至47%”。影响范围量化，用户数、订单量、金额，能算就算。

接下来是时间线。这是整份报告最值钱的部分。从故障触发到恢复，每个关键节点都要记。谁在什么时候做了什么操作，系统返回了什么。别写“运维人员介入处理”，写“02:23 张伟重启了订单服务Pod，延迟降至800ms，但两分钟后再次飙升”。时间线要精确到分钟，最好带上操作命令或日志片段。我习惯用表格，左边时间右边事件，一目了然。

根本原因别绕弯子。直接说“推荐接口的缓存过期策略设置为永不过期，但实际缓存被LRU淘汰后，请求直接穿透到MySQL”。别写“缓存机制存在缺陷”这种废话。如果是人为失误，就写“李四在配置中心误将超时时间从500ms改为5000ms”。承认错误不丢人，藏着掖着才会让同样的坑踩第二次。

修复过程要写清楚“临时方案”和“长期方案”。临时方案是止血，比如“紧急扩容数据库连接池从50到200”；长期方案是根治，比如“给推荐接口加二级缓存，并设置随机过期时间”。别把临时方案当长期方案写，我见过有团队每次故障都重启服务，报告里还写“重启后恢复”，这等于没修。

最后加一个“后续行动”清单。每条行动要有负责人和截止日期。别写“加强监控”，写“王五在3月20日前给推荐接口添加缓存命中率监控，阈值低于90%触发告警”。行动项不超过五条，多了没人记得住。

写故障报告最忌讳两点：一是甩锅，二是模糊。甩锅的报告没人愿意看，模糊的报告看了等于没看。我见过一份报告写“网络抖动导致服务不可用”，结果一查是机房交换机固件bug。还有写“代码逻辑问题”的，具体哪行代码、什么条件触发，一个字不提。

另外，别在报告里写“我们将深刻反思”“举一反三”这种话。故障报告是技术文档，不是思想汇报。把事实写清楚，把根因挖出来，把行动定下来，就够了。至于反思，那是复盘会上该聊的事。

最后说个细节：报告写完后，让没参与故障处理的人读一遍。如果他能看懂发生了什么、知道怎么避免，这份报告就算合格。如果读完后问“所以到底为什么挂了”，回去重写。