什么网站专门做自由行的wordpress书画主题

线上故障复盘会是团队总结经验、优化流程的重要环节，开好复盘会需要聚焦问题根源、避免甩锅文化、推动改进落实。复盘不是甩锅大会，是总结大会。

复盘的目的：

• 通过复盘总结教训，找到根因，从根本上进行优化和改进，后期工作中规避问题再发生。

• 有策略的、系统性的去组织复盘踩过的坑，还原事实，找到薄弱点加以改进。

• 最终目的是鼓励做事，而不是处罚失败。

 故障复盘原则：

• 鼓励做事和质量改进，反对推诿扯皮不作为；鼓励公开透明，反对掩盖问题；鼓励整体的系统思考和团队协同，反对把问题推给个人。

• 明确宗旨，拒绝甩锅：故障复盘的目的是为了找出问题，明确改进方案避免再次踩坑。要尽量对事不对人，避免形成对某一方的批评会。

• 心态开放，理性务实:敢于承认自己的问题，接受自己的不足。同时，在尊重他人的前提，每个人都可以就故障过程充分发表观点和看法。

• 鼓励快速恢复、鼓励通过演练发现更多的线上问题等。

以下是高效复盘会的关键步骤和注意事项：

一、会前准备：确保信息充分 明确核心目标

聚焦问题：明确复盘会的核心是解决问题，而非追责。

输出结果：需形成可执行的改进计划（Action Items）。

收集必要信息

时间线整理：按时间轴记录故障发生、响应、修复的全过程（精确到分钟）。

数据支撑：故障影响范围（用户量、业务损失）、日志、监控图表、用户反馈等。

初步分析：技术团队提前排查可能原因（如代码变更、配置错误、依赖服务异常等）。

确定参会人

必须参与：直接处理故障的技术负责人、值班人员、相关业务方。

可选参与：产品、运维、测试、管理层（视故障影响范围而定）。

提前同步材料

会前24小时将时间线、数据、初步分析文档发给参会人，确保信息透明。1

1.1 故障复盘前准备详情

1.1.1 提交故障报告

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

1.1.2 确定复盘owner

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

1.1.3 确定故障干系人

复盘owner确定故障直接原因方、关联(受影响)方等与故障有关的干系人。 3.1.4 组织复盘会议 确定故障复盘时间、形式及地点、参会人员等，并组织召开复盘会议。 •  时间要求：故障发生后一周内,时间拖到久容易遗忘故障细节  •  参会人员要求：故障干系人必须全部参与，复盘owner在复盘文档中记录参会人员名单，必要时抽调SRE专家团队，视故障的危害程度来确定是否需要更高层级的管理人员到场  

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

1.2.1 故障背景概述

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

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

1.2.3 故障时间线回放

故障时间线回放是指从故障的最源头开始，从旁观者的角度重新梳理一遍故障的详细过程，包括每个时间点的人员操作、指标变化、监控告警、系统异常、业务实际情况等等。注意对以下几个关键时间点进行识别。 •  故障发生时间点: 即这个故障实际上是从什么时候开始的。  •  业务指标变化时间点: 业务指标开始下跌、开始恢复等。  •  监控告警发出时间点: 即监控是从什么时候发现异常的，告警什么时候发出的。告警的级别、接收人是否响应超时等相关信息都要记录进来。  •  人员介入响应时间点: 故障对应的系统值班owner是从什么时候开始响应的。  •  异常定位时间点：即定位到故障的异常点。  •  关键操作时间点:是否做了一些应急预案，包括重启、恢复、止血、高可用配置等。还需要理清楚每个操作的结果，即每个操作之后，报错面有无缩小、系统资源水位有无变化等。  •  确认故障恢复时间点: 通过测试验证或者观测业务指标、系统日志等确认系统已经恢复。   根据以上时间点计算出故障平均修复时间(MTTR)，然后逐个沟通讨论如何缩短其中的每一个环节耗时。MTTR详细释义见附录。

1.2.4 深挖根因

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

1.2.5 改进项汇总

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

1.3 故障定级定责

复盘owner组织所有干系人确定故障干系方部门每一方责任占比以及故障级别，明确扣罚明细。定级定责标准参见各自故障考核管理办法。这里注意，故障定级定责标准规则要明确，并能够与各方达成一致，此外，故障定级定责标准要不断回头看，针对有争议的地方不断修缮，这样就会最大程度地减少扯皮推诿的情况出现

