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

《企业运维故障复盘步骤及改进方法.docx》由会员分享，可在线阅读，更多相关《企业运维故障复盘步骤及改进方法.docx（9页珍藏版）》请在优知文库上搜索。

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

2、方式、梳理故障应急时间轴、还嫌故障处置行动、根因分析及经验沉淀,问题及改进措施跟踪.编写故障报告并发布”六个步骤的故障包盘改进方法.1.关于复盘上个月在3.3.1构建持续提升的故障管理能力中，我将故障管理闭环周期分为故障预防、故障发现、故障响应、故障定位、故障恢复、复盘改进”,其中豆盘改进是从“总结改进中改动而来，相比总结,豆盘需要有一定套路和方法，强调客观回顾、持续学习.我裳试用我个人时间管理例子对比一下总结与基盘的差异。以前我的时间管理相对随意，比如将日常临时性安排登记为任务，不定期反思收获.今年以来，我使用手帐做时间管理，用法如下：每天上班路上登记当天需关注事项，在每天的碎片时间段中将已

3、完成事项标注done）,下班路上则根据手怅上己完成事项串起一天过程，通过手帐仪式感的例行反思，能持续在每日复盘中收获，比如：哪些待安排事项没安排好：这类事不一定我自己亲自做，但需要自己提前安排任务，作好计划.哪些需要提前沟通的事没有做：这类事只需要提前沟通即可减少后续的被动.哪些工作可以做得更好：针对已经完成的工作。哪些目标没完成：忘了？未就绪？延续到下一天？暂停？与预期不符的事背后合理的理由是什么：工作总会有些不破,关键要调整心态.相比而言，以前的不定期反思是“总结，最近的每日时间管理手帐可以归为“复盘。前者主要是反思总结，后者则在反思总结基地上增加了一些因素：持续性（笛天）、有方法（登记目

4、标事项，标注完成）、我（亲身经历者）、串起过程（回硕过程）、收获（影响目标的分析，收获经验）.可能通过“包盆”响原懑可以进一步抽象复盘关键要素。复盘来自围棋，指棋手在下完一盘棋后，重新在棋盘把对弈过程摆一遍，看哪里下得好，哪里下得不好，以从全局角度更新分析、研讨模局过程,了解不足与优点,找到更好的经验方法,从而提升模力。综上，我们可以将发盘归纳为5个要素：持续性复盘（红盘拱局是常规操作）、参与者或实经历棋手）、描述完整经历（对弈过程）、分析研讨对错（分析、研讨棋同、转化为能力（收获经验，提升棋力）。2、关于故障复盘通常，一个严函的生产故障是多个层面上的连续性保障均失效的结果，比如：架构的高可用

5、、人员应急处置能力、常规预防准备工作、监控发现能力、自动化工具应急能力等.这与海恩法则的描述统一:海恩法则：一起更大的飞行安全事故背后都会有29个事故征兆，每个征兆背后又有300个事故苗头，每个苗头背后还有1000个事故电患.由此可见，对隐患、苗头、征兆的忽略，是导致意想不到的安全事故发生的罪魁祸首。：Kr1度百；心）海恩法则强调两点：一是事故的发生是量的积累的结果：二是人自身的素质和责任心.站在运维角度，作为业务连续性隈后一道防线，可以从技术手段与管理手段进行可用性能力建设.所以，故障红盘是对事前与事中环节红盘，不仅关注引发故障根源性问题,还需要推动应急协同、工作机制、人员锢力、预案管理、潜

6、在风睑、监控发现、应急工具、架构高可用、上下游系统风险等全方位的分析.区别于运维组织通常主要围绕“根因分析、编写报告、创建及跟踪问题3个故障鱼盘步骤，下面我尝试将上一节总结红盘的持续性红盘、参与者真实经历、描述完整经历、分析研讨对错、转化为能力.五个要素融入进来，梳理一条圉绕“确定故障豆盘方式、梳理故障应急时间轴、还原故覆处置行动、根因分析及经酸沉淀、问即及改进措施跟踪、编号故解报告并发布“六个步骤的故障复盘过程.故障复盘过程在分解上面六个步骤前，可能需要关注下面对故障复盘分解的步骤相对理想化，实际情况下由于组织每天都会有大信故障,要求每个故障都进行详细复盘无法实现，组织应该通过管理机制及工具

