一分钟精髓快速概览故障恢复是指及时将过去的错误转化为未来可以避免的错误方法的核心是不断减少失败因素的滋生地，牢牢控制住，不至于引发危机。作为国家级基础设施的哈啰出行，在保障超过5.3亿注册用户的体验和系统稳定性的过程中，如何通过系统性、战略性的总结回顾，避免屡屡失败？笔者介绍哈啰科技风险负责人——孟创，拥有十年互联网行业研发经验。2015年加入哈啰出行，从0到1参与哈啰商务系统的建设，作为核心负责人主导了多个重点稳保项目。在高可用架构、技术风险等领域拥有丰富的经验。目前主要牵头建设哈啰稳定性保障体系，通过人员机构建设、工具/平台建设、重点项目实施等措施保障哈啰各项业务的稳定性。温馨提示：本文约6000字，预计阅读时间10分钟。后台回复“交流”进入读者交流群；回复“评论”或“模板”获取信息；在文章开始之前，先给大家讲一个故事。多年前有过这样的点评经历：有人在网上改了，后来客服反馈说用户投诉变多了。研发很快分析了原因，最后发现是代码bug导致的。回滚操作一段时间后，客户投诉逐渐消失。后来在review的时候大家讨论了如何避免代码bug本身，并没有深入讨论这个故障带来的其他隐患，比如如何提高故障发现的及时性。而这一次，由于审查不深入所造成的隐患，在近期又带来了新的风险。过了一段时间，又因为其他原因导致失败。这一次，是被外面先发现了。等报告开始处理时，已经过去了很长时间。在我十年的职业生涯中，经历过很多失败的修复，也看到了很多人对待失败的不同态度。唯一能让大家达成共识的是，故障的发生是无法完全控制的。我们能做的就是尽可能有策略、有系统地梳理审查中踩过的坑，还原事实，找出薄弱环节，加以改进。1.失败和恢复真的是坏事吗？说到replay，大多数人首先想到的是上线失败，现在有人来顶锅；或者他们暗自担心那个可怜的兄弟；或者因为与他们无关，所以他们一口气放了下来。那么失败和重播真的是坏事吗？我们应该怎么理解呢？我将从以下三点谈谈我对失败和恢复的理解。1.1正视失败的必然性——无论好坏。在说replay之前，先说说我对上线失败的看法。首先，在复杂的系统中，故障是不可避免的。任何系统都不能保证永远不会出现故障。重要的是没有重复的失败，所以我们接受失败可能发生的合理性。那么，从定性的角度来看，并不是所有的故障都是坏事，有些故障是积极的，比如通过一个小故障发现了重大隐患，或者某个故障中相关人员的意识和应急预案没有够好了。到位了，但是由于失败的原因很特殊，最后还是造成了比较大的影响，等等。对于类似的故障，要找出亮点。所以，我们一定要用辩证的眼光看待故障，防止大家“闻故障变脸”。要想做好这一点，需要在公司内部管理制度上做一些适当的倾斜和引导，比如鼓励快速恢复（对于快速恢复，故障率比较低），鼓励更多的在线问题通过演练发现（对于演练引起的故障有一定的免疫力）等。有奖有罚。与那些被鼓励的行为相比，哪些行为是必须认真对待的？这是人为错误。每个人都应该充分了解我们的故障哲学：偶尔的系统故障是可以容忍的，必须认真对待人为错误。例如不符合高可用规范的系统设计模式，强弱依赖设计不合理，人员意识不足导致故障处理时间长，oncall未及时接通等。值班人员、对在线系统重视不够导致的故障变更隐患、不遵守变更三规等1.2重视改进——关于审查的3个目的简而言之，回顾的目的是总结和改进，充分利用每一次失败的机会，从中吸取教训，提高经验，完善制度设计。强化人员意识等。从总体稳定建设看，希望实现三个目标：一是找准根源，从根本上优化提升——消除隐患、查漏补缺。2）想办法降低故障概率——提高MTBF。3)找到一种从故障中快速恢复的方法——减少MTTR。1.3不仅要优化技术，还要完善组织和制度。每次出现故障，都能挖出很多东西。有些看起来是技术问题，但如果继续深挖，可能会变成管理问题。比如应急人员不到位，值班制度为什么不到位，关键岗位是否缺乏后备机制等。我们常说好的系统架构是有弹性??的，那么好的团队组织也应该是反脆弱的。所以，在审核的过程中，除了要找制度本身的问题，还要找工具的问题、流程机制的问题、管理的问题等等。只有这样，才能从点到面，全面解决问题，标本兼治。2、故障恢复的流程是怎样的？线上出现故障后，优先解决问题。故障初步排除后，首先要检查是否还有其他已知隐患需要处理，确保隐患消除后再进行复位。或者至少在审查期间，其他人员正在跟进隐患的进展情况。不要出现一边在review，那边出现同样的故障的情况。3、复习开始前需要做哪些准备？3.1利益相关者必须到位。与故障有关的直接原因方、关联（受影响）方和其他利益相关者必须全部到场，并将参与人员名单记录在评审文件中。同时，根据故障的危害程度，确定是否需要上级管理人员在场。例如，影响范围超过一定级别的故障，必须有TL参与，以保证有效性和执行力。3.2明确审核负责人每次审核会议都必须有一个独特的审核负责人。审核开始前，审核负责人将推动各方梳理时间线，收集故障范围，与各相关方沟通验证影响数据，包括业务指标、系统指标、其他指标（客户投诉、舆论影响力等）。同时，在会议中，故障的恢复负责人要主动引导大家，推动恢复的进程，避免一些无意义的指责、与故障无关的分歧讨论等。3.3概念宣传复习的目的是为了总结和提高，但是一次线上失败后，大家压力都很大。在复习会上，他们经常以防御的态度进行交流，有时甚至会出现一些相互指责等情况。因此，复习的理念需要提前宣传。理性务实，敢于承担责任：首先从自身寻找问题，主动提出需要改进的地方。虚心接受批评：在尊重他人的前提下，每个人都可以提出问题。同时，大家要敞开心扉，敢于暴露自己的问题，真诚地接受他人的建议或批评。4.如何实施关键流程审核？4.1故障背景概述故障背景应说明本次故障恢复的背景，即发生了什么故障，影响了哪些业务（产品）等故障的基本情况。在评审文件中，可以用结构化的语言表达。例如：“x月x日xx，xxx系统出现异常，造成了xxx，影响了xxx的业务。故障背景的意义在于让别人一眼就明白review的来龙去脉。rootcause不用写太多，下面会有rootcause链接。4.2对齐故障的影响范围，明确本次故障的影响范围，包括影响时间段、影响业务（产品）线、影响系统（服务）、订单量、用户量、客户投诉量、是否有有没有资金损失等。从监控的角度，哪些指标出现了波动，从业务的实际数据来看，哪些业务受到了影响。4.3故障时间线回放这是回放的重点。很多时候，replay的评价好坏，取决于这个环节能挖出多少问题。故障时间线回放是指从故障源头重新梳理故障的详细过程，包括人员操作、指标变化、监控告警、系统异常、业务实际情况等。不管大小，越详细越好。因为我们上面提到，稳定性建设有两个关键点：提高MTBF和降低MTTR。MTTR（MeanTimetoRecoveryfromFailure）是指从故障发生到业务恢复的时间。我们将MTTR拆解得到如下时间段：MTTR=MTTI+MTTK+MTTF+MTTV。1）平均识别时间（MTTI）：从故障开始到应急响应介入的时间，一般用来检验监控告警和值班人员值班的合理性。2）MeanTimeToKnow（MTTK）：从应急响应介入到故障定位的时间，主要考察根本原因分析、可观察性等工具的能力。3）平均修复时间（MTTF）：从故障定位到故障恢复的时间，主要考察应急预案和快速恢复系统的能力。4）MeanTimeToVerify（MTTV）：从故障恢复后到确认故障已经解决的时间，一般通过用户反馈、自动化测试等方式来确认恢复。因此，在回放时间线的时候，也需要确定以下几个关键时间点，然后一一沟通讨论，如何缩短每个环节的耗时。需要注意提前识别的重点项目和时间点：故障引入的时间点：即故障真正开始的时间，可能是变更发布/上线运行/其他等。业务指标：业务指标什么时候开始下降，什么时候开始回升等。监控告警的时间：即监控发现异常的时间，什么时候发出告警。人员干预响应时间点：故障相关系统值班负责人何时开始响应。异常定位时间点：定位故障的异常点。注：故障处理过程中的定位是指初步原因定位，即大致定位故障点，可以进行下一步的紧急止血动作。它不是指根本原因定位，因为有时要找到根本原因是非常困难和耗时的。关键操作时间点：是否做好了一些应急预案，包括重启、恢复、止血、高可用配置等。还需要把每一次操作的结果写清楚，即每一次操作之后，错误面是否是否缩水，系统资源水位是否发生变化等。确认故障恢复时间点：通过测试验证或观察业务指标、系统日志确认系统已恢复。重点是把其中的每一步都讲透，想办法提高效率，缩短时间。“时间就是金钱”，真正处理过线上故障的同学应该能深刻体会到这句话的分量。如果故障处理速度快1分钟，或许可以挽救大量的业务损失。4.4深挖根源一般情况下，故障的原因有直接（诱发）原因和根本原因两种，即所谓的诱因和根本原因。因此，在检讨过程中，要厘清诱因，深挖根源。比如某业务系统由A/B/C三个服务组成，依赖关系是A依赖B，B依赖C，某开发同学修改了线上C服务的一个配置，使用错了格式。导致整个业务系统不可用。那么在分析原因的过程中，修改配置文件格式错误的动作肯定是直接原因，还要注意，服务B对服务C的依赖是不是强依赖？如果服务C出现异常，服务B是否需要覆盖？这里不合理的依赖可能是根本原因，需要分析清楚。可以根据5why分析法深挖根源，多问几个原因，层层推进。比如这样一个场景：在线系统运行过程中，ES节点突然抖动，RT时间明显变长。95行从200ms上升到800ms，然后触发上游业务异常。所以在分析原因时，提出以下问题：1）ES为什么会抖动？2)ES的可用性标准是什么？3）ES抖动后，有没有报警？相关人员是否第一时间介入？4）ES抖动后，直接使用它的上游服务有没有备份措施？是强依赖吗？5）对于这个业务场景，ES的直接上游系统是不是这个环节的核心依赖？整个链路是否有自下而上的机制？需要一层一层地越挖越深。不要一开始就停下来，否则你可能会错过真正的进步。从以往的故障来看，很多问题都是系统设计问题造成的。这样的问题我们越深入，我们的系统可用性就会越强，我们就会慢慢走向我们理想中的高可用架构。4.5改进项总结在分别确认了timeline和rootcause之后，我们就可以推导出本次故障评审我们的改进项。在梳理改进项时，除了故障系统相关的改进项外，还需要查看整个故障处理流程，看故障的各个环节是否有需要优化和改进的地方。从流程体系、团队组织、系统设计、底层工具平台等角度，都要综合考虑。比如人工发现故障（用户投诉），那么就要考虑这个业务的监控告警是否完善，如何减少故障联系时间；例如，某个故障告警发出后，长时间无人响应。从管理体制看，应急值守政策执行是否到位；比如在排查某个故障的过程中，定位比较困难，很多地方需要人工整理很多资料，所以要考虑相应的排查工具是否好用。例如，在定位问题并临时讨论解决方案后，需要评估相应的应急预案机制是否完善等。还有很多其他问题。大家可以参考上面的MTTR分解链接和故障根因分解链接自行思考。在记录改进项时，可以考虑结合SMART原则来设计改进项：1）S——必须是具体的（Specific），改进项必须是可实施的，不要泛泛而谈，比如“优化系统设计”它是一个反例。具体是重新设计系统A对系统B的依赖，使其完全理解异常。2）M——必须是可测量的（Measurable），即改进项是可以评估的，比如通过故障演练检查依赖关系的有效性。3）A——必须是可达到的（Attainable）。在目前的技术环境下，这个改进项目是可行的。不要写太远未来，无法实现的东西。4）R——与其他目标相关（Relevant），可以理解为与本次失败中的其他改进项相关。5）T——必须有明确的期限（Time-bound），改进项目的期限必须写清楚，到期后进行验收。最后，改进项集中在闭环上，即所谓的PDCA循环，Plan（计划）->Do（执行）->Check（检查）->Act（处理），对于我们的故障检讨，最后一个改进项必须有验证链接。验证通过后，故障恢复完成。5.评审需要回答哪些关键问题？设置问题的目的是引导，启发大家通过问题思考，引导大家朝着正确的方向去讨论。在复习过程中，由于很多参赛同学的经历或背景不同，大家对故障的理解可能不尽相同，所以复习的主人应该多提问，引发大家的讨论和思考，我们总结了几类问题，大家可以以此为框架进行讨论：1、故障的根本原因是什么，对业务可用性有何影响？这是我们现在谈论的根本原因吗？从业务场景对应的链接来看，这个系统（组件）是否强依赖？依赖是否合理，是否有backstop机制。本次变革进程是否完整，三大变革的落实是否到位。相应的观测指标是否能反映系统的真实状态，应急策略是否有效等。2、为什么会出现故障，能否避免或减少故障？也就是所谓的MTBF提升，尽量没有失败，能做到这一点自然是最好的结果。如果是变更引起的，需要考虑变更流程是否完整，是否按照流程规范操作，是否有相应的防御机制。比如变更是否严格按照测试环境、预发布环境、生产环境流程执行，为什么前面没有发现问题，灰度环节是否能发现问题。如果是某个系统组件故障引起的，那么需要评估该组件的可用性，是否与所在链路相匹配，是否应该为该链路设计备份计划等.比如一个SLA低的系统组件是否在核心环节。如果是外部原因造成的，那么就要仔细评估外部依赖的稳定性，对方的可用性是否能够满足我们的需求。是否将availability写入合作条款，不满足SLA后是否有相应的补偿或惩罚。3.我们应该怎么做才能更快地恢复业务？1）监控告警——这个故障是怎么发现的，监控告警是否足够完善，能否更快的发现这个问题。（延伸阅读：故障恢复后告警如何加效？）2）管理体系-值班人员是否及时响应oncall，关键人员是否到位，是否有后备机制对于关键职位，以及系统所有者是否足够熟悉负责的组件。3）定位效率——现有的故障排查工具是否好用，是否有需要优化的地方，故障定位时间是否可以缩短，故障处理原则是止血优先、恢复优先。当时排查过程中，有没有走错路。4）应急预案——故障排除过程中是否有应急预案，应急预案是否有效？是否通过日常故障演练验证应急预案的有效性。5）架构设计——架构本身的高可用是否完善，是否具备容灾能力。6）流程规范——现有系统规范是否完善，是否需要优化。六、过错定级与责任认定由于各公司都有自己的定级与责任认定制度，这里不再赘述，仅重点介绍几点。6.1故障评分一般根据用户体验、GMV、客诉率等指标综合计算得出。每个公司都有自己的计算方法。这里就不细说了，大家可以根据实际情况制定。分级的原则可以和业务方沟通。一般是找几个关键指标作为参考维度，然后根据不同的体量设置不同的层级。6.2故障责任的确定首先是团队责任，其次是个人责任：很多故障只是表象，根源多半是技术管理因素。换个角度看问题，避免把根本原因归咎于一个人。故障级别越高，越应避免简单归因。举个例子：一个新入职的同学，由于操作不当导致上线问题。这里需要注意新人为什么可以直接操作线上环境，入职后是否有相应的培训或者文档可以让他学习，告诉他如何避免高风险操作。（延伸阅读：故障判定的职责是什么？）鼓励快速止血和积极参与：对在故障处理过程中积极参与定位、止血等操作的人员给予积极肯定。对于积极参与网络救火的同学，利用系统进行掩护。第三方默认不负责：如果由于第三方合作伙伴或服务商导致上线失败，那么在进行内部审核时，需要让相应的内部团队承担责任，避免将责任推给第三方派对。也就是说，谁引入了第三方技术组件，谁就对其可用性负责。这反过来又需要我们仔细评估对方的可用性，以及我们在使用外部技术组件时的来回解决方案。红线和军规：在研发规范中，必须设置红线和军规。例如，高峰期严禁变更，变更过程必须遵守三轴（灰度、可观察、应急）原则等。红线和军规是稳定的底线，不得擅自更改。违反了。很多军规都是从过去各种失败的血腥历史中沉淀出来的。这些红线军规必须遵守和尊重，是铁律。屡犯错误必须认真对待：未知的失败并不可怕，可以用来丰富我们稳定性建设的经验，但反复犯错需要认真对待，需要思考为什么之前的改进项目没有落实到现在地方等我把它写在最后，回头看看我们一开始讲的故事。如果您是评论所有者，您会怎么做？你能提出以下问题吗？为什么线上环境会带来BUG，而线下环境却找不到？是案件覆盖不足还是其他原因？变更流程是否足够标准化？已经灰度化了吗？在灰度阶段能找到吗？为什么故障先被外部发现，如何尽早发现故障，监控告警的覆盖面是否足够，粒度是否足够细？如前所述，审查不是故障的结束，改进项在验收后才算是彻底完成。因此，改进项目的各相关方应积极推动完成。同时，为了最大限度地发挥评审文档的价值，我们还会考虑以下几点，以便在以后充分利用评审的价值：1）团队中的新人入职后，他们应该先整理和研究以前的审稿文件，吸取前人的经验，避免重复踩坑。2）以过去的失败为素材，放到团队日常的稳定文化建设中，比如通过考试等形式，加深大家对失败的理解和记忆。最后，我再重复一句：失败并不可怕，可怕的是反复失败。了解更多故障恢复详情，欢迎扫描二维码进入“读者交流群”与老师实时互动。公众号后台回复【评论模板】获取更多信息请点击“阅读原文”进入“TakinTalks稳定性社区”获取更多稳定性相关信息和知识。
