如果近期SRE领域出现了值得关注的变化，那便是AI不再仅仅停留在“告警摘要”的浅层应用。云智慧的Castrel AI（SRE智能体）带来了全新思路——让AI像经验丰富的人类工程师一样，带着明确假设去排查故障，而非单纯堆积数据、生成总结。其设计围绕三大核心展开：假设驱动的调查方法、人机协同机制以及业务知识的持续沉淀。核心目标只有一个：帮助运维团队高效走完从“发现告警”到“定位根因或快速升级”的完整闭环。

在深入探讨每个模块之前，我们先看看它的核心工作流程是怎样的。

Castrel AI工作的前提：可观测性上下文（Observability Context）

AI能否精准定位问题，很大程度上取决于它能获取哪些信息。如果上下文数据不完整，再智能的模型也会面临“巧妇难为无米之炊”的困境。一个高质量的可观测性上下文，不仅需要覆盖足够的可观测数据，还必须理解系统的拓扑关系。

三大核心可观测性数据类型

在可观测上下文中，最常见且最关键的三种数据类型是Metrics（指标）、Logs（日志）和Traces（链路追踪）。它们分工明确：

• Metrics告诉你“出问题了”；
• Logs告诉你“具体发生了什么错误”；
• Traces告诉你“问题发生在调用链的哪个环节”。

三者缺一不可。仅依赖任何单一数据类型，都难以高效完成故障排查。下表总结了它们各自的用途和典型来源。

系统拓扑关系

除了数据本身，AI还需要理解系统之间的“连接”方式。这主要依赖两类关系：

• 调用关系：描述服务之间的依赖链路（通常由APM提供）；
• 部署关系：说明服务运行在哪些主机或容器上（可来自APM、Zabbix或Kubernetes）。

有了调用关系，AI才能判断故障是上游传递而来，还是当前服务自身的问题。有了部署关系，AI则能将应用层的异常与基础设施层面的问题（如主机CPU飙升、磁盘写满）关联起来。

构建完整上下文的实践建议

在实际落地时，建议按以下优先级逐步完善数据接入：

• 优先集成APM：APM能同时提供Traces、调用关系和部署关系，性价比最高。
• 补充基础设施监控：Zabbix、Node Exporter等工具提供的主机级指标是关键补充。
• 纳入Kubernetes元数据：如果使用了K8s，其Events、Pod状态和Deployment记录都是非常重要的上下文信息。

一句话：数据越完整，AI的排障能力上限就越高。缺失任何一种数据类型，排查效率都会大打折扣。

Castrel AI的核心方法：假设驱动，让AI像人类SRE一样思考

传统的AI分析往往是先一次性收集所有可观测数据，然后让模型生成一份摘要。听起来很高效？但问题在于，数据量一大，模型容易被无关信号干扰，输出质量反而下降。

更聪明的做法是让AI像人类SRE一样思考——不是靠“堆积”，而是靠“推理”。具体来说，这个过程是一个迭代式的调查循环，包含四个关键步骤：

• 形成假设：基于告警和初步数据，生成可能的根因方向；
• 验证假设：针对每个假设，查询特定的可观测数据进行验证；
• 递归深入：当一个假设被验证后，继续生成更深层的子假设；
• 剪枝分支：当一个假设被证伪，果断放弃，聚焦其他可能性。

下图展示了一个典型的假设分支调查过程：从“API P95延迟飙升”开始，一步步定位到“数据库索引被删除”这个根因。

与传统的“摘要引擎”模式相比，假设驱动法在多个维度上具有明显优势。

正因如此，假设驱动让AI的分析过程变得透明、可追溯——每个结论都有明确的数据支撑。

Castrel AI的关键机制：人机协同

传统的AI分析是单向的：AI给出结论，用户被动接受或拒绝。而Castrel采用双向协作机制——AI和人类在调查过程中持续交换信息，共同推进根因定位。

在这个机制中，双方各司其职：

• AI：
• 掌握通用知识：理解系统架构、常见故障模式和标准排查方法论；
• 快速扫描数据：在海量Metrics、Logs和Traces中迅速定位异常；
• 并行验证假设：同时测试多个可能的根因方向。
• 人类：
• 提供业务上下文：例如“晚上9点CPU升高是营销活动，属于正常现象”；
• 输入经验知识：例如“我们网络不太稳定，上次是DNS服务器抖动”。

一个典型的协作场景如下：

AI：（完成初步假设分析）
“已验证3个假设：
✓ 数据库慢查询增多 —— 与告警时间吻合
✗ 网络延迟 —— 无异常
✗ 资源不足 —— CPU/内存充足
正在数据库方向继续深入调查……”
用户：（看到假设列表，想起上周的变更）
“DBA上周修改了订单表的索引。”
AI：（新增假设并验证）
“新假设：索引变更导致执行计划变化
→检查DDL变更记录：发现订单表索引于上周四被删除
→对比执行计划：删除前使用索引扫描，删除后变为全表扫描
→时间相关性：索引删除时间与慢查询开始时间一致
✓ 假设验证通过，确认为根因。”
用户：（验证成功）
“确认！需要恢复索引。”

这个机制说明了一个道理：AI擅长处理海量数据和通用知识，人类擅长提供业务上下文和历史经验。两者双向协作，排查效率远超纯AI或纯人工。

Castrel AI的务实设计：退出策略

