复盘，原本是围棋中的一个术语。
指下完棋后，重新在棋盘上走一遍，看看棋子下得好的地方和不好之处，哪些地方可以有不同甚至是更好的下棋方法等。这种重复棋局且带有思考的过程，就称为复盘或复局。
这样做的目的不仅可以找出双方攻守的漏洞，还可以让各自加深印象、总结经验、提高棋艺水平。
放在IT人的工作当中，亦是如此。
“在故障中成长，在复盘中强大”，IT人不仅在故障文化中经历一次次的“披荆斩棘”，还得知道在故障发生之后，总结经验，巩固自我，并防范于未然。
一、为什么要进行故障复盘？
1.对工作本身
对于IT工作来说，除了以做到高质、高效、高安全为目标之外，稳定性也十分重要。故障也就是稳定性问题的一大体现。可是光是解决故障还不行，一样的问题很可能会再次发生。
此刻，复盘就显得尤其重要。复盘故障能够帮助深挖问题的根因，找到目前稳定性的薄弱环节，并进行系统化的分析，从而变成未来提升优化动作的抓手。
简单来说，故障复盘的目的就是，发现系统、流程等存在的不足，进而不断完善，并提炼方法和经验，帮助团队共同进步。
2.对整个团队
有句话是这么说的，团队的复盘能力有多强，决定了团队的进步空间有多大。
只有团队反复复盘，才知道哪里做的对，哪里做的不对，哪里是运气，以及哪里是能力；通过复盘也可了解团队成员的强弱项，然后进行合理分工，这样才能突显团队协作的长板效应。
复盘的核心价值就是让犯过的错误不再重犯，不在同一个地方反复跌倒。理解这个道理容易，但是要真正做好这件事也不易。因为复盘和管理、团队、人员、技术和风险等都是息息相关的，是需要一整套体系来支撑的，这就需要我们充分理解其背后的底层逻辑才能把这事做好。
3.对于自我成长
通过故障复盘，IT人本身可以学习如何快速、准确地定位问题，分析问题原因，并制定有效的解决方案，培养出全局和透过现象看本质的思维方式；
同时IT人可清晰了解自己技术水平和可上升的空间，甚至能够突破和提升以往的认知，并制定相应的自我学习计划，进而加强对技术的理解；
此外在故障复盘过程中，IT人需要向非技术人员解释故障的影响、解决方案和教训，这样有助于加强自己团队协作能力和沟通能力。总之，故障复盘可以帮助IT人综合能力快速得到提升，是IT人成长和进步的重要途径之一。
二、故障复盘的流程是怎样的？
1、故障背景概述
故障的背景要解释清楚本次故障复盘的背景，即发生了什么故障，影响了什么业务(产品)。可以用个初步的报告来梳理故障的整体情况（后三项可在复盘中确定）：
a.故障标题：可按照【故障级别+日期+业务描述+故障简介+复盘报告+责任人】的格式，方便信息同步。
例如：【P0故障】20230401-服务器宕机-复盘报告-李某
b.梳理故障时间线：【完善时间线及细节，包括报警、监控、干系人提供的信息】（具体到分钟级）
包括故障发生的日期、简单原因描述、故障发现的时间及过程、报警的时间、故障定位时间和动作、止损时间和动作、恢复的时间等。
故障处理完成后，对时间线总结，看是否符合1-5-10要求（1分钟发现问题、5分钟定位问题、10分钟处理问题）。
c.故障影响：【故障影响统计汇总】（识别故障的直接/间接影响）
一般是收集资金、人员、声誉等方面的影响。也就是说这个故障影响了多少在线用户使用体验，导致了多少资金上面的损失。一般公司会有各种业务指标的大盘，会根据故障发生的这段时间统计出来影响到的流量。
d.故障定级：按照故障影响范围和对业务造成的损失对故障进行定级。
不同公司的故障定级的方法标准有所不同。有的公司是用 P0、P1、P2、P3 这样的分级标准，有的则是按一二三四级去定义级别的，但定级的逻辑一般都是影响越大级别越高。
计算公式（以电商公司为例）：
损单量=故障持续时长*昨日（或上周同期或近七日日均）同时段平均订单，到小时或者分钟级别。
故障级别和损单量的关系与公司业务量级以及对故障的容忍度有关。示例如下，P0为最高级故障。
e.故障定性：根据故障发生的原因进行有效分类。
包含代码质量、测试质量、流程规范、变更操作、容量规划、产品逻辑、硬件设备、预案失效、云厂故障等等。
f.故障发生根本原因
g.改进措施【暴露问题及改进措施】
h.故障定责
2、正式复盘前，确定复盘形式
①会议复盘
如果是故障级别较高且业务比较关注的，可以组织会议复盘，当面沟通效率更高、能快速平息故障，解决问题。
参会人员包括参与故障处理的人、部门负责人、相关知情人等，召开的时间离故障发生时间越近越好。
而在复盘过程中，参与故障的每个人都邀请发言，把不同角色看到的问题都记录下来，提炼出原因、教训和接下来的Action，最后形成会议纪要，邮件发送参会人及其他周边干系人。
②邮件复盘
而对于影响范围相对小，业务关注度低的故障，则可以采用邮件复盘的方式，把复盘过程邮件抄送相关方。比如当事人领导，相关部门负责，及知情人士（产品经理、开发、业务同事等）。
③文档复盘
至于业务影响很小的故障，在团队内做好复盘文档沉淀，作为组织过程资产存档即可。
3、开始复盘的重点内容
①确定故障发生根本原因
具体问题可能只是表面现象，员工更多的是整个体系中的执行者，做得不到位，一定是体系设计上还存在不完善的地方或漏洞。因此深挖根因，才能做到治标又治本。
做到这点，就需要层层递进做故障根因分析，最经典的就是采用5why分析法，也叫“丰田五问法”，“重复问五次为什么，问题的本质和解决办法显而易见”，丰田前副社长大野耐如是说。
案例：丰田汽车公司前副社长大野耐一，如何通过运用5WHY法来找到工厂设备停机的根本原因。有一次，他在生产线上发现机器总是停转，虽然修过多次，但仍不见好转。于是他询问工人机器停机的原因。
对话：
Q1：为什么机器停了？A1：因为机器超载，保险丝烧断了。
Q2：为什么机器会超载？A2：因为轴承的润滑不足。
Q3：为什么轴承会润滑不足？A3：因为润滑泵失灵了。
Q4：为什么润滑泵会失灵？A4：因为它的轮轴耗损了。
Q5：为什么润滑泵的轮轴会耗损？A5：因为杂质跑到里面去了。
经过连续五次不停地问“为什么”，才找到问题的真正原因和解决的方法，“在润滑泵上加装滤网”。如果没有以这种追根究底的精神来发掘问题，很可能只是换根保险丝了事，真正的问题还是没有解决。
，不仅要求你有全面系统的技术背景知识，还要你有努力求知不懈怠的态度，从而发掘问题的深层原因（可能涉及多层面，如技术层面+流程管控层面）。
②提出改进措施
那么我们应该怎么做，才能避免再次出现类似的问题？这里就可以考虑结合SMART原则来设计改进项：
S – Specific，表示改进项必须是具体的可以落地的，回答需要改进、优化的单项、指标是什么。例如“优化系统设计”就是泛泛而谈的，重新设计A系统对B系统的依赖关系，使其能够对异常进行兜底，这种就属于具体的。
M – Measurable，即改进项是可衡量的可评估的，回答指定改验收标准是什么。比如说通过故障演练来检验依赖关系的有效性。
A – Attainable，指的是在当前的技术环境下，这个改进项是可行的可达到的，避免出现一些假大空、无法落地的改进，也不要写未来太远的无法达到的事情。
R – Relevant，即要与其他改进具有一定的相关性。如本次故障中其他改进项需要有关联性，避免出现孤立的改进；
T -Time-bound，就是要有明确的截止期限。写清楚改进项的截止时间，这个时间段建议最长不要超过三个月，避免改进流于形式，在到期之后进行验收。
在SMART的基础上，还可用5W1H原则进行补充：
- 明确相关改进项的负责人。负责人可以有多个，但主要负责人有且只能有一个。即这个人需要对这个改进项的落地全权负责。
- 后续改进项的状态如何？是在准备、在进行中、还是已完成？
除了提出改进项，对改进措施做到闭环管理也很重要，有始有终，方能进步。常用的闭环管理工具有PDCA循环和RACI矩阵等。
拿PDCA循环举例：Plan（计划）-> Do（执行）-> Check（检查）-> Act（处理），对于我们的故障复盘来说，即所有的改进事项都必须经过故障演练，通过实战演练来确保改进计划一定是有效的。
③如何更快地恢复业务？
除此之外，我们还需考虑，如果下次实在还是出现类似问题，如何快速高效的处理故障，可以更快的恢复业务？如何完成1分钟发现问题、5分钟定位问题、10分钟处理问题？
或许可以从以下几个方面思考并做出提升：
a.监控指标和告警机制是否足够完善，让我们能够更快地发现这个问题；
b.管理制度方面，人员值班响应oncall是否及时，关键人员是否就位，关键岗位有无backup机制，系统owner对负责的组件是否足够熟悉；
c.定位效率方面，现有的排查工具是否好用，有无需要优化的地方，故障定位的时间能否再缩短一点，故障的处理原则是以止血恢复优先，当时的故障处理过程中，有无跑偏方向；
d.应急预案方面，是否准备充分，实际情况是否奏效？日常是否检验过应急预案的有效性；
e.技术层面是否有快速恢复的手段？比如限流、降级、隔离、切换等；
f.架构设计方面，架构本身的高可用是否完善，是否具有容灾能力；
g.流程规范方面，现有的制度规范是否完善，有无需要优化的。
④故障定责需要注意什么？
在故障复盘过程中我们不回避故障的定责和惩罚，但需要考虑的问题是我们的目的是什么？我们反对什么？我们提倡什么？
a.首先定责的目的不是为了处罚，扣绩效或者工资，而是更多让发生故障的部门和员工承担改进的责任，通过让责任人受到惩罚，起到高压线效应。
b.定责对应的首先是团队，其次是个人。很多故障只是表象，根因深挖下去，都会有技术管理的因素，虽然引发故障的操作可能是个人，但是更应该从团队的视角去看问题，避免把根因只归结到某个人身上。
b.应当鼓励快速止血和积极参与。对于故障处理过程中，积极参与定位、止血等操作的，给予正面的肯定。
c.第三方默认无责，谁引入了第三方的技术组件，谁就要对其可用性负责。而在使用外部技术组件的之前，就要仔细评估对方的可用性情况，以及兜底方案等等。
d.红线是底线，坚决不能违反。从以往的各个故障中沉淀出的条款，即是我们必须遵守的红线，应当把它当成自己工作中的铁律。
e.对于重复的错误必须严肃对待。要思考为什么以往的改进事项没有落实到位等等。
除了以上这些，我们还可以做的就是把复盘结果公诸于世。把故障报告同步给相关人员，包括公司管委会、风控部门、责任部门，视故障是否涉及机密，扩大范围让其他人引以为戒。
三、故障复盘应该提出怎样的要求？
1、注重复盘过程本身的质量
在故障复盘过程中，所有干系人共同参与，对过程和结果质量负责。为了获得最大化的产出和价值，我们需要建立一套标准化、可量化的复盘有效性保障方法，对复盘过程进行监督、纠正和持续改进。
数据评判指标包括数据准确度、调查轮次、处理时长等多维度数据，通过这些数据对复盘过程的质量进行评定，并且提供优秀的复盘案例，这样团队才会得到成长。
2、不以唯一根因为导向来复盘
在某些情况下，问题可能涉及多个因素，这些因素之间可能存在复杂的相互作用和影响，如果单独关注一个因素作为根因可能会导致忽略其他重要因素，从而无法全面地解决问题。
相反，以系统为导向的复盘方法可以更全面地分析问题，并考虑所有相关因素。这种复盘方法可以帮助团队更好地理解问题，并找到多个解决方案。确保复盘更加全面和有效，并帮助团队更好地应对未来的挑战。
3、不将定责和处罚直接挂钩
对于故障的事后处理，必须正确处理好定责和处罚之间的关系：定责并不等同于处罚。如果混淆了二者，则会导致无尽的推诿和卸责。
其次定责和处罚并非紧密的绑定关系，定责的原则是对事不对人，找出应负责的人，并执行和落实后续的改进措施，以达到改进的目的。
而处罚旨在防止主观意识薄弱导致的低级且重复的错误，从而有效降低再犯的概率，同时增强人的敬畏之心，激发责任心，巩固其基本的职业素养和操守。
4、不将处罚和绩效强绑定
再者，处罚也不该和绩效绑定。如果处罚与绩效有很强的关联，这让员工的注意力从如何改进转移到为什么被处罚，消极情绪和氛围由此产生。团队会陷入质疑和挑战，最终导致不信任，沟通改进措施的效果会大打折扣。
因此，建议采用迂回的方式，取消处罚与绩效的直接关联。对于出现的故障，设立专门的系统进行记录。然后，按照季度或半年度来统计故障，通过综合情况判断。
如果员工整体表现良好甚至出色，说明员工已经改进，或者故障是偶尔失误所致，这种情况下，员工仍然能获得好的绩效。但是，如果频繁失误、频繁出现问题，那么就直接用数据来说话即可。
5、不把故障归因于外部客观原因
每个问题都有主观和客观原因，但我们经常忽略主观原因，把责任推卸给别人，强调客观原因。
在进行故障复盘时，我们需要避免这种区分。当发生故障时，我们不应该将其归因于外部客观原因，而是应该思考我们自己没有做什么，因为这意味着我们需要积极主动地面向失败进行设计。这种认识升级是至关重要的。
6、故障缓解措施不要依赖于管理手段
在技术手段无法满足需求时，我们通常借助管理手段来协助。然而，管理手段只能作为辅助手段，不能成为常态。
需尽快将人为动作转化为技术平台，通过技术和工具来系统性地解决问题。否则，效果难以量化评估，同时还会增加管理成本。
举个典型的用管理手段解决问题的例子：当接口发生变化时，变更方需要通知对应的依赖方。如果未通知，变更方将承担责任；如果已通知，依赖方未及时做出调整，则依赖方承担责任。通知形式以公告和邮件为准。
但是如果是使用技术手段，建立接口设计的契约管理系统，所有的契约变更都由系统来完成通知和同步，这样就不会再有契约信息不同步的问题了。
总结
彼得圣吉曾说，“从本质上看，人类只能通过试错法进行学习”，但是没有思考的重复试错是没有意义的。只有学会从试错的经历中复盘，才能够得到成长，赢得螺旋式的成功。
故障复盘亦是如此，你必须知道自己错在哪里，是什么原因导致错误出现，能采取什么措施改进，只有知道了这些，才能不在同样的地方摔跟头。
