译者序

“铃铃铃……”办公桌上的on-call电话竟然响了。坐在空荡荡的办公室里值夜班的我，心里咯噔一下。我看了看表，凌晨2点多。揉揉睡眼，强打精神，我接通了电话：“Hello……”

这是2005年12月的一天，当时我是一家通信设备制造公司的开发人员，负责7×24小时接听来自全球的技术支持电话，解决关于VoIP网络管理系统的线上问题。

为了方便使用公司网络来解决问题，那些轮流值夜班的同事经常会像捧着“烫手山芋”那样，拿着那部on-call电话，在办公室过夜。

所幸那段日子只持续了1年，之后我就转到其他团队去了。但想到在那期间on-call电话的“午夜凶铃”，即使是14年后的今天，我依然心有余悸。我常想，有没有办法可以让on-call的开发人员睡个好觉呢？

2014年12月，我加入了ThoughtWorks公司。那时，DevOps开始在国内变得火热起来。一次，我听到公司里的一位同事在聊天时说：“要想做好DevOps，一定要读《发布！》。”这是我第一次听说这本书。

大概过了两年，我在《持续交付》一书的合著者Jez Humble写的有关持续交付的材料中，再次看到《发布！》的身影。这让我开始关注这本书。

第1版第5章的一段话吸引了我：“这八个健康的模式……会帮助你在软件发布之后，晚上可以睡个好觉。”

2018年1月，第2版英文版出版。

2018年3月，通过一个偶然的机会，我得知图灵公司在为第2版寻找译者，于是毫不犹豫地应征了。

2018年7月6日，我在北京参加ArchSummit全球架构师峰会。当时美国东北大学西雅图分校计算机系主任Ian Gorton讲解了可扩展的软件系统和架构的模式，他在幻灯片中插入了第1版英文版封面。“第2版都出了半年多了，系主任先生该更新PPT了。”我望着手边的译稿，心里说。

与第1版相比，第2版有何不同呢？

80%的内容是新的。

第1版与第2版均包含四个部分。第2版的第一部分仍然讨论实现分布式系统稳定性的方法，涉及稳定性的模式和反模式。对于后面三部分的内容，第2版分别用“为生产环境而设计”“将系统交付”“解决系统性问题”替代了第1版的“容量”“一般设计问题”“运营”。

第2版新增的主要内容包括以下几个方面。

❑ “一窝蜂”和“做出误判的机器”这两个稳定性反模式。

❑ “任其崩溃并替换”“卸下负载”“背压机制”和“调速器”等稳定性模式。

❑ 如何对部署进行设计。

❑ 如何处理软件部署版本的问题。

❑ 如何实践混沌工程。

书中介绍了如何构建高可用性分布式系统，即使系统在发布后出现了问题，开发人员也能睡个好觉，不会被深夜on-call电话叫醒。

为何有的分布式系统在上线后，会频繁出现故障，导致开发人员夜不能寐？某大型云平台故障说明中曾提到：“对于这次故障，没有借口，我们不能也不该出现这样的失误！”但事实证明，“不能也不该”出现的失误，最终还是出现了。为什么呢？这是因为很多开发人员在考虑分布式系统稳定性的设计时，会假设生产环境处于产品运行最理想的状态，且用户的行为是理智、可预见的。于是，他们便在测试环境中模拟理想场景，完成“终极”测试。他们只关注如何通过测试人员所编写的测试用例，认为只要通过了测试用例，便不会出现各类故障。但是，这是一种乌托邦式的观点，而且所谓的测试用例往往只覆盖了实际生产环境和用户使用场景中很小的范围。这样一来，当分布式系统在复杂残酷的真实生产环境中发生故障后，很难控制故障范围并进行自我修复，造成系统出现很小的“裂纹”。之后，“裂纹”逐渐蔓延，直至把整个系统拖垮。

如果你承认软件系统的失效不可避免，并且认为工作的重点应该是“当系统失效时，该如何提升系统的生存能力”（换句话说，当系统出现问题时，依然能稳定运行），那么你需要仔细阅读本书，找到适合自己的答案。

吾真本

2019年11月26日于北京