关于故障复盘、容忍度和 SLO

阅读数:4 2020 年 3 月 16 日 20:34

关于故障复盘、容忍度和SLO

黄金三问 - 如何更好的聚焦改进

故障复盘往往被我们开成了批斗会,推诿扯皮撕逼会。

原因就在于我们把故障复盘的目的搞错了,总想着找人背锅,把自己的责任撇清楚,而不是聚焦在如何改进上。

或者我们原本的目的是想着改进,但是开着开着就变了味,遇到这种情况怎么办呢?

黄金三问,转移矛盾和冲突的焦点,让我们更加聚焦如何从故障中提升和改进。

  • 第一,故障根因到底什么?

  • 第二,我们做什么,怎么做才能确保下次不会再出类似故障?

  • 第三,我们做什么,可以让本次故障时间更短,更快地恢复业务?

然后不断反复的重复三个问题,直至大家认为找到了改进的措施。

当然,大家可能还听说过 5Why 分析法,就是针对故障至少问 5 个为什么,通常就可以找到比较深层次的原因,或许不是根因,但是一定会比较有针对性了。

这个 5Why 的方式其实就是这三个问题的延伸,这三个问题会不断牵引着我们的讨论朝着本质问题深入,从我们实际实践的效果看,黄金三问效果会让讨论更加聚焦。

故障容忍度—业务优先还是稳定优先

关于这个话题,之前我们听到过很多,但是大多没有正面 PK 过。

从运维、SRE 或基础平台的同事的角度看,稳定一定是优先的,任何时候都不能放弃稳定,但是从业务同事的角度看,业务发展肯定是第一位的,没有发展,光有稳定会有什么用呢。

正好,近期碰到两个类似的交流,观点也相对一致,这里分享一下。

前段时间去 GTLC 台北分站做分享的时候,听环球易购的 CTO 乔总分享,提到了这一点。

环球易购正处于高速发展阶段,业务迭代速度快,基础设施变化也比较大,这个过程中也会遇到大大小小的故障,但是这里就有个取舍问题,到底是减缓业务开发的节奏,投入一定的时间和人力,一个个故障作分析,做改进,做好定责和绩效绑定,还是保障业务继续往前冲,提高容忍度,这个取舍怎么做?

其实就一个原则,业务在发展,能赚钱,就不要让周边这些小插曲影响了节奏,所以提高容忍度,不要在这个时候拿着故障当成了重点。

当时有个假设,如果每天能挣 10 个亿,出几个小故障又能怎么怎么样?难道非要把责任定清楚了,纳入到绩效考核里,科学管理了才行?这个时间成本怎么算?耽误的业务发展的收益怎么算?管理不好,对员工的积极性有打击,为竞争对手培养了人才,怎么办?

还有一个是前面参加 QCon 讲师演讲经验分享,跟社交大厂的总监在路上聊起来的,据说某个广告业务,虽然跟游戏比算不上最大的印钞机,但是赚钱也是哗哗滴,

所以,在他们内部貌似也没人要追着这个系统的故障问题不放,或者一定要怎么样,赚钱才是最重要的。

有的业务上去,两台主机跑起来,有自然流量进来,钱就哗哗地赚,挂了,挂了赶紧重启就行啊,别耽误赚钱就可以,据说容忍度极高。

所以,从这个两个案例来看,业务发展才是一家公司的命脉,在赚钱和故障上怎么做权衡,从上面的角度来看,就不难选择了,一定是业务优先。

当然,这里并不是说这两个业务和公司就会让故障放任自流毫不干涉,而是在业务和故障之间会有一个比较好的权衡取舍,内部仍然会有一些机制来科学地管理故障。

还有一个例外,就是对于提供基础设备和服务的厂商,如云厂商,网络设备、通信设备等等的厂商,这个没得说,一定是稳定优先,所以针对不同的特点,也要做不同的分析。

为什么需要 SLO- 故障认知标准的建立

关于 SLO 的定义这里我不做详细描述,大家可以 Google 或百度,也可以去看 Google SRE 的第二本图书,都有很详细的介绍。

这里我主要讲一下为什么需要 SLO。

SLO 的本质就是制定一个标准,使各方对稳定性和故障率形成一个统一的认知。

因为假设没有标准,大家默认稳定性就应该是 100%,我们的系统就不应该出现故障。

这个统一的认知,在我们内部可能相对比较容易建立,通过充分的沟通和讨论,大家总会形成一个可接受的 SLO 标准,但是对外部,就比较困难了。

这里我先举一个例子:

我们现在很多业务都运行在云上,也就是用了很多的云服务,比如我们的直播。

几个月前 T 云上海光缆被挖断,视频业务受到了影响,基本上 70%-80% 的视频是无法观看的,从业务特点上,是因为我们绝大部分的主播都集中在江浙沪一带,而北方和华南的主播是比较少的,所以虽然是一个局部地域的影响,对于我们来说,基本就是全局的。

不过,从云厂商的角度来看,实际的监控情况显示,一个地域的部分影响只占全局影响的 2%-3% 左右,这时对于云厂商就要判断,为了这 2%-3% 的局部影响,要不要做全局的切换动作,对于其它客户会不会造成影响等等,他就要考虑更多的因素。

所以,仅仅等这样一个决策,就花了很长时间,最终从业务角度出发和考虑,还是做了切换,保障了业务恢复。

这里 2% 对 80%,这个数字上的不一致,就是对稳定性标准认知的不统一。

这里很难界定谁对谁错,要解决这个问题,最好的方式就是引入业务 SLO,有一个统一的认知标准。这就要求云厂商要站在客户和业务角度看待问题,为业务稳定性目标负责,而不能仅仅站在自身,站在一整个大盘的角度看自己是不是有问题。

但是 SLO 的制定和约定,特别是厂商和客户之间的 SLO 制定,还是会有一些 GAP 需要填补,或者说对于云厂商的服务要求会更高。比如:

  • 云厂商的客户有很多,不同客户的标准也不一样,怎么确保这么多样性的 SLO 都能达标?

  • 没有统一的标准,很容易造成我定了 SLO,其他客户也要定 SLO,我定的 SLO 可能是非常严格的,如果不小心把 SLO 公布出来了,引起很多用户要按照这个标准提要求,这对于云厂商的压力是非常大的,这也是云厂商不敢轻易承诺的一个阻力。

  • 一旦为业务稳定性负责,必然就要有定制化的服务,定制化的服务就意味着独立的人力成本付出,这个显然是不符合云厂商的 ROI 策略的,所以落地时也很难执行到位。

所以,云厂商更多的执行 SLA 即可,没有必要去达成 SLO,其实我一直建议,SLO 的达成可以作为附加的增值服务,既然客户要求达到,那就应该付出一定的成本,因为毕竟我们是使用了厂商的专业服务能力,我想随着云计算产业的不断发展和完善,提供有价值的专业服务能力的那一天应该会到来。

本文转载自成哥的世界公众号。

原文链接: https://mp.weixin.qq.com/s/Z_wWnABDzh2BqTUzDVj7DA

评论

发布