04 | 错误预算：达成稳定性目标的共识机制
落地 SLO，先转化为 Error Budget
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
SRE中的错误预算机制是如何帮助团队达成稳定性目标的？本文通过生动的比喻和实际案例，深入浅出地介绍了错误预算的概念及其在SRE中的应用。文章详细阐述了四种应用错误预算的方式，包括稳定性燃尽图、故障定级、稳定性共识机制和基于错误预算的告警。通过错误预算的量化和标准化，团队可以更直观地监控稳定性目标的达成情况，并在实际工作中推进达成共识。此外，文章还强调了跨团队沟通共识机制的重要性，以及如何衡量SLO的有效性。总的来说，本文对SRE中的关键概念和实践方法进行了全面而深入的介绍，对于想要提升系统稳定性的技术人员具有一定的参考价值。 文章还提到了如何衡量SLO的有效性，从SLO达成情况、人肉投入程度和用户满意度三个维度进行评估，进而调整和优化SLO和错误预算策略。此外，对于不同情况下的应对方式也进行了详细的讨论，包括收紧SLO、放宽SLO和保持现状，并给出了相应的策略建议。最后，文章提出了一个思考题，引导读者思考在其团队中如何制定故障等级的标准。 总的来说，本文通过具体案例和实用建议，深入探讨了错误预算在SRE中的应用，以及如何衡量SLO的有效性，对于想要提升系统稳定性的技术人员具有很高的参考价值。
《SRE 实战手册》，新⼈⾸单¥29
全部留言(24)
- 最新
- 精选
于加硕之前我们是按照故障范围来制定，例如多个服务，核心服务，网络区域，IDC等来划分等级区间。 文中提到告警这块我分下我自己实践：告警这块很多都是通过(监控产品本身优化)收敛，聚合等优化，其实还可以通过运营的角度进行优化，通过对告警信息进行多维度的统计分析，为优化指明方向，参考:https://blog.csdn.net/qq_17472959/article/details/105001854 a.面向SRE - 告警总量统计 #清晰直观的告诉SRE每天的历史总告警趋势 - 各个业务线告警数量分析(统计数量与占比) #告诉SRE我们应该去关注那条业务线的告警 - 所有服务告警数量分析(统计数量与占比) #便于服务负责人第一时间知道服务告警情况 - 所有主机告警数量分析(统计数量与占比) #便于SRE精准定位是否由于个别主机造成的告警总量上升 - 各业务线告警明细分析(以此向下展示业务维度统计结果，服务维度统计结果，主机维度统计结果，告警类型统计结果) #通过这样的层级展示，基本就理清了告警的构成 b.面向监控 - 告警类型分析(统计各类告警数量与占比) #目的告知监控系统负责人，有些监控项，或阈值需要关注与优化 c.面向研发 - 研发告警分析(统计研发名下所有项目告警数量与占比) #如果是应用造成的长期告警，需要研发关注这个，共同优化告警作者回复: 很好的补充分享，感谢。
2020-04-078
Nick文中有一段是这样描述的：“假设在 4 周的时间，这个应用所有的请求次数是 4,653,680，按照给出的 SLO 反向推导，就可以得到容许的错误次数，这就是错误预算。” 我有个疑问，4周内的总请求数是未知的，而且不是固定的，那这样错误预算无法提前制定阿？作者回复: 这是非常好的一个问题。 通常我们队业务访问量或请求次数会有一个基线设定（根据历史情况推算），也就是未来一段时间内大致会有多少请求，然后结合这个次数进行估算，最终会以实际情况计算得出。 对于电商大促这样的特殊场景，也会有一系列的复杂算法结合历史大促的情况来评估一个基线数值。
2020-04-2626
lyonger感觉先要结合自身的系统或者应用做好各种数据分析，采集好SLI相关数据。接着推动周边团队达成共识，形成规范，这个推动只能靠大佬。有了规范和数据，就可以进行量化，出了问题大家不会互相甩锅。作者回复: 运维也应该利用好数据，这个就是技术运营的思路了。
2020-03-2824- 于加硕推广SRE体系采用自上而下的方式。前提是我的上级要非常相信SRE能产出成果，于是我应该先做出一些SRE尝试的案例且取得成果，并向上影响。既而达成自上而下？目前想这么干，可行不赵老师？
作者回复: 通过小投入得到一定产出，让领导看到结果，再继续推进，循序渐进，很好的策略。
2020-04-073 
leslie老师的3种划分其实蛮典型：这其实是不少企业挺典型的。 有些可能就更加粗暴点了：硬件问题-这个不背锅，备件/备用备用都出问题-你就被背吧； 系统问题：特例且及时上报了-不背，误操作导致或者隐瞒导致问题扩大了-等着大板子吧； 软件问题：有背锅侠供应商的那就他们了，没有且解释影响使用-等着处理吧。 其实结合运维体系那门课穿插-挺好的；挺容易理解。谢谢今天的分享。作者回复: 谢谢！ 关于这个问题，我在后面的故障复盘中会写到，到底应该怎么划分责任。关键在于，定责不是为了处罚谁，而是承担改进的责任。
2020-03-2521
终身学习者我们的故障定级和业务影响相关，这个要具体和应用、业务方进行沟通，确定实际业务影响时间、范围、损失金额，然后根据制定的标准进行对应。但是沟通过程也是个麻烦事。作者回复: 在定级时是可以考虑与业务指标挂钩的，比如资金、用户量等等
2020-03-31
soong产品处于验证阶段，目前暂未有故障定级，通过学习，愈发强化了建立稳定性共识的重要性，有必要立即着手建立一套关于稳定性的运作机制！作者回复: 对于故障和问题的共识很关键，因为每个人的理解不同，这就会造成技术团队非常被动。
2020-03-31- 黑暗天使像基础服务如何定义slo，如db，缓存，消息中间件等服务，他们一般出问题，虽然一般都会反映到应用定的slo来，但一般公司应用运维应用的告警，基础服务团队接基础服务的告警，这样基础服务团队按照应用的用户体验还是几xx错误率有点行不通，这里有什么好的办法定义slo与sli么
作者回复: 很好的问题。 我在文中也讲到，如果我们本身就是负责DB、缓存和消息维护的，那这时它们的指标就是我们定义SLI和SLO的基础，定义的方法和思路仍然适用VALET方法。 我文章提到的案例大多是以业务系统举例，所以我们更强调从用户使用体验的角度出发。
2020-03-26 
lhc故障定级确实有点难。可分为几类情况 交易强相关: 定级严格，如客诉超过10并且成功率持续（5分钟）时间小于80%并且错误码大于20 定为pX，其他类似。 资金相关:涉及到资损，大于500小于1000 p4，大于1000 p3等等 接囗:根据成功率加错误码的持续时间来定。 故障定级一定要拉上各方一起定级，定的太高太低都不太好。作者回复: 从业务角度，用钱的损失来定是最直接的，从系统角度，用技术术语来定会更有针对性，这两者不矛盾。 故障定级确实是比较复杂的，需要与周边达成一致才可以。
2020-03-25- Helios我们公司没啥故障定级，在客户内部署之后，如果遇到问题反馈给我们，然后开发反馈要多长时间能修复或者客户要求多长时间修复，等修复之后给客户一个补丁包😂 如果收到客户反馈必须要修复的问题，我们一般就是最高优先级，如果是能在下一个迭代中解决，那就在下个迭代中解决。 故障评级个人感觉主要是为了给一个响应的优先级（还有后续追责～），对于我们这种业务，目前只有一种优先级感觉还挺适用，请问老师有什麽建议没～
作者回复: 跟客户也可以达成一致，就是在什么情况下紧急，什么情况下不紧急，也就是跟客户也可以定SLO和Error Budget，这个策略其实就是Google的CRE策略。 我第一门课中有专门的一个章节是介绍CRE的，可以翻出来看一下。
2020-03-25
