3.3.4.1 复盘：向自己学习​

数智万物下，运维组织面临不断变化的内外部环境，不仅要应对每天海量信息轰炸，还需要对信息进行有效思考，沉淀经验转化为能力，推动学习型组织文化。通常来说，学习包括三种：一种是向前人学习，比如看书，吸收前人的归纳总结，获得知识；第二种是周边经验学习，比如向周围的朋友、领先的资讯知识、举一反三经验等学习；第三种是向自己（个人或组织）学习，通过自己的分析、讨论、思考，将自己经验转化为能力或知识。而“向自己学习”，最常见方法就是复盘，即对过去所做事情重新思考、分析，找出影响结果的因素，将好的行为或不足之处进行梳理，形成自己的经验知识，并最终转化为能力。

本节尝试借鉴“复盘”的关键内涵，建立一条围绕“确定故障复盘方式、梳理故障应急时间轴、还原故障处置行动、根因分析及经验沉淀、问题及改进措施跟踪、编写故障报告并发布”六个步骤的故障复盘改进方法。

1、关于复盘

上个月在《3.3.1 构建持续提升的故障管理能力》中，我将故障管理闭环周期分为“故障预防、故障发现、故障响应、故障定位、故障恢复、复盘改进”，其中“复盘改进”是从“总结改进”中改动而来，相比“总结”，“复盘”需要有一定套路和方法，强调客观回顾、持续学习。

我尝试用我个人时间管理例子对比一下总结与复盘的差异。以前我的时间管理相对随意，比如将日常临时性安排登记为任务，不定期反思收获。今年以来，我使用手帐做时间管理，用法如下：每天上班路上登记当天需关注事项，在每天的碎片时间段中将己完成事项标注“done”，下班路上则根据手帐上己完成事项串起一天过程，通过手帐仪式感的例行反思，能持续在每日复盘中收获，比如：

• 哪些待安排事项没安排好：这类事不一定我自己亲自做，但需要自己提前安排任务，作好计划。
• 哪些需要提前沟通的事没有做：这类事只需要提前沟通即可减少后续的被动。
• 哪些工作可以做得更好：针对已经完成的工作。
• 哪些目标没完成：忘了？未就绪？延续到下一天？暂停？
• 与预期不符的事背后合理的理由是什么：工作总会有些不顺，关键要调整心态。

相比而言，以前的不定期反思是“总结”，最近的每日时间管理手帐可以归为“复盘”。前者主要是反思总结，后者则在反思总结基础上增加了一些因素：持续性（每天）、有方法（登记目标事项，标注完成）、我（亲身经历者）、串起过程（回顾过程）、收获（影响目标的分析，收获经验）。

可能通过“复盘”一词原意可以进一步抽象复盘关键要素。复盘来自围棋，指棋手在下完一盘棋后，重新在棋盘把对弈过程摆一遍，看哪里下得好，哪里下得不好，以从全局角度重新分析、研讨棋局过程，了解不足与优点，找到更好的经验方法，从而提升棋力。综上，我们可以将复盘归纳为5个要素：持续性复盘（复盘棋局是常规操作）、参与者真实经历（棋手）、描述完整经历（对弈过程）、分析研讨对错（分析、研讨棋局）、转化为能力（收获经验，提升棋力）。

2、关于故障复盘

通常，一个严重的生产故障是多个层面上的连续性保障均失效的结果，比如：架构的高可用、人员应急处置能力、常规预防准备工作、监控发现能力、自动化工具应急能力等。这与海恩法则的描述统一：

海恩法则强调两点：一是事故的发生是量的积累的结果；二是人自身的素质和责任心。站在运维角度，作为业务连续性最后一道防线，可以从技术手段与管理手段进行可用性能力建设。所以，故障复盘是对事前与事中环节复盘，不仅关注引发故障根源性问题，还需要推动应急协同、工作机制、人员能力、预案管理、潜在风险、监控发现、应急工具、架构高可用、上下游系统风险等全方位的分析。区别于运维组织通常主要围绕“根因分析、编写报告、创建及跟踪问题”3个故障复盘步骤，下面我尝试将上一节总结复盘的“持续性复盘、参与者真实经历、描述完整经历、分析研讨对错、转化为能力”五个要素融入进来，梳理一条围绕“确定故障复盘方式、梳理故障应急时间轴、还原故障处置行动、根因分析及经验沉淀、问题及改进措施跟踪、编写故障报告并发布”六个步骤的故障复盘过程。

在分解上面六个步骤前，可能需要关注下面对故障复盘分解的步骤相对理想化，实际情况下由于组织每天都会有大量故障，要求每个故障都进行详细复盘无法实现，组织应该通过管理机制及工具赋能，摘取部分重点关键内容，减少故障复盘手工操作环节，让大部分故障在当天或24小时内即完成复盘，少数重要故障则细化复盘过程。

2.1 确定故障复盘方式

