30 | 四线复盘法：怎么避免成为背锅侠？

Feb 8, 2021

30 | 四线复盘法：怎么避免成为背锅侠？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

30 | 四线复盘法：怎么避免成为背锅侠？

2021-02-08 李运华来自北京

《大厂晋升指南》

课程介绍



讲述：安晓辉

时长11:45大小10.77M



你好，我是华仔。
在事后总结阶段，正常情况下我们主要是做收获总结和成果汇报即可，但是如果发生了明显的问题，就需要做问题复盘。
复盘是一个围棋术语，它指的是对局结束后回顾记录，检查招法的优劣和得失关键，并且根据分析提出更好的招法，提升以后的对局能力。后来，这个思路被引入到了管理工作中。
问题复盘技术人员主要参与的是线上问题复盘，比如业务或者系统出现了线上问题，在问题解决之后往往就会组织复盘。
不管团队技术多么厉害，也不管公司多么有钱，都不能完全避免业务或者系统出现问题的可能，比如 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 条不同的线索来展开复盘。它可以让你不偏不倚、公平公正地组织复盘，也可以让你避免背不必要的黑锅。
时间线就是问题发生的经过，问题链就是问题的传导路径，责任链就是问题责任人之间的关系，改进线就是问题的改进计划。
思考题这就是今天的全部内容，留一道课后思考题给你吧。你或者你的团队承担过线上问题的责任吗？如果有，主要原因是什么？你觉得处理结果是否公平，复盘过程有没有需要改进的地方？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 13

提建议

29 | 金字塔汇报法：怎么汇报才能让领导认可你的成果？

31 | 导学：为什么业务和管理是晋升高级别的基石？

 写留言

精选留言(13)

