重要 SRE 原则和做法:良性循环

已完成

如果在某种程度上“你即你所为”确实是对的,那么我们就已触及本模块的核心。 本单元将介绍两种通常被认为是 SRE 核心做法的做法。 这两种做法都源于务必要形成“良性循环”的原则。在这种情况下,良性循环是指在组织中构建有助于组织持续改进的反馈循环的做法。 将有完整的模块确切讲解这两种做法,因此本单元仅蜻蜓点水般地概述每种做法。

良性循环 1:SLI 和 SLO

本模块的前述部分重点介绍了实现“适当的可靠性级别”。 这一部分正是要引入相应概念的地方。

假设你正计划要将一项新服务投入生产,可能是已构造的服务,也可能是仍在计划过程当中的服务。 在此过程中,务必要对所需的可靠性做出一些决定。 如果不是所有代码都是你自己编写的,请与编写相应代码的开发人员共同做出这些决定(这一点至关重要)。

要做出的第一个决定是,应该用什么作为服务运行状况的指标(即“服务级别指标 (SLI)”)? 这个问题的另一种问法是,“如何判断服务何时在运行且运行良好?”。 有很多方法可以跟踪 SLI,我们稍后会详细探讨一些方法。 但是,以下指标是很典型的:

  • 成功与失败的度量。 服务是否在一定比例的时间内成功完成了操作?
  • 时间的度量。 我们是否在特定的时间阈值内返回了答案?
  • 吞吐量的度量。 我们是否处理了一定量的数据?

或者,所有这些度量的某种组合。

举个简单例子,可以说服务 SLI 是返回由 HTTP 200 代码(而不是 500 或其他一些代码)表示的成功状态的频率。

至此,已有了解服务运行状况的明确指标。 我们要决定的是预期或所需的可靠性级别。 例如,是否期望服务在一天内的故障率为 20%? 之所以使用较大的整数是因为,这样便于一开始轻松推算它们。 后面的模块将提高陈述的复杂性和精确度,例如“哪些用户会看到错误率?是部分用户,还是大多数用户?”等。 与服务开发人员共同建立的这种可靠性预期就是服务级别目标 (SLO)。

必须能够在监视系统中准确度量和表示 SLO。 多大数值才够好呢?这应该是一个客观且易于理解的服务可靠性目标。 不得有下面这样的说辞:“好吧,我认为这项服务在过去一周左右的时间里一直没问题,但具体怎样很难说”。 服务要么实现 SLO,要么没有实现。数据应该很明确。 如果服务没有实现 SLO(特别是在一段时间内反复这样),表示服务出现了问题,需要进行解决。

误差预算

组织可能会在服务未实现 SLO 时立即采取行动,这可以理解。 但 SRE 又将这整个概念进一步细分为,实现 SLO 或超出 SLO 这两种情况。 一些组织使用 SLO 构造所谓的“误差预算”。

为了阐明此概念,我们将以一直在讨论的示例服务为例,它的 SLO 为 80% 成功率(可视为“正常运行时间比例必须达到 80%”)。 在 SLO 为正常运行时间占 80% 的情况下,我们已声明服务的正常运行时间比例必须达到 80%。 而剩下的 20% 时间又如何呢? 对于剩下的 20% 时间,我们并不真正“关心”,因为已决定额外的 20% 正常运行时间对我们实现服务目标并不重要。

那么,如果我们不关心这段时间内发生了什么,该如何改进服务呢? 一定可以做的一件事是,通过升级服务来更新正在运行的服务,可能是升级到增加了一些功能的新版本。 如果新版本很坚挺且不增加任何故障时间,那就太好了。 如果新版本导致服务稳定性降低,且在调试时返回错误的时间耗费了 10% 的正常运行时间,也仍能接受。 我们在允许的不可靠性预算范围内。

误差预算是指,服务可能的理想可靠性与所需可靠性之间的差异 (100% - 80% = 20%)。 在这种情况下,误差预算提供了 20% 的不可靠性预算,即在 20% 时间内我们“不关心它是否在运行,因为它仍然符合规范”。 可根据需要随意利用并支出这 20% 的时间(可能是发布更多版本),直到它像其他任何预算一样耗尽时为止。

一些组织也将误差预算用于不太理想的情况,即没有实现 SLO 的情况。 在这种情况下,可选择采取一些比“采取措施”更严格的行动。 假设服务存在一些问题,之前选择的 SLI 表明,服务的正常运行时间只占 60%。 也就是说,并没有实现目标 (SLO)。 服务已耗尽误差预算。 组织可能会选择搁置计划发布,因为它知道如果此时进一步更新系统,可能只会导致可靠性情况变得更糟。 通常,错误预算是针对设定的时间段(月份、季度等)计算的。 因此,在不断滚动的基础上,如果服务可靠性提高,最终将返回该预算。

在封闭发布期间,组织可能会选择让一些工程资源从功能开发转向可靠性工作。 目标是帮助发现并改善导致服务未实现 SLO 的问题根源。

在误差预算方面,之所以会说“一些组织”是因为,实现(特别是在用于封闭发布的情况下)需要一定的机构支持。 当面临发布决定时,如果服务可靠性迄今尚未达到正常水平,组织必须愿意推迟发布。 并非所有组织都愿意做出这一决定。 这种决定也不是对已耗尽误差预算的唯一可能反应,但却是最常提到的反应。

我们将在一个单独的模块中更详细地介绍 SLI、SLO 和误差预算。 但在这里强调这些做法的良性循环一面也是值得的。 从理论上讲,这样一来,组织可以描述、沟通和努力实现服务可靠性。 同时,以一种让每个人都朝着提高可靠性的方向努力的方式来做这件事。 这种反馈回路非常重要。

良性循环 2:无责备事后调查

事后调查的概念是对通常不良的重大事件进行回顾性分析,甚至根本不是网站可靠性工程所特有。 对于运营领域来说,这种概念并不罕见。 更与众不同的一点是,SRE 坚持必须执行“无责备”事后调查。 需要关注事件期间的流程或技术故障,而不是特定人员的操作。 “现有流程中的什么让 X 的操作导致故障发生? 这个人缺少什么信息或甚至被强调了什么信息,导致其在关键时刻得出错误结论? 应制定哪些保护措施,才能杜绝此类灾难性故障再次发生?” 这些是在无责备事后调查中提出的问题种类。

这些问题的基调和方向至关重要。 我们寻求的是改进系统或进程的方法,而不是如何惩罚对系统或进程执行善意操作而导致故障发生的个人。 请务必记得,“解雇员工是不可能实现可靠性目标的”。 根据我们的经验,每次发生生产事件就解雇员工的组织,无法从这些事件中汲取经验教训(很少有例外)。 结果反而是,仅剩的一位员工躲在角落里瑟瑟发抖,害怕对任何事情做出任何改变。

不过,组织中运作良好的事后调查流程会形成良性循环。 这样一来,组织可以从故障中汲取经验教训,并不断改进系统(前提是完成适当分析和跟进工作)。

组织欣然接受将这种与故障和错误的关系作为学习和改进的机会,是网站可靠性工程的核心原则。 形成良性循环以便利用这些机会让组织提高可靠性是另一核心原则。

下一单元将探讨其他一些以 SRE 的人性面为主的原则和做法。

知识检查

1.

SLI 的全称是什么(在 SRE 上下文中)?

2.

SLO 的全称是什么(在 SRE 上下文中)?

3.

如果耗尽了服务的误差预算,该怎么办?

4.

如果超出了服务的误差预算,该怎么办?

5.

发生故障或其他事件时,是否应立即终止所涉及的人员?