SRE运维(七)错误预算和持续改进

2020年10月7日 发表评论 阅读评论

一、SLO目标与错误预算

SRE体系中的SLO制定有一个比较重要的原则就是需要获得利益干系者的认同。这些干系者包括但不限于产品经理、产品开发人员、运维人员。产品经理需要为用户负责,当SLO的指标值低于目标值时,显然会得不到用户的满意,不过产品经理也不能追求100%的SLO可靠性,这在上文中了有提到,因为这里要给产品开发人员和运维人员留错误预算。我们可以简单的用 SLO目标 + 错误预算 = 100% 这个公式表达错误预算和SLO目标值的关系。像我们日常提到的版本迭代、变更、故障处理(有影响用户使用体验的范围)都算在错误预算里的,其实际是SLO的反向指标。这也从侧面说明了为什么不能追求得到100%的可靠性的原因了。

上面提到了既然得到了个平衡,得到了相关利益者的认同,那我们就有了SLO目标,同时也就有了错误预算。具体可以参看下图一张图,左边就是SLO目标,右边就是分解到每个月的错误预算:

slo-wrong-budget

二、错误预算策略文档和策略的建立

上面提到了,我们设定了SLO目标,也同时获得了错误预算,这时SRE需要建立错误预算文档,并设置相应的策略。该策略文档涉及的内容如下:

服务概述:该SLO目标和错误预算适用的产品。比如是公司的IAAS层能力,还是APP产品,即使是一个APP产品可能还分前端、后端、客户端。这个要在错误文档里定义好适用范围。

目标:列出该策略的目标,比如本月(一般会在一年的指标分解到每个月,四周做一个维度是业内比较认可的一种方式)的错误预算是更多的追求功能性还是可靠性,还是说追求两者的平衡。

应对SLO失守的策略:比如定义,在某服务已经消耗了本月的错误预算目标的情况,需要停止变更和发布,向可靠性方面倾斜更多的精力。除非现在遇到的是P0最高级别的安全问题或bug,必须要进行变更升级修复的。同时对于失守的原因也进行二维划分,在以下哪些情况下必须致力于可靠性,哪些情况下可以继续进行功能性开发。这里举例说明下:比如,问题是电缆中断引起的网络问题、其他团队的服务问题引起的、压力测试或渗透测试引起的、DDOS攻击引起的等,这些情况就无需向可靠性倾斜资源了。因为这些问题可能完全运维就解决了,也不是产品本身功能性原因导致的可靠性下降。

故障应对:如果某一事件一下子消耗掉了本月错误预算的很大一个百分比,团队这时候必须要进行事后总结,寻找问题根因,并在给定的一个期限内进行问题的解决。

升级策略:因为各相关方站的维度不同,对于错误预算的计算也会存在一些差异。如果对于预定义的或者具体实施中的定义上存在差异,这时候就要进行问题升级,由产品总监、CTO进行最终决定。

在上面的内容完成后,就要将错误预算文档发给相关人员进行审批,并存放团队内部所有相关人便于查阅的地方(如内部WIKI、IM上)。同时还有记录类似于会议记要的内容:如SLO作者、评审人、审批人、批准日期、下次复审日期、SLO目标、SLI实现方式、错误预算的计算细节、消耗细节等。

在执行的时候,还要建立报表数据和仪表盘看板。报表数据里会以图表的方式列出最近几个季度选取的SLI指标和SLO的完成情况。同时给出错误预算燃尽图,百分百的预算还在已经用了多少,还剩余多少。

三、SLO目标的持续改进

SLO是用来衡量客户满意度的指标。而客户的满意度数据,我们可以从用户的评论(这里也会有意外翻车情况,例如疫情期间的dingding的评论打星值)、工单数据、投诉量、服务中断次数、故障时长等相关维进行收集。甚至可以进行用户回谈调查和采样。这些主要都是质量团队负责的内容。所以有了这些数据做支撑,我们就可以从实施成本最低的指标开始做起,并回到持续改善,产品、运维、质量的良性内部循环里去。

当然这一块儿里会有很多细节需要注意,比如某天处理了5个事件或工单,发现这5个事件消耗了20%的错误预算,另一天处理了50个事件或工单,错误预算确没有一点变化。这里就会涉及优点工作,需要对问题点和产生原因进行分析,甚至会涉及SLI、SLO设定是否合理。是需要增加覆盖面、还是更换指标、还是其他?

四、决策

SLO是基于数字化决策的,在错误预算文档就我们也对错误预算的消耗进行了相关措施的描述。在错误预算耗尽时,通常对应的策略需要停止特性发布,所有运维和开发人员投入到产品可靠性上,直到SLO重新返回正常。同时还需要对每次严重事故(故障)进行深入调查,并建立杜绝的方针。很多时候我们大部分的错误预算主要都是消耗在个别的事故上的。这部分事故如果从工具或流程上解决掉,收益将是比较大的。




本站的发展离不开您的资助,金额随意,欢迎来赏!

You can donate through PayPal.
My paypal id: itybku@139.com
Paypal page: https://www.paypal.me/361way

分类: 协同敏捷自动化 标签:
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.