大多数IT团队都经历过这样的状态：仪表盘显示正常，告警保持静默，SLO 尚未跌破，但部分运行信号已经呈现持续恶化趋势。传统故障排查通常围绕已经发生的服务影响展开，难以覆盖这类业务尚未受到影响、风险却在持续积累的场景。
要系统性地处理这类风险，还需要一个面向事前风险治理的运维环节：健康巡检。
它通常定期执行，或在发现早期异常趋势时启动，关注风险是否正在积累、可能如何传导，以及何时需要采取行动。风险源得到消除或控制后，还需要通过复检确认风险链已经关闭。
云智慧 Castrel AI 将健康巡检落实为可执行的闭环：按照巡检 SOP 读取当前状态、对照历史趋势、关联上下游证据，判断风险来源及其可能造成的业务影响，并给出按优先级排列的处置方案和明确的复检标准。
本文以典型电商微服务应用 ShopOne 为例，展示 Castrel AI 如何通过健康巡检，支持团队在业务尚未受到影响时发现、处置并关闭一次容量风险。
业务正常，Castrel AI 为什么给出 Warning？
ShopOne 是一个包含 11 个业务微服务的典型电商应用，其核心结账链路通过同步 HTTP 调用连接 gateway、order、inventory、catalog 和 payment 等服务。巡检开始时，ShopOne 的业务状态没有明显异常：
gateway 可用性：99.96%
gateway P95 延迟：168 毫秒，低于 200 毫秒目标
gateway 错误率：0.04%
正在触发的严重告警：0
如果巡检止步于这一时刻的快照，ShopOne 很可能会被判定为“应用健康”。但“业务暂未受影响”并不等于“没有运行风险”。当前磁盘使用率已经达到 82.4%，单独看这一数值，还无法判断它是短时峰值，还是持续增长趋势的一部分。与过去 12 小时的数据对照后，变化趋势变得清晰：
数据显示，磁盘使用率在这一时间窗口内上升了 8.2 个百分点，平均每小时增加约 0.68 个百分点。按照这一速率线性外推，并假设流量、数据写入速度和清理策略保持不变，磁盘预计将在约 11 小时后进入 90% 的高风险区间，并可能在约 26 小时后用尽可用容量。
尽管当前 SLO、延迟、错误率和告警状态均未显示业务异常，磁盘容量余量却在持续缩小。
因此，Castrel AI 将应用状态标记为 Warning，而非 Healthy。
关联多源证据，还原风险源头和影响路径
Warning 说明容量风险已经需要处置，但磁盘使用率持续增长的原因仍需进一步确认。Castrel AI 因此继续检查 MySQL、服务调用链和连接池状态，发现多个运行信号在同一时间窗口内同步变化：
这些信号表明，磁盘使用率上升并不是孤立的容量波动，其背后还伴随着 SQL 变慢、临时文件增加和连接池压力上升。沿调用链继续下钻后，Castrel AI 定位到一条包含异常关联条件的慢 SQL：
JOIN user_behavior_log ubl ONTRUE该 SQL 使用 ON TRUE 作为关联条件，缺少有效的业务关联关系，会导致笛卡尔积式的数据放大。随着结果集继续增长，MySQL 需要写入更多临时表和临时文件，该 SQL 占用数据库连接的时间也随之延长。
Castrel AI 将这些运行证据串联成一条可验证的风险传播路径：
异常 SQL 放大结果集→ 磁盘临时表与临时文件持续增长→ 可用磁盘空间快速下降→ 慢查询长时间占用数据库连接→ order 连接池排队和超时→ Checkout 链路延迟与失败
执行处置方案，复检验证修复效果
依据这条风险传播路径，Castrel AI 给出以下处置顺序：
先阻断增长来源：检查 user_behavior_log 查询生成逻辑，移除 ON TRUE 笛卡尔积关联，补充正确的业务关联条件。
恢复安全余量：清理异常查询产生的临时文件，将磁盘使用率恢复到安全区间。
降低复发风险：优化大结果集排序和深分页，为临时文件空间设置独立的容量与增长速率告警。
观察放大机制：持续检查连接池活跃连接、等待请求和超时，不以扩大连接池替代 SQL 修复。
修复后重新巡检：使用相同的 SLO、时间窗口和风险链验证处置结果。
按照上述处置顺序，团队先修正 SQL 关联条件，并清理异常查询产生的临时文件。完成这两项处置后，团队再次运行该巡检任务进行复检。Castrel AI 复用第一次巡检中的时间窗口、指标定义和风险链，逐项验证处置结果：
复检结果显示，磁盘使用率不再持续增长，MySQL 查询耗时和临时表创建速率恢复正常，order 连接池不再排队，核心业务指标继续保持稳定。满足这些关闭条件后，Castrel AI 将 ShopOne 的健康状态从 Warning 更新为 Healthy。
至此，第一次巡检为团队提供了处置窗口，第二次巡检提供了可复核的关闭证据，整个过程形成了从发现、判断到行动和验证的完整闭环。
一次 Castrel AI 健康巡检，团队能拿到什么？
从 ShopOne 的巡检过程可以看到，一次健康巡检不应只给出 Healthy 或 Warning 状态。Castrel AI 还会保留判断依据，并将其组织为团队可以交接、执行和持续验证的结果：
这些结果来自对不同运维对象的分别判断和关联分析。应用、服务、主机、基础设施和 MySQL 面对的风险不同，不能只依赖一套通用阈值。Castrel AI 可以为不同对象建立相应的巡检任务和历史基线，再在应用级巡检中关联它们之间的影响关系：
为了形成上述交付结果，Castrel AI 会分别检查应用、服务、主机、基础设施和 MySQL。由于不同对象的运行特征和风险重点不同，每类对象都需要相应的巡检任务和历史基线；在此基础上，应用级巡检再关联各对象之间的依赖关系和潜在影响：
具体可执行的检查项，取决于集成接入情况、权限配置和巡检规则。但无论面向哪类巡检对象，Castrel AI 的基本判断框架保持一致：读取当前状态、对照历史趋势、关联上下游证据、判断可能造成的业务影响、确定处置优先级，并通过复检确认风险关闭。
从被动应急到主动行动：在业务受到影响前完成风险处置
云智慧Castrel AI 健康巡检的核心价值，是将风险处置从告警触发后的被动应急，前移到业务受到影响前的主动行动。
它将分散的运行证据转化为明确的处置时机、行动顺序和复检标准，使团队能够判断何时介入、优先处理什么，并在修复后通过复检验证风险是否真正关闭。
相关判断依据和验证结果还会沉淀为历史基线，为后续巡检提供持续对照，也为人员交接保留完整依据。
关于云智慧
云智慧聚焦Agentic AI · AI 基础设施可靠性，秉持「Reliability for AI Infrastructure」品牌主张，帮助客户构建电力、AI算力与服务、AI 智能体的全栈安全和可靠性保障体系。致力于保障AI基础设施规模化、连续性、稳定运行，通过监测、预警、快速响应、自动化运维与合规治理，帮助客户实现更高可用性、更低风险与更优运营成本。
已服务金融、政府、能源、交通、制造、运营商等行业3000+客户，连续3年IDC中国IT统一运维ITSM软件市场占有率第一；连续7年入选 Gartner AIOps相关报告及推荐厂商；中国首家ITIL官方授权 IT咨询合作伙伴（AXELOS）；全球营销服务网络覆盖中国大陆及港澳、新加坡、泰国、 马来西亚和中东等30+地区。