王同学
2021-02-10
问题源头承担主责，问题放大者承担主责分不清楚。比如上游的数据格式出错，导致下游需要用数据的服务都有问题，那么是上游源头主责，还是下游放大问题者主责。上游定主责没问题，因为产生了错误的数据。下游定主责也可以，因为下游没有兼容缺陷数据。这个时候怎么定责
作者回复: 你要看下游有没有放大问题，注意是放大，而不是说出错，因为上游数据格式出错，正常来说下游肯定出错，只要没放大就没问题。
共 4 条评论
5
cloud
2021-08-31
李老师，我有些困惑。我们公司现在很多时候复盘也复盘了，也制定了一些措施，避免后续不再犯此类错误。但是一段时间之后，似乎又回到了老样子，如何让复盘后的措施，在团队中持续有效，这方面您有什么经验么?
作者回复: 要么落实到流程、要么落实到工具和系统，不能依赖人
共 2 条评论
4
菜心1986
2021-02-14
复盘什么频率做一次？复盘的归因和追责部分要到什么程度？这里的追责结果是否代表个人本身有问题？或者本人能力不行？多大的问题要追责，比如一周没事是否也要找个问题来汇报？追责是否都是底层人人员，领导或者老板会有问题可以复盘么？
作者回复: 1. 这里讲的是线上问题复盘，事件触发模式，不需要定期举行。 2. 多大问题要追责，实行什么样的奖惩措施，是公司或者团队要预先制定规则的。 3. 看问题大小来复盘和追责，支付宝5.27全网宕机的事故，总裁都要担责。
4
🍭
2021-07-12
作为研发怎么判断产品提出的需求是否合理呢，可以从哪几部分进行分析？
作者回复: 并没有很好的方法，更多靠个人的积累，如果遇到自以为是的产品或者运营，沟通很麻烦，我在阿里都遇到很多这样的产品，能力一般还很自信，开口闭口乔布斯、苹果之类的
共 3 条评论
2
周平
2021-04-11
复盘的目的是找到问题的原因并改进，避免同样的问题反复出现，降低问题的发生的概率和影响。我觉得，如果定不好责，特别影响复盘的目的，走偏。想想以前被定过的责，好像是公平的，让人口服的，至少从逻辑上是找不出什么毛病来。又一想，领导嘛，总能想出一些手段，做到逻辑上走通没毛病，再加上信息不对称，以及作为下属的弱势，总有办法让你说不出什么。同时，又感到，做的事越多，越容易被人揪住辫子，追责。总的感受，我做了那么多事情，那么努力，结果奖励没见多少，还受罚了。本文定责的原则，对我很有用，至少能帮我确定一些原则和边界。同时，应从大利益的维度去考虑事情，不要太计较这些。我自己还有个问题，心里特别怕出错，好像出了个错，好像天要塌下来一样。其实，想想看，不需要看的那么重。看来，定责是领导的一个技能，不是做事儿的人的技能，怎样定责也不在做事儿的人的影响范围内。事情该做就做，重要的还是自己的成长。回想了一下自己受过的责，也没几件。这些受责是否影响了自己的成长和晋升呢？我觉得最关键的还是自己的学识，认知。这方面的瓶颈，更大的影响了自己的晋升和成长。
展开
作者回复: 被别人定责的时候，明确定责标准再根据标准找事实，基本上能够避免背黑锅。你对定责的理解已经到了新的境界，点赞👍🏻 其实我也出过事单过责，但长期来看，关键还是自己成长，某次担责并不可怕，有时候担责反而让自己理解更深，印象更深
共 3 条评论
2
菜心1986
2021-02-14
这里的技术负责人都是底层研发吧。管理层，比如经理没有承担责任么？另外，团队合作时，比如测试遗漏怎么定？比如需求文档没有明确要求，测试是不是不需要关心了，出了问题也是无责任？或者这个因公司而异，都可以？
作者回复: 1. 团队leader也要承担连带责任 2. 大部分公司以结果导向，即使需求文档没写，如果是正常需求需要考虑的，在设计和测试的时候都要覆盖，需求文档不可能事无巨细全部覆盖到。
共 2 条评论
1
qinsi
2021-02-09
“问题放大者承担主责”不是很理解。如果A是问题源头，B放大了问题，这时候是源头主责还是放大者主责呢？
作者回复: B的主责肯定是跑不掉，至于A是不是主责，要看A造成的问题大小。举个例子，如果A的问题只持续了1分钟就解决了，那不需要承担主责，如果A本身也导致了30分钟的问题，那么也是要承担主责的。
1
Geek_14beb8
2023-01-17 来自广东
因为人为事故，我被安排进了优化名单。起初事故复盘之时，已经定责主责是操作接入层的人员，自身部门的责任是没有做好验证和及时监控处理，由我这边技术组长主导了事故的复盘，事故后期没有再发生，认为此事已处理妥当。自身没有意识到风险，也没有和领导对这件事做更多反馈。后来考核评语，只有事故的负面评价，对半年来的工作产出只字不提，认为忙碌的工作都只是战术上的勤奋，战略上的懒惰。另外主导复盘的同事受到年度的优秀员工奖。因为考核给了非常差的评价，接下来公司又恰好有一轮人员优化，我就这进了名单。职业生涯一道坎，就这样离开心心念念的中意的公司，非常惋惜。
展开
作者回复: 吃一堑长一智，从错误和失败中学习，不要气馁，我曾经也犯过上线就失败的错误。
毛成方
2023-01-08 来自浙江
把问题摆在台面上直面问题讲明白分析明确责任到人奖惩措施落地的改进措施
xing.org1^
2022-10-26 来自广东
案例：临近大促流量高峰时刻，后端修改线上数据配置出错，导致返回给前端的数据缺失一个字段，前端因没做容错导致页面挂掉（js报错后阻塞页面渲染），进而使得线上所有用户打开都是空白页，个别用户反馈问题后研发才发现并修复。请问老师，上述案例中后端配置错误是主责，前端因为没做容错放大了错误是不是主责呀？如果是的话，二者哪个更重呢？
展开
作者回复: 这里主责是前端，因为前端放大了错误的影响；后端配置出错只是导致缺失一个字段，这个字段对业务的影响不至于导致页面挂掉，用户完全无法使用业务；就算后端不配置错误，前端对于后端返回的数据，也应该做基本的容错处理。
共 3 条评论
怀揣梦想的学渣
2022-07-07
责任划分的太细致明确，反而导致团队互相甩锅，复盘时候都在急于撇清自己的责任，甚至弱化自己做错事情的程度。如果有连带责任，团队会互相监督，避免让对方的犯错拖累自己，除非集体摆烂。能用程序标准化管理的事情，就避免人去处理，人总有犯错的时候，再专业的也有犯错的时候。特别是经验老道的人，我所在团队就有一个老员工，凭借丰富的经验，给客户做安全配置，配置结束后，两个三线城市的短信业务全下线了，好在恢复比较快，五分钟就搞定。但是客户已经有感知和吐槽。复盘发现，是配置安全规则的时候人工手写写错了一个子网范围，后来统一要求图形界面勾选，再也没出过故障。
展开
作者回复: 理想情况当然能用系统做到最好，但总的有个建设过程，而且很多线上故障并不是靠开发一个系统就可以避免的。
bin的技术小屋
2021-05-25
背锅侠前来报道
作者回复: 好好学习这一讲，可以避免背黑锅：）
大魔王汪汪
2021-03-01
文中的case从发现到回滚，故障持续了1个多小时，那这个服务的全年可用性就只有4个9了吧
作者回复: 4个9都没有了😂

