内容摘要：凌晨三点十七分，值班室的电话响了。对方说系统在批量提交订单时出现“偶发性数据错位”，具体表现是收货地址串到了隔壁省。我让他先把日志发过来，别急着重启服务。挂了电话我盯着天花板想，这周第三个了。异常报告

凌晨三点十七分，异常值班室的报告电话响了。对方说系统在批量提交订单时出现“偶发性数据错位”，模板具体表现是异常收货地址串到了隔壁省。我让他先把日志发过来，报告别急着重启服务。模板挂了电话我盯着天花板想，异常这周第三个了。报告异常报告模板这东西，模板平时没人看，异常一出事全在找。报告

我见过最离谱的模板一份报告，正文只有一句话：“系统于14:23出现异常，异常现已恢复。报告”没了。模板提交人是个工作五年的运维，我问他当时CPU多少、哪个接口报错、影响多少用户，他回我“没来得及看，重启就好了”。这种报告交上来，等于把问题原地埋进土里，下次换个姿势再炸一遍。

所以模板得先解决“写什么”的问题。我的习惯是分四块，但别用那种“一、二、三、四”的标题去框，写的人难受，看的人更难受。第一块写现场——不是让你抒情，是把时间、节点、触发条件、第一手现象扔进去。比如“3月12日02:15，订单服务pod-7g8k在收到批量请求后，日志出现连续17条‘address_id mismatch’，同一批次请求中约3%的地址字段被替换为其他省份数据”。精确到这种程度，看的人才能判断是代码bug还是数据污染。

第二块写你干了什么。注意，是“干了什么”，不是“尝试解决”。很多人写报告喜欢用“排查了相关服务”“检查了数据库”，这种话等于没说。要写“02:23 重启pod-7g8k，异常消失，但02:47再次复现”。复现这个词很关键，它告诉后来人：重启没用，别走这条路。

第三块写推断，但别写成结论。推断要带证据链。比如“怀疑是缓存穿透导致旧地址ID被回填，依据是异常请求的session_id在Redis中对应的address缓存已过期，但本地Caffeine缓存未失效”。这种写法留了余地，也给了方向。最怕看到“疑似网络抖动”这种万金油推断，网络不背这个锅。

第四块写待办。待办要具体到人、到动作、到时间。别写“后续优化缓存策略”，写“张工在3月14日前给address缓存加二级过期时间，过期后强制回源”。谁、做什么、什么时候，三要素缺一个，这事就会永远躺在“后续”里。

模板的格式我建议用纯文本加缩进，别搞花哨的表格。表格填起来像在写作业，写的人会本能地凑字数。我自己的模板长这样：

 [异常编号] 20240312-0215-order-addr [发生时间] 2024-03-12 02:15 [持续时长] 32分钟（02:15-02:47） [影响范围] 批量订单接口，约3%请求地址错位，涉及用户约120人 [现场记录] - 02:15 pod-7g8k日志出现address_id mismatch - 02:17 监控显示该pod QPS突增到平时4倍 [处置动作] - 02:23 重启pod，异常消失 - 02:47 再次复现，确认非偶发 - 02:50 摘除该pod，流量切至其他节点，异常停止 [推断] - 缓存穿透导致旧地址ID回填，证据：异常session的Redis address key已过期，本地缓存TTL未同步 [待办] - 张工 03-14前 给address缓存加二级过期 - 李工 03-15前 给批量接口加地址校验开关 

有人觉得写这么细太费时间。但你想过没有，你花二十分钟写清楚，下一个接手的人可能花两分钟就能定位。你花两分钟糊弄过去，下一个接手的人可能花两小时重新踩一遍你踩过的坑。这笔账不难算。

还有一点，异常报告不是写给领导看的。领导只看“影响多大、多久恢复、谁负责”。真正读你报告的是凌晨三点接你班的那个同事。他困得眼睛都睁不开，指望你写的现场记录能让他少翻一次日志。你写“系统异常”，他就得从零开始查。你写“pod-7g8k在02:15出现address_id mismatch”，他直接去看缓存配置就行。

我现在的习惯是，处理完异常先不关终端，把关键日志复制到模板里，趁记忆还热乎赶紧写完。拖到第二天再写，你只会记得“大概重启了一下”。细节全丢了，报告就成了废纸。模板本身不复杂，复杂的是你愿不愿意在刚救完火、一身汗的时候，坐下来把火场图画清楚。