线上故障处理深入思考，看这篇就够了！

  点击上方 "程序员小乐" ，关注公众号

8点20分，第一时间与你相约

每日英文

Honestly I don't have time to hate people who hate me, because I'm too busy loving people who love me. 

说实话，我没时间去讨厌那些讨厌我的人，因为我在忙着爱那些爱着我的人。

每日掏心话

这是深秋的夜，特别的凉，那种凉不同于夏天，比不上春天，输与冬天，但就是因为它的这种，让秋很是不寻常，很是捉摸不定的。

来自：熊二哥 | 责编：乐乐

链接：cnblogs.com/xiong2ge/p/bughandle_standard.html

图片来自网络

往日回顾：史上最烂的项目：苦撑12年，600多万行代码...

   00 前言   

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

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

  01 事中处理   

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

1.1.线上故障处理SOP

• a.线上故障第一要务【发布回滚】，因此针对高风险代码，一定要单独发布，便于回滚

• b.线上故障第二要务【周知干系人】，随时通报故障处理进度，让真正了解该问题的干系人尽早参与进来

• c.故障代码revert【通常来说，代码问题只要无法在30分钟内修复，就一定要回退代码，避免其他项目把错误代码带上线，再次带来故障】

• d.修复问题，冷静的完成回归测试后重新上线，如果BUG带来错误数据则需要全面评估数据清洗的风险，避免造成更加严重的次生伤害【很常见】

   02 事后总结   

2.1.故障定级

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

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

• 不同业务：交易、支付、领券属于重要业务，出问题对公司影响很大；C端影响通常要比B端影响大很多

• 不同层次：前端的影响会小一些，后端的会大一些，基础的会更大【包括中间件、运维等】

• 不同持续时间：如故障持续3分钟，bug一上线就发现，通常故障级别会比较低，持续12小时，可能CTO都危险了，因此出现问题及时通报很重要，瞒报只会无限的扩大风险

• 不同后果：影响用户下单100单，产生15个客户投诉，影响商家编辑商品2小时等，这部分的指标一定要和业务、产品沟通确认，他们有这部分最大的发言权。

tip:

【后果数据来源】：通常取前1日、上周同日数据作为参考，根据业务线有差异，此外，互联网业务因变化快去年的数据通常不具参考意义

【构思角度】：可以从空间、时间、组合空间和时间维度

2.2.责任人范围

明确责任人，到底是产品、开发还是测试同学的责任，亦或者是多个干系人共同分担责任。比如由于是产品设计不合理带来的bug，产品同学需要负主要责任，有测试同学参与的项目，测试同学需要和开发同学共担责任，而其他情况，就只能是开发同学自己背锅了。

2.3.故障复盘

在故障处理完成后，一定要复盘并由责任人编写Case Study，并根据相关价值决定是否需要团队内分享【一定要避免同样的问题再次发生】

2.4.故障处罚

开发人员及其多级Leader、[测试人员]及其多级Leader共同分摊，比如开发小A罚款200元，Leader罚款500元，CTO罚款1000元等。

   03 事前预防   

3.1.故障预防

• a.规范代码规范、数据库设计规范、日志和告警打点规范

• b.规范git分支建立和合并、规范测试流程【全面的单元测试、是否需要测试介入等

• c.规范Review制度，明确审核的责任【至少要识别出代码上线带来的风险，以明确Review的仔细程度】

• d.规范上线流程【每个项目都需要上线计划，包括配置、数据库、代码项目和发布顺序、回滚方案等】

• f.引入灰度发布、预发和监控机制，灰度应用出现问题及时回滚

• e.规范【数据清洗】等高风险行为，高度重视这类操作【容易被忽视】，必须提供完整方案【包括是否备份、如何回滚等】

tip:

以上内容很多是站在比较理想的角度去思考的，实务中，一定要根据具体业务、成本考量、团队能力等因素进行剪裁和权衡，㊗️永远都没有线上故障。

名词解释

SOP: Standard Operating Procedure标准操作流程，就是将某一事件的标准操作步骤和要求以统一的格式描述出来，用来指导和规范日常的工作

说说你如何快速处理线上故障？

欢迎在留言区留下你的观点，一起讨论提高。如果今天的文章让你有新的启发，学习能力的提升上有新的认识，欢迎转发分享给更多人。

欢迎各位读者加入程序员小乐技术群，在公众号后台回复“加群”或者“学习”即可。

猜你还想看

阿里、腾讯、百度、华为、京东最新面试题汇集

10张 GIF 动图让你弄懂递归等概念

切换到Linux工作，世界更美好

OAuth2 实现单点登录 SSO，看这篇文章就对了！

详细介绍！Linux 上几种常用的文件传输方式

Spring 动态切换、添加数据源实现以及源码浅析