一分钟精髓速览
故障复盘指的是及时把过来产生的谬误，最大水平转化为将来能够躲避的方法，其外围是一直缩小失败因子繁殖的温床，将它们牢牢地掌控在不至于引发危机的范畴之中。作为国民基础设施的哈啰出行，在保障超 5.3 亿注册用户体验和零碎稳定性过程中，是如何通过零碎的、有策略的总结复盘来防止故障反复产生的？
作者介绍
哈啰技术危险负责人——孟闯
十年互联网行业研发教训，2015 年退出哈啰出行，参加哈啰业务零碎从 0 到 1 的建设，作为外围 owner 主导多个重点稳定性保障我的项目，在高可用架构、技术危险等畛域有丰盛教训。目前次要牵头哈啰稳定性保障体系化建设，通过人员组织建设、工具 / 平台建设、要害我的项目落地等措施保障哈啰所有业务稳定性。
舒适揭示：本文约 6000 字，预计破费 10 分钟浏览。
后盾回复“交换”进入读者交换群；回复“复盘”或“模板”获取材料；
在文章开始之前，先给大家讲一个故事，多年之前我有过这样的一段复盘经验：
事件的起因大略是有人做了一个线上变更，起初接到客服反馈说用户投诉减少，研发连忙剖析起因，最初排查发现是有代码 bug 导致的，做了回滚操作后一段时间客户投诉缓缓隐没了。起初复盘的时候，大家全程围绕代码 bug 自身如何躲避做探讨，并没有深刻探讨此次故障带来的其余隐患，比方，如何晋升故障发现时效。
而此次因为复盘不深刻导致的隐患，果然在不久后带来了新的危险——过段时间又呈现了一个其余起因导致的故障，这次依然是由内部先发现的，到研发接到报障开始解决的时候，曾经过来了很长时间。
在我的十年职业生涯中，经验过很屡次故障复盘，也见识过很多人看待故障的不同态度，惟一能让大家达成共识的是，故障的产生是不齐全能被管制的。而咱们能做的是尽可能有策略的、系统性地去组织复盘踩过的坑，还原事实，找到薄弱点加以改进。
一、故障和复盘真的都是好事吗？
提到复盘，大多数人第一工夫想到的是线上出了故障，这下又要有人背锅了；或者是为那个可怜的兄弟暗暗放心；也或者是因为跟本人无关，所以松了一口气。那么故障和复盘真的都是好事吗？咱们该如何了解它呢？我从以下三点讲一下我对故障和复盘的了解。
1.1 正视故障产生的偶然性 – 有好也有坏
在聊复盘之前，先聊下我对线上故障的认识，首先，在简单零碎中呈现故障是必然的，没有任何零碎能保障永远不呈现故障，重要的是不能呈现反复故障，因而，咱们要承受故障可能产生的合理性。接着从定性的角度来看，并非所有的故障都是好事，有些故障是有侧面意义的，比如说通过一个小故障发现了一个大隐患，或者是某次故障中相干人员的意识和应急预案都很到位，然而因为故障的起因十分非凡最初依然造成了较大的影响等等，相似这样的故障都要找出其中的亮点。
所以，咱们要用辩证的眼光去对待故障，防止大家“闻故障色变”。想做好这一点，在公司外部的管理制度上要做一些适当歪斜和疏导，比方，激励疾速复原 (对于疾速复原的故障定级比拟低)、激励通过演练发现更多的线上问题(对于因为演练导致的故障有肯定的豁免权) 等等。
有奖也有惩，相比那些激励的行为，哪些行为是必须要庄重看待的呢？就是人为导致的犯错。大家应该充沛意识到咱们对故障的理念：偶然的零碎生效是能够容忍的，人为的犯错是要庄重看待的。比方不合乎高可用标准的零碎设计模式、强弱依赖设计不合理、因为人员意识不到位带来的故障解决工夫较长、值班人员未及时接通 oncall、因为对线上零碎不够器重带来的变更隐患、不恪守变更三板斧标准等等。
1.2 重在改良 – 对于复盘的 3 个目标
总之，复盘的目标是为了总结和改良，要充分利用好每一次故障的机会，从中吸取教训进行学习，晋升咱们的教训，欠缺零碎的设计，强化人员意识等等。从整体稳定性建设的角度来看，心愿达到 3 个目标:
1）找到根因，从根本上进行优化和改良 - 消除隐患，查漏补缺。
2）找到升高故障产生概率的办法 – 增大 MTBF。
3）找到让故障疾速复原的办法 - 缩短 MTTR。
1.3 不要只优化技术 – 组织和制度也要改良
每次呈现故障之后，都能深挖出很多货色，有些看起来是技术问题，然而持续深挖上来，可能会变成治理问题。比方人员应急不到位，为什么 Oncall 值班制度没有落实到位，要害岗位是否短少 backup 机制等等。
咱们常常说好的零碎架构是具备韧性的，那么好的团队组织也应该是反软弱的。所以复盘的过程中，除了找零碎自身的问题，还要找工具的问题、流程机制的问题、治理的问题等等。这样咱们能力由点及面的全面解决问题，既治本又治标。
二、故障复盘依照什么流程进行？
线上呈现故障之后，优先解决问题。待故障初步复原之后，先看一下其余有没有待处理的已知隐患事项，确保隐患打消了再进行复盘。或者至多在复盘的时候，有其余人员在跟进隐患的治理停顿。不要呈现这边在复盘中，那边又呈现了同样故障的状况。
三、开始复盘前须要做哪些筹备？
3.1 干系人必须到位
间接起因方、关联 (受影响) 方等与故障无关的干系人必须全副到场，在复盘文档中记录参会人员名单。同时，视故障的危害水平来确定是否须要更高层级的管理人员到场，比方影响范畴超过某种程度的故障必须由 TL 到场，以此来确保相干定级定责、改良事项落地的有效性和执行力。
3.2 明确复盘 owner
每个复盘会议，都必须有惟一的复盘 owner，在复盘开始前，由复盘 owner 来推动各方实现工夫线的梳理，收集故障的影响范畴，与各个关联方核实影响的数据，包含业务指标、零碎指标、其余指标(客诉、舆情影响等)。同时在会议中，故障的复盘 owner 要被动疏导大家，推动复盘进度，避免出现一些无意义的指摘、与故障无关的发散探讨等等。
3.3 理念宣导
复盘的目标是为了总结和改良，然而出了线上故障之后，大家压力都很大，在复盘会议中往往会带着进攻的心态来沟通，甚至有时候呈现一些相互指摘等等。因而，复盘的理念须要提前宣导。感性求实，敢于担当：先从本身找问题，被动提出本人须要改良的中央。心态凋谢，接受批评：在尊重他人的前提下，所有人都能够提出问题，同时，大家也应该敞开心扉，敢于裸露本人的问题，承受他人的倡议或者善意地批评。
四、复盘的要害流程如何落地？
4.1 故障背景概述
故障的背景要解释分明本次故障复盘的背景，即产生了什么故障，影响了什么业务 (产品) 等故障的根本状况。在复盘文档中，能够通过结构化的语言进行表白。例如：“x 月 x 日 xx 时，xxx 零碎出现异常，导致了 xxx，影响了 xxx 业务，表象为用户无奈失常下单，点击下单按钮呈现网络开小差，呈现了大量客诉等等”。故障背景的意义在于让他人第一眼理解分明这个复盘的前因后果，根因能够不必写太多，上面会有根因环节。
4.2 对齐故障影响范畴
讲清楚本次故障的影响范畴，包含影响时间段、影响的业务 (产品) 线、影响的零碎(服务)、订单量、用户量、客诉量，以及有无产生资损等等。从监控的角度看，哪些指标产生了稳定，从业务的理论数据看，哪些业务受到了影响。
4.3 故障工夫线回放
这个是复盘的重点，很多时候评估复盘的好与坏，就看这个环节能挖出来多少问题。故障工夫线回放，就是指从故障的最源头开始，从新梳理一遍故障的具体过程，包含人员操作、指标变动、监控告警、零碎异样、业务理论状况等等。事无巨细，理得越细越好。因为咱们下面提到过，稳定性建设的两个要害要点: 减少 MTBF，放大 MTTR。MTTR(故障均匀复原工夫)就是指从故障产生开始，到业务复原的这段时间，咱们对 MTTR 其进行拆解，失去如下几个时间段:MTTR = MTTI + MTTK + MTTF + MTTV。
1）Mean Time To Identify (MTTI): 从故障开始到应急响应染指的工夫，个别是考查监控告警、人员值班 oncall 的合理性。
2）Mean Time To Know (MTTK): 从应急响应染指到故障定位的工夫，次要考查根因剖析、可观测性等工具的能力。
3）Mean Time To Fix (MTTF): 从故障定位到故障复原的工夫，次要考查应急预案、快恢体系的能力。
4）Mean Time To Verify (MTTV): 从故障复原之后到确认故障曾经解决的工夫，个别通过用户反馈、自动化测试等确认复原。
因而，在回放工夫线的时候，也要辨认出以下几个要害的工夫点，而后一一沟通探讨，如何缩短其中每个环节的耗时。
须要留神提前辨认进去的要害事项和工夫点:
故障引入工夫点：即这个故障实际上是从什么时候开始的，可能是某次变更公布 / 线上操作 / 其余等。
业务指标变动工夫点：业务指标何时开始上涨、何时开始复原等。
监控告警收回工夫点：即监控是从什么时候发现异常的，告警什么时候收回的。
人员染指响应工夫点：故障相干的零碎值班 owner 是从什么时候开始响应的。
异样定位工夫点：即定位到故障的异样点，留神: 故障处理过程中的定位是指初因定位，意思是大抵定位到了故障点，能够进行下一步的应急止血动作。不是指根因定位，因为有时候找到根因是一件十分难、十分耗时的事件。
要害操作工夫点：是否做了一些应急预案，包含重启、复原、止血、高可用配置等。还须要写分明每个操作的后果，即每个操作之后，报错面有无放大、系统资源水位有无变动等。
确认故障复原工夫点：通过测试验证或者观测业务指标、系统日志等确认零碎曾经复原。
重点是对外面的每一步都聊透彻，搞清楚怎么样晋升效率、缩短工夫。“工夫就是金钱”，真正解决过线上故障的同学应该能粗浅领会到这句话的重量。故障解决得快 1 分钟，可能业务上就能少损失很多。
4.4 深挖根因
个别状况下，故障是有两类起因引起的，包含间接 (诱发) 起因和根本原因，也就是所谓的诱因和根因。因而在复盘过程中，既要明确诱因，更要深挖根因。比如说，某个业务零碎由 A/B/C 3 个服务组成，依赖关系顺次是 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 改良项汇总
把工夫线和根因别离确认分明之后，就能推导出咱们对于本次故障复盘的改良事项了。在梳理改良事项的时候，除了与故障相干零碎的改良项之外，还须要从整个故障处理过程来看，在故障的各个环节中有无须要优化改良的中央。从 流程制度、团队组织、零碎设计、底层工具平台都要综合思考。
比方某个故障是靠人工 (用户投诉) 发现的，那么要思考下这个业务的监控告警是否欠缺，怎么样可能升高故障触达工夫；比方某个故障的告警收回之后，迟迟没有人响应，那么要从管理制度来看，对于应急值班政策的执行是否到位；比方某个故障的排查过程中，定位比拟艰难，很多中央要靠人工去梳理很多信息，那么要思考相应的排障工具是否好用；比方定位到问题之后，长期探讨解决方案，那么就要评估相应地应急预案机制是否欠缺等等。
还有很多其余的问题，大家能够参考下面的 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（解决），对于咱们的故障复盘来说，最初的改良项都要有验证环节，验证通过之后，故障复盘才算是彻底实现。
五、复盘中须要答复哪几个关键问题？
设置问题的目标是疏导，通过问题来启发大家思考，并且疏导大家往正确的方向去探讨。在复盘过程中，很多参加的同学因为教训或者背景不一样，大家对故障的了解不肯定统一，那么复盘的 owner 要多问一些问题，来引发大家的探讨和思考，从以往的教训中，咱们总结了几类问题，大家能够把这个作为探讨的框架:
1、故障的根因是什么，它是如何影响到业务可用性的？
以后咱们在聊的这个是根因吗？从业务场景对应的链路上看，这个零碎 (组件) 是强依赖吗？依赖是否正当、有无兜底机制。这次的变更流程是否欠缺、变更三板斧落实的是否到位。对应的观测指标是否能反映零碎的实在状态，应急策略是否无效等等。
2、故障为什么会产生，能够防止或者升高产生概率吗？
也就是所谓的晋升 MTBF，尽可能不出故障，能做到这个天然是最好的后果。
如果是变更引起的，那么要思考变更流程是否欠缺，是否依照流程标准操作，有无对应的防御机制。比方变更是否严格依照测试环境、预发环境、生产环境流程执行的，为什么没能在后面发现问题，是否能够在灰度环节发现问题。如果是某个零碎组件生效导致的，那么要评估该组件的可用性是多少，与它所在的链路是否匹配，这条链路是否要设计兜底计划等。比方某个低 SLA 的零碎组件是否在外围链路中。如果是内部起因引起的，那么就须要认真评估内部依赖的稳定性状况，对方的可用性可能满足咱们的诉求。是否把可用性写入到单干条款中，不满足 SLA 之后是否有相应的弥补或者惩办等。
3、咱们应该做什么，能力更快的复原业务？
1）监控告警 – 这个故障是如何被发现的，监控告警是否足够欠缺，咱们是否更快一点去发现这个问题。（扩大浏览：故障复盘后的告警如何加出成果？）
2）管理制度 – 人员值班响应 oncall 是否及时, 要害人员是否就位，要害岗位有无 backup 机制，零碎 owner 对负责的组件是否足够相熟。
3）定位效率 – 现有的排查工具是否好用，有无须要优化的中央，故障定位的工夫是否再缩短一点，故障的解决准则是以止血复原优先，过后的故障处理过程中，有无跑偏方向。
4）应急预案 – 故障处理过程中，是否有应急预案，应急预案是否见效？日常是否通过故障演练来验证应急预案的有效性。
5）架构设计 – 架构自身的高可用是否欠缺，是否具备容灾能力。
6）流程标准 – 现有的制度标准是否欠缺，有无须要优化的。
六、故障定级与定责
因为每家公司都有本人的定级与定责制度，这里不做赘述，只说几个关键点。
6.1 故障定级
个别按用户体验、GMV、客诉率等指标来综合计算，每家公司有本人的计算形式。这里不赘述，大家结合实际状况来制订就行。定级的准则能够与业务方一起沟通，个别找几个要害的指标作为参考维度，而后按不同的体量设置不同的级别。
6.2 故障定责
- 定责首先对应的是团队，而后是集体：很多故障只是表象，大部分根因深挖上来，都会有技术治理的因素，尽管引发故障的操作可能是集体，然而更应该从团队的视角去看问题，防止把根因只归结到某个人身上，越是高级别的故障，越要防止简略归因。这里举一个例子: 某个新入职的同学，因为操作不得当引发了一个线上问题。这里就要留神，为什么新人能够间接操作线上环境，入职之后是否有相应的培训或者文档让他学习，通知他如何防止高危操作。（扩大浏览：故障定责定的到底是什么责？）
- 激励疾速止血和积极参与：对于故障处理过程中，积极参与定位、止血等操作的，给与侧面的必定。对于那些积极主动参加线上救火的同学，用制度为他们兜底。
- 第三方默认无责：如果因为第三方合作方或者服务商出了线上故障，那么在做外部复盘的时候，须要让外部的对应团队来担责，防止把责任归给第三方。即谁引入了第三方的技术组件，谁就要对其可用性负责。这就能够反过来要求咱们在应用内部技术组件的时候，要认真评估对方的可用性状况，以及咱们的兜底计划等等。
- 红线和军规：研发标准中，要设定好红线和军规，比如说高峰期严禁变更、变更流程必须合乎三板斧 (可灰度、可观测、可应急) 准则等等。红线和军规是稳定性的底线，坚定不能违反。很多军规都是以往的各个故障血泪史中积淀进去的，必须恪守且尊重这些红线军规，把它当做铁律。
- 反复犯错必须庄重看待：未知的故障不可怕，能够用来丰盛咱们的稳定性建设教训，然而反复的踩坑就须要认真对待了，要思考为什么以往的改良事项没有落实到位等等。
写在最初
回过头来再看咱们最开始讲的那个故事，如果你是复盘 owner，你会怎么做呢，能不能问出以下几个问题？
- BUG 为什么会被带到线上环境，线下环境为什么没发现呢，是 case 覆盖度不够还是其余起因？
- 变更的流程足够标准么，有无进行灰度，在灰度阶段能发现吗？
- 为什么故障先由内部发现，咱们本人如何尽早发现故障，监控告警的覆盖度够么，粒度足够细么？
下面说到，复盘不是故障的完结，改良事项通过验收才算彻底完结，因而每一个改良事项的相干方，都应积极主动地 push 实现。同时，为了最大化的利用好复盘文档的价值，咱们将来也思考通过以下几点来充分利用复盘价值：
1）团队的新人入职后，先组织学习以往的复盘文档，排汇前人教训，防止反复踩坑。
2）把以往故障作为素材，放入到团队日常的稳定性文化建设中，比方通过考试等模式加深大家对故障的了解和记忆。
最初再反复一句：故障不可怕，反复的故障才可怕。
理解更多故障复盘细节，欢送扫码进入「读者交换群」，和老师实时互动。
公众号后盾回复【复盘模版】获取材料
更多内容欢送点击“浏览原文”，进入「TakinTalks 稳定性社区」，获取更多稳定性相干材料和常识。