关于故障:如何做一场高质量的复盘

正视故障和复盘的意义

故障也有积极意义

在简单零碎中，故障是必然的，无奈彻底防止。从定性的角度来看，并非所有的故障都是好事，有些故障是有侧面意义的，比如说通过一个线上的小故障发现了一个大隐患，或者是某次故障中相干人员的意识和应急预案都很到位，然而因为故障的起因十分非凡最初依然造成了较大的影响等等，相似这样的故障都要找出其中的亮点。

所以，咱们要用辩证的眼光去对待，防止大家“闻故障色变“。为了往这方面疏导，咱们在规章制度方面也做了很多设定，因而在咱们的故障管理制度上，咱们也是激励疾速复原 (对于疾速复原的故障定级比拟低)、激励通过演练发现更多的线上问题(对于因为演练导致的故障有肯定的豁免权) 等等。然而，大家也应该充沛意识到咱们对故障的理念：即偶然的零碎生效是能够容忍的，人为的犯错是要庄重看待的，比如说不合乎高可用标准的零碎设计模式、强弱依赖设计不合理、因为人员意识不到位带来的故障解决工夫较长、值班人员未及时接通 oncall、因为对线上零碎不够器重带来的变更隐患、不恪守变更三板斧标准等等。

复盘的 3 个目标

复盘的目标是为了总结和改良，要充分利用好每一次故障的机会，从中吸取教训进行学习，晋升咱们的教训，欠缺零碎的设计，咱们心愿达到三个目标:

• 找到根因，从根本上进行优化和改良，给别人带来参考，防患未然。
• 找到升高故障产生概率的办法 – 增大 MTBF。
• 找到让业务疾速复原的办法 – 缩短 MTTR。

零碎和组织都要高可用

每一次的线上故障，也是实战练兵的好机会，除开零碎自身的高可用，咱们的组织也应该是高可用的，咱们常常说好的零碎架构是具备韧性的，那么好的团队组织也应该是反软弱的。所以复盘的过程中，除了找零碎自身的问题，还要找工具的问题、流程机制的问题、治理的问题等等。这样，咱们能力由点及面的系统化地解决问题，即治本又治标。

复盘的整体过程

复盘前的筹备

故障参会方

• 间接起因方、关联 (受影响) 方必须全副参加，在复盘文档中记录参会人员名单。
• 工夫线提前梳理分明，做了哪些操作，产生了什么后果等，先与相干人员提前梳理分明，要害信息通过截图等进行佐证。

复盘 owner

每个复盘会议，都必须有惟一的复盘 owner，故障的复盘 owner 要被动疏导大家，推动复盘进度，避免出现一些无意义的指摘、与故障无关的发散探讨等等。

理念宣导

• 提前申明：摆正心态，防止甩锅、批评
  故障复盘的目标是为了探讨问题，找出改良计划防止再次踩坑。最重要的是要敞开心扉，无所顾虑的裸露问题。会议开始前当时申明复盘探讨的主题、目标。要尽量对事不对人，防止造成对某一方的批评会。
• 营造良好的复盘气氛
  诚恳：基于事实，敢于抵赖本人的问题；
  凋谢：对事不对人，在尊重别人的前提下，每个人都能够充沛分享本人的观点与认识；
  担当：每个团队或集体先从本身找问题，被动提出本人须要改良的中央。

复盘的关键环节

故障背景概述

故障的背景要解释分明本次故障复盘的背景，即产生了什么故障，影响了什么业务 (产品) 等故障的根本状况。在复盘文档中，能够通过结构化的语言进行表白。例如：“x 月 x 日 xx 时，xxx 零碎出现异常，导致了 xxx，影响了 xxx 业务，表象为用户无奈失常下单，点击下单按钮呈现网络开小差，呈现了大量客诉等等”。故障背景的意义在于让他人第一眼理解分明这个复盘的前因后果，根因能够不必写太多，上面会有根因环节。

对齐故障影响范畴

讲清楚本次故障的影响范畴，包含影响时间段、影响的业务 (产品) 线、影响的零碎(服务)、订单量、用户量、客诉量，以及有无产生资损等等。故障工夫线回放晋升系统可靠性的两个要害伎俩：升高故障产生概率和缩短故障持续时间。回放故障的工夫线，即先从旁观者的角度来理一遍故障过程，是为了思考如何缩短故障持续时间(MTTR)，MTTR 即故障的均匀修复工夫，咱们对 MTTR 其进行拆解，失去如下几个时间段:MTTR = MTTI + MTTK + MTTF + MTTV。

