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