每个故障都是运维团队学习成长的机会，我们不要浪费任何一个故障，要让故障复盘作为故障管理的必要环节。考虑到故障复盘涉及工作量较多，建议运维组织建立多种复盘模板，针对不同复盘模板与参与人员范围来应对不同类型的故障。在模板中定义好：哪些人参加，输出什么，设计/架构/故障预防/故障处置/故障发现等执行情况，是否需要纳入日、周、月、季例会等。

基于明确的判断条件提前制定故障复盘模板，比如针对故障影响级别高低、重复性故障、权益类交易、安全风险等。建议故障复盘采用线上化的管理工具落地，高级别的故障增加一些线下的辅助手段，比如对于故障影响级别高的故障需要跨团队参与分析，包括产品或需求团队从需求或设计角度评估软件逻辑设计角度评估，开发团队从架构或程序实现角度评估，测试团队对功能性与非功能性测试角度评估，SRE从系统稳定性、应急处置效率、应急协同、监控发现、自动化处置等角度评估，运维工具团队从监控、自动化操作、日志等专项角度进行分析。整个故障分析尽量保持透明、公开，让故障参与各方能够客观的参与进来。

除了根据明确条件判断的故障复盘模板，还有一类故障可能风险级别未达到高级别，但是在某方面己存在较大的风险隐患，比如潜在架构性能及容量问题、针对协同不畅、管理流程、操作不当、人员能力、运维工具应用等问题。这类问题容易漏分析或执行跟踪不到位，建议从组织管理团队或故障流程经理驱动，以线上任务方式，指定具体责任人牵头落实复盘目标。

2.2 梳理故障应急时间轴

第一节中，强调了复盘“参与者真实经历、描述完整经历”两个区别于一般总结的要素，将这两个要素应用于故障复盘，第一步是要建立故障应急时间轴，时间轴需要有故障处置的关键时点。为了标准化、线上化故障处置过程，需要将故障处置关键时点进行抽象。在选择关键时点时，故障应急时间轴可以参考业务连续性领域的：MTBF（无故障时长）、MTTI（平均故障发现时长）、MTTK（故障定位时长）、MTTF（平均故障处理时长）、MTTR(平均故障响应时长)，MTTF(平均故障恢复时长)的思路，从故障发生时间、发现时间、响应时间、尝试处置时间、诊断时间、生效应急处置开始时间、故障恢复时间等梳理应急处置的关键节点。通常，MTTI=发现时间-发生时间；MTTR =响应时间-发现时间；MTTK =定位时间-发现时间；MTTF =恢复时间-定位时间。要达成这个目标，要建立线上化的应急处置协同机制，以便上述时间点能够在事中落地客观数据。理想情况下，这个线上化应急处置协同机制可以在一个应急场景工具实现，或能够将多个应急工具中的关键操作行为数据整合在一起。故障应急时间轴是围绕故障应急关键时间点的过程还原，需要关注：客观、在线、量化，这个过程相对容易抽象，适合运维工具团队落地。

2.3 还原故障处置行动

有了故障应急时间轴，下一步是让参与方参与进来围绕应急时间轴还原具体的处置行动，全面复原故障处置行为。比如：

• 发现方式：谁（机器、IT人员、客服、客户）、什么时候（预防、及时、较大延迟）、什么方式发现（监控、巡检、投诉）等；
• 响应方式：产品/研发/测试/运维/安全响应情况，监控发现后响应效率等；
• 跨团队协同：运维团队内、运维与其他IT条线、IT与业务线、公司与客户之间协同是否顺畅；
• 尝试诊断：故障发生后尝试了哪些诊断动作，是否有效，专家意见是否快速有效；
• 影响分析：盘中影响分析是否到位，是否有足够数据支持盘中快速判断，提否提前准备关键KPI指标分析；
• 危机升级：故障处置过程对于应急处置时间超长，高风险事件的危机升级机制是否到位，现场危机组织是否到位；
• 情况通报：故障处置过程及恢复的信息通报是否及时、准确，话术是否合理；
• 启动预案：预案是否完整，具备可操作性，事中是否启动预案；
• 处置方案：尝试诊断中的生效应急处置，或事中准确判断的处置方案是什么；
• 故障恢复：制定处置方案后，方案的执行过程是否及时，跨团队交付方案是否快速，应急工具是否就绪；

在上述处置过程的还原上，可以考虑关注：能力（专家、预案等）、协同（跨团队）、机制（信息扩散、危机升级等）、工具（监控、日志、链路、数据等）。

2.4 根因分析及经验沉淀

