企业运维故障复盘步骤及改进方法

企业运维故障复盘步骤及改进方法

数智万物下，运维组织面临不断变化的内外部环境，不仅要应对每天海量

信息轰炸，还需要对信息进行有效思考，沉淀经验转化为能力，推动学习型组

织文化。通常来说，学习包括三种：一种是向前人学习，比如看书，吸收前人

的归纳总结，获得知识；第二种是周边经验学习，比如向周围的朋友、领先的

资讯知识、举一反三经验等学习；第三种是向自己（个人或组织）学习，通过

自己的分析、讨论、思考，将自己经验转化为能力或知识。而“向自己学

习”，最常见方法就是复盘，即对过去所做事情重新思考、分析，找出影响结

果的因素，将好的行为或不足之处进行梳理，形成自己的经验知识，并最终转

化为能力。

本文尝试借鉴“复盘”的关键内涵，建立一条围绕“确定故障复盘方式、

梳理故障应急时间轴、还原故障处置行动、根因分析及经验沉淀、问题及改进

措施跟踪、编写故障报告并发布“六个步骤的故障复盘改进方法。

1、关于复盘

故障管理闭环周期分为“故障预防、故障发现、故障响应、故障定位、

故障恢复、复盘改进“，其中“复盘改进”是从“总结改进”中改动而来，

相比“总结”，“复盘”需要有一定套路和方法，强调客观回顾、持续学习。

我尝试用我个人时间管理例子对比一下总结与复盘的差异.以前我的

时间管理相对随意，比如将日常临时性安排登记为任务，不定期反思收获。

今年以来，我使用手帐做时间管理，用法如下：每天上班路上登记当天需关

注事项，在每天的碎片时间段中将己完成事项标注“done"，下班路上则根

据手帐上己完成事项串起一天过程，通过手帐仪式感的例行反思，能持续在

每日复盘中收获，比如：

哪些待安排事项没安排好：这类事不一定我自己亲自做，但需要自己提

前安排任务，作好计划。

哪些需要提前沟通的事没有做：这类事只需要提前沟通即可减少后续

的被动。

哪些工作可以做得更好：针对已经完成的工作。

哪些目标没完成：忘了？未就绪？延续到下一天？暂停？

与预期不符的事背后合理的理由是什么：工作总会有些不顺，关键要调

整心态。

相比而言，以前的不定期反思是“总结”，最近的每日时间管理手帐可

以归为“复盘”。前者主要是反思总结，后者则在反思总结基础上增加了一

些因素：持续性（每天）、有方法（登记目标事项，标注完成）、我（亲身

经历者）、串起过程（回顾过程）、收获（影响目标的分析，收获经验）。

可能通过“复盘”一词原意可以进一步抽象复盘关键要素。复盘来自围棋,

指棋手在下完一盘棋后，重新在棋盘把对弈过程摆一遍，看哪里下得好，哪里下

得不好，以从全局角度重新分析、研讨棋局过程，了解不足与优点，找到更好的

经验方法，从而提升棋力。综上，我们可以将复盘归纳为5个要素：持续性复盘

（复盘棋局是常规操作）、参与者真实经历（棋手）、描述完整经历（对弈过程）、

分析研讨对错（分析、研讨棋局）、转化为能力（收获经验，提升棋力）。

2、关于故障复盘

通常，一个严重的生产故障是多个层面上的连续性保障均失效的结果，

比如：架构的高可用、人员应急处置能力、常规预防准备工作、监控发现能

力、自动化工具应急能力等。这与海恩法则的描述统一：

海恩法则：一起重大的飞行安全事故背后都会有29个事故征兆，每个

征兆背后又有300个事故苗头，每个苗头背后还有1000个事故除患。由此

可见，对隐患、苗头、征兆的忽略，是导致意想不到的安全事故发生的罪魁

祸首。

海恩法则强调两点：•是事故的发生是量的积累的结果；二是人自身的

素质和责任心。站在运维角度，作为业务连续性最后一道防线，可以从技术

手段与管理手段进行可用性能力建设。所以，故障复盘是对事前与事中环节

复盘，不仅关注引发故障根源性问题，还需要推动应急协同、工作机制、人

员能力、预案管理、潜在风险、监控发现、应急工具、架构高可用、上下游

