失败是成功之母，针对一次典型的生产事故做一次全方位的深度复盘，对于快速提升系统稳定性帮助非常大。然而现实中我们经常发现很多事故并没有复盘，或者复盘也仅仅是浅尝则止，就事论事，很难达到效果。事实上，一次触及灵魂的复盘能从组织保障、运维机制、人员分工、操作规范、研发流程、设计原则、系统架构等影响系统稳定性的方方面面找到问题，一劳永逸的补齐很多不足。那么，什么样的事故复盘才算是一次灵魂复盘？

一个典型事例

在一个 7X24 小时提供服务的移动 APP 应用中，存在 APP 网关、登陆服务、账户服务、订单管理服务等几个典型的微服务。账户服务提供账户认证和账户信息查询，订单管理服务接受下单请求并提供订单明细查询。某星期五晚上 11:30 发生了如下事故：

11:30：移动 APP 一线运维值班人员 A 通过监控发现有用户查询账户信息失败，便电话联系订单管理服务的运维人员 B 排查

11:35：B 确认订单管理服务一切正常

11:36：A 电话联系登陆服务运维人员 C 排查

11:41：C 确认是账户服务未返回成功响应，在内部即时聊天群中 @账户服务运维人员 D

11:50：D 看到聊天留言后登陆生产环境，并确认是账户数据库异常，电话联系 DBA 排查数据库故障

11:58：DBA 确认数据库主库无响应，重启后仍未恢复，于是电话联系 D 建议切换到备库

00:05：D 开始着手切换到备库，期间与 DBA 保持电话沟通

00:15：D 确认账户服务成功连接到备库，在内部即时聊天群中 @APP 一线运维人员 A，更新状态，内部处理结束

该问题从发现到彻底解决用时约 45 分钟，期间影响几百个用户使用账户查询功能，社交媒体上有一些负面帖子，公司客服也收到几起客户投诉。事实上，类似生产问题在这样的分布式应用中是非常常见的，做得好的话，该问题即时发生也可以做到几乎对客户无影响。但本次事件却持续了很长时间，也造成了很不好的影响。那么，到底是哪里做错了呢？如文章开头所说，一次成功的复盘可以帮我们找到绝大部分问题。事实上，因为事件影响较大，该事故相关方事后也进行了复盘。我们先来看看他们的复盘得出了什么结论，是否算是灵魂复盘。

第一次复盘

参与人：A，C，D，DBA

复盘结论如下：

1. D 和 DBA 负责的系统都有错误告警报出来，但是因为是周五晚上 11:30，运维人员并没有第一时间发现告警，后续加强告警巡检；

2. 从问题发生到处置结束花了 45 分钟，大部分时间用于沟通协调和排除故障，后续在应急处置中加强沟通；

3. 确认问题到 D 完成切换耗时 17 分钟，耗时较长，系统架构上需要做数据库主备自动切换，在架构改造完成之前利用周末做一次切换演练。

很显然，这样的复盘对后续改进起到的作用非常有限，也许仅能帮助“相同的问题发生时切换时间缩短几分钟”，若发生类似的问题，恐怕恢复时间，对客户的影响一样都不会少。当然，如此的复盘结论也无法“交差”，于是又有了第二次复盘。

第二次复盘

参与人：A，B，C， D，DBA，以及对应 Team 的 Leader 全部到场

复盘结论如下：

1. D 和 DBA 负责的系统都有错误告警报出来，但却被 D 和 DBA 遗漏，原因在于之前并没有明确规定运维人员夜班值班的时间和分工。从现在开始，该系统的所有运维人员，明确 7X24 小时运维要求，相应的需在 B，C，D，DBA 相关团队增加夜班值班人员，保证所有的严重级别告警第一时间处理。

短期改进负责人：B，C，D 负责在新增人员到岗前保障夜班值班

长期改进负责人：各 Team Leader 负责在一个月内解决夜班值班人员问题

2. 从问题发生到处置结束花了 45 分钟，主要体现在对系统不熟悉，查问题时间较长，同时沟通协调不够高效，链条过长，需要通过日常应急演练提高效率

改进负责人：A，B，C，D，DBA 负责在一个月内制定演练场景并完成演练

3. D 将账户服务切换到备库耗时 17 分钟，理想情况下此类问题需要自动切换至备库

改进负责人：账户服务及 DBA 一周之内完成架构改进方案并给出改进计划

两次复盘对比

针对同一事故的前后两次复盘有什么区别？效果又将有什么不一样呢？我们先来尝试对两次复盘过程和结果进行一次客观对比。

1. 参与人不同。第二次复盘参与人更全面，势必会对事故理解的更全面，相应的整改措施也会更全面，整改的后续推进也会更有保障。

2. 问题解决方案不同。虽然初看起来两次复盘识别到的问题原因基本一致，但两次给出的解决方案很不一样。如针对“没有第一时间发现告警”的解决方案，第一次仅装模作样的提出要“加强告警巡检”，而第二次非常明确的提出“7X24 小时运维值班要求”，形成具体的工作职责。前者基本上属于说过就忘，无法落地，下次继续犯错的典范，后者则提出了明确的整改点，具备可操作性和可落地性。