AI不一定总能直接找到根因——尤其是在数据集成不完整的情况下。但这不代表AI的分析没有价值。Castrel的“退出策略”正是为了在这种情况下，依然交付可操作的洞察。

在多组件问题的深度调查中，递归深挖至真实根因

复杂事件中，根因可能跨越多个系统，或需要多个步骤才能发现。假设驱动的方法允许AI递归地深入调查，直到搜索空间耗尽。

例如，“Pod频繁重启（CrashLoopBackOff）”的排查：

告警：Kubernetes Pod进入CrashLoopBackOff状态

第一层分析：
→ 假设：内存不足导致OOM Kill
→ 验证：检查Pod events，确认为OOMKilled
→ 结论：已验证，但这只是表面原因

第二层分析（递归深入）：
→ 假设：异常大的请求负载导致内存激增
→ 验证：检查入站流量，发现Kafka消息大小异常
→ 结论：已验证，继续深入

第三层分析：
→ 假设：上游系统发送了异常大的消息
→ 验证：检查消息来源，发现某些批处理数据包含损坏的大文件
→ 结论：根因确认——上游数据异常导致消息大小溢出

早期版本的AI可能会在第一层就停止，给出“Pod OOM”的结论——但这对于工程师帮助有限，因为告警本身已经告诉了他们。真正有价值的，是找出为什么发生OOM。

排除干扰项，节省工程师排查时间

即使AI无法定位最终根因，其排查过程本身仍有价值。通常它能做到：

• 指出大致调查方向：例如“问题很可能在数据库层”或“与最近的部署变更相关”；
• 排除无关干扰项：例如确认网络连通性正常、资源利用率充足、缓存命中率无异常。

这种“排除法”能为用户节省大量时间。在传统排查中，工程师需要逐一检查网络、资源、缓存等基础设施，才能排除这些可能性。而AI几分钟就能完成这些检查，让用户直接聚焦到真正可能的问题方向。

结构化交接排查成果，避免排查工作从零开始

当AI因数据不足无法继续深入时，它能把已有成果以结构化方式交给你，避免排查从零开始。下面是一个调查进展交接的示例：

⏱️ 分析耗时：5分钟 | 扫描组件数：12

✅ 已排除项：
• 网络连通性正常（Ping <1ms，无丢包）
• K8s资源充足（CPU<60%，内存<70%）
• 缓存命中率正常（Redis 99.2%）

? 大致方向：
• 问题集中在order-service → mysql-cluster链路
• 数据库性能相关问题的概率较高

⚠️ 需人工确认（缺失数据源）：
• 数据库慢查询日志（未接入）
• 近期Schema变更记录（未接入）

正如“退出策略”所体现的，早期的扫描结果不会被浪费。即使AI给不出最终答案，用户也能从一个更小的排查范围开始，而不是从零开始。

Castrel AI的持续进化能力：知识沉淀

如果团队没有标准操作流程（SOP）或运行手册（Runbook），AI在首次遇到某些问题时可能会耗费不少精力。但这些探索结果不该被浪费。

因果验证为何困难？业务语义无法从可观测数据中直接获取

假设驱动调查方法的核心是验证因果关系——判断某个异常是否确实导致了当前告警。但这里有个难点：因果验证远比看起来复杂，需要从多个维度综合判断。

最后一项“业务语义”尤其关键。举个例子：

• 订单服务延迟增加，AI发现数据库里有慢查询。但这个慢查询是定时报表任务（每天午夜运行，与核心业务无关），还是核心订单查询？只有了解业务的人才能判断。
• 某服务错误率上升，AI发现近期有代码部署。但这次部署是金丝雀发布（预期会有一定错误），还是意外缺陷？需要结合发布计划才能判断。

这类业务知识无法直接从可观测数据中获取，只能通过知识沉淀来积累。

从排查过程中积累知识

解决这一挑战的办法是：一次事件调查完成后，AI将排查过程总结成知识条目：

问题特征：哪些告警/症状组合触发了本次调查

• 排查路径：尝试了哪些方向，最终定位到了什么根因
• 解决方案：如何修复，有哪些注意事项

将知识绑定到特定告警和资源，以复用于同类问题

积累的知识可以绑定到特定的告警类型或资源上。下次遇到类似问题时：

• AI自动检索相关知识
• 参考之前的排查方法，快速确认是否为同一问题
• 如果症状匹配，直接提供修复建议；如果不匹配，至少排除这个方向

场景示例

下面这个例子展示了同一问题的两次排障过程：第二次通过复用第一次积累的知识，排查时间从30分钟缩短到5分钟。

第一次排障：

• 告警：order-service P95延迟增加
• 排查过程：检查网络→检查资源→检查数据库→发现索引问题
• 积累的知识：绑定到order-service + 延迟类告警

第二次排障：

• 相同告警触发AI
• 自动关联知识：“上次类似问题是由索引引起的，是不是要优先检查数据库？”
• 用户确认后，直接跳到数据库检查，跳过网络和资源排查
• 排查时间从30分钟缩短到5分钟

因果验证的准确性，很大程度上依赖于对业务的深入理解。通过知识沉淀，团队的业务经验不再只存在于个人头脑中，而是成为AI判断因果关系的重要依据。

总结

综合来看，云智慧Castrel AI在事件排障上的能力可以归纳为五个关键方面。

这些能力共同服务于一个核心目标：Castrel AI不是为了取代人类，而是要让“人机协同”的效率远超纯AI或纯人工的单独工作方式。