Castrel AI 健康巡检：在业务受影响前发现并关闭运行风险

当告警已经触发、用户请求已经失败，团队需要的是故障排查；当业务仍然正常，但风险正在积累，团队需要的是健康巡检。

Castrel AI 健康巡检的价值，就发生在这段仍可提前行动的时间里。Castrel AI 不只读取当前状态，而是按照巡检 SOP 主动检查 SLO、告警、指标、日志、调用链、Kubernetes 事件和依赖状态，与历史巡检结果对照，识别短暂波动背后的持续趋势，推演风险可能影响的业务链路，并给出可以验证的处置顺序。

健康巡检与故障排查都会使用日志、指标和调用链，但它们解决的问题不同：故障排查围绕已经发生的用户影响定位原因并尽快恢复服务；健康巡检则在影响发生前，将历史趋势、资源余量和依赖关系组织成可验证的风险判断，明确团队应在何时采取什么动作，以及满足哪些条件后才能关闭风险。

本文以典型电商微服务应用 ShopOne 为例，展示 Castrel AI 如何在业务尚未受影响时发现并关闭一次容量风险。ShopOne 包含 11 个业务微服务，核心结账链路通过同步 HTTP 调用连接 gateway、order、inventory、catalog、payment 等服务。

最新仪表盘显示正常，Castrel AI 仍将应用判定为 Warning

巡检开始时，ShopOne 的业务状态没有明显异常：

如果巡检止步于这组快照，结论很可能是“应用健康”。Castrel AI 没有在这里结束任务，而是继续执行三项工作：回看历史巡检趋势、检查高成本调用的运行证据、判断当前资源变化是否可能传导到核心结账链路。

Castrel AI 最终将状态标记为 warning。原因不是当前已经发生业务故障，而是它发现了一个正在快速缩小的容量窗口。

Castrel AI 计算增长速度，而不是只报告磁盘达到 82.4%

单个磁盘数值很难直接指导行动。82.4% 可能是短时峰值，也可能是长期稳定基线。Castrel AI 将当前结果与过去 12 小时的巡检数据对齐后，得到一条持续上升的趋势：

过去 12 小时平均每小时增加约 0.68 个百分点。按当前速度线性外推，磁盘将在约 11 小时后进入 90% 高风险区间，并可能在约 26 小时后耗尽。

Castrel AI 没有把这个时间估算当作确定预言。报告明确说明：如果流量、数据量或清理策略变化，实际时间也会变化。但相比“磁盘当前为 82.4%”，风险窗口回答了更重要的问题——团队还有多少时间可以在不影响业务的情况下处理它。

这一步改变了处置优先级。磁盘尚未越过严重告警阈值，却已经不能再作为普通容量问题等待下一次值班检查。

Castrel AI 跨越指标、日志和调用链，找到容量增长的驱动因素

仅根据线性趋势扩容磁盘，只能延缓问题。Castrel AI 继续检查 MySQL、服务调用链与连接池状态，发现多项证据在同一时间窗口内同步变化：

健康巡检并不止于发现“磁盘偏高”。只有确认资源压力的来源、传播方向和业务后果，团队才能判断它是可观察的波动，还是需要提前处置的风险。

调用链中的 SQL 包含 JOIN user_behavior_log ubl ON TRUE。缺少有效关联条件会形成笛卡尔积式的数据放大；当结果集继续增长，MySQL 需要写入更多临时文件，查询占用连接的时间也会延长。

Castrel AI 因而没有输出四条相互独立的异常，而是形成了一条可验证的风险传播路径：

异常 SQL 放大结果集
    → 磁盘临时表与临时文件持续增长
    → 可用磁盘空间快速下降
    → 慢查询长时间占用数据库连接
    → order 连接池排队和超时
    → Checkout 链路延迟与失败

此时最后两步尚未发生。也正因为业务仍然正常，这条传播路径才具有提前处置价值。普通快照只能说明每个组件现在的状态；Castrel AI 将趋势、依赖关系和历史证据组合起来，判断如果不处理，当前资源压力将如何转化为业务风险。

