网站可靠性入门：SLA、SLI、SLO是什么？如何设定你的服务目标

时间：2025-08-12

编辑：tance.cc

在你的团队里，是不是也流传着这样一个“神圣”的目标——“我们的网站，要做到100%的可用性！”

听起来多么鼓舞人心，多么追求极致。它仿佛代表着一种对技术、对用户的终极承诺。但今天，我想告诉你一个反直觉的真相：追求100%的可用性，不仅是不可能的，更是一个危险且有害的目标。

为什么？

想象一下，你开了一家披萨外卖店。你向全城承诺：“我们的披萨，保证0分钟送达！” 这听起来是不是很荒谬？为了实现这个目标，你可能需要给每个街区都配一个厨师和外卖员，禁止他们上厕所，并且祈祷永远不会堵车。这不仅成本高到无法想象，更扼杀了你推出新口味、优化流程的所有可能性，因为任何一点点“风险”都可能打破你那“0分钟”的神话。

100%的可用性，就是技术世界里的“0分钟送达”。它会让你的团队为了守护那最后一个“9”，而陷入无休止的、被动的“救火”状态，不敢做任何创新，最终被敢于承担合理风险的竞争对手所超越。

那么，如果我们不追求那虚无缥缈的100%，我们又该追求什么呢？

欢迎来到网站可靠性工程（SRE）的核心思想圈。谷歌的工程师们，早已为我们提供了一套更成熟、更科学、更人性化的框架，来定义和衡量我们对用户的“承诺”。这个框架，就建立在三个看似神秘的缩写词之上：SLA、SLI和SLO。

今天，就让我们彻底搞懂这三者的关系，学会如何设定真正有意义的服务目标，让你的“监控”，不再只是一个简单的“心跳检测器”，而是一个能指导你业务决策的“战略罗盘”。

第一章：“三位一体”的承诺 —— 用“披萨外卖”讲清楚SLA, SLO, SLI

为了让这三个抽象的概念变得可以触摸，我们将用一个贯穿全文的比喻：你经营着一家广受欢迎的在线披萨外卖服务。

SLA (Service Level Agreement) —— 服务等级协议

这是你对“顾客”的公开承诺，通常带点法律意味。
披萨店的比喻： 你在披萨盒上、在广告里，用最大号的字体写着：“披萨30分钟内保证送达，超时免单！”
定义： SLA是你和你的用户之间，一份正式或非正式的“协议”。它定义了服务的可用性标准，以及，如果未能达到这个标准，会产生什么后果（比如退款、赔偿服务时长等）。SLA通常是由商务或法务部门驱动的，它的目标是保护用户利益和公司信誉。它是一个对外的承诺。

SLO (Service Level Objective) —— 服务等级目标

这是你给“后厨和外卖团队”设定的内部奋斗目标。
披萨店的比喻： 作为经理，你对你的团队说：“听着，我们对外的承诺是30分钟。但为了留出缓冲，我们的内部目标是：确保99.9%的订单，在25分钟内完成配送。”
定义： SLO是衡量你的服务是否可靠的内部目标。它是具体的、可量化的，并且通常比对外的SLA更严格。比如，你的SLO可能是“在过去30天内，网站首页的成功访问率达到99.95%”。SLO是研发和运维团队工作的核心驱动力，是他们衡量自己工作成果的标尺。它是一个对内的目标。

SLI (Service Level Indicator) —— 服务等级指标

这是你用来衡量是否达到目标的“秒表和GPS追踪器”。
披萨店的比喻： 为了知道你是否达成了“99.9%的订单25分钟内送达”这个SLO，你需要测量什么？你需要两样东西：1）每一份披萨出炉的时间戳；2）每一份披萨送到顾客手上的时间戳。这两个时间戳相减，就是配送时长。这个“配送时长”，就是你的SLI。你还需要另一个SLI：“订单成功送达率”。
定义： SLI是一个对服务某个维度的量化指标。它必须是可测量的。常见的SLI包括：

可用性（Availability）： 成功请求的比例。计算公式：（成功请求数 / 总请求数） * 100%
延迟（Latency）： 响应时间低于某个阈值的请求所占的比例。计算公式：（响应时间 < X毫秒的请求数 / 总请求数） * 100%
吞吐量（Throughput）： 系统每秒处理的请求数。
正确性（Correctness）： 返回了正确数据的请求所占的比例。

现在，让我们把这三者串起来，形成一句完整的“咒语”：

我们通过监控工具，持续不断地测量一系列的 SLI（比如我们披萨店的“配送时长”），来确保我们的团队能够达成我们设定的 SLO（99.9%的订单在25分钟内送达），从而让我们有信心去履行我们对外的 SLA（超时30分钟就免单）。

看，它们之间的逻辑关系，是不是瞬间清晰了？

第二章：目标的艺术 —— 如何设定一个“好”的SLO？

理解了定义，下一个问题是：我该如何为我的网站，设定一个科学合理的SLO？

1. 测量那些用户真正在乎的东西

