在实际运维中，企业通常会将 SLO 作为判断关键数字服务是否达到预期可靠性水平的依据。然而，写下一条 SLO 很容易：选择一个指标，再填写一个目标值即可。但让它真正服务于日常运维，并非易事。

多数团队已经接入了指标、调用链、仪表盘和告警规则，但往往缺少一个可以共同确认且有数据依据的答案：哪些指标能够真实反映关键业务的运行状态？这些指标处于什么范围时，才意味着业务运行正常？

在很多团队中，启动 SLO 工作时，目的往往很明确：为关键业务建立可靠性目标。

但实际推进中，SLO 常常成为一份孤立的产物。服务目标可能写在文档里，PromQL 查询放在仪表盘中，服务负责人也清楚哪些链路更重要；但支撑这些判断的依据，仍然分散在不同的人和工具之间。

因此，每次建立或复核 SLO，团队都要重复一套人工流程：

1. 查找服务清单、拓扑、运行手册和历史巡检报告。

    

2. 判断哪条用户旅程真正影响核心业务。

    

3. 在指标、调用链和 Kubernetes 数据之间切换，找到有代表性的业务流量时段。

    

4. 检查错误率、延迟、可用性、重启和资源压力。

    

5. 根据观察结果设定目标，并编写相应的仪表盘查询。

    

6. 到下一次健康巡检或复盘时，再重新建立这些上下文。

难点不是工程师不会做这项工作，而是过程割裂、难以复核与复用。没有目标依据的仪表盘很难建立信任；没有实时视图的 SLO 很难运营；而缺少原始业务上下文的健康巡检，往往又会回到重复收集指标的起点。

要建立可用的 SLO，需要以下三个步骤：

• 团队需要先识别关键用户旅程，确定能够反映业务状态的指标；

   

• 再找到有代表性的流量窗口、验证底层查询，并依据数据设定目标；

   

• 最终形成可持续使用的仪表盘。

云智慧 Castrel AI 可以接管上述步骤。

用户为应用发起 SLO 请求后：

1. Castrel AI 会先读取应用上下文并探索可观测性数据

    

2. 再据此定义服务目标、生成可视化仪表盘，并将相关结果沉淀为应用知识

    

3. 最终得到的不只是文档或图表，而是一套可供后续健康巡检引用的运行基线

后续开展巡检、复盘或目标校准时，团队可以沿用同一套目标、阈值、查询和历史依据，而不必每次重新拼装判断标准。

下面以一个典型的微服务火车票预订应用为例，说明 Castrel AI 如何从关键业务旅程出发，生成并验证一套可用的 SLO 仪表盘。

第一步：识别关键业务旅程，找到有效数据窗口

数据是设定 SLO 目标的重要依据。在本案例中，识别出的核心购票路径为：

确定核心购票路径后，还需要找到能够代表正常业务状态的数据窗口。业务基线并不一定需要根据最新数据建立。在本次工作流中，应用近期的流量很低，因此最近 24 小时的视图无法代表正常用户行为。

Castrel AI 先读取应用上下文和既有巡检 SOP，随后查看过去 7 天的 Prometheus 数据，并从中定位到存在有效业务流量的历史窗口。它将 7 月 28 日至 7 月 31 日作为工作基线，检查三类核心信号：

• prod-chaos 命名空间内各服务的错误率；

• 订单服务及其他活跃服务的 P95 延迟；

• Kubernetes Deployment 就绪率。

在这个活跃窗口中，多数实际承载请求的服务，观测到的：

• 错误率为 5%–15%；

• ts-consign-service 持续出现 100% 错误；ts-order-service 的 P95 延迟通常处于 1–8 秒；

• Deployment 就绪率保持在 100%。

这些观测结果分别反映了服务错误情况、订单响应性能和基础设施就绪情况，并为下一步设定可用性、延迟和就绪率目标提供参考。

值得注意的是，上述数据仅反映本次工作流所选历史窗口的运行状态，不能直接作为其他系统的 SLO 标准。

基于前一步确定的业务旅程、历史基线和实时数据模型，Castrel AI 使用 OpenSLO（一种用于标准化描述服务目标的规范）生成了 4 条 SLO 定义：

这 4 条 SLO 从业务可用性、基础设施就绪情况、订单服务性能和服务活跃程度四个方面衡量应用状态，具体计算方式如下：

• 购票旅程可用性：计算非错误请求数占总请求数的比例，用于判断核心交易链路是否可用。

   

• 基础设施就绪率：比较可用副本数与期望副本数，用于判断 Kubernetes Deployment 是否达到预期状态。

   

• 订单服务 P95 延迟：跟踪 ts-order-service 的 P95 Span 时延，用于观察下单性能是否发生退化。

   

• 服务活跃覆盖率：计算有流量服务占已观测服务的比例，用于发现服务静默或活跃服务减少的情况。

围绕这 4 条 SLO，Castrel AI 进一步生成了 10 个可视化面板。前 4 个面板直接呈现 SLO 的达标情况：

1. 购票旅程可用性

2. 基础设施就绪率

3. 订单服务 P95 延迟

4. 服务活跃覆盖率

其余 6 个面板用于补充观察服务运行状态和潜在风险：

5. 各服务错误率

6. 各服务请求速率

7. 各服务 P95 延迟

8. 30 分钟窗口内的 Pod 重启健康度

9. 使用率超过 85% 的容器内存风险

10. 错误率 Top 5 服务

这样，团队可以在仪表盘的同一视图中持续查看业务目标及其支撑信号，并据此判断用户旅程是否健康、基础设施是否就绪、哪些服务仍在承载流量，以及哪些资源或稳定性信号需要关注。

