SRE:Google运维解密_第四章服务质量目标

SRE 实践解读：提高服务可靠性

📖 前言

对 SRE 的兴趣源于我的实习工作。在实习中，通过内部文档📜的技术视角拓展，我意识到不能止步于传统的网络技术。技术在不断进步，我也必须紧跟其步伐。SRE（站点可靠性工程，Site Reliability Engineering）作为现代运维的理念，能够帮助我们更好地解决工作中的实际挑战。

🤖 SRE 概述

SRE 是 DevOps 的一种进化形式，它将软件工程的方法应用于运维，以提高系统的可靠性和效率。SRE 的核心目标是通过工程化手段来管理和优化系统的稳定性，并减少手动操作的比例，使得系统能在高负载下稳定运行。

💻 为什么选择这本书？

《SRE：Google运维解密》是了解 SRE 的最佳起点之一，因为它展示了 Google 这家全球顶尖科技公司如何管理其庞大的系统。在全球范围内承载海量数据的网络系统管理中，Google 一直处于领先地位。虽然书中提到的一些 Google 自研工具🛠️可能难以直接应用于日常工作，但它的思维方式和设计理念对我们扩展技术视野有很大启发。

🛡️ 服务质量（SLA、SLI、SLO）

服务质量对系统的运维至关重要，度量服务质量能帮助我们更好地维护系统的健康状态。书中介绍了三个核心概念：

SLI（Service Level Indicator）：服务质量指标，用于量化某个具体服务的表现，例如响应时间、可用性。

SLO（Service Level Objective）：服务质量目标，是期望的 SLI 值或范围。例如，99% 的请求在 200ms 内得到响应。

SLA（Service Level Agreement）：服务质量协议，是服务提供方与用户之间的协议，规定当服务质量未达 SLO 时的后果，通常会涉及补偿或罚款。

🛠️ 服务质量指标（SLI）

SLI 是某个服务的具体量化指标，例如：99% 的请求在 200ms 内得到响应。SLI 通常通过汇总一定时间范围内的数据来定义，如平均值、百分比等。可用性是一个常见的 SLI 指标，通常被定义为服务在给定时间内的可用百分比，例如 Google 云计算服务的可用性为 “3.5 个 9”——99.95%。

🎯 服务质量目标（SLO）

SLO 是针对某个 SLI 的目标值，用于设定用户对服务质量的期望。例如，游戏玩家期望游戏延迟尽可能低，这就是一种 SLO。书中提到，设定合适的 SLO 是一个复杂的过程，因为它受到外部请求量、系统负载等多种因素的影响。

设定 SLO 有助于合理设定用户期望，避免用户因服务性能不达标而产生抱怨。没有明确 SLO 的服务容易让用户形成不合理的期望，进而失去对系统的信任。

📝 服务质量协议（SLA）

SLA 是服务提供方和用户之间的协议，用于规定当服务未达到 SLO 时的后果，可能涉及财务补偿或其他类型的补偿。SRE 工程师通常不直接参与 SLA 的制定，因为 SLA 涉及到业务和法律问题，但他们会协助定义合理的 SLI 和 SLO，避免触发 SLA 中的惩罚条款。

🤔 如何选择 SLI 和 SLO

在选择 SLI 和 SLO 时，建议从用户的角度出发，理解他们对系统的真实需求🤔，并避免设置过多或不必要的指标。一般来说，四到五个代表性的 SLI 就足以评估系统的健康状况。我们应重点关注可用性、延迟、吞吐量和持久性等用户最关注的服务属性。

🛠️ 实践中的指标应用

在运维实践中，理解用户对系统的需求至关重要，并不是所有的系统指标都能成为有效的 SLI。书中建议，选择四到五个关键指标来评估系统的健康状况。以下是常见的 SLI 类型：

用户可见的系统服务：包括可用性、延迟和吞吐量。

存储系统：主要关注延迟、可用性和持久性。

大数据系统：关注数据处理的吞吐量和端到端延迟。

系统正确性：衡量系统返回的响应是否正确，这是所有系统都应关注的指标。

🛠️ 如何收集和汇总指标

大多数监控系统（如 Zabbix、Prometheus）都会在服务器端收集数据，有时也可以通过日志分析系统📃来分析服务请求的状态。书中提到，在度量用户体验时，过于关注后端延迟可能会忽略用户在前端看到的实际延迟。因此，度量页面在浏览器中的响应延迟可能是更好的用户体验指标。

💻 数据汇总

监控数据通常非常庞大，因此我们需要通过汇总来简化数据，使其更易于使用。书中强调，应使用数据分布而非平均值来衡量响应时间，因为分布能更好地反映系统中的长尾问题，从而帮助发现和解决延迟与性能下降的问题。

🎯 SLO 与系统优化

合理设定 SLO 有助于优化系统，但过于严苛的 SLO 会增加运维压力，损害创新能力。书中提到一个重要的概念——错误预算（Error Budget），即对于未达到 SLO 的容忍度。通过监控错误预算，可以在保证系统可靠性的前提下为新版本发布提供依据，平衡可靠性与创新速度。

💻 目标的选择和应用

选择 SLO 不是单纯的技术活动，还涉及到产品和业务层面的权衡。书中给出了一些建议：

不要仅以当前状态为基础选择目标：应从全局出发，避免团队长期维护过时的系统。

保持简单：过于复杂的目标可能掩盖系统真实问题，增加理解的难度。

避免绝对值：绝对值通常不切实际，难以实现。

SLO 精简有效：SLO 应该尽量少而精，确保其准确有效。

不要追求完美：可以从宽松的目标开始逐步优化，而不是一开始就设定一个很难达成的目标。

🎯 SLO 和用户预期管理

通过公布 SLO，可以为用户设定合理的期望。SLO 的设定也应保留一定的余量，以便在遇到问题时能够快速响应并解决。

📝 服务协议（SLA）在实践中的应用

SLA 通常由业务和法务部门共同制定，SRE 工程师在其中作为协助者的角色，帮助这些部门制定合理的 SLI 和 SLO，避免因未达标而触发 SLA 的惩罚条款。

📈 小结

本章介绍了服务质量的概念及其实践应用，重点讨论了如何通过 SLI、SLO 和 SLA 来有效管理系统的可靠性和用户预期。通过合理的指标和目标，我们可以更好地度量、优化和提升系统服务质量，从而为用户提供可靠的体验。