如何做好故障复盘？

本文是年初做去年稳定性复盘和今年稳定性规划产出的一个子方向的内容，围绕于故障复盘标准。

目录

• 复盘的目的是什么？

• 现状与问题

• 如何进行复盘？

• 复盘要求

背景

对于21年下半年故障复盘wiki进行review之后，发现一个问题，就是目前对于故障复盘重视程度还不高，复盘质量还比较差。

所以要求大家做好故障复盘，为将复盘质量提高到及格线，在这篇文章中会提出一些具体的复盘要求。

复盘的目的

故障发生后，需要及时组织复盘。

复盘的目的在于深挖问题根因，找到目前系统中稳定性的薄弱环节（可能来源于业务、系统或者个人），并进行系统化分析，变为未来提升优化动作的抓手。

我们希望通过复盘发现流程、系统架构存在的不足，进而不断完善流程与系统。并提炼出可复制的方法论或经验，帮助其他团队共同进步。

复盘关键词：回顾、反思、探究、提升。

现状与问题

在现有复盘wiki中明显感受到的3个问题：

1. 复盘wiki格式不过关：我们对于复盘wiki的格式是有要求的，在故障复盘的内容做了格式的统一。大家写复盘wiki时一般是复制上一份wiki，所以如果第一篇wiki不规范，会导致后面所有的wiki都不合格。

2. 对于故障根因深挖不够：很多复盘过程中挖掘的问题根因停留在表面，基本只能解决单个故障自身问题，不具有普遍性。可以采用5why分析法，找到那个真正导致这个故障本质的问题。

3. 复盘改进项缺少跟进：每次复盘产出的改进项缺少跟进机制，改进项有没有做？做成什么样？改进之后是否符合预期？是否做过演练？缺少跟进的话，这些问题都很难确认改进效果。

现状关键词：wiki规范不合格；根因深挖不够，问题不够有挑战；改进项缺少跟进机制。

如何进行复盘

复盘可采用5why分析法和PDCA模型。

5why分析法：用于深挖问题根因，透过现象看本质。只有找到问题的本质才可以更好的解决同类问题，进而推进稳定性建设进入新的阶段。

PDCA模型：在于追踪改进项的状态及跟进改进效果。

复盘关键词：不以定责为第一目的，而要识别出流程与系统中潜在的问题和漏洞，并通过后续机制进行保障。

5why分析法

也叫“丰田五问法”，丰田前副社长大野耐一说：“重复问五次为什么，问题的本质和解决办法显而易见”。

一个5why分析法的例子：

背景：

丰田汽车公司前副社长大野耐一，如何通过运用5WHY法来找到工厂设备停机的根本原因。

有一次，他在生产线上发现机器总是停转，虽然修过多次，但仍不见好转。于是他询问工人机器停机的原因。

对话：

★问题一：为什么机器停了？

答案一：因为机器超载，保险丝烧断了。

★问题二：为什么机器会超载？

答案二：因为轴承的润滑不足。

★问题三：为什么轴承会润滑不足？

答案三：因为润滑泵失灵了。

★问题四：为什么润滑泵会失灵？

答案四：因为它的轮轴耗损了。

★问题五：为什么润滑泵的轮轴会耗损？

答案五：因为杂质跑到里面去了。

经过连续五次不停地问“为什么”，才找到问题的真正原因和解决的方法，“在润滑泵上加装滤网”。

如果员工没有以这种追根究底的精神来发掘问题，他们很可能只是换根保险丝草草了事，真正的问题还是没有解决。

在故障复盘时，我们希望通过5why分析法，深挖出本次故障的根因是什么，并修复根因，防止类似问题再次发生。

PDCA模型

通过复盘找到问题根因之后，接下来要做的就是持续改进，可以采用PDCA模型（Plan计划、Do实施、Check检查、Action行动）。

通过PDCA模型可以帮助我们不断识别问题并改进问题，形成良性循环。

写复盘wiki和写技术文档有同样的要求，希望大家重视格式，完善细节。

复盘wiki要求如下：

1. 复盘wiki模板中，要体现故障发生时间线及故障影响，要提供故障期间监控指标变化的截图，帮助大家还原场景，进而提出问题，采用5why分析法不断深挖问题根因，并给出建议。

2. 事故时间线要复原整个故障时间过程，综合多个干系人观察的结论进行完善，而不是只以自己视角去书写。

