推动 Google 生产：Google 的站点可靠性工程团队如何使用 Go

谷歌运行少数非常大的服务。这些服务由涵盖开发人员所需一切的全球基础设施提供支持：存储系统、负载平衡器、网络、日志记录、监控等等。然而，它不是一个静态系统——它不可能是。架构不断发展，新产品和想法不断涌现，必须推出新版本，推送配置，更新数据库架构等等。我们最终每秒将更改部署到我们的系统数十次.

由于这种规模和对可靠性的迫切需求，Google 率先推出了站点可靠性工程 (SRE)，此后许多其他公司都采用了这一角色。“当您将操作视为软件问题时，您就会得到 SRE。我们的使命是保护、提供和改进 Google 所有公共服务背后的软件和系统，同时密切关注它们的可用性、延迟、性能和容量。” —站点可靠性工程 (SRE).

在 2013-2014 年，Google 的 SRE 团队意识到我们的生产管理方法在很多方面都不再削减它了。我们已经远远超出了 shell 脚本，但是我们的规模有太多的移动部分和复杂性，需要一种新的方法。我们确定我们需要转向我们生产的声明性模型，称为“Prodspec”，驱动一个称为“Annealing”的专用控制平面.

当我们开始这些项目时，Go 刚刚成为谷歌关键服务的一个可行选择。大多数工程师更熟悉 Python 和 C++，这两者都是有效的选择。尽管如此，Go 还是引起了我们的兴趣。新颖性的吸引力当然是一个因素。但是，更重要的是，Go 承诺了其他语言都无法提供的性能和可读性之间的最佳平衡点。我们用 Go 开始了一个小实验，用于 Annealing 和 Prodspec 的一些初始部分。随着项目的进展，那些用 Go 编写的初始部分发现自己处于核心位置。我们对 Go 感到满意——它的简单性让我们受益匪浅，性能就在那里，并发原语很难被取代.

从来没有强制或要求使用 Go，但我们不想回到 Python 或 C++。Go 在 Annealing 和 Prodspec 中有机地发展。这是正确的选择，因此现在是我们选择的语言。现在，大部分 Google 产品都由我们用 Go 编写的系统管理和维护.

在这些项目中使用简单语言的力量怎么强调都不为过。在某些情况下确实缺少某些功能，例如在代码中强制某些复杂结构不应发生变异的能力。但对于这些案例中的每一个，毫无疑问，都有成百上千个案例的简单性所帮助.

例如，Annealing影响了各种各样的团队和服务，这意味着我们在很大程度上依赖于整个公司的贡献。Go 的简单性使我们团队以外的人可以了解为什么某些部分不适合他们，并且经常自己提供修复或功能。这让我们得以快速成长.

Prodspec 和 Annealing 负责一些非常关键的组件。Go 的简单性意味着代码易于跟踪，无论是在审查期间发现错误，还是在尝试确定服务中断期间究竟发生了什么时.

Go 性能和并发支持也是我们工作的关键。由于我们的生产模型是声明性的，我们倾向于操作大量结构化数据，这些数据描述了什么是生产以及它应该是什么。我们有大型服务，因此数据会变得很大，这通常会使纯顺序处理不够高效.

我们正在以多种方式和许多地方操纵这些数据。这不是让聪明人想出我们算法的并行版本的问题。这是一个偶然的并行问题，找到下一个瓶颈并并行化该代码部分。而 Go 正是实现了这一点.

由于我们在 Go 方面取得了成功，我们现在将 Go 用于 Prodspec 和 Annealing 的每个新开发.

除了站点可靠性工程团队之外，谷歌的工程团队也在他们的开发过程中采用了 Go。了解 Core Data Solutions、 Firebase Hosting和 Chrome 团队如何使用 Go 来大规模构建快速、可靠且高效的软件.