寻求 SRE

第 1 章 SRE 中的情境与控制

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

与微软（前 Netflix）的 Coburn Watson和 David N. Blank-Edelman的讨论

大卫：在我们相识的这段时间里，我们有幸谈论了很多事情。我听您说过的最有趣的事情之一，就是 SRE 的工作方式是专注于提供上下文，而不是使用以控制为中心的流程（这是 SRE 更常见的实践方式）。我们能再深入探讨一下吗？您能解释一下 "情境 "与 "控制 "的含义吗？

科本我认为上下文是指提供额外的、相关的信息，让别人更好地理解特定请求或声明背后的理由。在最高级别上，Netflix 与工程团队共享的可用性相关上下文是其微服务的可用性趋势，以及与预期目标的关系，包括下游依赖关系的可用性。有了这种特定领域的背景，工程团队就有责任（和背景）采取必要措施来提高可用性。

在基于控制的模型中，团队会意识到他们的微服务可用性目标，但如果他们未能实现该目标，可能会采取惩罚措施。这种措施可能会取消他们将代码推送到生产环境的能力。在 Netflix，我们倾向于前一种模式，即共享微服务级可用性的上下文，然后在需要时与团队合作，帮助提高可用性。

我们面临的挑战是确保向团队提供足够的上下文。在 Netflix，当有人做出非理想的运营决策时，首先要问的问题是这个人是否有足够的上下文来做出更好的决策。很多时候，SRE 团队会发现，可用性受到冲击是由于传递给团队的上下文不足造成的，尤其是与可靠性相关的上下文。作为 SRE 团队，我们就是要弥补这些不足，从而提高整体可用性。

在一个非常庞大的组织中，要提供足够的上下文，使人们仅凭上下文就能实现其服务所需的可用性目标，这可能具有挑战性。在这种规模的组织中，你往往不得不依靠更多的流程来实现可用性目标。谷歌的错误预算模式就是一个例子。¹另一种更基于控制的模式适用于人命关天的情况。如果有人经常为飞机自动驾驶系统编写不安全的软件，那么这个人（和公司）可能对主要基于上下文的方法容忍度很低。如果飞机从天上掉下来，他们可不想聚在一起研究如何通过额外的上下文来提高可用性。这取决于每个 SRE 组织决定他们能承担多大的风险，这是找到基于上下文与基于控制的模式之间的分界线的一个因素。

我认为信息和上下文之间是有区别的。在系统监控中，信息可能只是一堆可用性指标，我把它们塞进仪表盘，然后通过电子邮件发送给团队。一般的工程师收到这样的邮件都会置之不理，因为：1）他们负责编写服务的业务逻辑；2）他们缺乏消化和理解以时间序列形式呈现的资源和可用性指标的专业知识。

在 Netflix，我们可以使用成千上万的运行指标。为了支持上下文驱动模型以提高可用性，我们必须将特定领域的知识应用到数据中。这就需要获取信息，并将其加工成能说明可用性的格式。通过应用这种转换，我们就能根据需要将这种上下文推送给团队，这样他们就能衡量给定微服务的可用性是否有所提高。举例来说，一个关键的可用性指标是给定微服务上依赖服务的趋势成功率（从客户端测量并根据原因分解故障率）。

我的团队并不拥有可用性，但我们的工作是随着时间的推移提高可用性。为什么？因为总有人会爆胎。很多时候，团队会主动说："我不太清楚为什么我的可用性会下降，我们能谈谈吗？在调查情况时，可能会发现有人修改了客户端库或更改了超时设置。如前所述，重要的是要从这样一个原则出发，即人们的操作并非疏忽，他们只是缺乏做出更好决定的背景。我们也不要忘记，系统可能过于复杂，避免事故所需的操作门槛过高或没有必要。动态系统中静态超时的调整就是后一种情况的一个例子。 ...