【可靠性工程】GCP 可靠性核心原则

简介: 【可靠性工程】GCP 可靠性核心原则

Google Cloud Architecture Framework 中的这份文档解释了在云平台上运行可靠服务的一些核心原则。这些原则有助于您在阅读架构框架的其他部分时达成共识,这些部分向您展示了一些 Google Cloud 产品和功能如何支持可靠的服务。


关键术语

在架构框架可靠性类别中,使用了以下术语。这些术语提供了对如何运行可靠服务的关键理解。

服务水平指示器 (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 分钟的停机时间,并且在 43.2 分钟的全部预算未使用的情况下开始了 30 天的周期,则剩余的错误预算将减少到 33.2 分钟。

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

服务水平协议 (SLA)

服务水平协议 (SLA) 是与您的用户签订的明示或隐含合同,其中包括您遇到或错过合同中引用的 SLO 时的后果。

核心原则

Google 的可靠性方法基于以下核心原则。

可靠性是您的首要功能

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

可靠性由用户定义

对于面向用户的工作负载,衡量用户体验。用户必须对您的服务执行方式感到满意。例如,衡量用户请求的成功率,而不仅仅是 CPU 使用率等服务器指标。

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

100% 的可靠性是错误的目标

你的系统应该足够可靠,让用户满意,但又不能过于可靠,以至于投资不合理。定义设置所需可靠性阈值的 SLO,然后使用错误预算来管理适当的变化率。

仅当该产品或应用程序的 SLO 证明成本合理时,才将该框架中的设计和操作原则应用于产品。

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

使用错误预算在系统稳定性和开发人员敏捷性之间取得平衡。以下指南可帮助您确定何时快速或慢速移动:

  • 当有足够的错误预算可用时,您可以快速创新并改进产品或添加产品功能。
  • 当错误预算减少时,放慢速度并专注于可靠性功能。

设计和操作原则

为了最大限度地提高系统可靠性,以下设计和操作原则适用。在架构框架可靠性类别的其余部分中详细讨论了这些原则中的每一个。

定义您的可靠性目标

架构框架的这一部分涵盖的最佳实践包括以下内容:

  • 选择适当的 SLI。
  • 根据用户体验设置 SLO。
  • 迭代改进 SLO。
  • 使用严格的内部 SLO。
  • 使用错误预算来管理开发速度。

有关详细信息,请参阅在架构框架可靠性类别中定义您的可靠性目标。

在您的基础架构和应用程序中构建可观察性

架构框架的这一部分涵盖了以下设计原则:

  • 检测您的代码以最大限度地提高可观察性。

有关更多信息,请参阅架构框架可靠性类别中的在基础架构和应用程序中构建可观察性。

为规模和高可用性而设计

架构框架的这一部分涵盖了以下设计原则:

  • 创建冗余以提高可用性。
  • 跨区域复制数据以进行灾难恢复。
  • 设计多区域架构以应对区域中断。
  • 消除可扩展性瓶颈。
  • 过载时优雅地降低服务级别。
  • 防止和缓解流量高峰。
  • 清理和验证输入。
  • 以保留系统功能的方式进行故障保护。
  • 将 API 调用和操作命令设计为可重试。
  • 识别和管理系统依赖项。
  • 最小化关键依赖。
  • 确保每次更改都可以回滚。

有关详细信息,请参阅架构框架可靠性类别中的规模和高可用性设计。

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

架构框架的这一部分涵盖了以下操作原则:

  • 为应用程序和服务选择好的名称。
  • 通过金丝雀测试程序实施渐进式部署。
  • 分散流量以进行定时促销和发布。
  • 自动化构建、测试和部署过程。
  • 防止操作员错误。
  • 测试故障恢复程序。
  • 进行灾难恢复测试。
  • 练习混沌工程。

有关详细信息,请参阅架构框架可靠性类别中的创建可靠的操作流程和工具。

建立有效的警报

架构框架的这一部分涵盖了以下操作原则:

  • 优化警报延迟。
  • 警惕症状,而不是原因。
  • 警惕异常值,而不是平均值。

有关详细信息,请参阅架构框架可靠性类别中的构建高效警报。

建立协作事件管理流程

架构框架的这一部分涵盖了以下操作原则:

  • 分配明确的服务所有权。
  • 通过精心调整的警报缩短检测时间 (TTD)。
  • 通过事件管理计划和培训缩短缓解时间 (TTM)。
  • 设计仪表板布局和内容以最小化 TTM。
  • 记录已知中断情况的诊断程序和缓解措施。
  • 使用无可指责的事后分析从中断中学习并防止再次发生。

有关详细信息,请参阅架构框架可靠性类别中的构建协作事件管理流程。


相关文章
|
5天前
|
消息中间件 持续交付 数据库
构建高效可靠的微服务架构:策略与实践
【4月更文挑战第25天】 随着现代软件开发的复杂性日益增加,传统的单体应用已难以满足快速迭代和灵活部署的需求。本文深入探讨了如何构建一个高效且可靠的微服务架构,包括关键的设计原则、技术选型以及实践中的挑战和应对策略。通过分析多个成功案例,我们总结了一系列最佳实践,并提出了一套可量化的性能优化方法。文章不仅为开发者提供了具体的技术指导,同时也强调了团队协作和持续学习在微服务转型过程中的重要性。
|
4月前
|
前端开发
第8期 volta保证团队开发环境的完全统一
第8期 volta保证团队开发环境的完全统一
21 0
|
12月前
|
存储 监控 API
【可靠性工程】GCP 定义您的可靠性目标
【可靠性工程】GCP 定义您的可靠性目标
|
12月前
|
存储 安全 网络安全
【可靠性工程】Microsoft 可靠性模式
【可靠性工程】Microsoft 可靠性模式
|
12月前
|
缓存 负载均衡 安全
【可用性设计】 GCP 面向规模和高可用性的设计
【可用性设计】 GCP 面向规模和高可用性的设计
|
12月前
|
存储 缓存 Kubernetes
RPC框架设计的安全性考量
RPC里面该如何提升单机资源的利用率,你要记住的关键点就一个,那就是“异步化”。调用方利用异步化机制实现并行调用多个服务,以缩短整个调用时间;而服务提供方则可以利用异步化把业务逻辑放到自定义线程池里面去执行,以提升单机的OPS。
323 0
|
存储 设计模式 弹性计算
【可靠性架构】可靠性架构第1部分:概念
本故事的目标是提供可靠性的最佳实践来管理您的云环境。尽管它引用了AWS和Cloud,但这些原则同样适用于其他云提供商和内部环境。
|
Dragonfly Kubernetes Cloud Native
如何保证软件交付过程的标准化|学习笔记
快速学习如何保证软件交付过程的标准化
540 0
如何保证软件交付过程的标准化|学习笔记
|
Dragonfly 运维 Cloud Native
如何保证软件交付过程的标准化 | 学习笔记
快速学习如何保证软件交付过程的标准化
226 0
如何保证软件交付过程的标准化 | 学习笔记
|
监控 数据库 数据中心
ebay增强可用性的4个原则(1)
ebay增强可用性的4个原则(1)
117 0
ebay增强可用性的4个原则(1)