1.4 故障复盘结果通告

复盘owner根据复盘会议及故障定责结果、最终的故障原因、改进方案等结论，在原故障报告的基础上，修改完善并形成最终定稿，以邮件的形式发给所有故障干系人及相关领导进行上报和周知，方便干系人及领导查阅整个复盘报告，同时让改进计划中涉及的各方明确知晓后续相关工作。

二、会议进行：聚焦问题与协作

开场明确规则（5-10分钟）

强调会议原则：对事不对人，禁止指责性发言。

明确会议目标：找到根因，制定预防措施。

还原事实（15-20分钟）

按时间线逐条复盘：谁在何时做了什么操作？系统当时表现如何？

使用白板/共享文档记录关键节点（如代码发布、报警触发、沟通延迟）。

根因分析（30-45分钟）

5 Whys追问法：连续追问“为什么”直至找到根本原因。

示例：

为什么服务崩溃？→ 数据库连接池耗尽。

为什么连接池耗尽？→ 未对慢查询做限流。

为什么未做限流？→ 上线前压测遗漏了该场景。

工具辅助：鱼骨图（人、流程、技术、环境四维度分析）。

改进方案讨论（20分钟）

技术层面：代码优化、监控告警增强、容灾方案设计。

流程层面：发布流程卡点、灰度策略、应急预案完善。

协作层面：跨团队沟通机制（如值班响应SOP）。

明确Action Items（10分钟）

每项改进需指定责任人、完成时间、验收标准（如“3天内增加慢查询监控”）。

避免模糊描述（如“优化系统”改为“将API超时阈值从5s调整为2s”）。

三、会后跟进：闭环与迭代

输出复盘文档

包含故障详情、根因、改进项、后续计划，全员共享并归档。

跟踪改进进度

使用项目管理工具（如Jira）跟踪Action Items，定期同步进展。

横向经验共享

将案例写入团队知识库，组织分享会避免重复问题。

模拟演练与测试

对改进措施进行压力测试或故障演练（如Chaos Engineering）。

四、常见避坑指南

避免甩锅：主持人需及时打断情绪化发言，引导聚焦解决方案。

拒绝表面复盘：根因不能停留在“人为疏忽”，需追问流程漏洞。

避免过度复盘：控制会议时间（1-2小时为宜），复杂问题可拆分多次讨论。

警惕“假闭环”：改进项需量化验证（如“监控覆盖率提升至100%”）。

附录：相关名词解释

一、5why分析法：所谓5why分析法，又称“5问法”，也就是对一个问题点连续以5个“为什么”来自问，以追究其根本原因。虽为5个为什么，但使用时不限定只做“5次为什么的探讨”，主要是必须找到根本原因为止

二、MTBF：即平均无故障时间，即平均无故障工作时间，是衡量一个产品（尤其是电器产品）的可靠性指标。单位为“小时”。它反映了产品的时间质量，是体现产品在规定时间内保持功能的一种能力。具体来说，是指相邻两次故障之间的平均工作时间，也称为平均故障间隔。

三、MTTR：即故障的平均修复时间，对MTTR进行拆解，得到如下几个时间段:MTTR = MTTI + MTTK + MTTF + MTTV 1.  Mean Time To Identify (MTTI): 从故障开始到应急响应介入的时间，一般是考察监控告警、人员值班oncall的合理性。  2.  Mean Time To Know (MTTK):从应急响应介入到故障定位的时间，主要考察根因分析、可观测性等工具的能力。  3.  Mean Time To Fix (MTTF): 从故障定位到故障恢复的时间，主要考察应急预案、快恢体系的能力。  4.  Mean Time To Verify (MTTV):从故障恢复之后到确认故障已经解决的时间，一般通过用户反馈、自动化测试等确认恢复。  

四、SMART原则 •  S - 必须是具体的（Specific），改进项必须是可以落地的，不要泛泛而谈。  •  M - 必须是可以衡量的（Measurable），即改进项是可以评估的，比如通过故障演练来检验依赖关系的有效性。  •  A - 必须是可以达到的（Attainable）,在当前的技术环境下，这个改进项是可行的。  •  R - 与其他目标具有一定的相关性(Relevant)，可以理解与本次故障中其他改进项有关联性。  •  T - 必须具有明确的截止期限（Time-bound），要写清楚改进项的截止时间，在到期之后进行验收。