• Mean Time To Identify (MTTI): 从故障开始到应急响应染指的工夫，个别是考查监控告警、人员值班 oncall 的合理性。
• Mean Time To Know (MTTK): 从应急响应染指到故障定位的工夫，次要考查根因剖析、可观测性等工具的能力。
• Mean Time To Fix (MTTF): 从故障定位到故障复原的工夫，次要考查应急预案、快恢体系的能力。
• Mean Time To Verify (MTTV): 从故障复原之后到确认故障曾经解决的工夫，个别通过用户反馈、自动化测试等确认复原。

因而在回放工夫线的过程中，也要留神对以下几个要害工夫点进行辨认，而后一一沟通探讨如何缩短其中的每一个环节耗时。

须要留神提前辨认进去的要害工夫点:

• 故障引入工夫点: 即这个故障实际上是从什么时候开始的，可能是某次变更公布 / 线上操作 / 其余等。
• 业务指标变动工夫点: 业务指标开始上涨、开始复原等。
• 监控告警收回工夫点: 即监控是从什么发现异常的，告警什么时候收回的。告警的级别、接管人是否响应超时等相干信息都要记录进来。
• 人员染指响应工夫点: 故障对应的零碎值班 owner 是从什么时候开始响应的。
• 异样定位工夫点: 即定位到故障的异样点，留神: 故障处理过程中的根因定位，并非是最底层的根本原因，而是指初步确认了故障的异样点，能够进行下一步的应急止血动作。
• 要害操作工夫点: 是否做了一些应急预案，包含重启、复原、止血、高可用配置等。还须要写分明每个操作的后果，即每个操作之后，报错面有无放大、系统资源水位有无变动等。
• 确认故障复原工夫点: 通过测试验证或者观测业务指标、系统日志等确认零碎曾经复原。

深挖根因

个别状况下，故障是由两类起因引起的，包含间接 (诱发) 起因和根本原因，也就是所谓的诱因和根因。

因而在复盘过程中，既要明确诱因，更要深挖根因。比如说，某个业务零碎由 A /B/C 3 个服务组成，依赖关系顺次是 A 依赖 B、B 依赖 C，某次开发同学批改了线上 C 服务的一个配置，应用了谬误的格局，导致了整个业务零碎不可用。那么在起因剖析过程中，把配置文件批改为谬误的格局这个动作必定是间接起因，然而也要留神，B 服务对 C 服务的依赖关系是强依赖么？如果 C 服务出现异常的状况下，B 服务是否要进行兜底？等等。

能够基于 5why 分析法深挖根因，多问几个为什么，层层递进，比如说这样的一个场景: 线上零碎运行过程中，某个 ES 节点忽然抖动，RT 工夫显著变长，95 线由 200ms 升至 800ms，而后引发了上游业务异样。

那么在剖析起因的时候，要问以下几个问题:

• 为什么 ES 会抖动？
• ES 的可用性规范是什么？
• ES 抖动之后，有呈现告警吗？相干人员有第一工夫染指解决吗？
• ES 抖动之后，上游间接应用它的服务有兜底措施吗？是否为强依赖？
• 对于这个业务场景来说，ES 的间接上游零碎是这条链路的外围依赖吗，从整个链路上有无兜底机制？

要层层递进深挖根因，千万不要浅尝辄止，那样可能会错过真正的改良事项。从以往的故障来看，很多问题背地都是零碎设计的问题，这样的问题挖得越深，咱们的零碎可用性才会越强，能力缓缓朝咱们现实中的高可用架构后退。

改良项汇总

把工夫线和根因别离确认分明之后，就能推导出咱们对于本次故障复盘的改良事项了。在梳理改良事项的时候，除了与故障相干零碎的改良项之外，还须要从整个故障处理过程来看，在故障的各个环节中有无须要优化改良的中央。

比如说某个故障是靠人工 (用户投诉) 发现的，那么要思考下这个业务的监控告警是否欠缺，是否可能升高故障触达工夫；比如说某个故障的告警收回之后，迟迟没有人响应，那么要从管理制度来看，对于应急值班政策的执行是否到位；比方某个故障的排查过程中，定位比拟苦难，很多中央要靠人工去梳理很多信息，那么要思考相应的排障工具是否好用、应急预案机制是否欠缺等等。

还有很多的问题，大家能够参考下面的 MTTR 合成环节和故障根因合成环节，本人开展思考下，这也是下面说要深挖根因和详细分析工夫线的目标，这样咱们能力不节约每一次故障的机会。

在记录改良项的时候，能够思考联合 SMART 准则来设计改良项:

