编者按：造成服务中断的最常见原因之一是发布新版本的服务二进制文件；无论您的测试和QA有多好，只有当受影响的代码在生产环境中运行时，才会出现一些bug。多年来，谷歌网站可靠性工程（Google Site Reliability Engineering）经历了许多因发布而导致的中断，现在假设每一个新发布的版本都可能包含一个或多个bug。

作为软件工程师，我们都喜欢为我们的服务添加新功能；但每一个发布都有可能出现故障。即使假设我们适当地努力添加单元和功能测试来覆盖我们的更改，并进行负载测试以确定对系统性能是否有任何实质性影响，实时通信也有一种让我们吃惊的方式。这些很少是令人愉快的惊喜。

新二进制文件的发布是常见的中断源。从负责系统可靠性的工程师的角度来看，这可以转化为三项基本任务：

我们还假设您使用Stackdriver之类的工具来监控系统，测量内部流量和错误率。如果没有这种监控，那么就很难有意义地讨论可靠性；根据SRE手册中描述的可靠性层次结构，监控是可靠系统最基本的要求）。

检测

一种更微妙的情况是，新二进制文件在一小部分查询中返回错误-例如，用户设置更改请求，或者仅针对名称中包含撇号的用户（无论是好是坏）。在这种故障模式下，只有在升级了大多数服务实例之后，问题才可能在整体监视中显现出来。因此，将服务实例的错误和延迟摘要按二进制发布版本进行分解是很有用的。

回滚

许多错误的诱惑，特别是如果它们不是显示阻止程序，就是构建一个快速补丁，然后"前滚"，即。，制作一个新版本，包括原始版本和修复bug所需的最小代码更改（修复的"精选"）。不过，我们一般不建议这样做，特别是当有问题的bug是用户可见的或在内部造成重大问题时（例如，查询的资源成本翻倍）。

向前滚动有什么问题？设身处地为软件开发人员着想：你的经理在你的办公桌旁蹦蹦跳跳，血压明显攀升，她要求知道你的补丁何时发布，因为她让你公司的产品总监对他收到的所有负面用户反馈都听而不闻。您正在以最快的速度编写修复程序，因为每一分钟都会有上千个用户看到服务中的错误。在这种压力下，编码、测试或部署错误几乎是不可避免的。

我们在Google见过很多次这样的情况，匆忙部署的前滚修复程序要么无法修复原来的问题，要么确实让事情变得更糟。即使它解决了问题，也可能会发现系统中其他潜在的错误；你正在把自己从一个已知的良好状态带到一个没有经过常规艰苦的QA测试的版本的荒野中，我们的理念是"回滚是正常的"。当在新版本中发现或合理怀疑错误时，发布团队首先回滚，然后调查问题。回滚请求不会被解释为对发布团队的攻击，甚至是对编写包含bug的代码的人的攻击；相反，它被理解为使系统对用户尽可能可靠的正确做法。没有人会问"你为什么要把零钱退回来？"只要回滚变更列表描述了所看到的问题。

因此，要使回滚工作，隐含的假设是：

测试回滚

不兼容的更改

我们在这里推荐的方法是无特性的版本；从二进制文件的版本v开始，构建一个相同的新版本v+1除了它可以安全地处理新的数据库模式之外。使用新模式的新特性在v+2版本中。您的推出计划是：

这是一个更一般问题的特例。当您构建服务的依赖关系图并标识其所有直接依赖关系时，您需要为任何一个依赖关系突然被其所有者回滚的情况进行规划。如果您的启动正在等待依赖服务S从release r移动到r+1，那么您必须确保S将"坚持"在r+1。这里的一种方法是建立一个生态系统假设，即任何服务都可以被一个版本回滚，在这种情况下，您的服务将等待S到达版本r+2，然后根据r+1中的某个功能将您的服务移动到一个版本。

摘要

在第2部分中，我们将研究"canarying"策略，以检测实际的生产问题而不会在新版本上冒着大量生产流量的风险。