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

《企业如何构建持续提升的故障管理能力.docx》由会员分享，可在线阅读，更多相关《企业如何构建持续提升的故障管理能力.docx（13页珍藏版）》请在第一文库网上搜索。

1、企业如何构建持续提升的故障管理能力一、从几个故障管理领域的词语开始21、故障22、问题23、SLA、SLO、SLI34、时效性分析3二、故障管理闭环周期41、事前：防微杜渐与未雨绸缪42、事中：快速恢复53、事后:不要浪费任何一个故障6三、故障管理能力增长飞轮7四、从适应性系统看故障管理81、组织92、流程103、平台11五、从数字化角度看故障管理121、协同网络：在线连接机器、系统、人122、数据智能：数据驱动事前、事中、事后效果123、员工赋能：工具与机制赋能12六、小结12随着系统架构不断升级，功能持续迭代，系统运行复杂性越来越高，故障的发生不可避免，且发生场景愈发无法预测。从企业角度看

2、，系统故障影响客户体验，降低访问流量，带来交易损失，引发监管问责等；从系统架构角度看，系统故障反映的问题代表系统未来扩展性与局限性；从IT资源角度看，故障（尤其是重复性故障）将占用大量IT人力资源，影响IT价值创造能力；从运维角度看，故障是一个常态化的存在，故障既是业务连续性大敌，也是推动组织架构、人员能力、协同机制、工具平台持续优化的驱动力，对待好故障管理有助于建立学习型的运维组织。本文要解释的故障管理，除了指尽快恢复正常的服务以降低故障影响的相关措施，还尝试探索建立一个闭环的故障管理能力的模式。一、从几个故障管理领域的词语开始1、故障在ITIL中,故障用Incidnet来描述,即事件，IT

3、IL定义为“服务的意外中断或服务质量的降低”。对这个定义的理解，不同组织略有不同，有些组织只针对服务中断的业务可用性故障，有些组织则细化到与正常运行不一致的事件。我认为故障是驱动团队持续优化，跨组织协同效率提升的有力抓手，是培养学习型运维团队的切入点，在资源有条件的情况下细化到异常情况更好。故障管理的关键目标是快速恢复服务或业务，降低故障影响。除了一般故障，很多企业还会建立突发或重大故障管理，一般是针对数据中心大面积故障，或重要业务、影响客户交易中断等故障，制定更高优先级的应急协同管理，提前制定危机工作小组，确定相关联络人，沟通计划等。相应的，nil将上述故障定义为“灾难”：“对组织造成重大损

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

5、故障管理的关系十分密切，很多团队的问题主要由故障关联生成。通用的方案是，事件的复盘关联出多个已知或未知问题，问题工单可以作为变更需求来源，在变更流程中可以相应的自动关闭问题，高优先级的问题跟踪纳入到风险管理中。3、 SLA、 SLO、 SLI在故障管理讲这三个S,重点是希望区分不同故障的对待方式，谷歌SRE解密中对这几个词有一些描述：“我们需利用一些主观判断结合过去的经验来定义一些SLI,SLO, SLA,事先定义好合适的指标有助于在故障发生时帮助SRE进行更好的决策。” “要求所有SLO都是100%并不现实，过于强调这个会影响创新和部署速度。”“公开的SL0有助于管理用户的期望值”。注：SL

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

7、SLI为量化指标，来设计自身的服务流程、提供服务形式、绩效评估方法。4、时效性分析在故障处置过程中，有一些时长可以重点关注一下，比如：MTBF （无故障时长）、MTTI （平均故障发现时长）、MTTK （故障定位时长）、MTTF （平均故障处理时长）、MTTR（平均故障响应时长），MTTF（平均故障恢复时长），通过这些时效性分析有助于将故障处理能力数字化，并有针对性的在各个阶段选择优化方案，以不断降低上述时长，提升业务连续性。二、故障管理闭环周期故障管理闭环周期可以分为事前、事中、事后三个闭环节点，以下我梳理了一张故障管理生命周期，其中由于事中属于分秒必争的特点，又将事中划分为“故障发现、故障