• S – 必须是具体的（Specific），改良项必须是能够落地的，不要泛泛而谈，例如”优化零碎设计“这类就属于反例。从新设计 A 系统对 B 零碎的依赖关系，使其可能对异样进行兜底，这种就属于具体的。
• M – 必须是能够掂量的（Measurable），即改良项是能够评估的，比如说通过故障演练来测验依赖关系的有效性。
• A – 必须是能够达到的（Attainable）, 在以后的技术环境下，这个改良项是可行的，不要写将来太远的无奈达到的事件。
• R – 与其余指标具备肯定的相关性(Relevant)，能够了解与本次故障中其余改良项有关联性。
• T – 必须具备明确的截止期限（Time-bound），要写分明改良项的截止工夫，在到期之后进行验收。

最初，改良事项重在闭环，这个环即 PDCA 循环，Plan（打算）-> Do（执行）-> Check（查看）-> Act（解决），对于咱们的故障复盘来说，即所有的改良事项都必须通过故障演练，通过实战演练来确保改良打算肯定是无效的。

复盘过程中的几个关键问题

在复盘过程中，可能很多参加的同学因为教训或者背景不一样，大家对故障的了解不肯定统一，那么复盘的 owner 要多问一些问题，来引发大家的探讨和思考，从以往的教训中，咱们总结了几类问题，大家能够把这个作为探讨的框架:

1. 故障的根因是什么，它是如何影响业务可用性的？
以后咱们在聊的这个是根因吗？从业务场景对应的链路上看，这个零碎 (组件) 是强依赖吗？依赖是否正当、有无兜底机制。这次的变更流程是否欠缺、三板斧落实的是否到位。对应的观测指标是否能反馈零碎的实在状态，应急策略是否无效等等。

2. 故障为什么会产生，能够防止或者升高产生概率吗？
也就是所谓的晋升 MTBF，如果是变更引起的，那么要思考变更流程是否欠缺，是否依照流程标准操作，有无对应的防御机制。如果是某个零碎组件生效导致的，那么要评估该组件的可用性是多少，与它所在的链路是否匹配，这条链路是否要设计兜底计划等。如果是内部起因引起的，那么咱们对外部的这个依赖是否有过认真的评估，对方的可用性可能满足咱们的诉求。

3. 咱们应该做什么，能力更快地复原业务？

• 监控告警 – 这个故障是如何被发现的，监控告警是否欠缺，咱们是否更快地发现这个问题。
• 管理制度 – 人员值班响应 oncall 是否及时, 要害人员是否就位，要害岗位有无 backup 机制，零碎 owner 对负责的组件是否足够相熟。
• 定位效率 – 现有的排查工具是否好用，有无须要优化的中央，故障定位的工夫是否再缩短一点，故障的解决准则是以止血复原优先，过后的故障处理过程中，有无跑偏方向。
• 应急预案 – 故障处理过程中，是否有应急预案，应急预案是否见效？日常是否通过故障演练来验证应急预案的有效性。
• 架构设计 – 架构自身的高可用是否欠缺，是否具备容灾能力。
• 流程标准 – 现有的制度标准是否欠缺，有无须要优化的。

故障定责

故障定责每个公司都有对应的定责制度，这里不开展太多，只写几个要害的观点。

定责对应的首先是团队，其次是集体

很多故障只是表象，大部分根因深挖上来，都会有技术治理的因素，尽管引发故障的操作可能是集体，然而更应该从团队的视角去看问题，防止把根因只归结到某个人身上。

激励疾速止血和积极参与

对于故障处理过程中，积极参与定位、止血等操作的，给予侧面的必定。

第三方默认无责

即谁引入了第三方的技术组件，谁就要对其可用性负责。即咱们在应用内部技术组件的时候，要认真评估对方的可用性状况，以及咱们的兜底计划等等。

红线和军规

红线和军规是咱们的底线，坚定不能违反。当初的很多条款，都是以往的各个故障中积淀进去，咱们必须恪守且尊重这些红线军规，把它当做咱们研发人员的铁律。

对于反复的谬误必须庄重

看待未知的故障不可怕，能够用来丰盛咱们的稳定性建设教训，然而反复的踩坑就须要认真对待了，要思考为什么以往的改良事项没有落实到位、是否人员意识须要增强、对稳定性的器重度不够等等。

复盘不是故障的完结，改良事项通过验收才算彻底完结，因而每一个改良事项的相干方，都应积极主动 push 实现。同时，咱们要最大化利用好复盘文档的价值，如能够思考新人入职后，组织学习以往的复盘文档，排汇前人教训，防止反复踩坑。

很多问题背地都是一系列的起因，在复盘的过程中，除了惟一根因，还要把关联的起因和问题一起来看，防止头痛医头脚痛医脚的状况，争取可能体系化的解决问题。

（本文作者：孟闯）

本文系哈啰技术团队出品，未经许可，不得进行商业性转载或者应用。非商业目标转载或应用本文内容，敬请注明“内容转载自哈啰技术团队”。