我以前的文章,我写了关于使用SLIs和SLOs以度量形式捕获用户幸福感的文章,最终目标是提供最佳的软件可靠性水平,使用户幸福感最大化。

在这篇文章中,我将探讨如何使用错误预算以数据驱动的方式进行谈判,如何在创新和可靠性以及风险和稳定性之间进行权衡。

哪些系统是不可靠的

系统可能因为“照常运行”(Business-As-Usual, BAU)而变得不可靠(和不可用)。就像人类仅仅通过生活产生灰尘一样,工程师仅仅通过编码产生bug。其他BAU事件包括硬件/电源/网络故障由可爱的,毛茸茸的或有羽毛的朋友引起的或者第三方依赖失败。

这就是错误预算的作用:测量可接受的系统不可靠性水平.有这样一种东西太多的可靠性这可能是件坏事。每个。9增加10倍的成本

错误预算的需要

一切都是一种权衡。产品性能评估使用速度而平台性能的评估使用可靠性

创新速度与产品稳定性之间存在结构性冲突。错误预算的产生是由于我们观察到100%基本上是错误的可靠性目标(起搏器和防抱死刹车是明显的例外)。如果100%是错误的系统可靠性目标,那么,什么才是正确的系统可靠性目标呢?这实际上根本不是一个技术问题,而是一个产品问题考虑到用户使用产品的方式,他们会对什么级别的可用性感到满意?对产品的可用性不满意的用户有什么替代方案?在不同的可用性级别上,用户对产品的使用会发生什么变化?

谷歌都是书

产品/工程和业务必须不断地在两者之间进行平衡增值由新功能和失去了价值通过漏洞、中断、技术债务等。

“错误预算”是一种数据驱动的方式,用来说服领导层进行投资发展速度从长远来看意义:

  • 在下一个计划周期中,什么时候为bug和事后行动设定优先级。
  • 何时实现自动化、监控、可观察性。

就像家庭预算一样,如果我们有钱,我们可以把它花在新功能上,如果没有,我们必须减少我们的创新开支。

查看错误预算耗竭率和管理超支的钱一样有用。

如果利率是> 1,我们消耗预算的速度比我们应该的要快,我们会陷入债务。

我们也可以设置特殊类型的错误预算,但这通常都是一个糟糕的信号,我们应该仔细分析为什么要使用它们。

  • 雨天基金意想不到的事件。
  • 银子弹“关键的”新功能。

误差预算方程

的时间来检测(运输大亨)

从用户受到问题影响到有人被告知这个问题所花费的时间。

解决问题的时间(竞技场队伍)

从某人被告知一个问题到这个问题被解决所花费的时间。

失效到达时间/故障间隔时间(TTF转发/延长)

某一特定故障的频率。

当它们前面有个M,也就是到X的平均时间,他们是平均的。

错误预算= 1 -可用性目标

上面的公式告诉我们如何减少不可用性,从而增加可用性。

1.减少的时间来检测
  • 更快地监视和警报捕获中断。
2.减少解决问题的时间
  • 让它更快地与优秀的开发人员Runbooks进行故障排除。
  • 改善消防原木。
  • 添加痕迹。
  • 自动化故障转移,比如重定向流量或备份。
3.减少的影响
  • 限制逐步转出所影响的用户数量。
  • 使用特性标志增加可逆性。
  • 实现优雅的降级,例如断路器模式,节流请求,限制重试调用与指数回退,设置客户端超时,限制队列。
3.增加失效到达时间
  • 分析和理解故障原因。
  • 积极主动地进行维修工作。

一个好的错误预算政策的属性

由于错过了SLOs表明用户不高兴,因此拥有一种机制来加强对工程工作的投资以提高可靠性是符合业务利益的。

这种机制是由错误预算政策提供的,它概述了可靠性和特性工作之间的权衡。执行和遵循错误预算政策不仅会增加可靠性和客户满意度,还会减少团队内部的灭火和指责。这是一个双赢的局面。

