3.3.1 构建持续提升的故障管理能力

3.3.1 构建持续提升的故障管理能力

随着系统架构不断升级，功能持续迭代，系统运行复杂性越来越高，故障的发生不可避免，且发生场景愈发无法预测。从企业角度看，系统故障影响客户体验，降低访问流量，带来交易损失，引发监管问责等；从系统架构角度看，系统故障反映的问题代表系统未来扩展性与局限性；从IT资源角度看，故障（尤其是重复性故障）将占用大量IT人力资源，影响IT价值创造能力；从运维角度看，故障是一个常态化的存在，故障既是业务连续性大敌，也是推动组织架构、人员能力、协同机制、工具平台持续优化的驱动力，对待好故障管理有助于建立学习型的运维组织。本文要解释的故障管理，除了指尽快恢复正常的服务以降低故障影响的相关措施，还尝试探索建立一个闭环的故障管理能力的模式。

3.3.1.1 从几个故障管理领域的词语开始

1、故障

在ITIL中，故障用Incidnet来描述，即事件，ITIL定义为“服务的意外中断或服务质量的降低”。对这个定义的理解，不同组织略有不同，有些组织只针对服务中断的业务可用性故障，有些组织则细化到与正常运行不一致的事件。我认为故障是驱动团队持续优化，跨组织协同效率提升的有力抓手，是培养学习型运维团队的切入点，在资源有条件的情况下细化到异常情况更好。故障管理的关键目标是快速恢复服务或业务，降低故障影响。

除了一般故障，很多企业还会建立突发或重大故障管理，一般是针对数据中心大面积故障，或重要业务、影响客户交易中断等故障，制定更高优先级的应急协同管理，提前制定危机工作小组，确定相关联络人，沟通计划等。相应的，ITIL将上述故障定义为“灾难”：“对组织造成重大损失或重大损失的突发性意外事件”。本文介绍的故障管理包括一般故障与重大故障。

2、问题

很多人把故障与问题混淆，尤其是研发、测试侧的同学。在ITIL中，问题是指造成已知故障的原因或系统潜在风险，问题管理是针对问题解决进行的跟踪管理。问题管理包括问题识别、问题控制、错误控制。问题识别通常来源于生产故障、运行分析、从研发、测试，及外部供应商获知风险信息等。问题控制指问题分析，记录解决方案，问题优先级划分等。错误控制是针对问题的根因的解决，考虑到解决问题的成本，并非所有问题都需要解决，问题的解决需要具体评估，比如有些团队定义超过半年不发生的问题可以考虑关闭。

问题管理故障、风险、变更、知识等管理都有联系，与故障管理的关系十分密切，很多团队的问题主要由故障关联生成。通用的方案是，事件的复盘关联出多个已知或未知问题，问题工单可以作为变更需求来源，在变更流程中可以相应的自动关闭问题，高优先级的问题跟踪纳入到风险管理中。

3、SLA、SLO、SLI

在故障管理讲这三个S，重点是希望区分不同故障的对待方式，《谷歌SRE解密》中对这几个词有一些描述：

“我们需利用一些主观判断结合过去的经验来定义一些SLI,SLO,SLA，事先定义好合适的指标有助于在故障发生时帮助SRE进行更好的决策。”

“要求所有SLO都是100%并不现实，过于强调这个会影响创新和部署速度。”

“公开的SLO有助于管理用户的期望值”。

注：SLA（Service  Level  Agreement ）：服务水平协议，是IT服务提供方和被服务方之间就服务提供中关键的服务目标及双方的责任等有关细节问题而约定的协议；SLO（Service Level Objective）：服务质量目标，服务提供方与服务需求方对服务期望，比如系统可用性是4个9，还是3个9；SLI（Services Level Indicator）：服务质量指标，SLO需要通过一系列SLI技术指标指标细化并量化，比如上面的可用性可能会转化为运行时长，故障时间等，性能的话会转换为响应时长、成功率等。加强运维组织的IT服务管理，可以采用SLA为基础，以SLO为服务质量期望，以SLI为量化指标，来设计自身的服务流程、提供服务形式、绩效评估方法。

4、时效性分析

