基础设施即代码，第2版

第 2 章 云时代基础设施的原则 云时代基础设施的原则

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

IT 钢铁时代的计算资源与物理硬件紧密相连。我们将中央处理器、内存和硬盘装入机箱，安装到机架上，并与交换机和路由器连接。我们安装并配置操作系统和应用软件。我们可以描述应用服务器在数据中心的位置：哪一层、哪一排、哪一个机架、哪一个插槽。

云时代将计算资源与其运行的物理硬件分离开来。当然，硬件仍然存在，但服务器、硬盘驱动器和路由器漂浮在硬件之上。这些都不再是实体，而是我们可以随意创建、复制、更改和销毁的虚拟构造物。

这种转变迫使我们改变思考、设计和使用计算资源的方式。我们不能依赖应用服务器的物理属性保持不变。我们必须能够不慌不忙地添加和删除系统实例，即使在快速扩大系统规模时，我们也必须能够轻松保持系统的一致性和质量。

在云平台上设计和实施基础架构有几条原则。这些原则阐明了使用三大核心实践（将一切定义为代码、持续测试和交付、构建小块）的理由。我还列出了团队在使用动态基础架构时常见的几个误区。

这些原则和陷阱是本书中有关实施 "基础设施即代码 "实践的具体建议的基础。

原则：假设系统不可靠

在铁器时代，我们假设我们的系统运行在可靠的硬件上。在云时代，你需要假设你的系统运行在不可靠的硬件上。¹

Cloud 规模的基础设施涉及数十万台设备，甚至更多。在这种规模下，即使使用可靠的硬件，故障也会发生--而且大多数 Cloud 供应商使用的都是廉价、可靠性较低的硬件，在硬件损坏时会及时检测并更换。

除计划外故障外，您还需要将系统的某些部分下线。你需要修补和升级系统。您需要调整大小、重新分配负载并排除故障。

在静态基础设施中，做这些事情意味着系统离线。但在许多现代企业中，系统离线意味着业务离线。

因此，不能将系统运行所依赖的基础设施视为稳定的基础。相反，您必须在基础资源发生变化时设计出不间断的服务。²

原则：让一切都可复制

使系统可恢复的方法之一是确保可以毫不费力地可靠地重建其部件。

不费吹灰之力是指不需要就如何构建做出任何决定。您应将配置设置、软件版本和依赖关系等内容定义为代码。然后，重建就是一个简单的 "是/否 "决定。

可重复性不仅使故障系统的恢复变得容易，而且还有助于您：

• 使测试环境与生产环境保持一致

• 跨地区复制系统，提高可用性

• 按需添加实例，以应对高负载

• 复制系统，为每位客户提供专用实例

当然，系统会生成数据、内容和日志，这些都是无法提前定义的。您需要确定这些内容，并设法将其作为复制策略的一部分。具体做法可能很简单，就是将数据复制或流式传输到备份，然后在重建时将其还原。我将在"不断变化的系统中的数据连续性 "一文中介绍这样做的各种选择。

轻松构建和重建基础设施任何部分的能力非常强大。它消除了进行更改的风险和恐惧，让您能够自信地处理故障。您可以快速提供新的服务和环境。

陷阱Snowflake 系统

Snowflake 是难以重建的系统实例或系统的一部分。它也可能是一种环境，本应与其他环境（如暂存环境）相似，但却存在团队无法完全理解的差异。

人们不会去建立 Snowflake 系统。它们是一种自然现象。第一次使用新工具构建东西时，你会在过程中吸取教训，包括犯错误。但是，如果人们依赖于你所构建的东西，你可能就没有时间回头利用你所学到的东西重建或改进它了。如果你没有让改变变得容易和安全的机制和做法，那么改进你所建立的东西就尤其困难。

造成雪花的另一个原因是，当人们对系统的一个实例进行更改时，却没有对其他实例进行更改。他们可能迫于压力要修复一个只在一个系统中出现的问题，或者他们可能在测试环境中启动了一个重大升级，但却没有时间将其推广到其他系统。 ...