故障复盘是为了将故障处置行动过程进行分析，沉淀经验，转化为团队能力。随着业务的不断演进，系统的数据量不断扩大，技术栈越来越复杂，系统调用链路越来越长，造成信息系统中断的事件的风险场景越来越多，中断事件的频率和种类持续增长，且有相当一部份事件会造成业务中断，可用性问题越来越严峻。在前面《数智万物下，重新思考运维价值》中，用业务连续性事件起因鱼骨图总结了一下影响业务连续性因素：变更问题、维护问题、性能容量问题、操作问题/误操作、容灾/应用架构高可用、应用逻辑缺陷、版本控制、产品或功能设计不足、数据质量、高可用有效性、应急方案、技术保障方案不完善、应急预案缺失、应急演练不到位、问题跟踪不闭环、参数设置问题、配置问题、人员技能不足、流程机制不完善、外部攻击、基础设施异常、数据备份、数据丢失、监控发现及时性、故障处置时效性等，这些因素都可能是引发故障及导致故障影响升级的根因。

在故障复盘中，主要是对故障直接原因进行定位分析，但随着运维复杂性不断提升，只分析直接原因是不够的，运维在应对复杂性能力飞轮中需要更加主动。参考前面提到的海恩法则，故障根因分析需要从技术与管理两个角度进行多维度分析。技术手段主要是分析技术架构的高可用,非功能性需求的实现，运维的可观察性手段是否具备，运维监控工具的故障发现能力是否覆盖，日志等工具对于故障诊断是否有效，运维自动化工具对连续性恢复处置是否就绪等；管理手段则主要从事前预防、事中处置、事后跟踪等多方面分解，比如生产环境管控是否到位，预案是否有效，演练是否到位，对业务、运行的理解能力是否达标，协同是否顺畅等。

2.5 问题及改进措施跟踪

通过故障原因分析得到的多个待改进事项，将纳入到故障改进中，在ITIL中将这个待改进事项定义为问题。针对2.4中提到的问题，通常会给不同的角色分派改进事项，比如：

• for故障处置运维团队：加强人员对业务、运行的理解，提升监控覆盖面，加强应急预案管理，加强运行状态数据分析能力，加强运维工具的使用等；
• for工具团队：加强工具的运营，提升监控覆盖面与准确率能力，提升日志等异常诊断工具能力，提升自动化工具的使用，提升运维数据分析的平台能力；
• for流程经理：完善应急处置过程的协同效率，信息传输及触达效率，完善人员能力、工具平台能力的提升；
• for研发：修复程序设计逻辑缺陷，提升系统健壮性，增加日志完备度与监控埋点需求，加强版本管理优化等；
• for测试：提升非功能性测试、功能性测试覆盖面等；
• for需求/产品：完善业务逻辑设计、功能设计；
• for第三方厂商：完善硬件、软件、线路等方面的健壮性等；

建立上述问题只是开始，下一步是对问题的跟踪，需要有专项跟踪机制，比如专项的问题管理例会，问题催办进展与通报，问题与变更闭环，问题关闭的策略等。由于问题跟踪的复杂性，理想情况下问题管理应该与绩效关联上。结合管理机制，还需要建立数据驱动，绩效支持的协同方式来确保障高优先级的问题得到及时解决。在问题跟踪上，建议采用全线上的闭环，打通各关联方的工作平台，并基于线上化的问题跟踪数据进行自动化的催办。

2.6 编写故障报告并发布

最后每个故障都应该要有一份故障复盘报告。这里提的故障报告不限于一份标题为“XXXXX故障分析报告”的文档，实际上如果将前面几个步骤的数据线上化整合，就开始启动了一份故障分析报告。完整的故障报告包括：故障过程、根因、影响、问题及优化措施、故障定责，以及针对个别突出问题的专项分析。通常，ITSM、故障管理系统，或运维专家知识库可以作为故障报告的管理系统，系统最好能将故障复盘过程的时间轴关键时间点、操作内容、影响范围等数字化，减少复盘的操作性工作，并提供方便的报告检索，能够追踪问题的解决情况。

针对故障级别，报告有大报告与小报告之类区别，报告编写过程中最好能建立信息分享机制，以收集跨团队意见并修订报告，报告完成后最好能公开发布，发布不仅是问题的警戒与改进，还包括处理过程优点的公示。针对不同类型故障有不同的发布方式，比如：风险通报、专项例会、跨团队沟通、外部第三方等。

【小结】

故障复盘改进环节是故障管理闭环周期闭环的收尾阶段，是对事前与事中环节的分析，关注引发故障根源性问题的解决与故障事中处置效能的提升。缺少复盘的故障会重复发生，协同会更加低效，IT人力资源会被故障拖住，影响整个IT价值创造。采用“确定故障复盘方式、梳理故障应急时间轴、还原故障处置行动、根因分析及经验沉淀、问题及改进措施跟踪、编写故障报告并发布”六个步骤，可建立一条从故障中学习的方法。在落实过程中，组织应该通过管理机制及工具赋能，摘取部分重点关键内容，减少故障复盘手工操作环节，让大部分故障在当天或24小时内即完成复盘，少数重要故障则细化复盘过程。