Castrel AI 将风险判断转化为有顺序的处置方案

Castrel AI 没有把“扩容磁盘”作为唯一建议，而是根据风险链条安排动作：

1. 先阻断增长来源：检查 user_behavior_log 查询生成逻辑，移除 ON TRUE 笛卡尔积关联，补充正确的业务关联条件。
2. 恢复安全余量：清理异常查询产生的临时文件，将磁盘使用率恢复到安全区间。
3. 降低重复风险：优化大结果集排序和深分页，为临时文件空间设置独立容量与增长速率告警。
4. 观察放大机制：持续检查连接池活跃连接、等待请求和超时，不以扩大连接池替代 SQL 修复。
5. 修复后重新巡检：使用相同的 SLO、时间窗口和风险链验证处置结果。

这个顺序体现了 Castrel AI 与固定阈值脚本的区别。脚本可以在磁盘达到某个比例时通知值班人员；Castrel AI 进一步回答增长来自哪里、可能影响哪条业务链路、应该先修复什么，以及如何确认问题没有只是暂时消失。

第二次巡检确认风险已经关闭，而不是只确认告警消失

团队修正 SQL 关联条件并清理临时文件后，再次运行同一个 Castrel AI 巡检任务。Castrel AI 复用第一次报告中的时间窗口、指标定义和风险链，逐项验证结果：

Castrel AI 将健康状态从 warning 更新为 healthy，但依据不是“严重告警仍为 0”。真正的关闭条件是：磁盘增长趋势已经停止，异常查询耗时恢复，临时文件压力下降，连接池不再排队，核心业务指标保持正常。

第一次巡检给团队提供处置窗口，第二次巡检则提供可复核的关闭证据。健康巡检因此不再是一份定期生成后无人跟进的报告，而是一个从发现、判断、行动到验证的连续过程。

一次健康巡检交付的，不是异常列表，而是可执行的风险闭环

一次 Castrel AI 健康巡检会保留判断依据，并将它们组织成团队可以交接、执行和在下一轮继续验证的结果：

在 ShopOne 场景中，团队最终拿到的不是“磁盘使用率 82.4%”这一条监控信息，而是一份可执行的风险闭环：当前 Checkout 仍正常，但容量窗口正在缩小；异常 SQL 是增长来源；连接池压力可能将数据库问题传导到下单链路；应优先修复 SQL 而非只扩容；只有磁盘趋势、查询耗时、临时文件、连接池和业务指标同时恢复，风险才可以关闭。

Castrel AI 为不同运维对象保留独立基线，再在业务链路上汇合

容量风险之所以容易被漏掉，是因为每个对象单独看都可能尚未越线。应用、服务、主机、基础设施和 MySQL 面对不同的风险，不能只依赖一套通用阈值。Castrel AI 可以为每类对象建立独立巡检任务和历史基线，再在应用级巡检中关联它们之间的影响关系：

具体能执行哪些检查取决于已接入的集成、权限和巡检规则。但 Castrel AI 的判断结构保持一致：读取当前状态、对照历史趋势、关联上下游证据、推演业务后果、安排处置优先级，并通过复检确认风险关闭。

健康巡检的结果不止是一份报告，而是一项提前行动的风险决策

在 ShopOne 场景中，Castrel AI 面对的是一个当前业务正常、没有严重告警的应用。它没有重复仪表盘结论，而是完成了仪表盘本身无法独立完成的工作：

验证当前业务仍然健康
    → 计算磁盘容量的增长速度和风险窗口
    → 关联异常 SQL、临时文件与连接池压力
    → 推演对 Checkout 链路的影响路径
    → 给出按根因排序的提前处置方案
    → 修复后复检并确认风险关闭

这就是 Castrel AI 健康巡检的核心价值：不是等故障发生后解释过去，而是在业务仍然正常时识别未来风险，把分散证据转化为一项可以执行、可以复核、可以持续积累的运维决策。它既保留判断依据，明确处置顺序和关闭条件，也成为下一轮巡检的历史基线。