30 四线复盘法：怎么避免成为背锅侠？
你好，我是华仔。
在事后总结阶段，正常情况下我们主要是做收获总结和成果汇报即可，但是如果发生了明显的问题，就需要做问题复盘。
复盘是一个围棋术语，它指的是对局结束后回顾记录，检查招法的优劣和得失关键，并且根据分析提出更好的招法，提升以后的对局能力。后来，这个思路被引入到了管理工作中。
问题复盘
技术人员主要参与的是线上问题复盘，比如业务或者系统出现了线上问题，在问题解决之后往往就会组织复盘。
不管团队技术多么厉害，也不管公司多么有钱，都不能完全避免业务或者系统出现问题的可能，比如2015年5月27日支付宝发生了大规模宕机的事故，2018年10月22日GitHub发生了宕机24小时的事故等。
虽然无论做什么都不可能完全杜绝问题的发生，但这并不意味着我们只能坐以待毙。我们需要尽量降低问题发生的概率，减少问题导致的损失，因为就算事故不可避免，1年发生3次和10年发生1次，影响和意义也是完全不同的。
问题复盘的意义就在于找到问题的原因然后加以改进，避免同样的问题反复出现，降低问题的发生的概率和影响。
四线复盘法
但是，要做好问题复盘可不是一件容易的事。复盘会议上的各种明争暗斗，可能会让刚参加工作的“萌新”惊掉下巴，甚至让一些老员工也感到头疼。尤其是一些管理比较严的公司还会通过复盘来明确责任分配和处罚措施，复盘会议的激烈程度往往不亚于电视剧中的宫斗场景。
所以，怎么组织一场复盘，怎么分配责任和避免背锅，已经成了职场人的一项生存必备技能。
问题复盘的内容涵盖事实、分析、定责和改进4个部分，一次成功的问题复盘需要达成以下4个目标：
- 讲清楚事实：事实是复盘的基础，如果连事实都没有讲清楚就开始分析、定责和改进，无异于搭建空中楼阁，做得再漂亮也是没有意义的。
- 全面且深入地分析：首先需要保证没有遗漏问题，其次需要深入分析问题根因，否则以后问题还是会以其他方式反复出现。
- 得出让各方心服口服的定责结论：需要有明确的定责标准，避免拍脑袋定责，或者按照级别和关系来定责。
- 制定可以落地的改进措施：避免提出一些虚头巴脑的措施，看起来高大上，实际上却不知道怎么落地，后续也无法跟踪。
这一讲分享的四线复盘法，就是通过时间线、问题链、责任链和改进线这4条不同的线索来展开复盘，从而实现事实、分析、定责和改进这4个部分的目标。
如果你是复盘负责人，四线复盘法可以让你不偏不倚、公平公正地组织复盘；如果你是复盘参与人，它可以让你避免背不必要的黑锅。当然，如果出现问题确实是你的责任，它也不会教你怎么逃避责任，而是会告诉你怎么思考和改进。
接下来，我会针对每条线索逐一讲解说明。
第一条线：时间线
为了讲清楚事实，我们要明确时间线，也就是问题发生的经过，包括问题发现、问题处理过程中采取的各种关键措施、问题恢复的时间和问题影响的结果等。
其中，时间信息非常关键，因为它能够反映出问题发现速度、各项措施执行时间和团队响应效率等指标。比如，运维重启30台机器花了1小时，通常情况下这种处理效率肯定是有问题的。
第二条线：问题链
为了全面且深入的分析，我们要明确问题链，也就是问题的传导路径。
通常情况下，一个问题往往不是单一原因导致的，而是多个原因“碰巧”组合在一起所导致的，所以分析整个问题的传导路径，才能全面地了解产生问题的过程。
同时，针对单个问题的分析也不能浅尝辄止，而应该采用第26讲的“5W根因分析法”深入分析，找到根本原因，这样才能为后续制定改进措施提供有效的指导。
问题链的路径逻辑有两类：业务流程和项目流程。
业务流程是指，端到端的业务处理的过程，分析的对象是各个关联的系统。
项目流程是指，端到端的项目开发的过程，分析的对象是项目各个阶段相关的人员，比如开发、测试、产品和运维等。
我们一般先采用业务流程的逻辑将问题定位到单个系统，然后再针对单个系统采用项目流程的方式将问题定位到具体的人或者流程中的某个步骤。
第三条线：责任链
为了得出让各方心服口服的定责结论，我们要明确责任链，也就是问题责任人之间的关系。
我们需要结合时间线中问题影响的结果、公司的故障定级标准和问题链的分析，最终确定哪些团队或个人应该承担责任，分别承担多大的责任，接受什么样的处罚。
之所以叫责任链，是因为一个问题的发生往往是整个流程上多个环节相关的人处理有问题，才会导致最终问题的发生。比如开发人员引入bug，测试人员遗漏了测试，产品人员没有验收到，最终才会在上线后发现问题，这个环节中只要有一个环节把握住了，问题就不会发生。
定责是问题复盘中最棘手的部分，因为定责的结果会直接影响团队和个人的绩效，所以做到公平公正、让各方都心服口服是一项很大的挑战。
通常情况下，制定明确的定责标准有利于尽量减少争议，常见的标准包括以下4条：
- 违反公司规章/制度/流程的承担主责：比如公司规定必须要有灰度策略才能升级，某业务版本直接全量升级导致发生问题。
- 出现重大纰漏的承担主责：比如测试时漏测了某个常见的业务场景，导致上线后发生问题，测试承担主责，产品承担主责（因为上线前验收阶段没有发现问题），开发反而不一定承担责任（看具体的公司和团队要求）。
- 问题源头承担主责：比如A系统磁盘故障导致接口响应很慢且问题持续很长时间，从而进一步导致B系统对外响应也超时，这种情况下A系统应该承担主责，B系统承担次责。
- 问题放大者承担主责：比如A系统磁盘故障导致接口响应很慢但只持续了几分钟，结果诱发了B系统的设计缺陷，导致B系统瘫痪超过1小时，这种情况下B系统应该承担主责。
第四条线：改进线
为了制定可以落地的改进措施，我们要明确改进线，也就是问题的改进计划，包括具体措施、改进责任人和时间节点等。
（注：在这一讲中，问题责任人是指为问题承担责任的人，改进责任人是指负责落实改进措施的人，不一定是同一个。）
改进计划的思路来源于两个方面：时间线和问题链，通过时间线找到问题处理过程中不合理和可以优化的地方；通过问题链找到具体需要解决的问题。
具体措施可以是流程上的调整（增加或删除流程步骤），技术上的手段（增加功能、优化系统）和团队方面的措施（学习、培训、奖惩机制）等。
无论采取什么措施，都要求能够落地执行。比如“提升团队质量意识”这种比较虚的措施，应该细化为“团队参加公司的质量规范学习和考试”“推行Code Review”这种具体的措施。
接下来，我来带你拆解一个简单的线上问题复盘案例。
案例：线上商城
假设我们做了一个简单的线上商城，架构如下图所示：
某次线上故障导致用户下单后无法支付，我们按照四线复盘法来来复盘这个问题。
1. 时间线
首先，我们完整地回顾问题产生、处理和收尾的整个过程，梳理了时间线：
2. 问题链
我们先按照业务流程来分析问题链，由于系统架构和这次问题都比较简单，所以问题链只涉及风控服务和支付服务：
针对风控服务的问题，我们再按照项目流程来分析问题链：
3. 责任链
根据时间线中的影响结果，这次问题导致的损失是10000元；根据公司故障定级标准，属于轻微级别，惩罚措施是贡献活动经费；结合问题链和定责标准，我们得到了最终的责任链：
4. 改进线
我们分析了时间线中的步骤，针对两个可以改进的地方制定了改进措施：
然后，我们又分析了问题链中的问题，针对另外两个可以改进的地方制定了改进措施：
以上就是用四线复盘法对这次问题做复盘的整个过程。
小结
现在，我们回顾一下重点内容。
- 一次成功的问题复盘需要达成4个目标：讲清楚事实，全面且深入地分析，得出让各方心服口服的定责结论，以及制定可以落地的改进措施。
- 四线复盘法是通过时间线、问题链、责任链和改进线这4条不同的线索来展开复盘。它可以让你不偏不倚、公平公正地组织复盘，也可以让你避免背不必要的黑锅。
- 时间线就是问题发生的经过，问题链就是问题的传导路径，责任链就是问题责任人之间的关系，改进线就是问题的改进计划。
思考题
这就是今天的全部内容，留一道课后思考题给你吧。你或者你的团队承担过线上问题的责任吗？如果有，主要原因是什么？你觉得处理结果是否公平，复盘过程有没有需要改进的地方？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
- cloud 👍（8） 💬（2）
李老师，我有些困惑。我们公司现在很多时候复盘也复盘了，也制定了一些措施，避免后续不再犯此类错误。但是一段时间之后，似乎又回到了老样子，如何让复盘后的措施，在团队中持续有效，这方面您有什么经验么?
2021-08-31 - 王同学 👍（6） 💬（4）
问题源头承担主责，问题放大者承担主责分不清楚。比如上游的数据格式出错，导致下游需要用数据的服务都有问题，那么是上游源头主责，还是下游放大问题者主责。上游定主责没问题，因为产生了错误的数据。下游定主责也可以，因为下游没有兼容缺陷数据。这个时候怎么定责
2021-02-10 - 菜心1986 👍（5） 💬（1）
复盘什么频率做一次？复盘的归因和追责部分要到什么程度？ 这里的追责结果是否代表个人本身有问题？或者本人能力不行？ 多大的问题要追责，比如一周没事是否也要找个问题来汇报？ 追责是否都是底层人人员，领导或者老板会有问题可以复盘么？
2021-02-14 - 🍭 👍（3） 💬（3）
作为研发怎么判断产品提出的需求是否合理呢，可以从哪几部分进行分析？
2021-07-12 - 周平 👍（3） 💬（4）
复盘的目的是找到问题的原因并改进，避免同样的问题反复出现，降低问题的发生的概率和影响。 我觉得，如果定不好责，特别影响复盘的目的，走偏。 想想以前被定过的责，好像是公平的，让人口服的，至少从逻辑上是找不出什么毛病来。 又一想，领导嘛，总能想出一些手段，做到逻辑上走通没毛病，再加上信息不对称，以及作为下属的弱势，总有办法让你说不出什么。 同时，又感到，做的事越多，越容易被人揪住辫子，追责。总的感受，我做了那么多事情，那么努力，结果奖励没见多少，还受罚了。 本文定责的原则，对我很有用，至少能帮我确定一些原则和边界。 同时，应从大利益的维度去考虑事情，不要太计较这些。 我自己还有个问题，心里特别怕出错，好像出了个错，好像天要塌下来一样。 其实，想想看，不需要看的那么重。 看来，定责是领导的一个技能，不是做事儿的人的技能，怎样定责也不在做事儿的人的影响范围内。 事情该做就做，重要的还是自己的成长。 回想了一下自己受过的责，也没几件。 这些受责是否影响了自己的成长和晋升呢？ 我觉得最关键的还是自己的学识，认知。这方面的瓶颈，更大的影响了自己的晋升和成长。
2021-04-11 - qinsi 👍（2） 💬（1）
“问题放大者承担主责”不是很理解。如果A是问题源头，B放大了问题，这时候是源头主责还是放大者主责呢？
2021-02-09 - Geek_14beb8 👍（1） 💬（1）
因为人为事故，我被安排进了优化名单。 起初事故复盘之时，已经定责主责是操作接入层的人员，自身部门的责任是没有做好验证和及时监控处理，由我这边技术组长主导了事故的复盘，事故后期没有再发生，认为此事已处理妥当。 自身没有意识到风险，也没有和领导对这件事做更多反馈。 后来考核评语，只有事故的负面评价，对半年来的工作产出只字不提，认为忙碌的工作都只是战术上的勤奋，战略上的懒惰。另外主导复盘的同事受到年度的优秀员工奖。 因为考核给了非常差的评价，接下来公司又恰好有一轮人员优化，我就这进了名单。 职业生涯一道坎，就这样离开心心念念的中意的公司，非常惋惜。
2023-01-17 - xing.org1^ 👍（1） 💬（3）
案例：临近大促流量高峰时刻，后端修改线上数据配置出错，导致返回给前端的数据缺失一个字段，前端因没做容错导致页面挂掉（js报错后阻塞页面渲染），进而使得线上所有用户打开都是空白页，个别用户反馈问题后研发才发现并修复。 请问老师，上述案例中后端配置错误是主责，前端因为没做容错放大了错误是不是主责呀？如果是的话，二者哪个更重呢？
2022-10-26 - 怀揣梦想的学渣 👍（1） 💬（1）
责任划分的太细致明确，反而导致团队互相甩锅，复盘时候都在急于撇清自己的责任，甚至弱化自己做错事情的程度。如果有连带责任，团队会互相监督，避免让对方的犯错拖累自己，除非集体摆烂。 能用程序标准化管理的事情，就避免人去处理，人总有犯错的时候，再专业的也有犯错的时候。特别是经验老道的人，我所在团队就有一个老员工，凭借丰富的经验，给客户做安全配置，配置结束后，两个三线城市的短信业务全下线了，好在恢复比较快，五分钟就搞定。但是客户已经有感知和吐槽。复盘发现，是配置安全规则的时候人工手写写错了一个子网范围，后来统一要求图形界面勾选，再也没出过故障。
2022-07-07 - 菜心1986 👍（1） 💬（2）
这里的技术负责人都是底层研发吧。管理层，比如经理没有承担责任么？ 另外，团队合作时，比如测试遗漏怎么定？比如需求文档没有明确要求，测试是不是不需要关心了，出了问题也是无责任？ 或者这个因公司而异，都可以？
2021-02-14 - Geek_035c60 👍（0） 💬（1）
关于产品线上验证的情况，是不是不用全部验证所有银行呀？如果每一次上线都需要验证所有银行，是不是可以自动化测试工具验证？如果所有的渠道都需要验证一遍，就相当于线上回归不是简单的回归了，而是全盘重新测试。
2023-11-09 - 一个帅哥 👍（0） 💬（1）
工作已经4年了，还没出过线上事故。归根结底，就是因为自己胆小，总是怕出问题，所以方案梳理，代码改动都会评估影响的范围。 身边的例子：偷偷加代码，不通知qa测试，导致出了问题。
2023-06-21 - 千锤百炼领悟之极限 👍（0） 💬（1）
复盘目标： 1.事实：讲清楚事实 2.分析：全面深入地分析原因 3.定责：得出让各方都心服口服的定责结论 4.改进：制定可落地执行的改进措施 四线复盘法 时间线：问题发生到结束的经过 问题链：问题的传导路线 - 业务流程 web->A服务->B服务->C服务 - 项目流程 开发->测试->产品->运维 责任链：责任人之间关系 - 定责标准： - 违反规章/制度/流程 负主责 例如：系统规定要经过灰度测试才能全量上线，没有经过灰度测试就全量上线导致出问题。 - 重大失误纰漏 负主责 例如：测试漏测试一个重要功能，导致上线后出问题。测试，产品负主责 - 问题源头 负主责 例如：A服务故障导致B，C，D服务故障 - 问题放大者 负主责 例如：A服务故障导致B服务故障，但A服务故障几分钟后修复，B服务却触发了自己的bug导致继续故障2小时，B服务需要负主责 改进线：制定可落地执行的改进措施
2023-03-25 - Jeeffi 👍（0） 💬（1）
场景： 1. 业务线A和业务线B存在公共的底层代码。 2. 业务线A的项目中涉及底层公共逻辑的调整。并同步了业务线B。 3. 业务线A的开发在公共逻辑中引入了bug，但是在业务线A的case中不会出现，只业务线B功能的部分机型上存在功能不work。 两个问题： 1. 像这个case如何定责呢。业务线A觉得自己尽到了同步责任，改动了也回测了自身case. 业务线B觉得是外部改动引入的，且是机型问题，自己回测过只是没有多机型足够覆盖。 2. 一般定责分为产生责任和发现责任等，那么引入bug的开发需要承担产生责任吗。产生责任和发现责任哪个一般是主责。
2023-02-22 - 大魔王汪汪 👍（0） 💬（1）
文中的case从发现到回滚，故障持续了1个多小时，那这个服务的全年可用性就只有4个9了吧
2021-03-01