共计 3212 个字符，预计需要花费 9 分钟才能阅读完成。
故障复盘的重要性无需多说，每一次故障都是贵重的学习机会，自己接手故障复盘工作曾经半年无余，从一开始的不知所措，缓缓变得熟能生巧。以下内容为自己从网上查阅学习多个专家教训，并联合工作经验总结而来，仅供参考。
一、故障复盘目标
- 通过复盘总结教训，找到根因，从根本上进行优化和改良，前期工作中躲避问题再产生。
- 有策略的、系统性的去组织复盘踩过的坑，还原事实，找到薄弱点加以改进。
- 最终目标是激励做事，而不是处罚失败。
二、故障复盘准则
- 激励做事和品质改良 ， 拥护推诿扯皮不作为；激励公开通明，拥护覆盖问题；激励整体的零碎思考和团队协同，拥护把问题推给集体。
- 明确主旨，回绝甩锅：故障复盘的目标是为了找出问题，明确改良计划防止再次踩坑。要尽量对事不对人，防止造成对某一方的批评会。
- 心态凋谢，感性求实: 敢于抵赖本人的问题，承受本人的有余。同时，在尊重别人的前提，每个人都能够就故障过程充沛发表观点和认识。
- 激励疾速复原、激励通过演练发现更多的线上问题等。
三、故障复盘运作机制
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 准则释义详见附录。此外每条改良项必须有明确的责任人牵头人，确保每一条改良措施有人跟进有人负责。
3.3 故障定级定责
复盘 owner 组织所有干系人确定故障干系方部门每一方责任占比以及故障级别，明确扣罚明细。定级定责规范参见各自故障考核治理方法。这里留神，故障定级定责规范规定要明确，并可能与各方达成统一，此外，故障定级定责规范要一直回头看，针对有争议的中央一直修理，这样就会最大水平地缩小扯皮推诿的状况呈现
3.4 故障复盘后果通告
复盘 owner 依据复盘会议及故障定责后果、最终的故障起因、改良计划等论断，在原故障报告的根底上，批改欠缺并造成最终定稿，以邮件的模式发给所有故障干系人及相干领导进行上报和周知，不便干系人及领导查阅整个复盘报告，同时让改良打算中波及的各方明确通晓后续相干工作。
四、故障改良及闭环
故障复盘后由复盘 owner(或其余)将故障信息（也就是故障报告里的内容）录入故障管理系统，零碎将向故障改良措施负责人派单，整改负责人整改实现后在零碎回单并提交整改实现的证实资料，由复盘 owner 审核通过前方可敞开工单，这样能够保障整改措施的，实现故障闭环治理
五、处分机制
依据故障复盘过程中各位干系人及 SRE 专家团队体现（是否及时提交故障报告，配合度、是否踊跃改良、踊跃献策等维度逆向评估并给予相应奖惩，目标是激励各位被动复盘被动改良。
附录：相干名词解释
一、5why 分析法：所谓 5why 分析法，又称“5 问法”，也就是对一个问题点间断以 5 个“为什么”来自问，以追究其根本原因。虽为 5 个为什么，但应用时不限定只做“5 次为什么的探讨”，次要是必须找到根本原因为止
二、MTBF：即均匀无故障工夫，即均匀无故障工作工夫，是掂量一个产品（尤其是电器产品）的可靠性指标。单位为“小时”。它反映了产品的工夫品质，是体现产品在规定工夫内放弃性能的一种能力。具体来说，是指相邻两次故障之间的均匀工作工夫，也称为均匀故障距离。
三、MTTR：即故障的均匀修复工夫，对 MTTR 进行拆解，失去如下几个时间段:MTTR = MTTI + MTTK + MTTF + MTTV
- Mean Time To Identify (MTTI): 从故障开始到应急响应染指的工夫，个别是考查监控告警、人员值班 oncall 的合理性。
- Mean Time To Know (MTTK): 从应急响应染指到故障定位的工夫，次要考查根因剖析、可观测性等工具的能力。
- Mean Time To Fix (MTTF): 从故障定位到故障复原的工夫，次要考查应急预案、快恢体系的能力。
- Mean Time To Verify (MTTV): 从故障复原之后到确认故障曾经解决的工夫，个别通过用户反馈、自动化测试等确认复原。
四、SMART 准则
- S – 必须是具体的（Specific），改良项必须是能够落地的，不要泛泛而谈。
- M – 必须是能够掂量的（Measurable），即改良项是能够评估的，比方通过故障演练来测验依赖关系的有效性。
- A – 必须是能够达到的（Attainable）, 在以后的技术环境下，这个改良项是可行的。
- R – 与其余指标具备肯定的相关性(Relevant)，能够了解与本次故障中其余改良项有关联性。
- T – 必须具备明确的截止期限（Time-bound），要写分明改良项的截止工夫，在到期之后进行验收。
本文由 mdnice 多平台公布
