其实一直想写写有关故障处理方面的文章，互联网应用，都难免会因为人为或者不可抗的原因导致线上故障，只要业务在线上跑都有出现故障的风险，轻则只是其中某台机器down掉，实际对用户没有什么影响，重则可能整体服务不可用，影响大部分的用户。

一、定义故障等级

故障，是一个衡量业务、应用质量情况的指标，从故障的严重程度、次数，能够体现一个业务是否足够稳定，是否能够给用户提供高质量且可靠的服务。因此，我们需要给故障定义等级，定义故障等级的维度我认为可以从以下几方面进行：

有了衡量纬度，那么接下来就是认定故障等级了。不同的业务，业务的不同发展阶段，故障的认定标准都可能不一样，我们可以将故障命名为P，后面跟随一个数字，数字越小则表示故障越严重，其中P0是最大的故障，P1、P2…依次降低，因此我们可以画出类似这样的图:

可以看到有两个值比较显眼，分别是10%和8分钟，这两个值是区分不同故障等级的重要标志，不同的业务应该根据自身的情况来确定，一旦确定了不要轻易修改。即使是同一个业务，由于服务对象不同，这个故障等级也可以不一样，比如给用户提供服务的主站、给运营提供服务的运营系统、给客服提供服务的后台系统，如果根据同一个标准来指定故障等级，这是不公平且不合理的。

有些业务可能有一些非常核心的功能，可以根据这些功能单独制定一份故障标准，比如用户登录类的基础功能，如果出现5%的登录异常，可能就直接属于P2或以上等级的故障。

P0与P1故障的划分应该存在商量的余地，毕竟收获一个P0故障，是相当可怕的…

二、完善故障处理机制

很多时候开发、测试同学肩负着部分业务运营和故障处理的工作，当业务出现故障时，由研发和测试来定位和恢复是非常合适的，因为他们既懂得业务也能操作代码进行问题修复。在研测同学中建立值班制度是非常好的方法，这样既能解决业务运营时出现的故障，也能锻炼研测同学快速定位问题和恢复故障的能力。选择靠谱的研测同学，一个研发+一个测试的组合轮流值班，测试同学不够就两个研发组合，值班周期可以是一个星期到两个星期。值班的内容包含，但不局限于：

• 日常运营问题跟进，即产品或运营同学反馈的问题
• 日常观察监控大盘，主动发现是否出现异常
• 故障出现，需要主动响应
• 整理故障问题并确定故障等级，并在值班结束时，通过邮件或其他方式汇报值班情况。

值班同学并不一定要把问题跟出来，当确定了故障范围和功能，可以找负责相应功能的同学协助定位和恢复，值班人不一定是问题的解决者，但需要是问题解决的推动者，这点是非常重要的。

三、故障复盘

当一个故障恢复了，是否就意味着它下一次不会出现了呢，答案肯定是否定的。如果出现故障，每次我们处理完成后就让它过去了，那么我们可能并没有真正解决它。故障复盘，让我们有一种可以避免再次故障的能力。那么应该怎么做好故障复盘呢？

并不是任何故障都需要复盘的，对应的复盘力度也是不一样的，我认为P1、P0故障是需要认真复盘的，出现了这些等级的故障，很可能说明当前的业务或系统在流程或架构设计上出现了问题，因此我们要去复盘它，找到真正的原因。

1. 问题描述

   当故障出现时，短信、邮件、电话突然就来了，你也许会手忙脚乱，不知所措，这时候我们往往无法对当前发生的故障做一个准确的描述，毕竟机器不会说话，它不会告诉你它怎么了。经验告诉我们，要在关键的业务流程做好监控，当出现故障，告警的时候，我们能很快知道哪里出了问题。当然，在故障复盘时要准确、干练地描述故障。

2. 影响面

   故障等级里的指标可以部分回答这里的影响面，影响百分比与影响时长，这是影响面里很核心的指标，此外还需要根据业务类型来描述，比如影响了xxx订单的支付，影响了xxx人次的登录操作，影响了xxx个主播的正常开播，等等。

3. 问题跟踪过程

   每一次故障的排查过程都是一次学习的机会，对每一个值班的人来说，需要结合自己的知识和经验，快速定位问题，自己能够定位修复的自己跟进，不能定位的则找到对应的同学排查问题，把其中的过程或遇到的问题记录下来，这样以后自己或者其他人查看整个排查过程的时候能吸取一些经验和技巧。另外，把故障演进的过程记录下来，比如故障开始的时间点，开始处理的时间以及故障真正恢复的时间点，还有，在什么时间点尝试重启应用，在什么时间点尝试修改配置，等等。

4. 结论

   整个故障，原因究竟是什么？是主观原因 or 客观原因 ？ 根据经验，原因大部分集中在三个方面，一是刚上线不久的功能出现问题，二是依赖的第三方业务故障，导致自己对外服务异常，三是运维层面的原因，比如DNS故障、遭受DDos攻击、运营商网络故障等。也有少部分情况是，系统一直稳定运行，当达到某个临界点，出现故障，如果能够严格按照值班制度执行，类似的问题应该可以在出现真正故障前被发现。

5. 后续措施

   复盘完，必须要有对应的措施，且这些措施有对应的跟进人。每次复盘完的后续措施，一般包含两类，一是短期措施，即亡羊补牢，先把漏洞堵住，短期内不在出现。二是长效措施，这类措施一般是一些制度、规范，在后续的研测流程中需要具体实施的。

以上是复盘时采用的典型通用方法，最终以邮件或文档的形式记录，在后续能够方便的统计以及查阅。

四、小结

一个优秀的业务团队，一定是一个会经常复盘问题的团队，复盘的内容不仅是故障，线上问题也是一方面，尽管它还没有带来比较严重的问题。故障问题和线上问题在某些程度能够反映出一个业务某个阶段的质量情况，这不仅仅是质量同学关心的，所有负责该业务的同学都需要关注，并且为减少问题一起努力。