在故障处置过程中，有一些时长可以重点关注一下，比如：MTBF（无故障时长）、MTTI（平均故障发现时长）、MTTK（故障定位时长）、MTTF（平均故障处理时长）、MTTR(平均故障响应时长)，MTTF(平均故障恢复时长)，通过这些时效性分析有助于将故障处理能力数字化，并有针对性的在各个阶段选择优化方案，以不断降低上述时长，提升业务连续性。

3.3.1.2 故障管理闭环周期

故障管理闭环周期可以分为事前、事中、事后三个闭环节点，以下我梳理了一张故障管理生命周期，其中由于事中属于分秒必争的特点，又将事中划分为“故障发现、故障响应、故障定位、故障恢复”。可能也有同学会多了“影响分析，应急处置”节点，考虑到在故障定位过程中会不断的尝试诊断分析、影响评估，在故障响应过程中也有影响分析，所以这里不单列这两项。

关于故障管理闭环周期的内容后面将分几节单独细化，本章只做简单介绍。

1、事前：防微杜渐与未雨绸缪

随着系统架构不断升级，功能持续迭代，系统运行复杂性越来越高，故障的发生不可避免，且发生场景愈发无法预测。在事前环节，可以考虑围绕“发现潜在问题并修复”、“提升故障处置阶段效率”两个目标。前者可以围绕数据进行架构、容量、性能等评估，利用例行机制跟踪已知问题的解决，利用数据优化监控覆盖面与准确性，利用混沌工程发现复杂性未知问题等。后者可以进行应急自动化工具、运行看板、日志工具等工具建设，优化协同机制的顺畅，提升应急能力等。

2、事中：快速恢复

事中环节重点是在最经济的方式，快速恢复服务可用性/业务连续性。好的事中处理要有一个完备、在线的协同过程，这个协同过程能够赋能给人，更快速的恢复服务。

故障发现：故障发现的重点关注及时性。良好运维组织的故障发现应该大部分来自监控等自动化手段，甚至对一些确定性很强的故障进行自愈行为。采用机器发现故障，有助于在客户无感知的情况下恢复业务，减少对客户体验的影响。站在故障角度看监控，我认为可以分被动与主动两类，被动监控主要针对已知策略的监控，主动监控是利用自动化模拟、数据分析等手段自动化监控，主动监控将是未来运维组织的努力方向。另外，故障发现还可以通过运行分析、巡检、客户反馈等方式发现，随着系统复杂性不断提高，可以判断未来的故障将以我们无法预知的方式出现，更全面的故障发现方式是自动化发现的有力补充，两手都要抓。故障响应：相比故障发现、定位、恢复，故障响应环节对协同的顺畅要求更高，通常可以围绕信息触达的快速、信息透明，值班管理及启动应急的有序，预案准确的完备性，信息通报的合理，以及对故障影响初步判断的准确。其中对故障影响初步判断是一个难点，考验运维人员的故障识别能力，不仅要求有基本的应急技能，还要对系统有深刻的理解。另外，在故障响应过程中，系统故障受理人，关联上下游系统运维人员，值班经理等各个角色的作用都尤其重要，需要不断的练习、实战来提升协同顺畅性。 故障定位：故障定位包括：诊断定位与影响分析，通常是整个故障过程中耗时最长的环节。不使用根因定位，而使用诊断定位，是因为需要强调定位一定要建立在快速恢复的基础上，而非寻找问题根因，后者由问题管理负责。理想情况下，更好的监控应该能够更具体的发现触发故障的问题，但实际上这个过程需要不断的优化，所以很多时候需要运维团队不断的假设与执行。这个环节应用到的工具通常有监控、日志、运行看板、应急操作工具等，工具在这个环节的应用主要是为了提升故障定位的效率，由于运维人员主要依靠专家意见与临时运行状态分析来假设问题，随着系统复杂性不断提升，数字化手段的作用将越来越大，给运维平台建设团队带来的挑战是如何将数字化手段结合专家经验，融入到协同机制中，这考验场景的设计水平。故障恢复：故障恢复环节重点是在定位原因后的执行应急操作，再到故障恢复的过程，由于很多故障是在不断尝试验证解决恢复的动作，所以故障恢复环节与故障定位环节有一定的交叠，或在这两个环节之间不断试错的循环。通常故障恢复中的动作包括我们常说的应急三把斧：“重启、回切、切换”。随着运维由被动向主动转变，运维还要关注架构层面的可靠性、容错性、高可用，推动隔离、限流、降级等配套的非功能能力。

