要为云工作负载构建可靠的基础架构，第一步是确定工作负载的可靠性要求。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%）。根据您决定修改或阐明可用性要求的方式，您应该调整架构以满足新要求。