站点可靠性工程：Google 高可用性和快乐运营的秘诀

希望不是一种策略
——传统的 SRE 说法

我读过《网站可靠性工程——谷歌如何运行生产系统》这本书。我从中学到了很多，也汲取了很多好的实践经验，并应用到我们自己的服务中。以下是这本书的要点以及我从中学到的东西。我将重点介绍 Web 开发者可以从 SRE 中学到什么，而不会深入探讨谷歌基础设施的复杂性。

在深入探讨之前，需要先声明一下：在Marmelab，我们不在生产环境中运行客户的服务。我们的专长是通过敏捷迭代消除不确定性，因此我们通常会将托管服务委托给合作伙伴公司。即便如此，我们的工作也离不开生产环境。我们负责交付软件的质量，包括开发能够报告服务质量问题的软件，以及构建一个能够确保软件具有弹性和高性能的架构。因此，尽管这本身并非我们的工作，但我对 Web 服务的运维非常感兴趣。

什么是站点可靠性工程 (SRE)？

首先，让我们来定义一下这个由谷歌工程高级副总裁 Ben Treynor Sloss 创立的新兴职业。他曾这样描述：

从根本上说，SRE 就是当你要求软件工程师设计操作功能时发生的事情。

一个典型的 SRE 团队由 6 到 8 名工程师组成，以保持均衡的 on-call 轮换。其中一半由传统软件工程师（用 Google 的话来说就是 SWE）组成，另一半由几乎具备 SWE 资格的工程师组成，但他们拥有与运维领域相关的技能和兴趣：例如 Unix 内部机制、网络等等。

他们在公司工作流程中占据核心地位，与软件工程师、发布经理、数据中心工程师、产品负责人、会计服务和高层管理人员都有联系。

他们全面负责给定应用程序的可用性、延迟、性能、效率、费用管理、监控、应急响应和容量规划。

为了应对这些巨大的责任和艰难的扩展挑战，他们精心安排时间。他们以一种不同寻常的方式做到这一点：他们必须将不到 50% 的时间用于运营任务、繁重工作和应急响应。他们的大部分时间应该用于编写软件和工具来自动化自己的工作，或者确保他们的应用程序能够自我修复。

DevOps 与 SRE

DevOps 是Patrick Debois于 2008-2009 年发起的一项运动，旨在提高部署过程的敏捷性，并缩小开发人员和操作员之间的差距。

SRE 更确切地说是一个工程领域，是一种组织工程师以整体管理可靠性的方法。正如SRE 书籍第 7 页所解释的那样：

人们可以等效地将 SRE 视为具有一些特殊扩展的 DevOps 的特定实现。

平衡可用性和速度

我原本以为这本书能让我了解谷歌通往“始终可用系统™”的秘诀。结果我错了，反而学到了更宝贵的一课。谷歌工程师并不追求 100% 的可用性，因为这既不现实也不可持续。

相反，根据业务需求和预期，每个应用程序或生产系统都会有一个服务级别目标 (SLO)。对于一个典型的 Google 应用，其 SLO 设置为所有请求的成功率约为 99.99%（“四个九”的可用性），或 99.999%（“五个九”的可用性）。

以下是“9”的数量如何转化为每年的停机时间：

99%（“两个九”）：3.65 天
99.9%（“三个九”）：8.77 小时
99.99%（“四个九”）：52.60 分钟
99.999%（“五个九”）：5.26 分钟

在 marmelab，我们的大多数项目都拥有 99.9% 的正常运行时间（三个九，还不错！），尽管我们更注重速度而不是可用性。从 SRE 书中可以学到的一个重要教训是，如果我们想要达到下一个服务级别（四个九），就必须将可用性方面的努力提高十倍。

100% 可用性和“99.9%”可用性之间的差异非常重要，因为它提供了可衡量的回旋余地。例如，如果不可用性以计划外停机时间来衡量，并且 SLO 设置为 99.9%，那么一年内大约八小时的停机时间是可以接受的。

这种可接受的、计划外的停机时间的相对较小的裕度，是衡量速度带来的风险的一种方式。如果可用性下降，并接近 SLO，SRE 团队应该放慢功能交付的速度，并专注于稳定应用程序。相反，如果可用性远高于 SLO，那么团队就有一定的裕度，可以继续将新功能推向生产环境。

当然，服务级别目标可能会随着时间而变化。项目所有利益相关者都应该根据具体情况进行讨论。这是一个很有价值的指标。

消除辛劳

由于 SRE 不应将超过 50% 的时间投入到运维任务中，因此随着应用程序的扩展，他们必须定期实现工作自动化。他们应该专注于减少琐事，其定义如下：

这是一项手动、重复且可自动化的任务，对于应用程序的正常运行是必不可少的，并且会随着应用程序的发展而增长。

自动化琐事可能是一项不可忽视的投资，但它也带来了诸多好处。当然，它节省了工程师的时间。它还能让工程师在正确的时间（而不是在服务出现故障时）专注于一项任务，从而降低出错几率。此外，它还能减少上下文切换，让每个人都能专注于重要问题，专注于真正重要的事情。

作为开发者，我们每天也需要处理繁琐的琐事——只是形式不同而已。手动测试是最常见的繁琐工作，因此我们编写了自动化测试。第二常见的繁琐工作是部署和发布管理。持续交付是一项奢侈的工作，我强烈推荐！其他繁琐工作则更加微妙：更新没有重大变更的依赖项、性能基准测试、安全漏洞审计等等。