3、事后：不要浪费任务一个故障

事后环节是对事前与事中环节的复盘，关注引发故障根源性问题的解决与故障事中处置效率的提升。缺少事后环节故障会重复发生，协同会更加低效，IT人力资源会被故障拖住，影响整个IT价值创造。事后分析通常可以包括几个通用的步骤：

梳理故障处置过程：这个步骤最好是客观的反映过程，如果整个过程都在线留痕则最佳，通过梳理故障处置过程可以更加客观的观察处置过程存在的问题。要关注在梳理处置过程中如能保持跨团队在线协作更好，能促进过程的透明性。根因分析：找出引发这个故障的根源，除了系统程序或硬件层面的问题，还包括流程、组织层面的问题，另外还要关注并发引出的风险等。处置过程优化：通常包括监控是否及时准确，自动化应急工具是否就绪，日志工具是否就绪，运行数据是否可观察，协同是否顺畅，工作流程是否有效执行，人员技能是否达标，系统是否具备可运维性。建立问题跟踪：系统故障根因要建立问题单进行跟踪，问题单有专项跟踪机制，问题跟踪是一个难点，需要建立数据驱动，绩效支持的协同方式来确保障高优先级的问题得到及时解决。编写故障报告并发布：（上述的步骤也可以由报告驱动）针对故障级别，报告有大报告与小报告，报告编写过程中最好能建立信息分享机制，以收集跨团队意见并修订报告，报告完成后最好能公开发布，发布不仅是问题的警戒，还包括处理过程优点的公示。例会：例会不可或缺，视团队而定建立日、周、月、季例会，复盘重大故障，重复故障，问题解决等。定责：关于定责，很多人说复盘要对事不对人/团队，我个人观点是要视企业文化而定，很多时候这与组织架构相关，透明公开的定责能激发对生产事件的敬畏之心，同时也可以减少关于“背锅”的负面情绪。当然，考虑到定责带来的负面影响，可以减小定责的公布范围。

3.3.1.3 故障管理能力增长飞轮

前面提到了故障管理的前、中、后的闭环，并提出持续优化每个环节的一些优化措施，下一步我们看一下如何推动运维组织自驱动的故障管理能力提升，去有效落实上面的具体举措。我尝试利用飞轮效应思想画一个故障管理的自驱动模型。

我先介绍一下飞轮效应，团队能力提升过程中是一个持续推动的过程，你先利用最大力气推动一个沉重的飞轮，飞轮开始慢慢转动，随着一圈一圈的转动，飞轮获得了动能，速度越来越快，飞轮开始不断循环的往复。在多个飞轮的组合中，根据组织现状你可以选择从大飞轮或小飞轮作为切入点，就像你的自行车上坡时你会选择前面牙盘小一些，在平路竞速时你会选择前面牙盘大一些。在飞轮的组合中，每个飞轮更快的转动都能够带动下一个飞轮更快的转动，同样某个飞轮减速了也会影响下一个飞轮的速度。运维故障管理中也一样可以找到这样一个增长飞轮，比如上图的“提高应急处置效率，提升业务连续性”，运维组织可以有更多时间提升组织能力，来“提升故障管理与应急协同机制的可扩展性”，有了机制则可以推动“运维能力的持续提升”等等。我觉得每个运维组织都可以尝试画一个适合自身组织故障能力提升的飞轮，飞轮的方法可以借鉴吉姆.柯林斯的《飞轮效应》。

3.3.1.4 从适应性系统看故障管理

在第2章中我画了一个运维适应性系统的飞轮闭环：“提出需求，（实现需求）带来改变，（改变）引发风险，（解决风险）需要进行改变，改变好了可以（接受更多需求）”。站在整个运维适应性系统的能力提升中，我们可以看到，运维面临业务迭代需求更多且要求更快，商业模式与新技术创新，海量数据的应用，连接因素更加复杂等因素，驱动IT能力的持续提升，带来新技术与新架构模式的引入，运维在新技术选择时机、技术成熟度、架构及数据高可用的评估能力、对存量技术架构的影响，以及新技术附带的选择成本，种种挑战对运维带来的直接挑战就是故障更多，故障处理时效性要求更高。

