大家都知道测试是不可穷尽的，有时候遇到项目时间紧、测试时间被压缩，就很容易产生业务场景漏测。如果漏侧场景引起线上故障，是一件非常可怕的事情。前事不忘，后事之师。那么，我们如何对线上故障进行复盘，并有效避免重蹈覆辙呢？今天就给大家分享一下这方面的经验，本文可以作为故障分析的范式，大家可以按照这个模式来做。
有相关经验的同学应该晓得，参与同组或者兄弟团队的线上故障复盘会议，对于不熟悉这块业务的同学来说，作为故障分享者，做好一场高质量故障分析的难点就是如何给“小白”讲懂业务，讲懂根因，这样才能让大家给你一些建议。
下面切入正题，大家可以参考下图，一场高质量故障分析可以采用下面的步骤。
我们以《B站宕机事故复盘》为案例，可以对这个线上故障重新进行分析。
1.故障描述
1.1 故障类型
故障类型可以分为 1、代码错误 2、设计缺陷 3、性能问题 4、配置相关 5、安全相关 等
1.2 故障等级
一般决定故障等级的因素就是对公司核心业务的影响程度，例如本司是做支付的，那么核心业务就是资金的流动，等级可以根据资金损失的多少来制定（当然还会结合其他因素综合评定例如客诉等）。B站的缺陷等级应该和我司的有所不同，我也在网上Google到其故障等级，如下图：
高危漏洞 毫无疑问应该是P0故障了。
1.3 影响面
这个就是说这个故障影响了多少在线用户使用体验，导致了多少资金上面的损失。
这个一般公司会有各种业务指标的大盘，会根据故障发生的这段时间统计出来影响到的流量。（本司的话就是交易量、用户量、资金金额等）
1.4 应急时间
可以理解为故障止损时间，即从开始处理故障到故障处理完成的时间。
1.5 问题如何发现的
首次发现是通过业务告警（系统具备业务告警能力是非常重要的），其次是客诉。
2.背景介绍
这块建议把缺陷引入的迭代与上个迭代进行业务对比来说明。例如这个缺陷引入前的功能是怎样的，然后缺陷引入的迭代是业务是怎样的。通过对比可以分析但业务影响点。
3.根因分析
对于互联网产品来说，问题根源基本上是代码逻辑的问题。这块的分析重点肯定就是代码逻辑，可以重点分析问题代码引入前后两个线上版本的差异。
4.解决方案
应急策略一般是临时打补丁（治标不治本），而解决方案则是治本的。
5.反思
反思是故障分析的核心，可以从 事前事后 出发。以B站这个问题为例，它主要分析故障发生后的一些反思。但我认为二者同等重要。
事前
- 当时测试这块功能的用例是怎样的？用例覆盖的业务全面吗？
- 为什么当时测试没发现呢？（线上为何没发现。。）
事后
6.改进措施
首先明白一点，线上问题的锅不能只让测试来背（不容置疑，很多小公司的作风就是这样的，测试就是背锅侠），改进措施也需要从开发、测试的角度出发。
