SRE运维（七）错误预算和持续改进

一、SLO目标与错误预算

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

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

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

上面提到了，我们设定了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重新返回正常。同时还需要对每次严重事故（故障）进行深入调查，并建立杜绝的方针。很多时候我们大部分的错误预算主要都是消耗在个别的事故上的。这部分事故如果从工具或流程上解决掉，收益将是比较大的。