为了减少故障，提升故障处理过程中的时效性需求，运维组织在故障管理过程中可以考虑从运维体系的组织、流程、平台三个角度来融入体系适应性系统的建设。

1）组织：

适应性系统面临环境的复杂性，导致故障处理过程经常面临跨团队协作，尤其是重大故障或危机时，大量不同团队的人涌入ECC值班室，线上IM出现各种信息，各种指令涌向应急执行人员，容易带来混乱，继而影响处理处理效率，良好的组织配置及能力要求有助于建立有序的应急处置。

建立故障管理专项或横向岗位：暂且叫这个岗位为故障经理，有些团队的故障经理偏流程，我认为故障经理需要从一线运维出身，这样的人才能更好的指挥危机处理。这个岗位技术、经验方面有突出的要求，考虑到信息太多所以这个人不一定是技术能力最强的，但他需要具备在应急过程中能够起到指挥协调作用的内在思考与外在沟通的个人魅力，注意是在应急混乱过程中的能力。在《架构即未来》对这个角色，有一段描述：“他的三分之一是工程师，三分之一是经理，三分之一是业务经理。虽然很难找到这样一个综合经验、魅力、业务能力的人去履行这个职责，当你找到这个人时，他可能不想要这份工作，因为这是一个无底的压力池。然而，正如一些享受做急诊室医生的快感，一些运维人员享受带领团队渡过危机”。加强技术团队管理岗位的领导作用：一线技术团队的经理要发挥技术、业务、协调资源、应急经验等，起到应急决策的关键作用，传达行动指令，必要时为应急操作执行人员理清思路，减少外部不必要的信息或指令干扰，协调团队其他技术骨干及跨团队协同的支持，向故障经理、部门领导描述进展、发现、决策等。提升运维工程师/系统管理员能力：运维专家的能力水平与以下几点相关，“与特定系统不相关的特定技能”、“与系统相关的掌控程度”、“协同机制与工具的应用程度”，第一、三点是通用能力，第二点是特定的能力。事实上，我觉得在金融行业第二种能力是运维团队要重点扩展的能力，运维的价值一定要围绕在业务上，对业务系统的理解的要求可以视团队的资源情况选择关键点进行切入，详细的观点可以见《以业务为中心重塑运维岗位能力》。促进其它条线团队应急人员协同紧迫性：前面提了多次关于跨条线协同，要在跨条线协同顺畅，关键是让所有运维人员对故障有敬畏心，面对故障能够放下手上所有工作快速进入协查，主动排查自身的可用性，自己是否是根源，或受影响等，并在线反馈信息，接受指令。强化二、三线技术骨干支持协同能力：除了一线应急处置人员，还需要打造二线运维骨干，三线研发、测试、外部厂商的支持协同能力。通常在线、透明的信息传递对协同有帮助。

2）流程：

ECC管理流程：国内金融企业通常都会有一个ECC总控中心（或叫监控管理中心、监控指标中心），是运维团队进行日常运行监控管理、工单处理、应急处置、调度联络、服务台等日常工作的场所。ECC的管理流程主要包括：值班管理流程、ECC工作守则两点，值班管理流程通常又会有一线、二线值班要求，值班经理要求，故障经理要求等职责，ECC工作守则主要是规范在ECC中的行为要求。ECC管理流程的完善是保证应急资源就绪的基础，为运维人员履行应急职责、为监控系统、应急指挥作战等提供可靠的发现环境等提供基础。应急处置协同流程：好的应急处置协同流程应该是围绕事中处置过程的人、系统、机器、事、工具建立一个在线的连接网络。这个网络需要视不同组织的特点，比如《google sre解密》中提到的一些故障跟踪系统可能就不一定完全适合金融企业，因为google的办公是全球办公的协同，涉及时差等特点。好的应急处置协同流程应该是围绕企业应急管理场景，将专家知识、工具、数据、沟通整合在一起。事后复盘机制：复盘是为了从故障中学习，找到组织、流程、运维工具、系统架构的不足，持续改进。复盘机制涉及故障报告、日/周/月/季例会、专题分析会议、信息公布等。其它流程：比如问题跟踪管理流程、整改分析等。

