Google Cloud 架构框架中的本文档提供了以可靠方式运行服务的操作原则，例如如何部署更新、在生产环境中运行服务以及测试故障。可靠性架构设计应涵盖服务的整个生命周期，而不仅仅是软件设计。
为应用和服务选择好的名称
避免在生产配置文件中使用内部代号，因为它们可能会造成混淆（尤其是对于较新的员工），从而增加服务中断的缓解时间 (TTM)。请尽可能为您的所有应用、服务和关键系统资源（例如虚拟机、集群和数据库实例）选择良好的名称，并遵守其各自的名称长度限制。良好的名称应描述实体的用途；应该是准确、具体且独特的，并且读起来应该是有意义的。良好的名称应避免首字母缩略词、代号、缩写以及可能具有冒犯性的用语，并且即使对外发布，也不会引发负面的公众反应。
借助 Canary 测试实现渐进式发布
对服务二进制文件或配置进行的即时全局更改本身就存在风险。逐步发布新版本可执行文件和配置更改。从一个小范围（例如一个可用区中的几个虚拟机）开始，逐步扩大范围。如果更改没有达到预期效果，或者在部署过程中的任何阶段对用户产生负面影响，则快速回滚。您的目标是在只影响一小部分用户流量时识别并解决错误，然后再在全球范围内发布更改。
设置一个 Canary 测试系统，该系统会注意到服务更改，并对更改后的服务器与其余服务器的指标进行 A/B 比较。系统应标记意外行为或异常行为。如果更改没有达到预期效果，则 Canary 测试系统应该会自动停止发布。问题可能很明显（如用户错误）或很细微（如 CPU 使用率增加或内存膨胀）。
最好在出现问题的第一个提示时停止并回滚，然后在没有服务中断时间压力的情况下诊断问题。更改通过 Canary 测试后，请逐步将其传播到更大的范围，例如先传播到一个完整的可用区，然后再传播到第二个可用区。让更改后的系统有时间逐步处理更多用户流量，以发现潜在的 bug。
如需了解详情，请参阅应用部署和测试策略。
为限时促销和发布活动分散流量
您可能有一些促销活动（例如在某个精确时间开始的促销），并鼓励许多用户同时连接到服务。如果是这样，请设计客户端代码以将流量分散到几秒内。在发出请求前添加随机延迟。
您还可以预热系统。预热系统时，您需要提前将预期的用户流量发送到系统，以确保系统按预期运行。此方法可以防止在规划的开始时间出现的即时流量高峰导致您的服务器崩溃。
自动构建、测试和部署
通过使用持续集成和持续交付 (CI/CD) 流水线，消除发布流程中的手动工作。执行自动集成测试和部署。 例如，使用 GKE 创建现代化 CI/CD 流程。
如需了解详情，请参阅持续集成、持续交付、测试自动化和部署自动化。
防范运维人员的错误
设计您的操作工具以拒绝可能无效的配置。当配置版本为空、部分或截断、损坏、逻辑不正确或不符合预期或者未在预期时间内收到时，检测并发出提醒。工具还应拒绝与先前版本存在很大差异的配置版本。
禁止范围宽泛导致可能具有破坏性的更改或命令。这些宽泛的命令可能是“撤消所有用户的权限”“重启此地区中的所有虚拟机”或“重新格式化此地区中的所有磁盘”。只有当操作员在部署配置时添加紧急替换命令行标志或选项设置时，才应该应用此类更改。
工具必须显示有风险的命令的影响范围（例如，更改影响的虚拟机数量），并且要求在工具继续操作之前需要明确的操作员确认。您还可以使用功能来锁定关键资源并防止意外或未经授权删除它们，例如 Cloud Storage 保留政策锁定。
测试故障恢复
定期测试从服务故障中恢复的操作过程。如果不进行定期测试，则当发生实际故障而需要这些过程时，它们可能不起作用。定期测试的内容包括地区性故障切换、如何回滚版本以及如何从备份恢复数据。
执行灾难恢复测试
与故障恢复测试一样，不要等到灾难来袭再行动。请定期测试和验证您的灾难恢复程序和流程。
您可以创建一个系统架构来提供高可用性 (HA)。此架构与灾难恢复 (DR) 并不完全重叠，但在考虑恢复时间目标 (RTO) 和恢复点目标 (RPO) 值时，通常需要考虑 HA。
HA 可帮助您达到或超出商定的操作性能级别，例如正常运行时间。当您在 Google Cloud 上运行生产工作负载时，您可以在第二个地区中部署被动或主动备用实例。在此架构中，如果主要地区发生灾难，应用会从不受影响的地区继续提供服务。如需了解详情，请参阅针对云服务中断设计灾难恢复架构。
试验混沌工程
考虑在测试做法中使用混沌工程。将实际故障引入到安全环境中的负载下生产系统的不同组件中。这种方法有助于确保对系统整体没有影响，因为您的服务会在每个级别正确处理故障。
注入到系统中故障可能包括 RPC 的崩溃任务、错误和超时，或者资源可用性的降低。使用随机故障注入功能来测试服务依赖项中的间歇性故障（波动）。这些行为在生产环境中难以检测和缓解。
混沌工程可确保将此类实验的影响降至最低并加以控制。您可以将此类测试视为实际服务中断的演习，并利用收集的所有信息来改善服务中断响应。
后续步骤
- 构建高效的提醒（本系列的下一个文档）
探索架构框架中的其他类别，例如系统设计、卓越运营以及安全性、隐私权和合规性。