从 SLO 到健康巡检：可视化仪表盘如何成为应用的运行基线

写下一个 SLO 很容易，让它真正服务于日常运维却并不简单。

多数团队已经接入了指标、调用链、仪表盘和告警规则，但往往缺少一个可以共同确认、且有数据依据的答案：为了让业务正常运转，究竟什么必须保持健康？ 将这个答案转化为服务等级目标，不只是选一个百分比。团队还需要识别关键用户旅程、找到有代表性的流量窗口、验证底层查询、依据数据设定目标，并最终形成可持续使用的仪表盘。

Castrel 可以接管这段衔接工作。用户为应用发起 SLO 请求后，Castrel 可以读取应用上下文、探索可观测性数据、定义服务目标、生成可视化仪表盘，并将结果沉淀为应用知识。最终得到的不只是文档或图表，而是一套可供后续健康巡检引用的运行基线。

这也是这类能力的核心价值：SLO 不再只是某个时刻写下的规则，而会变成“人可以查看、Agent 也可以复用”的应用运行上下文。团队后续做巡检、复盘或目标校准时，可以从同一套目标、阈值、查询和历史依据出发，而不是每次重新拼装判断标准。

真正的问题：SLO 常常与日常运维脱节

在很多团队中，SLO 工作开始时目标明确，最后却成为一份孤立的产物。目标可能写在文档里，几条 PromQL 查询放在仪表盘中，服务负责人也清楚哪条链路更重要；但这些判断依据分散在不同的人和工具之间。

于是，每次建立或复核 SLO 都要重复一套人工流程：

1. 查找服务清单、拓扑、运行手册和历史巡检报告。
2. 判断哪条用户旅程真正影响核心业务。
3. 在指标、调用链和 Kubernetes 数据间切换，找到有代表性的业务流量时段。
4. 检查错误率、延迟、可用性、重启和资源压力。
5. 将观察结果转换为目标与仪表盘查询。
6. 到下一次健康巡检或复盘时，再重新建立这些上下文。

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

一个典型 SLO 工作流：先从业务旅程出发，而不是先选指标

以一个典型的微服务火车票预订应用为例，识别出的核心购票路径是：

ts-ui-dashboard → ts-travel-plan-service → ts-order-service

创建 SLO 时，不能默认最新数据就能代表正常业务基线。在这次工作流中，近期流量很低，最近 24 小时的视图无法代表正常用户行为。Castrel 先读取应用上下文和既有巡检 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 将数据探索转化为可运营的仪表盘

基于业务旅程、历史基线和实时数据模型，Castrel 生成了 4 条 OpenSLO 定义。

其中，购票可用性使用非错误请求数与总请求数的比值；基础设施就绪率比较可用副本与期望副本；延迟目标跟踪订单服务的 P95 Span 时延；服务活跃覆盖率则让低流量和服务静默不再只是空白图表。

这些目标会进一步渲染为 10 个面板，而不是停留在配置文件中：

1. 购票旅程可用性
2. 基础设施就绪率
3. 订单服务 P95 延迟
4. 服务活跃覆盖率
5. 各服务错误率
6. 各服务请求速率
7. 各服务 P95 延迟
8. 30 分钟窗口内的 Pod 重启健康度
9. 使用率超过 85% 的容器内存风险
10. 错误率 Top 5 服务

这样，团队可以在同一个视图中看到业务目标及其支撑信号：用户旅程是否健康、基础设施是否就绪、哪些服务仍在承载流量，以及哪些资源或稳定性信号需要关注。

验证本身也是结果的一部分

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

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

随后，Castrel 通过 sum by (pod, container) 聚合查询两侧，以 pod 和 container 进行关联，并加入 or vector(0)，避免没有匹配数据时返回空结果。修复后的查询成功返回数据，仪表盘配置也随之更新。

这一区别很重要。最终结果并不只是“生成一份 YAML”，而是包含真实数据源验证、查询失败诊断和已更新可加载仪表盘的一套可检查工作产物。

仪表盘生成后，为什么能服务于健康巡检

仪表盘可以立即用于观察运行状态，但它的长期价值来自于被沉淀为应用知识。

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

• 服务目标与阈值；
• Prometheus 查询和服务范围；
• 关键业务旅程与优先级分层；
• 设定目标时所依据的历史基线；
• 关于低流量、数据缺口和已知持续性问题的说明。

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

但 SLO 不是健康巡检的全部。4 条 SLO 负责定义必须优先保护的业务目标和判断门槛；完整巡检还要扩大到支撑这些目标、解释偏离原因的信号：全服务错误率与请求量、各服务延迟、当前告警、Pod 重启、内存风险、调用链和日志。SLO 让巡检知道先看什么、偏离意味着什么；跨信号分析则回答偏离发生在哪里、是否正在扩大，以及下一步应如何排查。

一次巡检如何使用仪表盘，而不止使用 4 条规则

在后续的一次健康巡检中，Castrel 先读取已归档的 SLO，将购票可用性、基础设施就绪率、订单服务 P95 延迟和服务活跃覆盖率作为巡检主线。随后，它并行检查 24 小时当前窗口与 7 天对照窗口内的服务错误率和请求量、全服务 P95 延迟、Prometheus 告警、Pod 重启与容器内存，并按服务拓扑和优先级汇总结果。

这使巡检可以区分“规则是否达标”与“为什么会偏离”：

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

例如，后续巡检可以区分以下情况：

• Tier-1 购票可用性的错误预算正在快速消耗；
• 基础设施就绪率偏离了 100% 的基线；
• 可用性看似正常，但订单延迟正在上升；
• 部分服务不再有流量，导致服务活跃覆盖率下降；
• 内存压力或重启活动正在增加，但尚未影响用户旅程。

SLO 基线并不能替代工程判断。当流量模式发生变化、数据源不完整或产品能力演进时，团队仍需要复核并重新校准目标。在本次工作流中，应用处于低流量状态，因此仪表盘明确记录了一个前提：正常流量恢复后，需要重新评估目标是否仍然合理。保留这个前提与保留目标数值同样重要。

从一次请求，到可复用的运行基线

SLO 自动化的价值不只是更快地生成仪表盘，更在于让目标定义与持续运营形成连续工作流。

应用上下文 + 可观测性数据
    → 识别业务旅程与历史基线
    → 生成并验证 OpenSLO 定义
    → 可视化仪表盘
    → 归档为应用知识
    → 全量健康巡检：目标判定 + 跨信号解释
    → 持续校准

通过这种方式，SLO 不再只是文档里的一次承诺，而成为可视化、可验证、可持续维护的运行基线：它为健康巡检提供业务优先级与判定标准；巡检再结合全服务、基础设施、告警、调用链和日志信号，解释系统真实的运行状态，并让团队可以随着应用变化持续修正服务目标。