错误预算可能适用于组织中的多个服务和团队。最好将其保存和维护在一个高度可见的位置,并将其作为元数据存储在SLO定义旁边(例如作为链接)。

一个好的错误预算政策有七个属性:

如果错误预算已耗尽或受到威胁,则Policy应该能够实施工程的努力重新安排提高可靠性的特性的优先级。

政策应该澄清这一调整何时生效例如,当预算接近枯竭时。

它描述了团队将如何优先考虑可靠性工作.例如,如果预算受到威胁但没有耗尽,那么就会分配一两个开发人员来修复相关事后分析中的所有优先级问题。另一方面,如果预算已经连续几个月耗尽,也许整个开发团队应该只专注于可靠性工作,直到预算补充到一个令人满意的水平。

为了执行一个政策,它必须带来重要的后果和风险吗年代如果可靠性没有发挥作用。在一天结束的时候,这项工作是需要满足客户的幸福。如果不这样做,公司的核心价值最终就会失败。

这一政策应该在整个团队中一致地应用吗.可能会有一两个例外,如《银弹》,因为潜在的违约或意外的营销机会。然而,“银弹”应该被视为特殊情况,并在事后解释如何在未来避免这种情况。

这一政策需要一个最终的所有者和决策者因为各方(如产品和工程团队或不同的开发团队)之间的分歧总是会发生。

人们很难坚持自己不喜欢的政策。然而,一旦所有相关方(产品经理、开发人员、SREs、高管等)提供了经过分析并纳入政策的反馈,每个人都应该遵守这一政策为了显示实际的结果。

预算政策

错误预算政策场景和升级的例子

谷歌的CRE生活课程-应用升级政策有四个场景说明了如何为希望获得“3个9”可用性但将一半的错误预算用于背景错误的服务应用策略阈值。

CRE风险分析模板示例

一个风险矩阵在计算风险水平时,是否可以考虑概率(可能性、频率)严重(影响)的一个事件。其目的是增加风险的可见性和协助管理决策。

了解你的敌人:如何区分风险的轻重缓急和沟通风险——cre人生课程

应用于SRE的一般风险矩阵的缺点变得显而易见:

  • 停工期几分钟是“灾难性的”吗?这要看情况,很可能是的,在预期可用的4个9,但不是那么多,在2个9。
  • 什么是更容易管理的:发生灾难性但极其罕见的故障,还是频繁但最小的故障?

当我们应用上述概念时,我们对实际的SLO环境中的风险有了更清晰的认识:

  • 可能性用平均故障间(MTBF)来衡量
  • 影响平均恢复时间(MTTR)
  • 可接受的风险是由错误预算设定的吗
  • 可用性目标是由SLO设定的吗

有了这些,我们可以通过在一段时间内以分钟为单位估计损失,创建一个风险目录。我们使用过去的数据和我们的直觉为MTBF(天)和MTTR (SLO的分钟数)分配可接受的值。我们可以使用交通灯系统来直观地突出风险排名:

  • 红色的风险是不可接受的.我们需要立即投入工程工作,因为这些工作超出了单个风险的误差预算,并且可能在单个事件中对可靠性产生重大影响。
  • 琥珀的风险亟待解决因为,虽然不是关键,但他们是我们错误预算的一个大消费者。然而,如果有足够的预算,他们是可以容忍的。
  • 绿色风险是可以接受的因为他们不是我们错误预算的主要消费者,即使是总体上,也不要超过错误预算。当我们想要“回购”一些预算以接受更难消除的琥珀风险时,我们可能需要解决这些问题。

最后,下面提供了这类CRE风险分析的电子表格模板,以供进一步帮助。你可以为你自己的目的复印一份.您可以使用上述策略来降低“风险目录”表中的ETTD、ETTR、ETTF和影响,或更改“风险堆栈排名”下的“目标可用性”。

Baidu