mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-11-16 06:03:45 +08:00
144 lines
11 KiB
Markdown
144 lines
11 KiB
Markdown
<audio id="audio" title="30 | 四线复盘法：怎么避免成为背锅侠？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/6d/3a/6d24fcbfc6a3d1851cd698bc9606523a.mp3"></audio>
|
||
|
||
你好，我是华仔。
|
||
|
||
在事后总结阶段，正常情况下我们主要是做**收获总结**和**成果汇报**即可，但是如果发生了明显的问题，就需要做**问题复盘**。
|
||
|
||
复盘是一个围棋术语，它指的是对局结束后回顾记录，检查招法的优劣和得失关键，并且根据分析提出更好的招法，提升以后的对局能力。后来，这个思路被引入到了管理工作中。
|
||
|
||
## 问题复盘
|
||
|
||
技术人员主要参与的是线上问题复盘，比如业务或者系统出现了线上问题，在问题解决之后往往就会组织复盘。
|
||
|
||
不管团队技术多么厉害，也不管公司多么有钱，都不能完全避免业务或者系统出现问题的可能，比如2015年5月27日支付宝发生了大规模宕机的事故，2018年10月22日GitHub发生了宕机24小时的事故等。
|
||
|
||
虽然无论做什么都不可能完全杜绝问题的发生，但这并不意味着我们只能坐以待毙。我们需要尽量降低问题发生的概率，减少问题导致的损失，因为就算事故不可避免，1年发生3次和10年发生1次，影响和意义也是完全不同的。
|
||
|
||
问题复盘的意义就在于找到问题的原因然后加以改进，避免同样的问题反复出现，降低问题的发生的概率和影响。
|
||
|
||
## 四线复盘法
|
||
|
||
但是，要做好问题复盘可不是一件容易的事。复盘会议上的各种明争暗斗，可能会让刚参加工作的“萌新”惊掉下巴，甚至让一些老员工也感到头疼。尤其是一些管理比较严的公司还会通过复盘来明确责任分配和处罚措施，复盘会议的激烈程度往往不亚于电视剧中的宫斗场景。
|
||
|
||
所以，怎么组织一场复盘，怎么分配责任和避免背锅，已经成了职场人的一项生存必备技能。
|
||
|
||
问题复盘的内容涵盖**事实、分析、定责和改进**4个部分，一次成功的问题复盘需要达成以下4个目标：
|
||
|
||
1. **讲清楚事实**：事实是复盘的基础，如果连事实都没有讲清楚就开始分析、定责和改进，无异于搭建空中楼阁，做得再漂亮也是没有意义的。
|
||
1. **全面且深入地分析**：首先需要保证没有遗漏问题，其次需要深入分析问题根因，否则以后问题还是会以其他方式反复出现。
|
||
1. **得出<strong><strong>让各方心服口服**</strong>的定责结论</strong>：需要有明确的定责标准，避免拍脑袋定责，或者按照级别和关系来定责。
|
||
1. **制定可以落地的改进措施**：避免提出一些虚头巴脑的措施，看起来高大上，实际上却不知道怎么落地，后续也无法跟踪。
|
||
|
||
这一讲分享的**四线复盘法**，就是通过时间线、问题链、责任链和改进线这4条不同的线索来展开复盘，从而实现事实、分析、定责和改进这4个部分的目标。
|
||
|
||
如果你是复盘负责人，四线复盘法可以让你不偏不倚、公平公正地组织复盘；如果你是复盘参与人，它可以让你避免背不必要的黑锅。当然，如果出现问题确实是你的责任，它也不会教你怎么逃避责任，而是会告诉你怎么思考和改进。
|
||
|
||
接下来，我会针对每条线索逐一讲解说明。
|
||
|
||
## 第一条线：时间线
|
||
|
||
为了讲清楚事实，我们要明确**时间线**，也就是**问题发生的经过**，包括问题发现、问题处理过程中采取的各种关键措施、问题恢复的时间和问题影响的结果等。
|
||
|
||
其中，时间信息非常关键，因为它能够反映出问题发现速度、各项措施执行时间和团队响应效率等指标。比如，运维重启30台机器花了1小时，通常情况下这种处理效率肯定是有问题的。
|
||
|
||
## 第二条线：问题链
|
||
|
||
为了全面且深入的分析，我们要明确**问题链**，也就是**问题的传导路径**。
|
||
|
||
通常情况下，一个问题往往不是单一原因导致的，而是多个原因“碰巧”组合在一起所导致的，所以分析整个问题的传导路径，才能全面地了解产生问题的过程。
|
||
|
||
同时，针对单个问题的分析也不能浅尝辄止，而应该采用第26讲的“5W根因分析法”深入分析，找到根本原因，这样才能为后续制定改进措施提供有效的指导。
|
||
|
||
问题链的路径逻辑有两类：业务流程和项目流程。
|
||
|
||
**业务流程**是指，端到端的业务处理的过程，分析的对象是各个关联的系统。
|
||
|
||
**项目流程**是指，端到端的项目开发的过程，分析的对象是项目各个阶段相关的人员，比如开发、测试、产品和运维等。
|
||
|
||
我们一般先采用业务流程的逻辑将问题定位到单个系统，然后再针对单个系统采用项目流程的方式将问题定位到具体的人或者流程中的某个步骤。
|
||
|
||
## 第三条线：责任链
|
||
|
||
为了得出让各方心服口服的定责结论，我们要明确**责任链**，也就是问题责任人之间的关系。
|
||
|
||
我们需要结合时间线中问题影响的结果、公司的故障定级标准和问题链的分析，最终确定哪些团队或个人应该承担责任，分别承担多大的责任，接受什么样的处罚。
|
||
|
||
之所以叫责任链，是因为一个问题的发生往往是整个流程上多个环节相关的人处理有问题，才会导致最终问题的发生。比如开发人员引入bug，测试人员遗漏了测试，产品人员没有验收到，最终才会在上线后发现问题，这个环节中只要有一个环节把握住了，问题就不会发生。
|
||
|
||
定责是问题复盘中最棘手的部分，因为定责的结果会直接影响团队和个人的绩效，所以做到公平公正、让各方都心服口服是一项很大的挑战。
|
||
|
||
通常情况下，制定明确的定责标准有利于尽量减少争议，常见的标准包括以下4条：
|
||
|
||
1. **违反公司规章/制度/流程的承担主责**：比如公司规定必须要有灰度策略才能升级，某业务版本直接全量升级导致发生问题。
|
||
1. **出现重大纰漏的承担主责**：比如测试时漏测了某个常见的业务场景，导致上线后发生问题，测试承担主责，产品承担主责（因为上线前验收阶段没有发现问题），开发反而不一定承担责任（看具体的公司和团队要求）。
|
||
1. **问题源头承担主责**：比如A系统磁盘故障导致接口响应很慢且问题持续很长时间，从而进一步导致B系统对外响应也超时，这种情况下A系统应该承担主责，B系统承担次责。
|
||
1. **问题放大者承担主责**：比如A系统磁盘故障导致接口响应很慢但只持续了几分钟，结果诱发了B系统的设计缺陷，导致B系统瘫痪超过1小时，这种情况下B系统应该承担主责。
|
||
|
||
## 第四条线：改进线
|
||
|
||
为了制定可以落地的改进措施，我们要明确改进线，也就是问题的改进计划，包括具体措施、改进责任人和时间节点等。
|
||
|
||
（注：在这一讲中，**问题责任人**是指为问题承担责任的人，**改进责任人**是指负责落实改进措施的人，不一定是同一个。）
|
||
|
||
改进计划的思路来源于两个方面：时间线和问题链，通过时间线找到问题处理过程中不合理和可以优化的地方；通过问题链找到具体需要解决的问题。
|
||
|
||
具体措施可以是流程上的调整（增加或删除流程步骤），技术上的手段（增加功能、优化系统）和团队方面的措施（学习、培训、奖惩机制）等。
|
||
|
||
无论采取什么措施，都要求能够落地执行。比如“提升团队质量意识”这种比较虚的措施，应该细化为“团队参加公司的质量规范学习和考试”“推行Code Review”这种具体的措施。
|
||
|
||
接下来，我来带你拆解一个简单的线上问题复盘案例。
|
||
|
||
## 案例：线上商城
|
||
|
||
假设我们做了一个简单的线上商城，架构如下图所示：
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/86/42/864113641db6yy72ccae6b3079ec4142.jpg" alt="">
|
||
|
||
某次线上故障导致用户下单后无法支付，我们按照四线复盘法来来复盘这个问题。
|
||
|
||
### 1. 时间线
|
||
|
||
首先，我们完整地回顾问题产生、处理和收尾的整个过程，梳理了时间线：<br>
|
||
<img src="https://static001.geekbang.org/resource/image/0d/26/0d5f8ccba6582c9b9a7a2d4e15f2ab26.jpg" alt="">
|
||
|
||
### 2. 问题链
|
||
|
||
我们先按照业务流程来分析问题链，由于系统架构和这次问题都比较简单，所以问题链只涉及风控服务和支付服务：
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/03/bc/03bdf8bdaea4aa34c38b6983368631bc.jpg" alt="">
|
||
|
||
针对风控服务的问题，我们再按照项目流程来分析问题链：
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/62/65/620a8fea9d3027730a3yy0898b832f65.jpg" alt="">
|
||
|
||
### 3. 责任链
|
||
|
||
根据时间线中的影响结果，这次问题导致的损失是10000元；根据公司故障定级标准，属于轻微级别，惩罚措施是贡献活动经费；结合问题链和定责标准，我们得到了最终的责任链：
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/13/10/1362eba268e637bfbf95aae0a2103910.jpg" alt="">
|
||
|
||
### 4. 改进线
|
||
|
||
我们分析了时间线中的步骤，针对两个可以改进的地方制定了改进措施：<br>
|
||
<img src="https://static001.geekbang.org/resource/image/83/fe/8396ef8c1ca0d5e4945b268a741e8ffe.jpg" alt=""><br>
|
||
然后，我们又分析了问题链中的问题，针对另外两个可以改进的地方制定了改进措施：<br>
|
||
<img src="https://static001.geekbang.org/resource/image/82/5e/8295af67ba20b2cb2153177efe10e35e.jpg" alt="">
|
||
|
||
以上就是用四线复盘法对这次问题做复盘的整个过程。
|
||
|
||
## 小结
|
||
|
||
现在，我们回顾一下重点内容。
|
||
|
||
1. 一次成功的问题复盘需要达成4个目标：讲清楚事实，全面且深入地分析，得出让各方心服口服的定责结论，以及制定可以落地的改进措施。
|
||
1. 四线复盘法是通过时间线、问题链、责任链和改进线这4条不同的线索来展开复盘。它可以让你不偏不倚、公平公正地组织复盘，也可以让你避免背不必要的黑锅。
|
||
<li>时间线就是问题发生的经过，问题链就是问题的传导路径，责任链就是问题责任人之间的关系，改进线就是问题的改进计划。<br>
|
||
<img src="https://static001.geekbang.org/resource/image/90/de/902c1097fcd425362551584d8f6730de.jpg" alt=""></li>
|
||
|
||
## 思考题
|
||
|
||
这就是今天的全部内容，留一道课后思考题给你吧。你或者你的团队承担过线上问题的责任吗？如果有，主要原因是什么？你觉得处理结果是否公平，复盘过程有没有需要改进的地方？
|
||
|
||
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。<br>
|
||
<img src="https://static001.geekbang.org/resource/image/af/76/af90ee9acaea177d9d3acbc278921876.jpeg" alt="">
|