Google 云架构的可靠性原则

注：原文来自GCP。原文似乎没有分清可用性和可靠性。我个人认为，可靠性是指程序的正确性，比如一个计算器在计算1.0加2.0时，应该等于3.0。而可用性指的系统在指定时间范围内提供服务的时长，即计算器在1年里，有多久是可用的。所以，我个人认为本文实际上讲的是可用性。

主要术语

在架构框架可靠性类别中，使用了以下术语。这些术语对如何运行可靠的服务至关重要。

服务等级指标 (SLI)

“服务等级指标”(SLI) 是对所提供服务的等级的某些方面进行精心定义的定量衡量的指标。它是一个指标，而非目标。

服务等级目标 (SLO)

“服务等级目标”(SLO) 指定服务可靠性的目标等级。SLO 是 SLI 的目标值。当 SLI 等于或高于此值时，该服务被视为“足够可靠”。由于 SLO 是做出有关可靠性的数据驱动型决策的关键，因此它们是站点可靠性工程 (SRE) 做法的焦点。

错误预算

一段时间内“错误预算”的计算方式为 100% – SLO。错误预算可说明您的系统在某个时间窗口内是高于还是低于所需的可靠性，以及该时间段内允许多少分钟的停机时间。

例如，如果您的可用性 SLO 为 99.9%，则 30 天期限的错误预算为 (1 - 0.999) ✕ 30 天 ✕ 24 小时 ✕ 60 分钟 = 43.2 分钟。每当系统不可用时，系统都会使用或消耗系统的错误预算。在上一个示例中，如果系统在过去 30 天内有 10 分钟的停机时间，并且 30 天期限在开始时有 43.2 分钟的未使用总预算，则剩余的错误预算会减少到 33.2 分钟。

我们建议您在计算总错误预算和错误预算消耗率时使用 30 天的滚动窗口。

服务等级协议 (SLA)

服务等级协议 (SLA) 是与您的用户签订的显式或隐式合同，其内容涵盖达成（或未达成）合同中引用的 SLO 而造成的影响。

核心原则

Google 的可靠性理念源于以下核心原则。

可靠性是您的首要任务

从短期来看，新产品功能有时会是您的首要任务。但从长远来看，可靠性是您的首要产品功能，因为如果产品速度太慢或长时间不可用，就可能会被用户放弃，从而使其他产品功能无关紧要。

可靠性由用户定义

对于面向用户的工作负载，请衡量用户体验。用户必须对您的服务的表现满意。例如，衡量用户请求的成功率，而不仅仅是查询 CPU 使用率等服务器指标。

对于批量和流式工作负载，您可能需要衡量数据吞吐量的关键性能指标 (KPI)，例如每个时间窗口扫描的行数，而不需要衡量服务器指标，如磁盘使用率。吞吐量 KPI 有助于确保用户需要的每日报告或季度报告按时完成。

100% 可靠性是错误的目标

您的系统应足够可靠以确保用户满意，但不能过于可靠以至投资不合理。确定 SLO 以设置所需的可靠性阈值，然后使用错误预算将变化速率控制在适当的范围内。

只有当该产品或应用的 SLO 与费用相符时，才将此框架中的设计和操作原则应用于产品。

可靠性和快速创新相辅相成

使用错误预算在系统稳定性和开发者敏捷性之间取得平衡。以下指导可帮助您确定何时应该加快或放慢速度：

• 如果错误预算充足，您可以快速创新、改进产品或添加产品功能。

• 当错误预算减少时，请放慢速度并专注于可靠性功能。

设计和操作原则

为了最大限度地提高系统可靠性，需要遵循以下设计和操作原则。架构框架可靠性类别的其余部分中详细讨论了其中每个原则。

确定您的可靠性目标

架构框架的这一部分中介绍的最佳做法包括以下内容：

• 选择适当的 SLI。

• 根据用户体验设置 SLO。

• 反复验证以改进 SLO。

• 使用严格的内部 SLO。

• 使用错误预算来管理开发速度。如需了解详情，请参阅架构框架可靠性类别中确定您的可靠性目标。

将可观测性内置到您的基础架构和应用中

架构框架的这一部分介绍了以下设计原则：

• 对代码进行插桩以最大限度地提高可观测性。

在设计时确保可扩缩性和高可用性

架构框架的这一部分介绍了以下设计原则：

• 创建冗余以实现更高的可用性。

• 跨区域复制数据以进行灾难恢复。

• 设计多地区架构以应对地区级服务中断。

• 消除可扩缩性瓶颈。

• 过载时平缓降低服务水平。

• 预防和缓解流量峰值。

• 清理并验证输入。

• 以可以保留系统功能的方式进入故障安全模式。

• 将 API 调用和操作命令设计为可重试。

• 识别和管理系统依赖项。

• 最大限度地减少关键依赖项。

• 确保可以回滚所有更改。

创建可靠的操作流程和工具

架构框架的这一部分介绍了以下操作原则：

• 为应用和服务选择良好的名称。

• 借助 Canary 测试过程实现渐进式发布。

• 为限时促销和发布活动分散流量。

• 自动执行构建、测试和部署流程。

• 防范运算符错误。

• 测试故障恢复过程。

• 执行灾难恢复测试。

• 试验混沌工程。

构建高效提醒

架构框架的这一部分介绍了以下操作原则：

• 优化提醒延迟时间。

• 针对表现（而非原因）触发提醒。

• 针对离群值（而不是平均值）触发提醒。

构建突发事件管理协作流程

架构框架的这一部分介绍了以下操作原则：

• 指定明确的服务所有权。

• 利用经过微调的提醒来缩短检测时间 (TTD)。

• 通过突发事件管理计划和培训，缩短缓解时间 (TTM)。

• 设计信息中心布局和内容以最大限度地缩短 TTM。

• 针对已知的中断情况记录诊断过程和缓解措施。

• 利用无责备事后分析来了解服务中断情况并防止再次发生。

原文链接：https://cloud.google.com/architecture/framework/reliability/principles?hl=zh-cn

往期好文推荐：

• SRE认知升级之可用性的本质

• 金丝雀发布的本质