系统风险等全方位的分析。区别于运维组织通常主要围绕“根因分析、编写

报告、创建及跟踪问题”3个故障复盘步骤，下面我尝试将上一节总结复盘

的“持续性复盘，参与者真实经历，描述完整经历、分析研讨对错，转化为

能力”五个要素融入进来，梳理一条围绕“确定故障复盘方式、梳理故障应

急时间轴、还原故障处置行动、根因分析及经验沉淀、问题及改进措施跟

踪、编写故障报告并发布“六个步骤的故障复盘过程。

故障复盘过程

确定故障复植理故随应编写故隆报

盘方式急时间轴告并发布

watiarMWM一.产复角■一.1VRV

1.w•i«mc•可用.OW•torSI*.9•・・过・力＞

•工堂•M方式fttt•幽，‘：八

•x«ff*•n㈤队”•ciiHfttt.me.♦•Sr■三方厂・

•w••«9^»Q•lor*■除■*・・・仪化■■

254・•WaftlHtl**MRe«0队•

・■人・•••”),•彭■»场B.£IM•«or工KW•tvauamwt

•山&国■杜・并■•坦•—M*ei・KxBftttKW.M.5

■■•・次・可・uxaumffitt)

・“・修■时问・f;。4"•a・0・•kxVUKLM

•计・方・★•力武

二,ftSU二

2.1W方聋・awwa•弁・履由••■■ft

•0号人员M•MW.

.•风

•MAAft•MTTR

.・▼；«*含

•MTTK

•tA»T0tn二.M34二.Mmaeoc.

•MT7F•H映有•

.折

•MTBF•・力WV.M*•XAss.ee.•*■■三方

HT

•MRfiDUWB.■・・・・HtMi•smn

•fm••4,B•UMaw■

■/月

二.xaa•IAKR.SB.•as：»M.■行

■・BBWVHW.msnit

•■化•3MM

在分解上面六个步骤前，可能需要关注下面对故障复盘分解的步骤相

对理想化，实际情况下由于组织每天都会有大量故障，要求每个故障都进行

详细复盘无法实现，组织应该通过管理机制及工具赋能，摘取部分重点关键

内容，减少故障复盘手工操作环节，让大部分故障在当天或24小时内即完

成复盘，少数重要故障则细化复盘过程。

2.1确定故障复盘方式

每个故障都是运维团队学习成长的机会，我们不要浪费任何一个故障,

要让故障复盘作为故障管理的必要环节。考虑到故障复盘涉及工作量较多,

建议运维组织建立多种复盘模板，针对不同复盘模板与参与人员范围来应

对不同类型的故障。在模板中定义好：哪些人参加，输出什么，设计/架构

/故障预防/故障处置/故障发现等执行情况，是否需要纳入日、周、月、季

例会等。

基于明确的判断条件提前制定故障复盘模板，比如针对故障影响级别

高低、重复性故障、权益类交易、安全风险等。建议故障复盘采用线上化的

2.3还原故障处置行动

有了故障应急时间轴，下一步是让参与方参与进来围绕应急时间轴还

原具体的处置行动，全面复原故障处置行为。比如：

发现方式：谁（机器、IT人员、客服、客户）、什么时候（预防、及

时、较大延迟）、什么方式发现（监控、巡检、投诉）等；

响应方式：产品/研发/测试/运维/安全响应情况，监控发现后响应效率

等；

跨团队协同：运维团队内、运维与其他IT条线、IT与业务线、公司与

客户之间协同是否顺畅；

尝试诊断：故障发生后尝试了哪些诊断动作，是否有效，专家意见是否

快速有效；

影响分析：盘中影响分析是否到位，是否有足够数据支持盘中快速判断,

是否提前准备关键KPI指标分析；

危机升级：故障处置过程对于应急处置时间超长，高风险事件的危机升

级机制是否到位，现场危机组织是否到位；

情况通报：故障处置过程及恢复的信息通报是否及时、准确，话术是否

合理；

启动预案：预案是否完整，具备可操作性，事中是否启动预案；

处置方案：尝试诊断中的生效应急处置.，或事中准确判断的处置方案是

什么；

故障恢复：制定处置方案后，方案的执行过程是否及时，跨团队交付力

案是否快速，应急工具是否就绪；

