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。
记录已知中断情况的诊断程序和缓解措施。
使用无可指责的事后分析从中断中学习并防止再次发生。
有关详细信息，请参阅架构框架可靠性类别中的构建协作事件管理流程。
| 本文 :https://architect.pub/gcp-reliability-core-principles | ||
| 讨论：知识星球【首席架构师圈】或者加微信小号【ca_cto】或者加QQ群【792862318】 | ||
| 公众号 | 【jiagoushipro】 【架构师酒馆】 精彩图文详解架构方法论，架构实践，技术原理，技术趋势。 我们在等你，赶快扫描关注吧。 |  |
| 微信小号 | 【ca_cea】 50000人社区，讨论：企业架构，云计算，大数据，数据科学，物联网，人工智能，安全，全栈开发，DevOps，数字化. |
|
| QQ群 | 【285069459】深度交流企业架构，业务架构，应用架构，数据架构，技术架构，集成架构，安全架构。以及大数据，云计算，物联网，人工智能等各种新兴技术。 加QQ群，有珍贵的报告和干货资料分享。 |
|
| 视频号 | 【架构师酒馆】 1分钟快速了解架构相关的基本概念，模型，方法，经验。 每天1分钟，架构心中熟。 |
|
| 知识星球 | 【首席架构师圈】向大咖提问，近距离接触，或者获得私密资料分享。 |
|
| 喜马拉雅 | 【超级架构师】路上或者车上了解最新黑科技资讯，架构心得。 | 【智能时刻，架构君和你聊黑科技】 |
| 知识星球 | 认识更多朋友，职场和技术闲聊。 | 知识星球【职场和技术】 |
| 领英 | Harry | https://www.linkedin.com/in/architect-harry/ |
| 领英群组 | 领英架构群组 | https://www.linkedin.com/groups/14209750/ |
| 微博 | 【架构师酒馆】 | 智能时刻 |
| 哔哩哔哩 | 【架构师酒馆】 |
|
| 抖音 | 【cea_cio】架构师酒馆 |
|
| 快手 | 【cea_cio_cto】架构师酒馆 |
|
| 小红书 | 【cea_csa_cto】架构师酒馆 |
|
| 网站 | CIO(首席信息官) | https://cio.ceo |
| 网站 | CIO,CTO和CDO | https://cioctocdo.com |
| 网站 | 架构师实战分享 | https://architect.pub |
| 网站 | 程序员云开发分享 | https://pgmr.cloud |
| 网站 | 首席架构师社区 | https://jiagoushi.pro |
| 网站 | 开发者闲谈 | https://blog.developer.chat |
| 网站 | CPO工作宝典 | https://cpo.work |
| 网站 | 应用开发和开发平台 | https://apaas.dev |
| 网站 | 开发信息网 | https://xinxi.dev |
| 网站 | 超级架构师 | https://jiagou.dev |
| 网站 | 企业技术培训 | https://peixun.dev |
| 网站 | 程序员宝典 | https://pgmr.pub |
| 网站 | 首席安全官 | https://cso.pub |
| 网站 | CIO酷 | https://cio.cool |
| 网站 | CDO信息 | https://cdo.fyi |
| 网站 | CXO信息 | https://cxo.pub |