8、响应、故障定位、故障恢复”。可能也有同学会多了 “影响分析，应急处置”节点，考虑到在故障定位过程中会不断的尝试诊断分析、影响评估，在故障响应过程中也有影响分析，所以这里不单列这两项。故障管理闭环周期野樽评估优化 I61K1A日比分W至优利心善同色菖分折* (方产反停也按分析收拽星立1-1业务反慑 二5?X，折，匕用常德性优化坦多沙W量洞分析 3于分析应急二H优化 AIOps危帆升电 esxAtt中情将如 ECC爸博吁观察工浦-如以发现川富启动现场假设应1Mt案可用性削鹿巡校情况通科弓事发王像庾巡检町1分析-L总行分析测扬及笠熨飞一反三现场保沼。木技器到位情不通愚第口话小出电工第喟况通检 AIO

9、ps物. 及：也门。.与部仁包咖ftt灾代赛费级茹儿皿2回工。需氟清柒生的过卷蝇庠谯因力所（理文化而江）改遇看恒控刎位义港，常可加平改遇协同M陇彳济流用弋H0改送陆籍速标次遇东现风除优化改遇累猊可洋缠性,边淌已fflFKFKH点发布日/印节测会信息共享J5J分析报名关于故障管理闭环周期的内容后面将分几节单独细化，本章只做简单介绍。1、事前：防微杜渐与未雨绸缪随着系统架构不断升级，功能持续迭代，系统运行复杂性越来越高，故障的发生不可避免，且发生场景愈发无法预测。在事前环节，可以考虑围绕“*发现潜在问题并修复”、“提升故障处置阶段效率” *两个目标。前者可以围绕数据进行架构、容量、性能等评估，利用

10、例行机制跟踪已知问题的解决，利用数据优化监控覆盖面与准确性，利用混沌工程发现复杂性未知问题等。后者可以进行应急自动化工具、运行看板、日志工具等工具建设，优化协同机制的顺畅，提升应急能力等。2、事中：快速恢复事中环节重点是在最经济的方式，快速恢复服务可用性/业务连续性。好的事中处理要有一个完备、在线的协同过程，这个协同过程能够赋能给人，更快速的恢复服务。故障发现：故障发现的重点关注及时性。良好运维组织的故障发现应该大部分来自监控等自动化手段，甚至对一些确定性很强的故障进行自愈行为。采用机器发现故障，有助于在客户无感知的情况下恢复业务，减少对客户体验的影响。站在故障角度看监控，我认为可以分被动与主

11、动两类，被动监控主要针对已知策略的监控，主动监控是利用自动化模拟、数据分析等手段自动化监控，主动监控将是未来运维组织的努力方向。另外，故障发现还可以通过运行分析、巡检、客户反馈等方式发现，随着系统复杂性不断提高，可以判断未来的故障将以我们无法预知的方式出现，更全面的故障发现方式是自动化发现的有力补充，两手都要抓。故障响应：相比故障发现、定位、恢复，故障响应环节对协同的顺畅要求更高，通常可以围绕信息触达的快速、信息透明，值班管理及启动应急的有序，预案准确的完备性，信息通报的合理，以及对故障影响初步判断的准确。其中对故障影响初步判断是一个难点，考验运维人员的故障识别能力，不仅要求有基本的应急技能，

12、还要对系统有深刻的理解。另外，在故障响应过程中，系统故障受理人，关联上下游系统运维人员，值班经理等各个角色的作用都尤其重要，需要不断的练习、实战来提升协同顺畅性。故障定位：故障定位包括：诊断定位与影响分析，通常是整个故障过程中耗时最长的环节。不使用根因定位，而使用诊断定位，是因为需要强调定位一定要建立在快速恢复的基础上，而非寻找问题根因，后者由问题管理负责。理想情况下，更好的监控应该能够更具体的发现触发故障的问题，但实际上这个过程需要不断的优化，所以很多时候需要运维团队不断的假设与执行。这个环节应用到的工具通常有监控、日志、运行看板、应急操作工具等，工具在这个环节的应用主要是为了提升故障定位的

13、效率，由于运维人员主要依靠专家意见与临时运行状态分析来假设问题，随着系统复杂性不断提升，数字化手段的作用将越来越大，给运维平台建设团队带来的挑战是如何将数字化手段结合专家经验，融入到协同机制中，这考验场景的设计水平。故障恢复：故障恢复环节重点是在定位原因后的执行应急操作，再到故障恢复的过程,由于很多故障是在不断尝试验证解决恢复的动作，所以故障恢复环节与故障定位环节有一定的交叠，或在这两个环节之间不断试错的循环。通常故障恢复中的动作包括我们常说的应急三把斧：“重启、回切、切换”。随着运维由被动向主动转变，运维还要关注架构层面的可靠性、容错性、高可用，推动隔离、限流、降级等配套的非功能能力。3、事

14、后：不要浪费任何一个故障事后环节是对事前与事中环节的复盘，关注引发故障根源性问题的解决与故障事中处置效率的提升。缺少事后环节故障会重复发生，协同会更加低效，IT人力资源会被故障拖住，影响整个IT价值创造。事后分析通常可以包括几个通用的步骤：梳理故障处置过程：这个步骤最好是客观的反映过程，如果整个过程都在线留痕则最佳，通过梳理故障处置过程可以更加客观的观察处置过程存在的问题。要关注在梳理处置过程中如能保持跨团队在线协作更好，能促进过程的透明性。根因分析：找出引发这个故障的根源，除了系统程序或硬件层面的问题，还包括流程、组织层面的问题，另外还要关注并发引出的风险等。处置过程优化：通常包括监控是否及时准确，自动化应急工具是否就绪，日志工具是否就绪，运行数据是否可观察，协同是否顺畅，工作流程是否有效执行，人员技能是否达标，系统是否具备可运维性。建立问题跟踪：系统故障根因要建立问题单进行跟踪，问题单有专项跟踪机制，问题跟踪是一个难点，需要建立数据驱动，绩效支持的协同方式来确保障高优先级的问题得到及时解决。编写故障报告并发布：（上述的步骤也可以由报告驱动）针对故障级别，报告有大报告与小报告,报告编写过程中最好能建立信息分享机制，以收集跨团队意见并修订报告，报告完成后最