在上述处置过程的还原上，可以考虑关注：能力（专家、预案等）、协

同（跨团队）、机制（信息扩散、危机升级等）、工具（监控、日志、链路、

数据等）。

2.4根因分析及经验沉淀

故障复盘是为了将故障处置行动过程进行分析，沉淀经验，转化为团队

能力。随着业务的不断演进,系统的数据量不断扩大，技术栈越来越复杂，

系统调用链路越来越长，造成信息系统中断的事件的风险场景越来越多，中

断事件的频率和种类持续增长，且有相当一部份事件会造成业务中断，可用

性问题越来越严峻。在前面《数智万物下，重新思考运维价值》中，用业务

连续性事件起因鱼骨图总结了一下影响业务连续性因素：变更问题、维护问

题、性能容量问题、操作问题/误操作、容灾/应用架构高可用、应用逻辑缺

陷、版本控制、产品或功能设计不足、数据质量、高可用有效性、应急方案、

技术保障方案不完善、应急预案缺失、应急演练不到位、问题跟踪不闭环、

参数设置问题、配置问题、人员技能不足、流程机制不完善、外部攻击、基

础设施异常、数据备份、数据丢失、监控发现及时性、故障处置时效性等，

这些因素都可能是引发故障及导致故障影响升级的根因。

业

务

连

续

性

小

件

设计问题

在故障复盘中，主要是对故障直接原因进行定位分析，但随着运维复杂

性不断提升，只分析直接原因是不够的，运维在应对复杂性能力飞轮中需要

更加主动。参考前面提到的海恩法则，故障根因分析需要从技术与管理两个

角度进行多维度分析。技术手段主要是分析技术架构的高可用，非功能性需

求的实现，运维的可观察性手段是否具备，运维监控工具的故障发现能力是

否覆盖，日志等工具对于故障诊断是否有效，运维自动化工具对连续性恢复

处置是否就绪等；管理手段则主要从事前预防、事中处置、事后跟踪等多方

面分解，比如生产环境管控是否到位，预案是否有效，演练是否到位，对业

务、运行的理解能力是否达标，协同是否顺畅等。

2.5问题及改进措施跟踪

通过故障原因分析得到的多个待改进事项，将纳入到故障改进中，在

ITIL中将这个待改进事项定义为问题。针对2.4中提到的问题，通常会给

不同的角色分派改进事项，比如：

for故障处置运维团队：加强人员对业务、运行的理解，提升监控覆盖

面，加强应急预案管理，加强运行状态数据分析能力，加强运维工具的使用

等；

for工具团队：加强工具的运营，提升监控覆盖面与准确率能力，提升

日志等异常诊断工具能力，提升自动化工具的使用，提升运维数据分析的平

台能力；

for流程经理：完善应急处置过程的协同效率，信息传输及触达效率，

完善人员能力、工具平台能力的提升；

for研发：修复程序设计逻辑缺陷，提升系统健壮性，增加日志完备度

与监控埋点需求，加强版本管理优化等；

for测试：提升非功能性测试、功能性测试覆盖面等；

for需求/产品：完善业务逻辑设计、功能设计；

for第三方厂商：完善硬件、软件、线路等方面的健壮性等；

建立上述问题只是开始，下一步是对问题的跟踪，需要有专项跟踪机制,

比如专项的问题管理例会，问题催办进展与通报，问题与变更闭环，问题关

闭的策略等。由于问题跟踪的复杂性，理想情况下问题管理应该与绩效关联

上。结合管理机制，还需要建立数据驱动，绩效支持的协同方式来确保障高

优先级的问题得到及时解决。在问题跟踪上，建议采用全线上的闭环，打通

各关联方的工作平台，并基于线上化的问题跟踪数据进行自动化的催办。

2.6编写故障报告并发布

最后每个故障都应该要有一份故障复盘报告。这里提的故障报告不限

于一份标题为“XXXXX故障分析报告”的文档，实际上如果将前面几个步骤

的数据线上化整合，就开始启动了一份故障分析报告。完整的故障报告包括:

故障过程、根因、影响、问题及优化措施、故障定责，以及针对个别突出问

题的专项分析。通常，ITSM、故障管理系统，或运维专家知识库可以作为故

障报告的管理系