你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
云监视服务级别目标
本文是云监视指南系列教程的一部分。
在以下部分中，你将了解服务级别目标的基本原则，以及如何实现和应用它们。
概述
服务级别目标（SLO）是关键以客户为中心的服务级别指标（SLI）的可衡量目标。 它们衡量客户对业务或基础结构工作负载的体验，并确定业务服务提供商是否符合正式协商服务级别协议（SLA）或各方之间的非正式协议中的承诺。
作为 Service Broker，你依赖于 Microsoft 对 Microsoft 针对 Azure 服务的服务级别协议中定义的服务可靠性的承诺。 这样，就可以专注于服务链中的职责，例如综合监视、网络连接和安全性与合规性。
术语
下面是每个术语的定义和简要说明。 这些定义取自 Google 的 SRE 手册。
| 术语 | 说明 |
|---|---|
| 服务级别协议（SLA） | 通常是服务提供商和客户之间的绑定承诺。 协议通常包括缺少 SLO 目标的后果。 服务的特定方面是服务提供商和服务使用者之间商定的质量、可用性和职责。 |
| 监视 | 收集有关服务和系统的定量实时数据的做法。 |
| 度量值 | 度量相关的服务行为，并可以聚合到服务级别指标（SLI），这些指标经过处理和聚合，以度量服务的当前操作状态并量化其行为。 SLI 是服务当前运行状况的主要实时指标。 |
| 日志 | 从代码开始，并报告有关单个执行代码路径或谨慎事件的信息。 使用此信息来帮助排查并努力确定影响 SLI/SLO 衡量的客户体验和服务可靠性的根本原因问题。 |
| 服务级别目标 （SLO） | 服务级别的目标值（由服务级别指示器（SLI）测量，用于设置服务性能的预期。 SLO 专门跟踪端到端客户体验。 若要建立良好的 SLO，通常首先定义所需的体验，然后检测服务代码来衡量该体验（收集相关的 SLI），并设定你如何满足客户期望的目标。 |
| 服务级别指示器（SLI） | 一个指标，用于量化服务的质量或可靠性。 至少会评估四个常见的 SLA： 可用性、 延迟、 吞吐量和 错误率。 |
| 可用性 | 通常是指系统正常运行和正常运行的时间的可度量或可观测百分比。 将可用性衡量为面向客户的体验连续性目标，这受一个或多个可靠性问题（以及与配置更改、应用更新等相关的其他故障模式）的影响。 |
| 错误预算 | 有关 SLO 的剩余缓冲区的百分比。 错误预算是 DevOps 的工具，IT 用于平衡服务可靠性与创新步伐。 |
SLO 的用途
SLO 在云工作负荷的开发和操作中提供许多基本用途，包括：
- 准实时（NRT）：提供客户体验的服务运行状况的 NRT 视图。
- 缩短通知时间（TTN）：为客户推动服务问题的自动通知，显著缩短通知时间（TTN）。
- 主要信号给客户：充当部署操作的主要信号，在出现问题时推动自动回滚，从而减少客户面临潜在问题。
- 更改验证：提供验证，使更改实现了预期的客户体验改进。
- 确定优先级：帮助团队了解是构建功能还是处理可靠性。
- 服务运行状况见解：启用以客户为中心的客观讨论服务运行状况。
- 缩短分析时间：通过将焦点定向到负责任的服务，加快客户问题的缓解和根本原因分析（RCA）。
- 体系结构依赖项：在服务采用依赖项时，充当体系结构决策的基本输入。
- 构建信任：提供对运行状况措施的共享理解，从而在团队之间建立信任。
- 带来透明度：公开用于为客户经营业务所需的相同 SLA，以便客户能够运行业务。
- 单窗格：为服务启用水平单一玻璃窗格及其依赖项和故障接收器。
通过使用 SLO 来推动工程过程，DevOps 和 IT 可以尽早了解他们在 Azure 中生成或迁移的应用程序或基础结构服务的运行状况。 然后，这可以用于推动需要对这些服务的可靠性做出的人工和自动化决策。 工程实践中的这种转变将极大地影响短期内这些服务的可靠性。
如何定义 SLO？
SLO 的目的是从客户的角度获取准确测量质量的明确信号。 每个服务团队都会创建一组服务级别目标 (SLO)，这些目标定义了服务使用者所体验到的服务最重要的可衡量指标的允许范围。 SLO 是服务发出的指标的已定义数值目标。 可以监视与此目标关联的指标，以确定服务是否正常。
例如，下面是基于 Web 的内部时间跟踪应用程序的 SLO 的简化示例 - 过去 5 分钟内的请求在 99% 的 1000 毫秒内提供。
这些指标是称为服务级别指示器（SLI）的时序数据的聚合。 收集 SLI 的位置很重要。 在上面的示例中，如果客户使用 API 与服务交互，则测量系统处理请求的时间是准确的 SLA。 但是，如果客户使用 Web 门户与服务交互，则请求的总服务时间还应包括网页的 JavaScript 性能。
服务所有者的重点是确定以下内容：
- 从客户的角度来看，哪些方案是服务运行状况的关键指标，
- 在哪里收集 SLI，才能让他们尽可能接近客户体验，以及
- SLO 应该针对这些 SLA 是什么 ？
SLO 可以采用逐步方法来推动成就，也可以由业务直接规定。 使用服务定义的 SLO 制定体系结构决策，以了解如何生成 SLA。 因此，必须仔细选择要度量的方案，以及要测量它们的时间范围。 总之，SLO 由以下值组成：
- SLI。 例如，从负载均衡器测量的足够快的请求的比例小于 400 毫秒。
- 持续时间。 衡量指标的时间段。
- 目标。 例如，希望在给定持续时间内满足的快速请求占总请求的目标百分比（例如 90%）。
SLO 的类型
纵观整个行业，有两种类型的 SLO：
以服务为中心的 SLO - 这些 SLO 是团队定义的战术目标，旨在随着时间的推移逐步提高服务质量。 它们旨在成为在工程里程碑中实现的务实目标。 例如，如果某个服务当前实现 99.7% 的可用性，团队可以设定一个目标，在下一季度达到 99.9% 的可用性。
以客户为中心的 SLO - 这些 SLO 定义了理想的未来状态或目标。 此时，对质量的进一步投资被认为是不必要的，因为你正在充分满足客户的期望。
例如，如果客户期望你运营的业务或基础结构服务提供 99.99% 的可用性，而该服务当前仅实现 99.8% 的可用性，则以客户为中心的 SLO 仍为 99.99%。
定义适当的 SLO 需要时间。 第一步是与客户交谈，并了解用户希望从服务中获取少量指标并将其记录在一起。 了解他们如何使用你的服务以及服务需要提供哪些功能才能成功运行其业务的方案和容忍度。 这通常是一种反复的体验，他们的期望范围从“我希望在所有条件下实现 100% 的可用性，而不会影响我们的收入流”，到管理客户细分市场之间的相差较大的期望。
仅查看服务（或服务实例）运行状况的监视方法容易受到两端缺少客户体验问题的侵害：服务运行状况并不总是与客户体验的质量相关。 这是因为 Azure PaaS 和 SaaS 服务之间存在不同的行为特征、这些 Azure 服务的配置、部署资源的方式和位置（即哪个区域）以及添加自定义代码/逻辑，这增加了进一步的复杂性。
定义 SLO 时，请务必记住云提供商是 SLA 的依赖项。 考虑为其每个服务指定的服务级别协议。 对于 Azure，请参阅 联机服务的服务级别协议（SLA）
如何定义 SLI？
SLI 规范是用户对服务的特定可靠性维度的预期正式声明，例如延迟或可用性。
首先，选择正确的指标来度量和收集，并且不要通过收集过多不有意义的指标来使它复杂化。 确保定义的 SLI 与客户体验有直接关系。 这就是为什么必须了解用户从几个指示器开始的观点。
如果服务以某种方式受到资源限制，例如内存或 CPU，则其饱和度也可能是出色的 SLI。 但是，饱和度不应用作 SLO，因为它不直接对应于较差的用户体验（服务可能具有较高的内存利用率，但用户不受影响）。
建议最多创建三个指示器。 三个以上的指标很少能增加重要价值。 通常，过多的指示器可能意味着你包括主要指标的症状。 流量和饱和度应是这三个主要指标的补充，因为这些指标描述了服务负载和支持对其他服务指标的解释。
如何实现 SLO？
最重要的 SLA 是最明显地代表客户对服务的影响的 SLI。 对于许多服务，这包括延迟、吞吐量、错误率和可用性。 如果服务有任何影响客户体验的特殊注意事项，则还应测量这些领域的 SLI。 例如，消息传递服务的端到端处理延迟是客户体验的直接指标，应由 SLI 涵盖。
SLO 示例
人力资源有兴趣在企业 IT 的帮助下将其内部时间跟踪 Web 应用程序现代化，并将其托管在 Azure 云中。 他们希望组织中的所有用户都能继续使用该服务，因此他们应关注以下内容：
- 使用情况报告，以及一段时间内有多少用户在使用该服务。
- 定期运行状况监视，例如可用性、性能、安全性和合规性（服务保修）。
- 成本，例如服务的每月成本。
- 网络安全，通过遵循零信任安全策略来控制对资源和数据的访问。
如以上示例中所示，在服务设计早期定义 SLO/SLI 类别和示例是必要的。 这与一直在生成的本地服务没有任何不同。
SLO 表/SLI 类别
以下示例绝非详尽列表。 虽然可靠性和可维护性 SLO 是几十年来系统的标志，但你可以定义 SLO，其中包括网络安全、质量和用户体验以及成本度量值。
服务
服务或系统的典型高级度量值通常在服务协议中编码。 大多数新式协议衡量可用性作为关键 SLO，并根据关键工作负荷项或生产单位（例如身份验证令牌、邮箱或存储帐户）使用简单的停机时间度量。
| 类别 | 说明 | 示例 |
|---|---|---|
| 可用性 | 简单空闲时间或平均维护间隔时间或操作可用性 (MTBM/[MTBM+MDT]) | 每月 99.99% |
| 容量 | 确保有足够的、最大或最佳的业务和服务性能、吞吐量、存储、人员、带宽、需求、资源和服务功能。 包括作为触发器的劳动力和时间限制。 | 利用率百分比（CPU、存储、内存、延迟、吞吐量、缩放） |
| 安全性 | 对业务、资产和数据造成损害的活动威胁和漏洞（内部和外部）。 | 检测 HAFNIUM 威胁 |
| 合规性 | 更新、服务级别、强化合规性、所需的配置偏移 | 对所有资产进行 99.5% 的服务更新 |
| 连续性 | 能够从大型灾难和外部事件中生存和恢复。 | 时间（重建） |
| 服务质量 (QoS) | 用户实际体验随时间推移的特征。 | Teams 通话质量 - 收到的数据包丢失 < 2% |
可靠性
可靠性（经典 SLO）意味着随着时间的推移，系统、服务、资源或组件到故障和故障转移的依赖性、持久性和质量的程度，管理工作应用于解决故障（例如在更多冗余中构建或添加内容分发网络）以提高运行时间或可用性。 它还可能意味着用于测量 SLO 的数据的准确性、保真度、完整性和可信度。 这可能意味着系统将在指定条件下执行其预期功能的经典 概率 ，例如温度压力。 复原能力还包括提供适应性的内置设计因素或功能，例如缩放、冷却、负载均衡、恢复、不可预知的需求、严重压力下的性能下降，以及大型灾难（通常是单独的 SLO）的连续性设计。
| 类别 | 说明 | 示例 |
|---|---|---|
| 失败率 | 总运行时间内的故障数 | 973 小时内发生 5 次故障，失败率为 .00514 |
| 平均无故障时间 (MTBF) | MTBF 是故障率的倒数 | 194.6 小时 |
可维护性
将事件和问题管理等 IT 服务管理流程的支持 SLO 与可靠性 SLO 相结合，从而实现可用性度量。
| 类别 | 说明 | 示例 |
|---|---|---|
| 服务事件性能 | 按类别或产品或优先级。 | 事件生命周期每个阶段的时间和成本度量值。 |
| 安全事件性能 | 按类别或产品或优先级。 | 事件生命周期每个阶段的时间和成本度量值。 |
| 组件平均修复时间 (MTTR) | 从事件检测到还原或修正。 | |
| 平均维护间隔时间 (MTBM) | 所有维护操作之间的平均或平均时间，包括发生正常生产工作的预防性操作。 | 请参阅“维护延迟时间” |
| 维护延迟时间 (MDT) | 从检测到恢复的总时间，包括物流和管理延迟。 | 更换硬件的时间，包括订购、发货和安装。 |
客户体验
| 类别 | 说明 | 示例 |
|---|---|---|
| 吞吐量 | 随时间推移，放置在系统上的工作负载或生产负载的数量、速率或速度。 | 每单位时间的事务数。 |
| 错误率 | 总错误数（以百分比表示）。 | 安全事件百分比 |
| 延迟 | 从输入到输出、工作在进程中的移动或从应用程序到用户的时间或延迟度量值。 | 平均秒数。 |
其他
| 类别 | 说明 | 示例 |
|---|---|---|
| 成本 | 按服务、组件或时间度量支出、计费和发票。 | 资本支出或运营费用 |
| 覆盖率 | 管理下的组件、系统和服务的百分比（合规性） | 合规性 |
| 源可靠性 | 检测信号、连接器、更改等故障。 | 跟踪任务关键型公司数据的更改。 |
| 工作效率 | 高效完成任务的效率 | 劳动力、员工时间、分析师工作效率。 |
注意事项
确保访问。 确保组织中的经理和其他角色有权访问 Azure Monitor 或其他 Azure 服务（尤其是 Azure SaaS 和 PaaS）中提供的可视化效果，以避免重复。
确保监视覆盖范围或总资产可见性。 确保代理、发出的日志、表和查询需要管理和保护的所有资产，并确定覆盖中的“盲点”或空白，以确保 SLA 中的现实性。
在正确的使用者面前获取正确的数据。 确保 SLO 和 SLI 的使用者可以解释基础数据，以使用从数据获取的信息生成信任和指导决策。
做出合理的承诺。 将 SLO 设置为 目标 时，尤其是当成本管理至关重要时，请确保实际系统性能不会过度执行或交付不足，或调整目标以管理客户期望。
考虑不可预见的外部事件。 制定连续性计划和风险评估，以考虑不可控事件，例如天气、停电或自然灾害。
考虑更改。 确保 SLO 考虑到对服务的更改或对技术可靠性、吞吐量、质量和可维护性的更改，例如支持人员的减少。
提供一组均衡的 SLO。 确保对服务或系统提供均衡或 360 度 透视的 SLO 范围，并专注于可靠性。