评估云工作负载的可靠性要求

若要为云工作负载构建可靠的基础架构，第一步是确定工作负载的可靠性要求。Google Cloud 基础架构可靠性指南的这一部分提供了一些准则，可帮助您定义在 Google Cloud中部署的工作负载的可靠性要求。

确定特定于工作负载的要求

应用的可靠性要求取决于应用提供的服务或执行的流程的性质。例如，为银行提供 ATM 服务的应用可能需要 99.999% 的可用性。支持在线交易平台的网站可能需要 99.999% 的可用性，并且需要快速响应。每天结束时，将银行交易写入会计分类账的批处理的数据新鲜度目标可能是 8 小时。

在应用中，各个组件或操作可能具有不同的可靠性要求。例如，与读取请求相比，订单处理应用将数据写入订单数据库的操作可能需要更高的可靠性。

精细评估工作负载的可靠性要求有助于您将支出和精力集中在对业务至关重要的工作负载上。

确定关键时期

有时，应用可能对业务至关重要，而在其他时候则没有那么重要。这些时间段通常是应用负载高峰期。确定这些时段、规划充足的容量，并针对高负载条件测试应用。为避免在负载高峰时段出现应用服务中断的风险，您可以使用适当的操作做法，如冻结生产代码。

下面的示例应用会遭遇季节性负载高峰：

• 在安排每月、每季度或每年进行库存审核的日子，财务会计应用的库存模块通常会被更频繁地使用。
• 在购物旺季或促销活动期间，电子商务网站的负载会出现明显的激增。
• 支持大学招生模块的数据库在每年的几个月内都会执行大量写入操作。
• 在纳税季期间，在线纳税服务的负载会很高。
• 在线交易平台可能需要 99.999% 的可用性和快速响应时间，但仅限于交易期间（例如，周一至周五上午 8 点至下午 5 点）。

考虑其他非功能性要求

除了可靠性要求之外，企业应用可能还有其他重要的非功能性要求，例如安全性、性能、成本和运营效率。在评估应用的可靠性要求时，请考虑依赖项以及与这些其他要求的权衡。

以下是并非针对可靠性的要求示例，但可能涉及与可靠性要求的权衡。

• 费用优化：为了优化 IT 费用，您的组织可能会对某些云资源设置配额。例如，为了降低第三方软件许可费用，贵组织可以为可预配的计算核心数量设置配额。可以存储的数据量和跨区域网络流量可能存在类似的配额。考虑这些费用约束条件对设计可靠基础架构的可用选项的影响。
• 数据驻留：为满足监管要求，即使企业为全球用户提供服务，您的应用也可能需要在特定国家/地区存储和处理数据。在决定部署应用的区域和可用区时，请考虑此类数据驻留限制。

您为满足其他要求而做出的某些设计决策有助于提高应用的可靠性。下面列出了一些示例：

• 部署自动化：为了高效运行云部署，您可以决定使用基础架构即代码 (IaC) 自动执行预配流程。同样，您可以使用持续集成和持续部署 (CI/CD) 流水线来自动执行应用构建和部署流程。使用 IaC 和 CI/CD 流水线不仅有助于提高运营效率，还能提高工作负载的可靠性。
• 安全控制：您实现的安全控制措施还有助于提高应用的可用性。例如，Google Cloud Armor 安全政策有助于确保应用在遭受拒绝服务 (DoS) 攻击期间保持可用。
• 内容缓存：如需提高内容传送应用的性能，您可以在负载均衡器配置中启用缓存。采用这种设计后，用户不仅可以更快地访问内容，还能获得更高的可用性。即使源服务器已关停，他们也可以访问缓存的内容。

定期重新评估要求

随着业务的发展和壮大，应用的要求可能会发生变化。定期重新评估可靠性要求，确保这些要求与贵组织当前的业务目标和优先事项保持一致。

假设某个应用为所有用户提供标准可用性。您可能已在一个区域内的两个可用区中部署了该应用，其中有一个区域负载均衡器作为前端。如果贵组织计划推出可提供更高可用性的付费服务选项，则应用的可靠性要求会发生变化。为了满足新的可用性要求，您可能需要将应用部署到多个区域，并使用启用了 Cloud CDN 的全球负载均衡器。

发生服务中断后，您还可以重新评估应用的可用性要求。服务中断可能会暴露您企业内不同团队之间不匹配的期望。例如，一个团队可能会认为每年 45 分钟中断服务一次（即每年的可用性为 99.99%）是可接受的。但另一个团队可能希望每月的最长停机时间为 4.3 分钟（即每月的可用性为 99.99%）。根据您决定修改或阐明可用性要求的方式，您应调整架构以满足新要求。