随着系统架构不断升级，功能持续迭代，系统运行复杂性越来越高，故障的发生不可避免，且发生场景愈发无法预测。从企业角度看，系统故障影响客户体验，降低访问流量，带来交易损失，引发监管问责等；从系统架构角度看，系统故障反映的问题代表系统未来扩展性与局限性；从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）流程：
3）平台：
围绕“监管控析”的运维平台，在故障管理中涉及的平台建设主要有：
3.3.1.5 从数字化角度看故障管理
1、协同网络：在线连接机器、系统、人
故障管理过程是一个多角色，跨团队协同的过程，过程的参与者既包括运维内部组织与员工，也包括运维以外的研发、测试、业务、客服、厂商、监管机构等，以及一切以数字或软件形式存在的机器、系统，将参与者在线化，产生互动连接，将形成一张数字化的协同网络。协同网络将促进员工与组织、员工与客户、人与机器等节点间的互动在线化、透明化，能够有效的加强事前的主动发现问题与解决问题的能力，事中快速响应与快速恢复的能力，事后复盘客观与有效。协同网络将呈现“点线面”的形态，其中，“点”是前提到的各类参与者，“点”与“点”通过协同机制连接成“线”，“线”与“线”互动协作成“面”，“点线面”是一个协同演化，升维变革的过程。
2、数据智能：数据驱动事前、事中、事后效果
数据智能实现故障协同网络的在线化，加强参与节点的有效连接。实现故障过程的数据智能包括：一是推动在线协作的线上化，系统运营数据的在线资产化，监管控数据管理工具的就位；二是对线上化、资产化带来的数据进行变现，为事前评估分析，事中应急发现与执行决策，事后复盘分析提供数据支撑；三是基于数据推进运维智能化，实现对未知故障的发现、定位、处置、恢复的决策支持，并结合自动化实现人机协同的模式，将可量化、可衡量、可程序化的工作由机器辅助人处理。
3、员工赋能：工具与机制赋能
员工是故障协同网络中核心节点，提升故障应急能力，尤其是临场故障决策，关键的是发挥员工能力。运维组织要从监管控析工具与运维机制两点为员工提供一个全数字化的工作环境，激活跨团队应急协同的参与，重塑运维由被动向主动运营转型。建立全数字化的工作环境，需要从从组织架构上进行优化，优化资源配置，强化信息传导机制，促进协同效率；二是利用在线数据构建更加安全、透明的工作环境，形成员工数字镜像，挖掘优秀员工，辅助员工成长，为应急管理的持续优化赋能；三是为员工提供全在线的“监管控析”工作装备。
3.3.1.6 小结
end
注：本文为《数智万物下的运维思考》的第3章第1节，系列的其它内容参见公众号菜单。