Google Cloud 架构框架中的这一类别简要介绍了在云平台上构建和运营可靠服务所需的设计原则，
该架构框架介绍了最佳实践，提供了实现建议，并说明了一些可用的产品和服务。该框架旨在帮助您设计 Google Cloud 部署，以便它能够完全满足您的业务需求。
如需运行可靠的服务，您的架构必须包含以下内容：
- 可衡量的可靠性目标，可在出现偏差时及时纠正
- 以下各项的设计模式：
- 可伸缩性
- 高可用性
- 灾难恢复
- 自动化变更管理
- 可以自行修复的组件（能够自行修复问题，无需人工干预）
- 包含可观测性的插桩的代码
- 无需手动操作（例如服务运行），只需极少的人工工作、认知操作负担以及快速的故障检测和缓解
整个工程组织负责服务的可靠性，包括开发、产品管理、运营和站点可靠性工程 (SRE) 团队。团队必须了解其应用的可靠性目标、风险和错误预算，并负责这些要求。可靠性和产品功能开发之间的冲突将得到优先处理，并相应地上报。
核心可靠性原则
本部分探讨了可靠服务的核心原则，并为后面的更详细文档奠定了基础。在进一步阅读本主题时，您将了解 Google 的可靠性方法基于以下可靠性原则。
确保可靠性是您的首要任务
工程团队有时会优先开发新产品。尽管用户期待他们喜爱的应用有新的激动人心的更新，但产品更新是用户的短期目标。您的客户始终期待服务可靠性，即使他们没有意识到这一点。如果您的用户无法访问您的服务或您的服务性能不佳，则应用中一组扩展的工具或闪亮的图形无关紧要。应用性能不佳很快就会使这些扩展功能变得无关紧要。
可靠性由用户定义
简而言之，当客户满意时，您的服务是可靠的。用户并非总是可以预测的，您可能会高估满足他们所需满足的条件。
根据现行的标准，某个网页应该在大约两秒钟内完成加载。当加载时间再延迟一秒时，网页放弃率约为 53%；如果加载时间延迟 3 秒，网页放弃率会大幅增加到 87%。但是，努力提供一秒钟便可呈现网页的网站可能不是最佳投资。若要为客户确定合适的服务可靠性等级，您需要衡量以下内容：
- 面向用户的工作负载：衡量用户体验。例如，衡量用户请求的成功率，而不仅仅是查询 CPU 使用率等服务器指标。
- 批量和流式工作负载：衡量数据吞吐量的关键性能指标 (KPI)，例如每个时间窗口扫描的行数。此方法比磁盘使用率等服务器指标信息更丰富。吞吐量 KPI 有助于确保用户请求的处理按时完成。
100% 可靠性是错误的目标
该原则是对前一个原则的扩展。当用户满意时，您的系统足够可靠。通常，用户无需 100% 的可靠性即可满意。因此，定义服务等级目标 (SLO)，将可靠性阈值设置为让用户满意所需的百分比，然后使用错误预算来管理适当的变化率。
只有当该产品或应用的 SLO 与费用相符时，才将此框架中的设计和操作原则应用于产品。
可靠性和快速创新相辅相成
使用错误预算在系统稳定性和开发者敏捷性之间取得平衡。以下指南可帮助您确定何时应更多地关注稳定性或开发：
- 当错误预算减少时，请放慢速度并专注于可靠性功能。
- 如果错误预算充足，您可以快速创新、改进产品或添加产品功能。
设计和操作原则
架构框架的可靠性类别中的其余文档提供了可帮助您最大限度地提高系统可靠性的设计和运营原则。以下部分总结了本系列的每个文档中的设计和运营原则。
确定您的可靠性目标
请记住，用户满意度定义了可靠性，您的可靠性目标由您设置的 SLO 来表示。设置 SLO 时，请考虑以下事项：
- 选择适当的服务等级指标 (SLI)。
- 根据用户体验设置 SLO。
- 反复验证以改进 SLO。
- 使用严格的内部 SLO。
- 使用错误预算来管理开发速度。
如需了解详情，请参阅服务等级目标的组成部分。
将可观测性内置到您的基础架构和应用中
对代码进行插桩以最大限度地提高可观测性如需了解详情，请参阅将可观测性内置到您的基础设施和应用中。
在设计时确保可扩缩性和高可用性
在扩缩和高可用性 (HA) 方面，请考虑以下原则：
- 为高可用性创建冗余
- 跨区域复制数据以进行灾难恢复 (DR)
- 设计多区域架构以灵活应对区域级服务中断
- 过载时逐步降低服务级别
- 以可以保留系统功能的方式进入故障安全模式
- 将 API 调用和操作命令设计为可重试
- 考虑依赖项：
- 确定和管理系统依赖项
- 最大限度地减少关键依赖项
- 确保可以回滚所有更改
此外，以下活动有助于提高服务的可靠性：
- 消除可伸缩性瓶颈
- 预防和缓解流量峰值
- 清理并验证输入
如需了解详情，请参阅在设计时确保可伸缩性和高可用性。
创建可靠的工具和运营流程
通过执行以下操作，将可靠性构建到工具和运营流程中：
- 为应用和服务选择逻辑、自定义的名称
- 使用 Canary 版测试实现流程逐步发布
- 安排提升和发布的时间，以便分散流量并减少系统过载
- 制定程序化构建、测试和部署流程
- 防范人为原因的突发事件（无论有意还是无意）
- 开发、测试和记录故障响应活动
- 定期开发和测试灾难恢复步骤
- 混沌工程：尝试将故障注入系统中，以确定服务的容错和弹性
如需了解详情，请参阅创建可靠的运营流程和工具。
构建高效提醒
创建提醒时，建议您执行以下操作：
- 优化提醒以适当延迟
- 针对表现（而非原因）触发提醒
- 针对离群值（而不是平均值）触发提醒
如需了解详情，请参阅架构框架可靠性类别中构建高效的提醒。
构建突发事件管理协作流程
突发事件响应和管理 (IRM) 对于服务恢复和最大限度地减少损害至关重要。有效的 IRM 包括：
- 所有权：指定明确的服务所有者。
- 经过微调的提醒：借助精心设计的提醒，改进突发事件响应 (IR) 并缩短检测时间 (TTD)。
- IRM 计划和培训：通过全面的计划、文档和培训，缩短缓解时间 (TTM)。
- 信息中心：设计信息中心布局和内容，以便在出现问题时高效地发出提醒，从而最大限度地缩短 TTM。
- 文档：为服务支持的各个方面（包括针对中断场景的诊断过程和缓解措施）创建并维护简明扼要的内容。
- 无责备文化：
- 在组织中打造无责备的环境。
- 建立事后分析流程，重点关注什么，而不是谁。
- 通过正确调查并识别需要改进的方面，从服务中断中汲取经验，防止再次发生服务中断故障。
如需了解详情，请参阅架构框架可靠性类别中的构建突发事件管理协作流程。