3）平台：

围绕“监管控析”的运维平台，在故障管理中涉及的平台建设主要有：

监控：全面覆盖，主动拨测，及时准确报警，集中式的监控报警，多渠道触达相关人员或自动化操作等是监控平台能力的一些要求。日志：统一的日志平台，方便信息检索、配置监控、历史比对、日志分析是日志平台的要求。自动化操作：主要从效率与安全角度出发，包括：应急操作的自动化，批量操作，操作风险控制，操作留痕等作用。数据观察：运维工作的大部分对象是软件、硬件、系统，本身面对的就是一个数字世界，观察数字世界的运行状态，最好的办法就是为数字世界的组成部分建立数字化的在线观察看板，叫数字孪生也不为过。过程管理：事前、事中、事后涉及过程的管理工具，这块通常需要以实际情况为基础，进行个性化设计，很少有成熟的产品供使用。ITSM：事件管理、问题管理、服务台管理，以及相互之间的联动。

3.3.1.5 从数字化角度看故障管理

1、协同网络：在线连接机器、系统、人

故障管理过程是一个多角色，跨团队协同的过程，过程的参与者既包括运维内部组织与员工，也包括运维以外的研发、测试、业务、客服、厂商、监管机构等，以及一切以数字或软件形式存在的机器、系统，将参与者在线化，产生互动连接，将形成一张数字化的协同网络。协同网络将促进员工与组织、员工与客户、人与机器等节点间的互动在线化、透明化，能够有效的加强事前的主动发现问题与解决问题的能力，事中快速响应与快速恢复的能力，事后复盘客观与有效。协同网络将呈现“点线面”的形态，其中，“点”是前提到的各类参与者，“点”与“点”通过协同机制连接成“线”，“线”与“线”互动协作成“面”，“点线面”是一个协同演化，升维变革的过程。

2、数据智能：数据驱动事前、事中、事后效果

数据智能实现故障协同网络的在线化，加强参与节点的有效连接。实现故障过程的数据智能包括：一是推动在线协作的线上化，系统运营数据的在线资产化，监管控数据管理工具的就位；二是对线上化、资产化带来的数据进行变现，为事前评估分析，事中应急发现与执行决策，事后复盘分析提供数据支撑；三是基于数据推进运维智能化，实现对未知故障的发现、定位、处置、恢复的决策支持，并结合自动化实现人机协同的模式，将可量化、可衡量、可程序化的工作由机器辅助人处理。

3、员工赋能：工具与机制赋能

员工是故障协同网络中核心节点，提升故障应急能力，尤其是临场故障决策，关键的是发挥员工能力。运维组织要从监管控析工具与运维机制两点为员工提供一个全数字化的工作环境，激活跨团队应急协同的参与，重塑运维由被动向主动运营转型。建立全数字化的工作环境，需要从从组织架构上进行优化，优化资源配置，强化信息传导机制，促进协同效率；二是利用在线数据构建更加安全、透明的工作环境，形成员工数字镜像，挖掘优秀员工，辅助员工成长，为应急管理的持续优化赋能；三是为员工提供全在线的“监管控析”工作装备。

3.3.1.6 小结

不要浪费任务一个故障，从运维角度看，故障是一个常态化的存在，故障既是业务连续性大敌，也是推动组织架构、人员能力、协同机制、工具平台持续优化的驱动力，对待好故障管理有助于建立学习型的运维组织。故障管理的关键目标是快速恢复服务或业务，降低故障影响。问题是指造成已知故障的原因或系统潜在风险，问题管理是针对问题解决进行的跟踪管理。在事前环节，可以考虑围绕“发现潜在问题并修复”、“提升故障处置阶段效率”两个目标。事中环节重点是在最经济的方式，快速恢复服务可用性/业务连续性。事后环节是对事前与事中环节的复盘，关注引发故障根源性问题的解决与故障事中处置效率的提升。以故障管理飞轮推动运维组织自驱动的故障管理能力提升，有效落实故障管理的具体举措。将连接、数据、赋能的数字化思维，融入到故障管理。

end