日常运维工作中，处理问题是常态，但对这些问题的研究和复盘，才可能对系统的稳定运行起到积极的保障作用，技术社群的这篇文章《SRE故障复盘：更快的恢复、减少重复故障》给我们讲解了SRE对问题的复盘，学习了解下。
在当前经济的大形式下，企业对承载存量业务的系统稳定性与可靠性要求越来越高。故障复盘是持续提升系统稳定性保障能力的重要抓手，其重要性不言而喻。通过系统性的复盘，从每一次失败中汲取教训，围绕“更快的恢复故障，减少重复故障”两个关键目标，不断优化的稳定性保障的各项工作，提升团队应急作战能力。
一、故障复盘目标
故障复盘时要带着这两个问题：“能否更快”恢复、“避免重复”发生，因此，相应的目标是“加速应急处置速度、避免重复故障”。
1. 加速应急处置速度
在故障复盘过程中，需要分析“发现、响应、定界、止损、根因分析、彻底恢复”等各个环节的耗时与效率，识别是否存在可提升的空间，并提出优化措施。比如，通过提升监控覆盖面与发现效率、告警的快速响应能力、可观测性在问题定界中的作用、预案的有效性与执行效率、自动化操作对恢复速度的促进、系统架构的容错与韧性、跨团队协同的顺畅度、资源调度的及时性，以及人员技能与操作规范等方面。
2. 避免重复故障
通过挖掘故障根因，制定解决问题的方案，以防止重复故障发生。比如，通过分析应用层面的代码缺陷、配置错误，或非技术层面涉及的人为操作失误、管控流程等因素，制定针对性的修复与预防措施。同时，通过鼓励团队其他SRE[1]举一反三，将根因的防范应用于类似场景，提升企业整体系统的健壮性。
另外，在金融企业中，故障复盘还应关注流程管理的定级、定性、通报、舆情等事项。根据故障的影响范围、持续时间及根本原因，合理定责，并调整故障额度与可用性评估标准。通过不断优化管理流程，确保在故障发生时能够迅速定位问题，高效执行预案，同时促进团队间的沟通与协作。
二、复盘措施
在故障复盘的过程中，为了确保能够全面且深入地达成之前提到的“能否更快，避免重复”的目标，SRE需要重视每一次生产故障复盘机会，组织需要建立一个细致且系统化的复盘方法。
1. 制定复盘模板
复盘模板可以理解为一个细致性的Checklist，这些确认项主要围绕上面提到的两个目标，每一项需要明确到参与人员、检测方法、执行情况等要求。组织如果能将模板内容线上化，甚至将确认项上的客观信息数字化，能够提高复盘效率和透明度。当然，对于一些高级别或涉及分歧的故障，还应结合线下辅助手段，组织跨团队联合分析会议等模式。统一的、在线的复盘模板有助于统一各团队对复盘工作的执行力，且有助于更快的将共性的潜在问题或好的经验传递到其他SRE团队。
2. 梳理故障应急时间轴
类似1-5-10的应急SLO是SRE持续提升系统稳定性架构韧性、应急能力的风向标。要落实这个SLO目标，组织需要有一个客户应急过程的时间轴，比如我们常说的MTBF、MTTI、MTTK、MTTF、MTTR等指标，梳理故障应急关键节点（各个时间的信息我在《运维数字化转型》一书中有详细梳理过）。为了有一个客观的应急时间轴，有条件的团队应建立线上化的应急处置协同指挥机制，确保关键时间点的数据记录能够更加准确。客观的数据，有助于在一个平面上看到每一个故障处置各环节的时长在某一个系统、某一个团队、整个团队、某一种类型等故障中的应急情况，激发SRE挖掘应急上的不足。
3. 还原故障处置行动
有了应急时间轴，就可以分析每一个环节涉及的应急处置能力的执行，其反映到以下一些能力：
（1）发现环节：
监控发现：监控能在更短时间内发现系统异常，效果快于其他故障发现手段，从而迅速止损，最大限度减少业务中断与损失。另外，当故障尚处于萌芽阶段，监控能够及时预警，避免问题随时间推移而复杂化，影响范围扩大。很多SRE组织已经将监控发现作为一个OnCall、一线办公、应急指挥等工作机制的关键入口，也是很多工具场景的流量入口。在故障复盘过程中，SRE不仅要看其是否具备故障发现的覆盖面能力，更要考量其发现故障的及时性——能否在第一时间捕捉异常。同时，监控告警的级别设置需合理，既要避免“狼来了”式的误报，也要确保关键时刻的警报能引起足够重视。此外，告警信息的描述应准确无误，清晰传达问题本质，便于OnCall值班人员能够快速识别故障。基于告警的事件分析能力更是不可或缺，它应具备一定的故障定界的能力，帮助团队快速界定故障范围。此外，在监控告警时应掌控业务层面的监控发现能力，比如蚂蚁、阿里提取的资损数据质检等业务异常的发现能力。复盘时还需分析监控平台的功能性与扩展性，确认其是否能够支撑SRE对监控覆盖能力的要求。
风险挖掘：在故障应急的紧迫战场上，时间极为宝贵。SRE不仅要在故障露头时迅速响应，还要具备在潜在风险酝酿之初即能洞察并提前布局的能力。通过深度剖析故障前后运行数据，建立异常指标的波动与日志中潜藏的不寻常模式，力求在故障来临前捕捉预警信号，将故障扼杀于萌芽之中，或减轻其实际发生时的影响。这种“治未病”的理念，要求我们在时间充裕时便做好准备，为应对可能的危机赢得宝贵的时间窗口。在复盘时，需要评估是否可通过分析故障前后的指标与日志等数据提前发现风险，团队是否建立常态化的容量规划与性能优化等措施。同时，需反思并优化风险发现的问题是否得到有效跟进与防范。
常规巡检：巡检是一种以时间切面为视角的系统健康状态检测方法，其核心价值在于全面评估系统在特定时间段内的健康与稳定状况。与监控相比，监控更侧重于实时、连续地捕捉并响应系统状态的变化，而巡检则更像是定期对系统进行的一次深度体检。另外，巡检还能引导SRE更加系统地了解系统的运行规律，识别出那些在日常监控中可能被忽视或难以捕捉的细微变化，从而提前预判并应对潜在的风险。所在，复盘中，可分析系统例行巡检中是否能发现此故障的风险，或能否增加巡检项更早发现异常。
协同反馈：在复杂多变的业务环境中，某些业务逻辑、功能使用、数据正确性、客户体验等方面有可能出现监控或巡检发现不到位的问题。此时，需要建立流畅的跨团队协同反馈机制，复盘时需评估跨团队反馈事件时，反馈渠道与SRE的值班人员之间是否通畅。
（2）响应环节：
异常响应：与故障识别后应急指挥的高度紧张与集中处理相比，异常响应与识别的初始阶段更需引起我们的高度重视。在应对系统或业务异常时（此处的异常指监控、巡检、协同反馈的事项），从异常初现到受理的这段时间，容易出现延误、导致问题扩大的阶段。异常响应的及时性，直接关系到问题能否在萌芽状态被有效遏制，从而避免后续更大规模的故障发生。它要求我们不仅要在监控系统中设置合理的告警阈值，确保异常能够被迅速捕捉，还要在巡检过程中保持高度的警觉性，不放过任何潜在的异常迹象。同时，协同反馈机制的顺畅运行也是至关重要的，它确保了异常信息能够在不同团队间迅速传递，形成合力共同应对。所以，复盘时应纳入异常出现后到告警受理的时长，异常是否涉及升级，出现响应延迟的原因，监控系统存在盲区、巡检流程不够严谨，还是协同反馈机制存在障碍。
故障识别：从异常响应被触发到明确识别为具体故障的时长，直接影响着故障处理的后续步骤与整体效果。快速而准确的故障识别，不仅能够迅速定位问题根源，为后续的修复工作提供明确方向，还能够更快的召集应急指挥调度机制，以确保一旦异常被捕捉，就能迅速触发故障识别流程。所以，在复盘时，需要建立异常响应后到识别为故障的时长，评估数字化的故障识别的指挥、健康检测。另外，故障识别还需要得到跨团队角色的支持 ，复盘分析是否需要提升故障识别的协同能力也必不可少。
影响分析：响应异常并初步判断其影响，是启动故障应急的基础。快速的故障响应，需要SRE具备快速分析故障影响能力，以便在故障初期就能对其影响范围、严重程度有初步预判。快速的影响分析有助于更快决策采用何种应急级别，调配相应资源，确保故障得到及时有效的处理。由于一些异常的故障识别还需要研发、平台、测试等团队协助，建立高效的跨团队协作也是提升故障响应效率的重要因素。另外，随着故障应急的深入，故障的实际影响可能会逐渐显现，甚至超出初步判断的范围。因此，SRE需要保持高度的敏感性和灵活性，根据实际情况动态调整应急级别和应对措施。在复盘过程中，从提升故障应急速度的角度出发，我们应该梳理异常响应到故障识别的时长，识别并消除瓶颈环节，如信息传递不畅、分析工具不足等，以缩短从异常响应到故障识别的时间。另外，还需要分析故障初次识别的准确性，主要影响何时明确，分析是否需要加强SRE人员能力，建立数字化感知指标与状态监测体系，以提升故障影响判断的准确性与速度。
（3）定界与止损：
尝试诊断：故障应急是一个在尝试诊断与止损的过程，有经验的SRE可能第一个尝试诊断即准确，并发起合适的止损策略。同样，也经常会出现多次尝试后才最终止损的情况。尝试诊断不仅考验着应急人员的专业素养和实战经验，也直接关系到后续应急策略的制定与资源的调配。准确的判断能够引导团队采取针对性的应急措施，有效控制故障影响；反之，则可能导致资源浪费、应急效率低下。为了验证判断的可靠性，相关验证步骤应尽可能落地为数字化方式。通过建立故障案例库，借助智能分析工具等手段，将人为判断与数据验证相结合，提升评估分析的准确性。在复盘过程中，应重点关注尝试诊断的实施情况。梳理应急人员尝试了哪些判断、这些判断的准确性如何、以及验证过程是否充分数字化。通过分析这些信息，识别应急过程中的亮点与不足，为优化未来应急流程、提升团队能力提供宝贵经验。同时，应关注是否具备可观测性等工具辅助故障定界，相关工具能力是否有提升空间。
止损措施：在应急响应中，止损措施如配置调整、参数优化、服务重启、流量切换及服务降级等被迅速实施，以遏制故障影响并最小化损失。有效的止损策略能迅速控制事态，避免损失扩大；反之，则可能延误时机，增加恢复难度。复盘时，应评估止损措施的实施情况，包括措施的选择依据、执行效率及实际成效。通过分析止损过程中的亮点与不足，如措施是否及时、针对性强、执行顺畅等，可提炼出优化建议。同时，需考虑是否借助了可观测性工具来辅助决策，以及这些工具在故障定界与止损中的表现与提升空间。另外，还需推动架构韧性与故障自愈的策略，提升止损效率。
应急预案：止损措施包括基于未知场景的临时性决策与基于已知场景的应急预案决策。基于已知场景的应急预案往往更加全面，能够在事前进行预案有效性的验证。另外，采用事前梳理止损方案，有助于推动系统面对异常下的架构韧性建设。SRE团队应持续推动应急预案的覆盖面，以及预案有效性与可操作性。在复盘时，应关注相关止损的应急预案是否完备，是否采用预案达到止损，预案的自动化程度，预案能否实现匹配。
系统架构韧性：我在公众号前面的左移文章里已经多次提到了系统架构韧性，故障复盘时建议将架构韧性作一个闭环管控，评估系统是否具备故障可恢复、性能可扩展涉及的相关止损韧性，或在架构或应用层面配备完善的应急配套的非功能性需求的交付。
（4）指挥调度
应急协同：面对复杂多变的故障，单个SRE的力量已难以满足高效、全面的应急需求。因此，基于应急作战指挥体系，构建一个高效协同的故障应对体系显得尤为重要。一旦故障被识别，应立即触发跨团队协同应急机制，SRE及指挥作战平台应能够快速建立产品、开发、测试、安全、网络、数据库等多团队快速沟通的渠道和流程。通过预设的紧急通讯协议（如即时通讯、报警系统等），确保信息在第一时间准确无误地传递给所有相关方。另外，很多SRE组织设计了应急管理机制，以有序、高效地推进各环节的应急动作，比如：一线值班人员应急止损，收集影响信息；二线支持团队深入分析故障根因；值班经理统筹全局，协调资源，确保信息透明流通；跨团队的专家团队提供技术指导和支持，解决复杂难题。故障复盘时，应评估跨团队沟通机制的有效性、信息流通的顺畅度及团队协作的默契度，涉及的危机管理机制的应急预案的适用性、灵活性及调整能力，指挥作战系统是否需要进一步优化，提升故障扩散、触达、连接的能力。
情况通报：对于已经产生业务影响的故障，应建立实时的情况通报，将必要的信息触达到相应的人员。因此，需复盘故障过程中必要的人员是否通报到位，服务台、值班经理、事件经理、外联岗是否落实相应职能。
危机升级：在应急过程中因应急时间过长，或随着诊断深入等原因，发现故障影响扩大，需要进行危机升级。因此，此类事件需复盘危机升级机制是否落实，故障影响分析是否数字化。
日志审查：某些重要级别的故障，在必要时还可通过查找可能的错误日志或异常行为记录，作为故障发现的辅助证据。
管理流程优化：回顾并优化故障管理流程中的各个环节，如应急响应流程、问题升级机制、跨团队协作流程等，确保流程高效顺畅。是否建立健全的故障预防、预警、响应和恢复机制，如定期演练、应急预案更新、自动化监控与告警等，提高系统的整体稳定性和可靠性。
技能提升：根据复盘结果中暴露出的团队能力短板，制定针对性的培训计划，提升团队成员在监控、告警、可观测性、故障排查等方面的技能水平。
4.问题及改进措施跟踪
根因分析：关于根因与定界已形成了广泛的共识，根因分析是在应急恢复后，其重点聚焦在引发故障的技术或非技术因素，比如技术因素中的代码缺陷、配置错误、容量不足、产品设计缺陷、第三方依赖故障等问题，制定修复计划并验证修复效果。同时，建立代码审查、自动化测试等机制，预防类似问题再次发生。以及，非技术层面中的类似人为操作失误等，加强操作规范培训，明确操作红线，提高团队成员的操作技能和责任心。
举一反三：在组织层面，每一个系统故障的发生都是一次宝贵的学习机会，它不仅影响当前系统，也为其他系统提供了借鉴意义。因此，SRE组织应积极推动团队学习讨论，鼓励团队成员深入分析故障案例，从中提炼出普遍适用的规律和教训。这种学习方式不仅能够提升团队对特定故障的理解和处理能力，更重要的是能够增强整个组织对系统故障的防范意识和应对能力。在实施上，一些SRE组织会选择以某一个重大或典型的系统故障事件为驱动，通过组织专题会议、研讨会或培训活动等形式，集中力量进行深入剖析和讨论。这种方式能够迅速集中团队的注意力，形成对故障问题的共识，并推动相关改进措施的实施。然而，仅仅依靠事件驱动的方式是远远不够的，所以有些SRE组织还需要建立常态化的事件例会机制来推动这一进程，比如每天召开事件整体复盘会、案例分析会等，将故障案例作为例会重要议题。更为关键的是，SRE组织还需要采用闭环思路来构建故障案例学习的完整体系，即不仅要对部分故障案例进行深入剖析和讨论，还要将复盘过程中的经验教训转化为团队知识，并纳入知识库或专家系统中进行管理和维护。数字化手段可以促进团队成员之间的知识共享和协作，再结合大模型、RAG等技术有助于复盘的非结构化数据进行再利用，提升知识管理作用。
问题跟踪：通过根因分析发现且无法立即解决的问题，需要建立闭环的跟踪机制。根据根因分析结果，将待改进事项分配给不同角色，如运维团队、工具团队、流程经理、研发、测试、需求产品等。并采用专项跟踪机制，如问题管理例会、催办进展与通报、问题与变更闭环等，确保改进措施得到有效执行。
5.编写故障报告并发布
数字化报告：利用ITSM、故障管理系统等工具，将复盘过程的时间轴、操作内容、影响范围等数字化，减少操作性工作。
公开发布：完成报告后，通过风险通报、专项例会、跨团队沟通、外部第三方等方式公开发布，促进知识共享与警示教
流程定级与定性：根据故障的影响程度和根本原因，合理定级并定性故障，明确责任归属和奖惩机制。同时，建立故障额度管理制度，控制故障发生频率和严重程度。
通过构建详尽的复盘模板、清晰梳理应急时间轴、准确还原处置行动，打造了一个高效透明、促进团队沟通与协作的复盘机制。体系化的故障复盘机制，能够激发SRE建立持续的学习型文化，汲取每一次应急中的宝贵经验，提升组织的应急响应效率，持续推动组织“加速故障恢复，减少重复故障”。展望未来，SRE还可以积极拥抱LLM与RAG等技术，建立故障复盘的知识管理，为应急管理提供辅助支持作用。
三、附件：故障复盘模板
（一）故障概述
简述故障发生的具体日期、主要应急环节时间，故障影响等概述。
（二）故障现象
1.故障现象
具体描述故障发生时观察到的具体现象，包括但不限于系统异常表现、用户反馈的问题、日志中的错误信息等。
2.影响范围
明确指出故障影响的用户群体、服务范围、业务模块或具体功能点，以及故障对业务连续性、用户体验、经济损失等方面的初步影响，可量化指标更佳（如用户量减少百分比、经济损失金额等）。
（三）应急响应过程复盘
注：以下部分需以时间轴为线索，客观、直接地反映故障应急处理流程与预期服务级别目标（SLO）的匹配情况。
1.发现：
记录故障被首次发现的时间、发现人及发现途径（如监控系统告警、用户反馈等）。
2.响应：
描述接收到故障报告后的初步行动，包括确认故障、通知相关人员等。
3.定界：
阐述如何快速定位故障影响的具体范围，隔离问题区域。
4.止损：
详细说明采取的临时措施以减轻故障影响（如多次止损则列多次），包括但不限于服务降级、流量切换等。
5.根因定位：
记录故障根本原因的定位过程及最终结论。
6.彻底恢复时间：
若故障已完全解决，记录系统恢复正常服务的确切时间。
（四）应急能力提升
关注：如何通过本次故障反思，提升未来应对类似故障的能力。
1.监控覆盖面与告警：
分析现有监控体系的不足，提出增强监控覆盖范围和告警有效性的建议。
2.异常响应效率：
评估响应速度，探讨优化流程、自动化工具使用等以提升效率的方法。
3.可观测性工具及数据标准：
讨论如何提升系统可观测性，包括日志管理、追踪系统、监控数据标准化等。
4.预案有效性：
回顾现有应急预案的执行情况，提出改进预案内容、演练频率等建议。
5.指挥调度有效性：
分析指挥调度过程中的亮点与不足，优化沟通机制、决策流程等。评估团队成员间的协作效率，提出加强跨部门沟通、提升团队凝聚力的措施。
6.系统架构韧性：
探讨如何通过架构设计增强系统容错能力、提升故障恢复速度。
7.人员能力：
分析人员技能短板，规划技术培训、应急演练等提升计划。
（五）根因分析
1.故障根因：
深入剖析导致故障发生的根本原因，包括但不限于代码缺陷、配置错误、外部依赖问题等。
2.历史故障关联：
查找并列出与本次故障类似或相关的历史故障案例，分析共性问题，提出避免重复发生的策略。
（六）故障根因的优化方向与关联问题
1.短期优化：
列出针对本次故障的直接改进措施，如紧急修复、配置调整等。
2.长期规划：
提出系统性的优化方向，如技术升级、架构重构、流程改进等，以预防未来类似故障的发生。
3.关联问题追踪：
对于与本次故障相关的其他潜在问题或风险点，建立跟踪机制，确保问题得到妥善解决。
如果您认为这篇文章有些帮助，还请不吝点下文章末尾的"点赞"