7、后能，摘取部分更点关键内容，减少故障红盘手工操作环节，让大部分故障在当天或24小时内即完成夏盘，少数正要故障则细化豆盘过程.蝮理故应急时间错行动根因分析及较聆沉淀告并发布2.1 确定故障豆盘方式每个故障都是运维团队学习成长的机会，我们不要浪费任何一个故障，要让故障登盘作为故障管理的必要环节。考虑到故障基盘涉及工作品较多，建议运维组织建立多种夏盘模板，针对不同复盘模板与参与人员范围来应对不同类型的故障.在模板中定义好：哪些人参加，输出什么，设计/架构/故障预防/故障处置/故障发现等执行情况，是否需要纳入日、周、月、季例会等.基于明确的判断条件提前制定故障宜盘模板，比如针对故障影响级别高低.正复性

8、故障、权益类交易、安全风险等.建议故障豆盘采用线上化的菅理工具落地，高级别的故障增加一些线下的辅助手段，比如对于故陪影响级别高的故障需要跨团队参与分析，包括产品或翕求团队从需求或设计角度评估软件逻辑设计角度评估，开发团队从架构或程序实现角度评估,测试团队对功能性与非功能性测试角度评估，SRE从系统稳定性、应急处置效率、应急协同、监控发现、自动化处置等角度评估，运维工具团队从监控、自动化麋作、日志等专项角度进行分析.整个故障分析尽量保持透明、公开，让故障参与各方能够客观的参与进来。除了根据明确条件判断的故障红盘模板，还有一类故障可能风险级别未达到高级别，但是在某方面已存在较大的风险隐患，比如潜在

9、架构性能及容量问题、针对协同不畅、管理流程、操作不当、人员能力、运维工具应用等问题.这类问题容易漏分析或执行跟踪不到位，建议从组织管理团队或故障流程经理驱动，以线上任务方式，指定具体责任人牵头落实红盘目标。2.2 掇理故障应急时间轴第一节中，强调了豆盘参与者真实经历、描述完整经历.两个区别于一般总结的要素，将这两个要素应用于故障复盘，第一步是要建立故障应急时间轴，时间轴需要有故障处普的关椎时点.为了标准化、线上化故障处置过程，需要将故障处置关键时点进行抽象.在选择关梃时点时，故障应急时间抽可以参考业务连续性领域的：MTBF（无故障时长）、MTTI（平均故障发现时长）、MTTK（故障定位时长）、

10、MTTF（平均故障处理时长）、MTTR（平均故障响应时长），MTTF（平均故障恢豆时长）的思路，从故障发生时间、发现时间、响应时间、尝试处等时间、诊断时间、生效应急处首开始时间、故障恢复时间等梳理应急处置的关键节点.通常,MTn=发现时间-发生时间；MTTR=响应时间-发现时间；MTTK=定位时间-发现时间；MTTF=恢且时间-定位时间。要达成这个目标，要建立线上化的应急处署协同机制，以便上述时间点能够在事中落地客观数据.理想情况下，这个线上化应急处置/同机制可以在一个应急场景工具实现，或能够将多个应急工具中的关键操作行为数据整合在一起.故障应急时间轴是围绕故障应急关键时间点的过程还原，需要关

11、注：客观、在线、量化，这个过程相对容易抽象，适合运堆工具团队落地.2.3 还原故障处蹙行动有了故障应急时间轴，下一步是让参与方参与进来围绕应急时间轴还原具体的处置行动，全面复原故障处置行为.比如：发现方式：谁（机器、IT人员、客服、客户）、什么时候（预防、及时、蛟大延迟）、什么方式发现（监控、巡检、投诉）等；响应方式：产品/研发/测试/运维/安全响应情况，监控发现后响应效率等；跨团队协同：运维团队内、运维与其他IT条线、IT与业务线、公司与客户之间协同是否顺畅；尝试诊断：故障发生后尝试了哪些诊断动作，是否有效，专家意见是否快速有效；影响分析：盘中影响分析是否到位，是否有足够数据支持盘中快速判断

