前不久线上发生了一个事故，主线是这样的，XX 平台对接了 web 端和手机终端，一个伸手不见五指的夜晚，web 端出现了问题，SRE 发现故障后迅速发起了 oncall 机制，建立了作战室。一个小时后，web 端发现是服务端的一条数据导致；这时服务端同学开始介入，发现数据库里面一个字段内容导致，小范围验证后发现置空可以解决问题，执行置空操作后，web 端线上问题解决。凌晨，SRE 再次发起 oncall 机制，手机终端白屏，查明原因是因为服务端数据为空，客户端没有判空；于是服务端升级，皆大欢喜。
领导发话，影响严重，绩效没了，赶快写复盘报告。服务端同学连夜写了一个复盘报告，XX 时间..... 持续.....解决方案..... 另外客户端也要加强逻辑的严谨性。从此客户端和服务端结下了梁子，我这么相信你，你怎么能欺骗我，无缘无故传递空数据。
身处互联网行业的人深有体会，出现问题，解决问题，这是天经地义的事情，谁还没有写过 bug。但写复盘报告，那可是要死的感觉，各种回忆，谁写谁知道。即便如此，还是要写，毕竟这是团队成长的机会。
究其根本我们应该写点啥？
个人认为，我们主要应该关注两点点，事故是怎么引起的；解决问题过程用了多久，下次能不能缩短时间。
解释下这两点，首先事故究竟是怎么引起了，变更导致的、服务依赖导致的、还是第三方基础设施或者硬件导致；不吭不响变更了线上业务导致别人故障，肯定是变更者的责任，反过来你周知了，别人还是故障了，第一责任应该是别人了。比如执行了 redis 的 keys *拖死了 redis，导致其它服务不能正常使用 redis，你不应该责怪 SRE 为什么没把业务数据库隔离开，为什么没有把 keys * 命令裁掉，自己的锅自己背，不要顾左右而言它，建议报告里面都不要提；事故解决过程一定要详细记录，这直接关乎下次碰到类似问题处理效率，如果说线上出现了一个事故，你一分钟把他解决了，可能就不再是个事故了，所以我们要认真反思解决问题的时间，并想办法缩短解决问题的过程。而不要在事故报告里面写很多放之四海而皆准的大道理，目的就是想让大家一起帮忙担责任，其实没什么意义的。
谷歌有句名言，系统正常，只不过是系统无数异常的一种特例而已。谷歌尚且这样看待故障，更何况我们呢？
说到这里可能有人要说了，这可能关乎我的钱途命运，不公平。个人认为线上事故还是要分情况对待的，比如有个同学为了提高性能引入了一个问题，最终导致事故，这种事故就不应该记入考核或者先观察观察，否则会打消大家的积极性。
到底什么应该记入考核，设置了一个 SOP 标准流程，不按照标准流程开发或者发布，这种应该记入考核，如果没有，出问题，管理者就该反思了，或者想办法制定一个。比如中午吃饭的时候发了个版本，发布完成之后，没有观察是否正常，直接去吃饭了，回来后发现故障发生了，又找不到人一起解决，最终导致了线上事故。
但事故本身都是级别的啊，评论不能用和加入购物车不能用，这完全不能划等号。换句话说，不能同等对待，可能有些看似是故障，但是完全没有影响。这就需要给故障进行定级了，对于电商或者金融交易平台，可以根据界面功能的重要性和金钱相对损失进行定级，而对于大多数后端服务而言我们可以考虑使用请求成功率进行定级，比如从请求次数的维度承诺服务可用性 95%，一个季度总共调用 1000 次；其中 50 次不可用是可以忍受的，如果一次故障消耗了 25 次，也就是 50%，就可以定位 P0 级故障，其它的以此类推。这是一种比较容易落地的方式。生活中也很常见，告诉你喝酒不要开车，非要开，只能把分扣完了。
