故障治理：如何进行故障复盘

故障复盘的重要性无需多说，每一次故障都是宝贵的学习机会，本人接手故障复盘工作已经半年有余，从一开始的手足无措，慢慢变得游刃有余。以下内容为本人从网上查阅学习多个专家经验，并结合工作经历总结而来，仅供参考。图片来源网络

一、故障复盘目的

通过复盘总结教训，找到根因，从根本上进行优化和改进，后期工作中规避问题再发生。
有策略的、系统性的去组织复盘踩过的坑，还原事实，找到薄弱点加以改进。
最终目的是鼓励做事，而不是处罚失败。

二、故障复盘原则

鼓励做事和质量改进， 反对推诿扯皮不作为；鼓励公开透明，反对掩盖问题；鼓励整体的系统思考和团队协同，反对把问题推给个人。
明确宗旨，拒绝甩锅：故障复盘的目的是为了找出问题，明确改进方案避免再次踩坑。要尽量对事不对人，避免形成对某一方的批评会。
心态开放，理性务实:敢于承认自己的问题，接受自己的不足。同时，在尊重他人的前提，每个人都可以就故障过程充分发表观点和看法。
鼓励快速恢复、鼓励通过演练发现更多的线上问题等。

三、故障复盘运作机制

3.1 故障复盘前准备

3.1.1 提交故障报告

故障直接原因方（非最终认定的故障责任方）在故障发生后3个工作日内提交故障报告。如故障原因涉及多个部门，需跨部门共同协助撰写故障报告。

3.1.2 确定复盘owner

每次故障复盘都必须有唯一的复盘owner，故障复盘owner负责主动引导大家，推动复盘进度。复盘owner的主要职责如下：

复盘开始前，由复盘owner根据故障处理报告初稿来推动所有故障干系方完成时间线的梳理，比如某时间点做了哪些操作，产生了什么结果等；搜集故障影响范围，与各个关联方核实影响的数据，包括业务指标、系统指标、其他指标(客诉、舆情影响等)。关键信息通过截图等进行佐证，结合故障处理报告形成故障复盘报告初稿。
复盘会议中，复盘owner要主动引导参会人员，推动复盘进度，避免出现一些无意义的指责、与故障无关的发散讨论等。
复盘会议后，结合故障处理报告形成故障复盘报告定稿，发给所有故障干系人及相关领导。

3.1.3 确定故障干系人

复盘owner确定故障直接原因方、关联(受影响)方等与故障有关的干系人。

3.1.4 组织复盘会议

确定故障复盘时间、形式及地点、参会人员等，并组织召开复盘会议。

时间要求：故障发生后一周内,时间拖到久容易遗忘故障细节
参会人员要求：故障干系人必须全部参与，复盘owner在复盘文档中记录参会人员名单，必要时抽调SRE专家团队，视故障的危害程度来确定是否需要更高层级的管理人员到场

3.2 故障复盘关键流程步骤(包括但不限于)

3.2.1 故障背景概述

故障的背景要解释清楚本次故障的基本情况，即发生了什么故障，影响了什么业务(产品)等。

3.2.2 对齐故障影响范围

讲清楚本次故障的影响范围，包括影响时间段、影响的业务、影响的系统(服务)、订单量、用户量、客诉量，以及有无产生资金损失等等。

3.2.3 故障时间线回放

故障时间线回放是指从故障的最源头开始，从旁观者的角度重新梳理一遍故障的详细过程，包括每个时间点的人员操作、指标变化、监控告警、系统异常、业务实际情况等等。注意对以下几个关键时间点进行识别。

故障发生时间点: 即这个故障实际上是从什么时候开始的。
业务指标变化时间点: 业务指标开始下跌、开始恢复等。
监控告警发出时间点: 即监控是从什么时候发现异常的，告警什么时候发出的。告警的级别、接收人是否响应超时等相关信息都要记录进来。
人员介入响应时间点: 故障对应的系统值班owner是从什么时候开始响应的。
异常定位时间点：即定位到故障的异常点。
关键操作时间点:是否做了一些应急预案，包括重启、恢复、止血、高可用配置等。还需要理清楚每个操作的结果，即每个操作之后，报错面有无缩小、系统资源水位有无变化等。
确认故障恢复时间点: 通过测试验证或者观测业务指标、系统日志等确认系统已经恢复。

根据以上时间点计算出故障平均修复时间(MTTR)，然后逐个沟通讨论如何缩短其中的每一个环节耗时。MTTR详细释义见附录。

3.2.4 深挖根因

在复盘过程中，既要明确诱因，更要深挖根因。可以基于5why分析法深挖根因，多问几个为什么，层层递进。5why分析法释义详见附录。

3.2.5 改进项汇总

提升系统可靠性的两个关键手段：降低故障发生概率（MTBF）和缩短故障持续时间（MTTR）。参考第3步的MTTR分解环节和第4步的故障根因分解环节，推导出我们对于本次故障复盘的改进事项。在梳理改进事项的时候，还要从流程制度、团队组织、系统设计、底层工具平台综合考虑。改进项需遵循SMART原则，SMART原则释义详见附录。此外每条改进项必须有明确的责任人牵头人，确保每一条改进措施有人跟进有人负责。