企业运维故障复盘步骤及改进方法

彭华盛
站在运维角度,作为业务连续性最后一道防线,可以从技术手段与管理手段进行可用性能力建设。所以,故障复盘是对事前与事中环节复盘,不仅关注引发故障根源性问题,还需要推动应急协同、工作机制、人员能力、预案管理、潜在风险、监控发现、应急工具、架构高可用、上下游系统风险等全方位的分析。

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

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

1、关于复盘

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

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

哪些待安排事项没安排好:这类事不一定我自己亲自做,但需要自己提前安排任务,作好计划。

哪些需要提前沟通的事没有做:这类事只需要提前沟通即可减少后续的被动。

哪些工作可以做得更好:针对已经完成的工作。

哪些目标没完成:忘了?未就绪?延续到下一天?暂停?

与预期不符的事背后合理的理由是什么:工作总会有些不顺,关键要调整心态。

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

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

2、关于故障复盘

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

海恩法则:一起重大的飞行安全事故背后都会有29个事故征兆,每个征兆背后又有300个事故苗头,每个苗头背后还有1000个事故隐患。由此可见,对隐患、苗头、征兆的忽略,是导致意想不到的安全事故发生的罪魁祸首。(《百度百科》)

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

360截图16440809323970.png

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

2.1确定故障复盘方式

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

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

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

2.2梳理故障应急时间轴

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

2.3还原故障处置行动

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

发现方式:谁(机器、IT人员、客服、客户)、什么时候(预防、及时、较大延迟)、什么方式发现(监控、巡检、投诉)等;

响应方式:产品/研发/测试/运维/安全响应情况,监控发现后响应效率等;

跨团队协同:运维团队内、运维与其他IT条线、IT与业务线、公司与客户之间协同是否顺畅;

尝试诊断:故障发生后尝试了哪些诊断动作,是否有效,专家意见是否快速有效;

影响分析:盘中影响分析是否到位,是否有足够数据支持盘中快速判断,提否提前准备关键KPI指标分析;

危机升级:故障处置过程对于应急处置时间超长,高风险事件的危机升级机制是否到位,现场危机组织是否到位;

情况通报:故障处置过程及恢复的信息通报是否及时、准确,话术是否合理;

启动预案:预案是否完整,具备可操作性,事中是否启动预案;

处置方案:尝试诊断中的生效应急处置,或事中准确判断的处置方案是什么;

故障恢复:制定处置方案后,方案的执行过程是否及时,跨团队交付方案是否快速,应急工具是否就绪;

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

2.4根因分析及经验沉淀

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

360截图16440809323970.png

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

2.5问题及改进措施跟踪

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

for故障处置运维团队:加强人员对业务、运行的理解,提升监控覆盖面,加强应急预案管理,加强运行状态数据分析能力,加强运维工具的使用等;

for工具团队:加强工具的运营,提升监控覆盖面与准确率能力,提升日志等异常诊断工具能力,提升自动化工具的使用,提升运维数据分析的平台能力;

for流程经理:完善应急处置过程的协同效率,信息传输及触达效率,完善人员能力、工具平台能力的提升;

for研发:修复程序设计逻辑缺陷,提升系统健壮性,增加日志完备度与监控埋点需求,加强版本管理优化等;

for测试:提升非功能性测试、功能性测试覆盖面等;

for需求/产品:完善业务逻辑设计、功能设计;

for第三方厂商:完善硬件、软件、线路等方面的健壮性等;

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

2.6编写故障报告并发布

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

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

小结

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

THEEND

最新评论(评论仅代表用户观点)

更多
暂无评论