我认为最重要的是：要还原事实，找到薄弱点加以改进。

提到复盘，大多数人第一时间想到的是线上出了故障，这下又要有人背锅了。或者是为那个可怜的兄弟暗暗担心，也或者是因为跟自己无关，所以松了一口气。

那么故障和复盘真的都是坏事么，我们该如何理解呢？我从以下3点讲一下对故障和复盘的理解。

在聊复盘之前，先聊下对线上故障的看法，首先，在一个复杂系统中，出现故障是必然的，没有任何系统能保证永远不出现任何故障，因此，我们要接受故障。

然后，从定性的角度来看，并非所有的故障都是坏事，有些故障是有正面意义的。比如说通过一个线上的小故障发现了一个大隐患，或者是某次故障中相关人员的意识和应急预案都很到位，但是由于故障的原因非常特殊最后仍然造成了较大的影响等等，类似这样的故障都要找出其中的亮点。

所以，我们要用辨证的眼光去看待，避免大家“闻故障色变”。为了往这方面引导，在我们的故障管理制度上，我们也是鼓励快速恢复（对于快速恢复的故障定级比较低）、鼓励通过演练发现更多的线上问题（对于由于演练导致的故障有一定的豁免权）等等。

但是同时，大家也应该充分意识到我们对故障的理念：即偶尔的系统失效是可以容忍的，人为的犯错是要严肃对待的，比如说不符合高可用规范的系统设计模式、强弱依赖设计不合理、由于人员意识不到位带来的故障处理时间较长、值班人员未及时接通oncall、由于对线上系统不够重视带来的变更隐患、不遵守变更三板斧规范等等。

总之，复盘的目的是为了总结和改进，要充分利用好每一次故障的机会，从中汲取教训进行学习，提升我们的经验，完善系统的设计，我们希望达到3个目的:

每一次的线上故障，都是一次实战练兵的好机会，除开系统本身的高可用，我们的组织也应该是高可用的，我们经常说好的系统架构是具有韧性的，那么好的团队组织也应该是反脆弱的。

所以复盘的过程中，除了找系统本身的问题，还要找工具的问题、流程机制的问题、管理的问题等等。这样，我们才能由点及面、系统化地解决问题，既治标又治本。

每个复盘会议，都必须有唯一的复盘owner，故障的复盘owner要主动引导大家，推动复盘进度，避免出现一些无意义的指责、与故障无关的发散讨论等等。

故障的背景要解释清楚本次故障复盘的背景，即发生了什么故障，影响了什么业务(产品)等故障的基本情况。在复盘文档中，可以通过结构化的语言进行表达。

例如：“x月x日xx时，xxx系统出现异常，导致了xxx，影响了xxx业务，表象为用户无法正常下单，点击下单按钮出现网络开小差，出现了大量客诉等等”。

故障背景的意义在于让别人第一眼了解清楚这个复盘的来龙去脉，根因可以不用写太多，下面会有根因环节。

讲清楚本次故障的影响范围，包括影响时间段、影响的业务(产品)线、影响的系统(服务)、订单量、用户量、客诉量，以及有无产生资损等等。

提升系统可靠性的两个关键手段：降低故障发生概率和缩短故障持续时间。回放故障的时间线，即先从旁观者的角度来理一遍故障过程，是为了思考如何缩短故障持续时间(MTTR)，MTTR即故障的平均修复时间，我们对MTTR其进行拆解，得到如下几个时间段：

MTTR = MTTI + MTTK + MTTF + MTTV。

因此在回放时间线的过程中，也要注意对以下几个关键时间点进行识别，然后逐个沟通讨论如何缩短其中的每一个环节耗时。需要注意提前识别出来的关键时间点：

一般情况下，故障是由两类原因引起的，包括直接（诱发）原因和根本原因，也就是所谓的诱因和根因。

因此在复盘过程中，既要明确诱因，更要深挖根因。比如说，某个业务系统由A/B/C 3个服务组成，依赖关系依次是A依赖B、B依赖C，某次开发同学修改了线上C服务的一个配置，使用了错误的格式，导致了整个业务系统不可用。那么在原因分析过程中，把配置文件修改为错误的格式这个动作肯定是直接原因，但是也要注意，B服务对C服务的依赖关系是强依赖么？如果C服务出现异常的情况下，B服务是否要进行兜底？等等。