生成一条查询，与生成一个可用面板，并不是同一件事。

在本次工作流中，容器内存风险面板最初加载失败。Castrel AI 直接在 Prometheus 中验证查询，并定位到指标关联中的重复时序问题：同一个 Pod 和容器标签组合，因为 id 标签不同，对应了多条时序数据。

随后，Castrel AI 使用 sum by (pod, container) 对查询两侧的数据进行聚合，再以 pod 和 container 作为关联条件。它还加入 or vector(0)，避免在没有匹配数据时返回空结果。修改后的查询成功返回数据，仪表盘配置也随之更新。

这一步很重要。最终交付的不只是一份 YAML，而是由真实数据源验证、查询失败诊断，以及更新后能够正常加载的仪表盘共同构成的一套可检查工作产物。

经过业务旅程识别、目标设定和查询验证，团队已经得到一套可用的 SLO 仪表盘。但文章要回答的问题并没有到此结束：这套仪表盘为什么能够进入后续健康巡检，并成为可以反复使用的运行基线？

四、SLO 基线延伸：支撑应用自动化健康巡检

仪表盘生成后，可以立即用于观察运行状态。但要让它在后续巡检中持续发挥作用，还需要将相关目标、查询和判断依据一并沉淀为应用知识。

当 SLO 仪表盘归档到应用后，保留下来的不只是可视化面板，还包括：

• 服务目标与阈值；

• Prometheus 查询和服务范围；

• 关键业务旅程与优先级分层；

• 设定目标时所依据的历史基线；

• 关于低流量、数据缺口和已知持续性问题的说明。

这些信息共同构成了后续健康巡检的起点。巡检不需要每次重新回答“哪些服务最重要”或“正常状态应当是什么样”，而可以围绕已有 SLO 评估目标是否偏离、查看支撑面板，并以业务语言输出结果。

但 SLO 不是健康巡检的全部。本案例中的 4 条 SLO 负责定义必须优先保护的业务目标和判断门槛，让巡检知道应该先看什么，以及目标偏离意味着什么。

完整巡检还需要将分析范围扩展到支撑这些目标、解释偏离原因的信号，包括：

• 全服务错误率与请求量

• 各服务延迟

• 当前告警

• Pod 重启

• 内存风险

• 调用链和日志

将这些信号结合起来进行跨信号分析，可以进一步判断偏离发生在哪里、是否正在扩大，以及下一步应如何排查。

在后续的一次健康巡检中，Castrel AI 先读取已归档的 SLO，并将购票可用性、基础设施就绪率、订单服务 P95 延迟和服务活跃覆盖率作为巡检主线。

随后，Castrel AI 并行检查当前 24 小时窗口与 7 天对照窗口内的服务错误率和请求量、全服务 P95 延迟、Prometheus 告警、Pod 重启与容器内存，再按服务拓扑和优先级汇总结果。

这样，巡检不只能够判断“规则是否达标”，还可以进一步解释“为什么会发生偏离”：

因此，即使基础设施就绪率保持在 100%，巡检也不会直接将应用判定为健康。它还会继续检查是否存在 SLO 未达标、错误率升高、延迟尖峰、告警集中触发或资源风险，并将这些信号关联回受影响的业务旅程。

基于这套运行基线，后续巡检可以进一步区分以下情况：

• Tier-1 购票可用性的错误预算正在快速消耗；

• 基础设施就绪率偏离了 100% 的基线；

• 可用性看似正常，但订单延迟正在上升；

• 部分服务不再有流量，导致服务活跃覆盖率下降；

• 内存压力或重启活动正在增加，但尚未影响用户旅程。

需要说明的是，SLO 基线并不能替代工程判断。当流量模式发生变化、数据源不完整或产品能力演进时，团队仍需要复核并重新校准目标。

以本次工作流为例，应用处于低流量状态，因此仪表盘明确记录了一个前提：正常流量恢复后，需要重新评估目标是否仍然合理。保留这个前提，与保留目标数值同样重要。

五、价值升华：SLO 转变为可持续迭代的应用运行基线

Castrel AI 的价值不只是更快地生成仪表盘，更在于将目标定义与持续运营连接成一套连续工作流：

通过这套工作流，Castrel AI 让 SLO 不再只是文档里的一次承诺，而成为可视化、可验证、可持续维护的运行基线。

SLO 为健康巡检提供业务优先级与判断标准；巡检再结合全服务、基础设施、告警、调用链和日志信号，解释应用真实的运行状态。

随着应用发生变化，团队还可以基于这套运行基线持续校准服务目标，让可靠性标准始终与业务优先级和实际运行状态保持一致。由此，可靠性管理不再停留在一次性的目标设定，而成为能够随业务持续演进的运维能力。

关于云智慧&轻帆云

云智慧聚焦 Agentic AI・AI 基础设施可靠性，面向电力、AI 算力服务、AI 智能体场景，打造全栈安全与智能运维保障体系。保障 AI 基础设施规模化连续稳定运行，通过监测预警、快速响应、自动化运维与合规治理，帮助客户实现更高业务可用性、更低运行风险、更优运营成本。

轻帆云是云智慧旗下专注全栈智能化 IT 管理的核心品牌，2024年与2025年凭借综合实力蝉联亚太区 IT 服务管理软件市场前十，中国市场占有率排名第一。依托云智慧在Agentic AI领域的深厚技术积淀与 ITIL 深度实践，轻帆云已构建覆盖 IT 服务管理（ITSM）、配置管理（CMDB ）、IT 资产管理、AI-SRE 智能体、可观测平台等全链路产品矩阵，实现企业 IT 管理全场景闭环支撑。