怎么复盘事故

如何复盘

系统在线上出现异常是不可避免的，但是可以降低问题发生的概率，减少问题导致的损失。所以在出现问题后及时有效复盘可以帮助团队更好的避免故障。

复盘包括事实、分析、订责、改进四个部分。

1. 事实：首先事实是复盘的基础，如果事实都没讲清楚就开始分析改进是没有任何意义的。
2. 分析：保证没有任何遗漏的问题，深入分析问题的根因。
3. 定责：有明确的定责标准，不要胡乱甩锅。
4. 改进：定制完整的可落地的改进方案。

四线复盘法

四线复盘法通过时间线、问题链、责任链和改进线这 4 条不同的线索来展开复盘，从而实现事实、分析、定责和改进这 4 个部分的目标。

时间线

时间线也就是问题发生的经过，包括问题发现、问题处理过程中采取的各种关键措施、问题恢复的时间和问题影响的结果等。时间信息非常关键，因为它能够反映出问题发现速度、各项措施执行时间和团队响应效率等指标。比如，运维重启 30 台机器花了 1 小时，通常情况下这种处理效率肯定是有问题的。

问题链

问题链就是明确问题的传导路劲，大多数情况下，一个问题往往不是单一原因导致的，而是多个原因组合在一起所导致的，所以分析整个问题的传导路径，才能全面地了解产生问题的过程。

问题链的路径逻辑有两类，业务流程和项目流程。业务流程是指，端到端的业务处理的过程，分析的对象是各个关联的系统。项目流程是指，端到端的项目开发的过程，分析的对象是项目各个阶段相关的人员，比如开发、测试、产品和运维等。

责任链

责任链也就是问题责任人之间的关系。结合时间线中问题影响的结果、公司的故障定级标准和问题链的分析，最终确定哪些团队或个人应该承担责任，分别承担多大的责任，接受什么样的处罚。

一个问题的发生往往是整个流程上多个环节相关的人处理有问题，才会导致最终问题的发生。比如开发人员引入 bug，测试人员遗漏了测试，产品人员没有验收到，最终才会在上线后发现问题，这个环节中只要有一个环节把握住了，问题就不会发生。

常见的责任划分：

1. 违反公司规章 / 制度 / 流程的承担主责：比如公司规定必须要有灰度策略才能升级，某业务版本直接全量升级导致发生问题。
2. 出现重大纰漏的承担主责：比如测试时漏测了某个常见的业务场景，导致上线后发生问题，测试承担主责，产品承担主责（因为上线前验收阶段没有发现问题），开发反而不一定承担责任（看具体的公司和团队要求）。
3. 问题源头承担主责：比如 A 系统磁盘故障导致接口响应很慢且问题持续很长时间，从而进一步导致 B 系统对外响应也超时，这种情况下 A 系统应该承担主责，B 系统承担次责。
4. 问题放大者承担主责：比如 A 系统磁盘故障导致接口响应很慢但只持续了几分钟，结果诱发了 B 系统的设计缺陷，导致 B 系统瘫痪超过 1 小时，这种情况下 B 系统应该承担主责。

改进线

为了制定可以落地的改进措施，要明确改进线，也就是问题的改进计划，包括具体措施、改进责任人和时间节点等。

改进计划的思路来源于两个方面，时间线和问题链，通过时间线找到问题处理过程中不合理和可以优化的地方，通过问题链找到具体需要解决的问题。

改进的方案一定要是可落地的，不要提一下很虚的方案。

案例

时间线

yyyy-mm-dd 9:00 运营收到线上反馈，有新用户登陆失败，需要多次尝试才能登陆上。
yyyy-mm-dd 9:10 相应的反馈开始增多，运营反馈问题给开发经理。
yyyy-mm-dd 9:13 开发经理收到反馈联系登陆模块负责人开始进行排查问题。
yyyy-mm-dd 9:18 登陆模块负责人开始排查问题。
yyyy-mm-dd 9:20 通过日志发现在登陆过程中查询用户资料返回为空，导致登陆失败。
yyyy-mm-dd 9:25 因为登陆服务近期没有进行更新和发版，所以把排查重点发在了mysql服务上面。开始反馈给DB团队进行排查。
yyyy-mm-dd 9:38 通过mysql监控服务发现主从同步出现延迟过高，且没有下掉延迟的从库，导致偶现数据插入后立马查询会查询不到。
yyyy-mm-dd 9:40 DB 定位到主从延迟主要问题是从库配置落后，在大并发的情况下追不上主库的进度。
yyyy-mm-dd 9:45 DB 下掉过于落后的从库。
yyyy-mm-dd 10:30 运营人员反馈暂时没有收到新用户无法登陆的反馈。
yyyy-mm-dd 14:30 开发人员升级登陆服务，对及时性高的查询强制走主库。
yyyy-mm-dd 18:00 DB 从新上线从库，对配置进行了升级，并且增加了对延迟的告警。
yyyy-mm-dd 19:00 观察一小时后没有收到反馈，问题解决

问题链

业务流程来分析：mysql 从库延迟过大，登陆服务在查询时出现查询异常。

项目流程来分析：登录开发人员没有考虑到主从延迟到来的登陆流程失败， DB 没有针对从库延迟的对应监控报警机制。

改进线

1. DB相关：
   1. 针对所有从库同步情况进行监控，针对延迟超过阈值的从库进行下线处理。
   2. 升级从库配置，与主库保持一致。
2. 开发相关
   1. 针对关键业务中及时性要求很高的数据强制走主库查询。
   2. 针对非关键业务查询增加重试功能。

责任链

由于 mysql 主从延迟过高导致登陆服务查询失败进而新用户不能登陆。虽然开发人员在关键业务中没有强制走主库，但是如果在正常的处从延迟下业务是会正常走下去的，所以主要责任应该是DB。