3. 复盘内容要体现核心指标影响时间、波动范围、故障定级原则及故障级别信息。

4. 在改进措施todo模块中，要体现出后续的改进事项，参照PDCA模型，并给出改进时间及验收方式，只有后续的改进措施落地与完善，本次复盘才算结束。

5. 事故改进项录入事故管理平台，周会维度进行状态跟踪：

复盘要求

为提高复盘质量，特提出如下要求：

1. P4及以上故障复盘时，需要通知所有稳定性接口人，大家都需要参加；

2. 每次复盘人本身及本团队方向所有同学必须参加；

3. 我们要求事故处理做到1-5-10（1分钟发现问题、5分钟定位问题、10分钟处理问题）；

4. 复盘过程中必须回答以下几个问题：

- 是监控报警发现还是业务反馈？（监控报警是否可靠）

- 你的变更动作是什么样？（你的止损动作是否标准）

- 故障发生时有没有收到报警？（报警是我们的天眼，要不断优化）

- 为什么不能1分钟之内发现问题（报警或者监控），如果做到1分钟报警感知还有什么需要完善？

- 为什么不能5分钟内定位问题，还有什么需要细化？

- 为什么不能10分钟止损、恢复，还有什么不到位？

复盘模板（参考）

如下：↓↓↓↓↓↓↓↓

故障标题

【故障标题要可以概况故障原因及影响】【复盘之后补充故障级别，如：xxx-P2】

-------------------------------------------

1. 时间轴 （具体到分钟级）

【完善时间线及细节，包括报警、监控、干系人提供的信息】

-------------------------------------------

<事故日期  2020-06-22>

2020-06-22 16:24 –  2020-06-22 16:35

【事故起因】

【调用链路现在，做简单原因描述，帮助大家快速进入状态，结论先行】

参考：

调用链路：xxx产品服务 → xxx计价服务 → MySQL

什么场景过程中，除了请求xxx估价接口，还会请求xxx计价接口，获取个品类的计价套餐，由于并发量大造成计价服务对MySQL请求拥堵，最终导致此次雪崩发生。

【事故发现/报警】

16:24 xx中心报警“rpc请求失败过多,10s超过5条”

16:24 开始排查

16:26 多个故障群客服反馈业务有影响

【有图更好】

【事故定位/处理】

16:28 定位是mysql报错，定位“The MySQL server is xxx”

【止损】

16:30 操作xxx接口降级开关（降级效果xxx）

16:34 联系dba

【恢复】

16:36 故障恢复

【有图更好】

【事故处理及时性总结】

发现时间：2020-06-22 16:24 → 2020-06-22 16:25 【1 分钟】（发生->发现）

定位时间：2020-06-22 16:25  → 2020-06-22 16:28 【3 分钟】（发现->定位）

止损时间：2020-06-22 16:28 → 2020-06-22 16:30 【3 分钟】（定位->止损）

恢复时间：2020-06-22 16:30 →  2020-06-22 16:36 【6 分钟】（止损->修复）

-------------------------------------------

2. 事故影响

【事故影响统计汇总，故障定级及影响主要体现在这里】

结合业务核心指标受损情况，GMV、单损、舆情定级等

-------------------------------------------

故障时间段内，xxx指标受到影响，业务指标（xx量）下跌：

时间范围：xx:xx-xx:xx

事故时段单量：xxx

事故时段按照环比估计应有单量：yyy

事故时段损失单量：yyy-xxx

事故时段损失单量占同时段预估单量比例：X%

事故时段损失单量占当日总单量比例：X%

-------------------------------------------

3. 事故原因/责任

-------------------------------------------

1、xxx做了什么样的变更，导致了什么样的问题

或者系统存在怎样bug，当单量到达阈值导致性能瓶颈，造成雪崩

-------------------------------------------

4. 事故定级

-------------------------------------------

【不可用时长计算方式】

不可用时长计算方式（从业务受损的时刻开始计算，到业务开始恢复上涨的时刻结束计算）（参照部门定级标准）：

1. P0事故：不变，扣除受影响时段中下跌部分；

2. P1/P2事故：不可用时长 = （事故时段的受影响核心指标量/事故时段应有总核心指标量）* 总受影响时长；

事故定级：P2，消耗不可用时长：xx分钟

5.改进措施【暴露问题及改进措施】

------------------------------------------

希望对你有用。