简单来说，SRE的职责是运维一个服务。该服务由一些相关的系统组件组成，为最终用户提供服务（可以是内部用户或外部用户）。SRE 的终极责任是确保该服务可以正常运转。为达成这个目标，SRE 需要完成以下一系列工作∶开发监控系统，规划容量，处理紧急事件，确保事故根源被跟踪修复等。这一部分将主要讨 ...

法国诗人 Antoine de Saint Exupery 曾写道，"不是在不能添加更多的时候，而是没有什么可以去掉的时候，才能达到完美。"（参见文献【Sai39】）这个原则同样适用于软件的设计和构建。API是这个规则应该遵循的一个清晰的例子。 书写一个明确的、最小的API 是管理软件系统管理简单性必要的部分。我们 ...

因为工程师也是人，他们经常对于自己编写的代码形成一种情感依附，这些冲突在大规模清理源代码树的时候并不少见。一些人可能会提出抗议，"如果我们以后需要这个代码怎么办?""我们为什么只是把这些代码注释掉，这样稍后再使用它的时候会更容易吗?""为什么不增加一个功能开关?"这些都是糟糕的建议。源 ...

可靠性只有靠对最大程度的简化不断追求而得到。—C.A.R. Hoare,Turing Award lecture 软件系统本质上是动态的和不稳定的。只有真空中的软件系统才是永远稳定的。如果我们不再修改代码，就不会引入新的 Bug。如果底层硬件或类库永远不变，这些组件也就不会引入Bug。如果冻结当前用户群，我们将永 ...

当采用合适的工具、合理的自动化方式，以及合理的政策时，开发团队和SRE 都无须担心如何发布软件。发布过程可以像按一个按钮那么简单。 大部分公司，不论团队大小和使用何种工具，都面临着同样的发布工程问题∶如何管理包的版本?应该采用持续构建和部署的模型，还是应该定期构建?发布的频率应该怎样? ...

配置管理是发布工程师与SRE 紧密合作的一个区域。虽然初看起来，配置管理可能很简单，但是这其实是不稳定性的一个重要来源。因此、我们的发布流程和系统运维与配置管理流程都随着时间不停地发展。今天我们使用下面几段描述的模型来分发配置文件。所有这些模型都需要将配置文件存放于我们的主要代码仓库 ...

图 8-1展示了Rapid系统中的主要组件。Rapid是用Bhueprin文件配置的。Blueprint文件是一种利用Google内部配置语言写成的，用来定义构建目标和测试目标、部署规则，以及一些管理用信息（例如项目负责人信息）。基于角色的访问控制列表可以决定谁能执行哪些动作。 每个Rapid项目都有一些工 ...

分支所有的代码都默认提交到主分支上（mainline）。然而，大部分的项目都不会直接从主分支上进行直接发布。我们会基于主分支的某一个版本创建新分支，新分支的内容永远不会再合并入主分支。Bug 修复先提交到主分支，再cherrypicking到发布分支上。这种方式可以避免在第一次构建之后，再引入主分支上的 ...