如何做一场高质量的复盘

avatar
@哈啰

开启掘金成长之旅!这是我参与「掘金日新计划 · 12 月更文挑战」的第1天,点击查看活动详情

正视故障和复盘的意义

故障也有积极意义

在复杂系统中,故障是必然的,无法彻底避免。从定性的角度来看,并非所有的故障都是坏事,有些故障是有正面意义的,比如说通过一个线上的小故障发现了一个大隐患,或者是某次故障中相关人员的意识和应急预案都很到位,但是由于故障的原因非常特殊最后仍然造成了较大的影响等等,类似这样的故障都要找出其中的亮点。

所以,我们要用辩证的眼光去看待,避免大家“闻故障色变“。为了往这方面引导,我们在规章制度方面也做了很多设定,因此在我们的故障管理制度上,我们也是鼓励快速恢复(对于快速恢复的故障定级比较低)、鼓励通过演练发现更多的线上问题(对于由于演练导致的故障有一定的豁免权)等等。但是,大家也应该充分意识到我们对故障的理念:即偶尔的系统失效是可以容忍的,人为的犯错是要严肃对待的,比如说不符合高可用规范的系统设计模式、强弱依赖设计不合理、由于人员意识不到位带来的故障处理时间较长、值班人员未及时接通oncall、由于对线上系统不够重视带来的变更隐患、不遵守变更三板斧规范等等。

复盘的3个目的

复盘的目的是为了总结和改进,要充分利用好每一次故障的机会,从中汲取教训进行学习,提升我们的经验,完善系统的设计,我们希望达到三个目的:

  • 找到根因,从根本上进行优化和改进,给他人带来参考,未雨绸缪。
  • 找到降低故障发生概率的方法 - 增大MTBF。
  • 找到让业务快速恢复的方法 - 缩短MTTR。

系统和组织都要高可用

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

复盘的整体过程

image.png

复盘前的准备

故障参会方

  • 直接原因方、关联(受影响)方必须全部参与,在复盘文档中记录参会人员名单。
  • 时间线提前梳理清楚,做了哪些操作,产生了什么结果等,先与相关人员提前梳理清楚,关键信息通过截图等进行佐证。

复盘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):从故障恢复之后到确认故障已经解决的时间,一般通过用户反馈、自动化测试等确认恢复。

image.png

因此在回放时间线的过程中,也要注意对以下几个关键时间点进行识别,然后逐个沟通讨论如何缩短其中的每一个环节耗时。

需要注意提前识别出来的关键时间点:

  • 故障引入时间点: 即这个故障实际上是从什么时候开始的,可能是某次变更发布/线上操作/其他等。
  • 业务指标变化时间点: 业务指标开始下跌、开始恢复等。
  • 监控告警发出时间点: 即监控是从什么发现异常的,告警什么时候发出的。告警的级别、接收人是否响应超时等相关信息都要记录进来。
  • 人员介入响应时间点: 故障对应的系统值班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(处理),对于我们的故障复盘来说,即所有的改进事项都必须经过故障演练,通过实战演练来确保改进计划一定是有效的。

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

image.png

在复盘过程中,可能很多参与的同学由于经验或者背景不一样,大家对故障的理解不一定一致,那么复盘的owner要多问一些问题,来引发大家的讨论和思考,从以往的经验中,我们总结了几类问题,大家可以把这个作为讨论的框架:

1.故障的根因是什么,它是如何影响业务可用性的?
当前我们在聊的这个是根因吗?从业务场景对应的链路上看,这个系统(组件)是强依赖吗?依赖是否合理、有无兜底机制。这次的变更流程是否完善、三板斧落实的是否到位。对应的观测指标是否能反应系统的真实状态,应急策略是否有效等等。

2.故障为什么会发生,可以避免或者降低发生概率吗?
也就是所谓的提升MTBF,如果是变更引起的,那么要考虑变更流程是否完善,是否按照流程规范操作,有无对应的防御机制。如果是某个系统组件失效导致的,那么要评估该组件的可用性是多少,与它所在的链路是否匹配,这条链路是否要设计兜底方案等。如果是外部原因引起的,那么我们对外部的这个依赖是否有过认真的评估,对方的可用性能够满足我们的诉求。

3.我们应该做什么,才能更快地恢复业务?

  • 监控告警 - 这个故障是如何被发现的,监控告警是否完善,我们能否更快地发现这个问题。
  • 管理制度 - 人员值班响应oncall是否及时,关键人员是否就位,关键岗位有无backup机制,系统owner对负责的组件是否足够熟悉。
  • 定位效率 - 现有的排查工具是否好用,有无需要优化的地方,故障定位的时间能否再缩短一点,故障的处理原则是以止血恢复优先,当时的故障处理过程中,有无跑偏方向。
  • 应急预案 - 故障处理过程中,是否有应急预案,应急预案是否奏效?日常是否通过故障演练来验证应急预案的有效性。
  • 架构设计 - 架构本身的高可用是否完善,是否具有容灾能力。
  • 流程规范 - 现有的制度规范是否完善,有无需要优化的。

故障定责

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

定责对应的首先是团队,其次是个人

很多故障只是表象,大部分根因深挖下去,都会有技术管理的因素,虽然引发故障的操作可能是个人,但是更应该从团队的视角去看问题,避免把根因只归结到某个人身上。

鼓励快速止血和积极参与

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

第三方默认无责

即谁引入了第三方的技术组件,谁就要对其可用性负责。即我们在使用外部技术组件的时候,要仔细评估对方的可用性情况,以及我们的兜底方案等等。

红线和军规

红线和军规是我们的底线,坚决不能违反。现在的很多条款,都是以往的各个故障中沉淀出来,我们必须遵守且尊重这些红线军规,把它当做我们研发人员的铁律。

对于重复的错误必须严肃

对待未知的故障不可怕,可以用来丰富我们的稳定性建设经验,但是重复的踩坑就需要认真对待了,要思考为什么以往的改进事项没有落实到位、是否人员意识需要加强、对稳定性的重视度不够等等。

复盘不是故障的结束,改进事项经过验收才算彻底结束,因此每一个改进事项的相关方,都应积极主动push完成。同时,我们要最大化利用好复盘文档的价值,如可以考虑新人入职后,组织学习以往的复盘文档,吸收前人经验,避免重复踩坑。

很多问题背后都是一系列的原因,在复盘的过程中,除了唯一根因,还要把关联的原因和问题一起来看,避免头痛医头脚痛医脚的情况,争取能够体系化的解决问题。

(本文作者:孟闯)