如何设计SLA、SLO、SLI

最新推荐文章于 2026-05-02 06:47:18 发布

原创最新推荐文章于 2026-05-02 06:47:18 发布 · 1.3k 阅读

15 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#运维 #数字化 #服务管理 #ITSM #ITIL

项目管理同时被 3 个专栏收录

6 篇文章

订阅专栏

管理学

5 篇文章

订阅专栏

服务管理

3 篇文章

订阅专栏

简介

按我理解，经营一家公司始终离不开用户（包括内部用户和外部用户），用户对公司提供的产品或服务付费，公司向用户提供产品服务，这是一种商业规律。公司设计产品或服务、给产品或服务定价，而用户期望得到与自己所付费用对应的产品或服务。用户可能会问：

您的系统多久可用一次？
如果系统出现故障，您的团队会以多快的速度做出响应？
您对速度和功能做出了什么样的承诺？

为帮助各方在服务水平方面达成共识，我们需要制定和维护一些规则与标准：

SLA（服务级别协议）：对用户的承诺
SLO（服务级别目标）：帮助我们信守承诺的内部目标
SLI（服务级别指标）：评价我们做得怎么样（绩效/表现的可跟踪度量）¹

什么是 SLA？

SLA（服务级别协议） 是服务提供方与客户之间达成的协议，明确了正常运行时间、响应能力和责任等可量化指标。你可以将其理解为一份定义服务承诺的合同条款。
这些协议通常由企业的新业务部门和法律团队起草，旨在明确客户期望，并规定未能兑现这些承诺的后果（例如罚款）。SLA 是企业向客户作出的正式承诺。

SLA 的挑战

在实践中，SLA 往往面临以下挑战：

难以衡量：某些承诺很难量化，缺乏具体标准。因为编写协议的人本身可能不在业务最前线，做出的承诺对最终执行团队来说很难衡量，并不总是与当前和不断发展的业务优先事项保持一致，并且不考虑细微差别。
难以报告：缺乏完善的追踪和报告机制。
难以满足：协议条款常常不切实际或未考虑技术细节。

例如，国内有的销售不怕事大，随口答应客户2小时内解决系统故障，也不会考虑解决过程中可能需要客户参与，但却没有在SLA中并没有明确由于客户自身原因引起的超时怎么划分责任，又或者没有充分考虑自己的团队有没有能力在2小时解决等等一系列问题，导致实际执行中的产生分歧，很容易让执行的人/团队讨厌。

改进建议

技术团队（如 IT 经理和 DevOps）应参与 SLA 的制定，与法律和业务团队协作，确保条款能够反映实际场景和执行的可能性。

SLA适用性

SLA 通常适用于提供商与付费用户之间的协议，而对于免费用户来说，SLA是非必需的。

什么是 SLO？

SLO（服务级别目标） 是 SLA 中定义的具体指标（例如正常运行时间或响应时间）的具体目标。简单来说，如果 SLA 是正式承诺，SLO 则是企业对客户设定的具体目标，用以指导内部团队的工作，告诉 IT 和 DevOps 团队他们需要达到的目标并据此衡量自己。

SLO 的挑战

与 SLA 相比，SLO 拉到执行人/团队的仇恨会少一些，但如果SLO含糊不清、过于复杂或无法衡量，它们也会产生同样多的问题。制定优秀 SLO 的关键在于：

简单明确：仅关注对客户最重要的指标。
可量化：确保目标具体可测量。
考虑延迟因素：当客户自身导致问题解决时间延长时，SLO 应明确如何处理这些情况。

SLO适用性

SLO 对付费和非付费用户，以及内部和外部客户都非常有用。尤其是对内部系统（如 CRM 或内部数据平台）设定 SLO，有助于优化企业运营目标，并支持团队实现自身的服务承诺。

什么是 SLI？

**SLI（服务级别指标）**是用于衡量 SLO 达成情况的指标。为了始终遵守SLA，SLI 需要满足或超过SLA中做出的承诺。例如，若 SLA 要求系统 99.95% 的正常运行时间，那么 SLO 可能设定为 99.95%，而 SLI 则是实际运行时间的测量值（如 99.95%、99.96% 或 99.99%）。

SLI 的挑战

SLI 的难点在于：

保持简洁：避免追踪过多无关（对客户实际上并不重要）的指标。
选择关键指标：仅跟踪对客户影响最大的指标，以免增加 IT 团队的工作负担。

SLI适用性

任何依据 SLO 衡量服务绩效的企业都需要 SLI，以准确评估目标的达成情况。没有 SLI，SLO 将无法执行。

SLA、SLO 和 SLI 最佳实践

通过合理制定 SLA、SLO 和 SLI，企业可以更好地管理客户期望、提高服务质量，并优化内部团队的工作效率。

1. 根据客户期望制定 SLA
SLA 应聚焦于客户关注的核心事项（围绕对客户重要的事情），而非技术细节。例如，与其对系统的每个组件逐一承诺，不如直接定义整体服务的用户体验指标（如系统可用性、满意度）。实际上，也可能会有些客户乐意要把某些细化的指标项写进SLA，这个就需要提供方评估是否合理了（如价钱是否给到位、考评是否会过于复杂等）。

2. SLA使用简明语言
复杂的语言可能导致误解和争议。清晰、直白的表达可以减少客户困惑，降低潜在冲突的风险。我见过某国企的IT运维经理怕担责，写了差不多十页的SLA。一是他的SLA得看半天，二是他的设计逻辑令人费解，三是啥都想要让供应商找不到重点，并且每期扣款近20%，甚至有倒扣的现象。

3. 对 SLO，少即是多
仅为最关键的客户需求设定 SLO，避免过度承诺。确保目标简单易懂且与客户成功直接相关。还是上面那个例子，希望服务提供方能够争取利益平衡。

4. 选择关键的 SLI
不要为每个 SLO 的所有子指标单独设定 SLI，而是专注于那些对核心目标最重要的指标，提升测量效率。

5. 包括无法控制的因素
明确 SLA 和 SLO 中客户责任的范围。例如，当客户延迟提供信息时，是否暂停计时？通过合理定义，可以避免团队因不可控因素被施加不合理的绩效要求。