3. 改进计划不同。前者没有任何改进计划，后者明确了短期，长期改进点，对应的负责人并给出了相应的检查时间。

根据上述对比，我们有理由相信，若第二次复盘的改进均按计划完成，那相比第一次复盘，至少会有以下效果提升。

1. 更快发现问题。再发生相同事故，无论日间还是晚上，A，D 及 DBA 都可以在第一时间看到告警，发现问题。也即本次事件中的 11:30-11:50 之间的 20 分钟可以节省掉，本次事件最多需要 25 分钟可以解决。

2. 更快定位问题。D 在看到告警后会主动去排查问题，不需要等人通知。假设 D 排查问题实际需要 4 分钟，也即本次事件中的 11:50-11:58 之间的 8 分钟至少可以节约一半，加上发现问题节约的 20 分钟，本次事件最多需要 21 分钟可以解决。

3. 更彻底解决问题。本次事件技术上的根因是数据库主库故障时无法自动完成切换，若计划中的架构改造完成，即使主库再次故障，系统自动切换至备库，对业务的影响不会超过 2 分钟，客户基本无感知，也基本不会出现负面社交帖子和投诉。

复盘方法论

分析到这里，两次复盘的客观差异和改进效果差异已经很清晰了。那么，是什么根本原因造成两次复盘的差异？我们又能得到什么启示使得我们每次复盘都能有比较好的效果呢？要回答这个问题，就需要一些复盘方法论了。

1. 复盘要以“识别潜在风险，解决根本问题，避免后续事件”为目标。这是最显而易见但却经常犯错的一点。很显然，上述第一次复盘的目标是“给上级领导一个交代”，因为事件影响大，不复盘过不去。第二次复盘才算真正以解决问题，避免类似事件再次发生为目标进行的。概括一下就是“被动式复盘”和“主动式复盘”的区别。

2. 复盘需要所有直接利益相关方参与。本次事故的直接利益相关方至少包括该移动 App 产品负责人，客户服务人员，社交媒体舆情管理人员，涉及服务的运维人员，DBA，主要架构师，各 Team Leader 等。以这个标准来看，第二次复盘的参与人也不够全面，这跟复盘方法论的第三点（复盘级别）密切相关。

3. 复盘要在现场，创造一个宽松的环境，以头脑风暴的形式让所有参与者充分参与。因篇幅所限，本次事故并未对复盘形式作介绍，但现实中复盘环境，气氛以及所有人充分、深度参与是决定复盘是否能够深入关键因素。

4. 复盘有“业务级复盘”和“纯技术复盘”两种级别。选择哪种复盘级别取决于一些客观情况。以本次事故来讲因为事件造成了客户投诉和负面舆情，事实上是应该进行“业务级复盘”的，但现实中只进行了“纯技术复盘”。

5. 复盘应触及“灵魂”，尽一切可能挖出组织保障、运维机制、人员分工、操作规范、研发流程、设计原则、系统架构等方面的问题。如果只看到某次具体操作失误，某个特定功能 Bug 或者某次性能容量问题，那复盘根本无法解决问题。如果复盘只关注 IT 系统或者技术架构本身，也无法真正触及灵魂。

6. 复盘结果要指定明确的整改措施，整改负责人，整改完成时间以及检查机制。再好的复盘如果无法落实到具体行动上，也就是一场口嗨，过目即忘，那这样的复盘还不如不做。

复盘分级

根据上述复盘方法论，我们再来看看第二次复盘算是一次灵魂复盘吗？答案显然是否定的。从这次生产事件的技术问题本身来看，第二次复盘勉强说的过去。但要说这次复盘能够对该业务后续的生产事件有多大改进就很难说了，它明显存在以下两点局限性。

1. 复盘广度不够，只做到了“技术复盘”。因技术问题带来的业务影响以及后续发生类似事件时如何避免或者减少业务影响完全未涉及。

2. 复盘深度不够，最多只触及系统架构改进，未触及灵魂。此次事件虽然是由系统架构引起，但应急处置时犯了很多错误。比如没有人关注业务影响，沟通时全部是点对点沟通造成信息碎片，沟通即时性和紧迫性不高，缺乏生产事件应急处置机制等等均未涉及。

我们可以总结一些不同级别复盘评级标准，供大家后续进行复盘时作参考。

复盘评级标准

对照上述标准，例子中的第二次复盘也仅仅是刚刚及格的“初级复盘”而已。

结尾

写到这里，关于复盘的话题也就差不多了，文中的“复盘方法论”和“复盘级别标准”均来自工作总结，记录下来以期对后续相关工作起到一定的指引作用。事实上，降低业务风险的环节有很多，文中描述的复盘环节仅仅是事后总结，是发生生产事故后的亡羊补牢。除了复盘，避免生产事故，降低业务风险还有很多更应该关注的环节，如研发流程、上线变更、运维巡检、监控告警、日常演练等等，不同环节的改进都有一些方法论可以深入探索。