企业如何建设持续提升的故障管理能力

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

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

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为量化指标，来设计自身的服务流程、提供服务形式、绩效评估方法。