12、，是否提前准备关键KPI指标分析；危机升级：故障处置过程对于应急处置时间超长，高风险事件的危机升级机制是否到位，现场危机组织是否到位；情况通报：故障处百过程及恢复的信息通报是否及时、准确，话术是否合理；启动预案：预案是否完整，具备可操作性，事中是否启动预案；处餐方案：尝试诊断中的生效应急处首，或事中准确判断的处冒方案是什么；故獐恢复：制定处置方案后，方案的执行过程是否及时，跨团队交付方案是否快速，应急工具是否就绪；在上述处首过程的还原上，可以考虑关注：能力（专家、预案等）、协同（吟团队）、机制（信息扩散、危机升级等）、工具（监控、日志、腌路、数据等）.2.4 根因分析及经豁沉淀故障复盘是为了将

13、故障处笆行动过程进行分析，沉淀经脸，转化为团队能力。随若业务的不断演进，系统的数据量不断扩大，技术栈越来越豆杂,系统调用链路越来越长，造成信息系统中断的事件的风险场景越来越多，中断事件的频率和种类持续增长，且有相当一部份事件会造成业务中断，可用性问题越来越严竣.在前面数智万物下，重新思考运维价值中，用业务连续性事件起因鱼骨图总结了一下影响业务连续性因素：变更问题、维护问题、性能容最问题、麋作问题/误操作、容灾/应用架构高可用、应用逻掘缺陷、版本控制、产品或功能设计不足、数据质.量、高可用有效性、应急方案、技术保障方案不完善、应急预案缺失、应急演练不到位、问透跟踪不闭环、参数设三问题、配置问遁、

14、人员技能不足、流程机制不完善、外部攻击、基础设施异常、数据备份、数据丢失、监控发现及时性、故障处置时效性等，这些因素都可能是引发故障及导致故障影响升级的根因.业务连续性小件在故障且盘中，主要是对故障直接原因进行定位分析，但随着运维且杂性不断提升，只分析直接原因是不够的，运维在应对复杂性能力飞轮中需要更加主动.参考前面提到的海恩法则，故障根因分析需要从技术与管理两个角度进行多维度分析.技术手段主要是分析技术架构的高可用,非功能性需求的实现，运堆的可观察性手段是否具备,运维监控工具的故障发现能力是否濯盖，日志等工具对于故障诊断是否有效，运维自动化工具对连续性恢复处苣是否就绪等；管理手段则主要从事前

15、预防、事中处25、事后跟踪等多方面分解，比如生产环境管控是否到位，预案是否有效，演练是否到位，对业务、运行的理解能力是否达标，协同是否破畅等。2.5 问题及改进措施跟踪通过故障原因分析得到的多个待改进事项，将纳入到故障改进中，在111.中将这个待改迸事项定义为问廖.针对2.4中提到的问题，通常会给不同的角色分派改进事项，比如：for故獐处置运维团队：加强人员对业务、运行的理解，提升监控覆盖面，加强应急预案管理，加强运行状态数据分析能力，加强运维工具的使用等；for工具团队：加强工具的运营，提升监控羯盖面与准确率能力，提升日志等异常诊断工具能力，提升自动化工具的使用，提升运维数据分析的平台能力；

16、for流程经理：完善应急处m过程的协同效率，信息传输及触达效率，完善人员能力、工具平台能力的提升；for研发：修且程序设计逻辑缺陷，提升系统健壮性，增加日志完备度与监控埋点需求，加强版本爸理优化等；for测试：提升非功能性测试、功能性测试覆盖面等；for需求/产品：完善业务逻辑设计、功能设计；for第三方厂商：完善硬件、软件、线路等方面的健壮性等；建立上述问题只是开始，下一步是对问题的跟踪，需要有专项跟踪机制，比如专项的问题管理例会，问题催办进展与通报，问题与变更闭环，问题关闭的策略等.由于问题跟踪的豆杂性，理想情况下问题管理应该与绩效关联上.结合管理机制，还需要建立数据驱动，绩效支持的协同方式来确保障高优先级的问题得到及时解决.在问题跟踪上，建议采用全线上的闭环，打通各关联方的工作平