可以基于5why分析法深挖根因，多问几个为什么，层层递进，比如说这样的一个场景: 线上系统运行过程中，某个ES节点突然抖动，RT时间明显变长，95线由200ms升至800ms，然后引发了上游业务异常。那么在分析原因的时候，要问以下几个问题：

要层层递进深挖根因，千万不要浅尝辄止，那样可能会错过真正的改进事项。从以往的故障来看，很多问题背后都是系统设计的问题，这样的问题挖得越深，我们的系统可用性才会越强，才能慢慢朝我们理想中的高可用架构前进。

把时间线和根因分别确认清楚之后，就能推导出我们对于本次故障复盘的改进事项了。在梳理改进事项的时候，除了与故障相关系统的改进项之外，还需要从整个故障处理过程来看，在故障的各个环节中有无需要优化改进的地方。

比如说某个故障是靠人工(用户投诉)发现的，那么要考虑下这个业务的监控告警是否完善，是否能够降低故障触达时间；比如说某个故障的告警发出之后，迟迟没有人响应，那么要从管理制度来看，对于应急值班政策的执行是否到位；比如某个故障的排查过程中，定位比较苦难，很多地方要靠人工去梳理很多信息，那么要考虑相应的排障工具是否好用、应急预案机制是否完善等等。

还有很多其他的问题，大家可以参考上面的MTTR分解环节和故障根因分解环节，自己展开思考下，这也是上面说要深挖根因和详细分析时间线的目的，这样我们才能不浪费每一次故障的机会。

在记录改进项的时候，可以考虑结合SMART原则来设计改进项：

最后，改进事项重在闭环，这个环即PDCA循环，Plan（计划）→ Do（执行）→ Check（检查）→ Act（处理），对于我们的故障复盘来说，即所有的改进事项都必须经过故障演练，通过实战演练来确保改进计划一定是有效的。

在复盘过程中，可能很多参与的同学由于经验或者背景不一样，大家对故障的理解不一定一致，那么复盘的owner要多问一些问题，来引发大家的讨论和思考，从以往的经验中，我们总结了几类问题，大家可以把这个作为讨论的框架：

当前我们在聊的这个是根因吗？从业务场景对应的链路上看，这个系统(组件)是强依赖吗？依赖是否合理、有无兜底机制。这次的变更流程是否完善、三板斧落实得是否到位。对应的观测指标是否能反映系统的真实状态，应急策略是否有效等等。

也就是所谓的提升MTBF，如果是变更引起的，那么要考虑变更流程是否完善，是否按照流程规范操作，有无对应的防御机制。如果是某个系统组件失效导致的，那么要评估该组件的可用性是多少，与它所在的链路是否匹配，这条链路是否要设计兜底方案等。如果是外部原因引起的，那么我们对外部的这个依赖是否有过认真的评估，对方的可用性能够满足我们的诉求。

故障定责每家公司都有自己对应的定责制度，这里不展开太多，只写几个关键的观点。

很多故障只是表象，大部分根因深挖下去，都会有技术管理的因素，虽然引发故障的操作可能是个人，但是更应该从团队的视角去看问题，避免把根因只归结到某个人身上。

对于故障处理过程中，积极参与定位、止血等操作的，给予正面的肯定。

即谁引入了第三方的技术组件，谁就要对其可用性负责。即我们在使用外部技术组件的时候，要仔细评估对方的可用性情况，以及我们的兜底方案等等。

红线和军规是我们的底线，坚决不能违反。现在的很多条款，都是以往的各个故障中沉淀出来，我们必须遵守且尊重这些红线军规，把它当做我们研发人员的铁律。

未知的故障不可怕，可以用来丰富我们的稳定性建设经验，但是重复的踩坑就需要认真对待了，要思考为什么以往的改进事项没有落实到位等等。

上面说到，复盘不是故障的结束，改进事项经过验收才算彻底结束，因此每一个改进事项的相关方，都应积极主动地push完成。同时，为了最大化的利用好复盘文档的价值，我们也未来也考虑通过以下几点来充分利用复盘价值：

很多问题背后都是一系列的原因，在复盘的过程中，除了唯一根因，还要把关联的原因和问题一起来看，避免头痛医头、脚痛医脚的情况，争取能够体系化解决问题。