线上故障处理深入思考

最新推荐文章于 2022-10-10 14:05:47 发布

weixin_34013044

最新推荐文章于 2022-10-10 14:05:47 发布

阅读量569

点赞数

文章标签：数据库运维 git

原文链接：http://www.cnblogs.com/xiong2ge/p/bughandle_standard.html

版权

周末早上，一个哥们突然@我，问是否有线上故障处理和定级的规范或者模板，虽然手头有既有文档，但内容显的太具象了，跟我们的业务有很强的关联性，并不是那么好直接复制到他的团队中。因此，个人对过去的线上故障处理进行了回顾和思考，并进行了简要的归纳，望帮助到需要的同学。文本将按事中处理、事后总结和事前预防的顺序进行介绍，不足之处望大家不吝赐教。

换个角度来说，其实故障处理的过程，和小朋友发高烧的处理过程类似。首先mama会带孩子上医院，如果温度高医生会要求打退烧针，类似发布回滚，之后再通常吃对症的药物慢慢恢复疾病。接下来，mama会明确小朋友生病的原因，如吹风受凉，并抱怨程序员爸爸不细心。最后，mama会提出很多的预防计划，比如禁止程序员爸爸带孩子时写代码，6了6了。

1.事中处理

遇到线上故障永远是尽快处理问题，而不是追究谁的责任，有时候快速合理的故障处理，完全可以规避掉大部分的故障危害

1.1线上故障处理SOP

a.线上故障第一要务【发布回滚】，因此针对高风险代码，一定要单独发布，便于回滚
b.线上故障第二要务【周知干系人】，随时通报故障处理进度，让真正了解该问题的干系人尽早参与进来
c.故障代码revert【通常来说，代码问题只要无法在30分钟内修复，就一定要回退代码，避免其他项目把错误代码带上线，再次带来故障】
d.修复问题，冷静的完成回归测试后重新上线，如果BUG带来错误数据则需要全面评估数据清洗的风险，避免造成更加严重的次生伤害【很常见】

2.事后总结

2.1.故障定级

简单的可以定位3级【推荐更进一步细化为3-5个层次】，严重性逐步递增：a.线上bug；b.线上故障；c.线上灾难。

一定要针对不同业务、不同层次、不同持续时间、不同后果细化故障定级，并且要周知所有干系人，确认后执行，以电商平台为例。

不同业务：交易、支付、领券属于重要业务，出问题对公司影响很大；C端影响通常要比B端影响大很多
不同层次：前端的影响会小一些，后端的会大一些，基础的会更大【包括中间件、运维等】
不同持续时间：如故障持续3分钟，bug一上线就发现，通常故障级别会比较低，持续12小时，可能CTO都危险了，因此出现问题及时通报很重要，瞒报只会无限的扩大风险
不同后果：影响用户下单100单，产生15个客户投诉，影响商家编辑商品2小时等，这部分的指标一定要和业务、产品沟通确认，他们有这部分最大的发言权。

业务	持续时间	后果	定级
用户订单	5分钟	损失10万订单	线上灾难
商家商品	45分钟	商家45分钟不能编辑和新增商品信息	线上故障
用户评论	3分钟	用户3分钟不能编辑和查看评论信息	线上bug