你的SLO不应该是“服务器CPU使用率低于80%”。为什么？因为用户根本不关心你的CPU。一个CPU使用率95%但响应飞快的网站，远比一个CPU 10%但每次点击都转圈的网站，要好得多。
要从用户的视角出发。 用户在乎什么？

可用性： 我能打开你的网站吗？
延迟： 你的网站打开够快吗？
正确性： 打开的页面，是我想要的那个，内容完整吗？

你的SLO，就应该围绕这些用户能直接感知的维度来设定。

2. “错误预算”的魔力 —— 在“可靠”与“创新”之间跳舞

这是SRE思想中最具革命性的一个概念。

我们先来量化一下“几个9”到底意味着什么：

99% 可用性 (“两个9”) = 每月最多允许 (1-0.99) * 30天 * 24小时 * 60分钟 ≈ 7.2小时 的宕机时间。
99.9% 可用性 (“三个9”) = 每月最多允许 ≈ 43.8分钟 的宕机时间。
99.99% 可用性 (“四个9”) = 每月最多允许 ≈ 4.38分钟 的宕机时间。

现在，“错误预算”登场了。它的定义极其简单：错误预算 = 1 - SLO。

如果你为一个服务设定了99.9%的可用性SLO，那么你就拥有了0.1%的“错误预算”。

这个预算是什么意思？它意味着，在这个月里，你有43.8分钟的时间，是“被允许出问题的”。

这是一个颠覆性的想法！它不再将“故障”视为一种需要被谴责的“事故”，而是将其视为一种可以被管理的、必然存在的“成本”。

如何“花掉”这个预算？

发布一个有风险的新功能？这可能会消耗掉10分钟的预算。
进行一次系统升级？这可能会消耗掉5分钟。
发生了一次意外的宕机？这消耗了20分钟。

错误预算耗尽了，会怎么样？

SRE的核心原则是：一旦某个周期的错误预算被耗尽，所有的新功能发布、所有非紧急的变更，都必须被冻结！ 整个团队的唯一目标，就是投入所有精力去提升系统的稳定性，直到下一个周期，我们重新获得预算。

看到了吗？“错误预算”就像一座天平，一端是“创新与迭代的速度”，另一端是“系统的稳定与可靠”。它为“开发团队想快点上功能”和“运维团队想尽量求稳定”这对永恒的矛盾，提供了一个完全由数据驱动的、不含任何个人情绪的决策框架。

第三章：“战略罗盘”的数据来源 —— 监控平台如何提供SLI？

这一切听起来都非常美好，但有一个最根本的问题：我们用来衡量SLO的那些SLI指标，那些原始的、精准的“秒表读数”，从哪里来？

答案是：从你专业的、7x24小时的监控平台而来。

本站提供的在线监控平台，其核心功能之一，就是为你提供计算SLO所需的最关键的SLI。

可用性SLI：

我们的HTTP(S)监控，每分钟从全球节点访问你的网站。月底，你可以轻易地得到总的请求次数和成功的次数。（成功次数 / 总次数） * 100%，这就是你最核心的可用性SLI。

延迟SLI：

每一个监控点，都记录了详细的响应时间。你可以轻易地导出一个月的数据，然后计算出“响应时间低于500ms的请求占比”。这就是你的延迟SLI。

正确性SLI：

利用我们监控任务中的“内容匹配”功能，你可以检查页面是否包含某个“必定存在的关键字”。（关键字匹配成功的次数 / 总次数） * 100%，这就是一个基础的正确性SLI。

你的监控仪表盘，本质上，就是一个实时SLI数据的大屏。它上面的每一条曲线、每一个数字，都是你用来衡量SLO、管理错误预算的“原材料”。没有精准的SLI测量，SLO和错误预算，就都成了空中楼阁。

SLA, SLO, SLI这套框架，其真正的力量，不在于那几个听起来很酷的缩写词，而在于它在团队内部，建立了一种共同的语言和一种共同的文化。

它让产品经理、开发者、运维工程师和业务决策者，能够坐在一起，看着同一份数据，用同一种语言，来讨论“可靠性”这个原本极其主观和感性的话题。

它用冰冷的数据，取代了“我觉得网站最近有点慢”这样模糊的抱怨。它用可量化的“错误预算”，取代了“到底该快点上功能，还是该先保证稳定”这样永无休止的争吵。

它让“可靠性”，从一个模糊的“质量属性”，变成了一个可以被设计、被测量、被管理、被迭代的“产品功能”。

去和你的团队聊聊吧。从定义第一个简单的SLI开始，设定第一个有意义的SLO，然后，开始享用你们的“错误预算”。这不仅仅是一次技术实践，这更是一场关于如何更科学、更成熟地构建和运营线上服务的、深刻的管理革命。

资讯与帮助

网站可靠性入门：SLA、SLI、SLO是什么？如何设定你的服务目标

第一章：“三位一体”的承诺 —— 用“披萨外卖”讲清楚SLA, SLO, SLI

第二章：目标的艺术 —— 如何设定一个“好”的SLO？

第三章：“战略罗盘”的数据来源 —— 监控平台如何提供SLI？