• 时间:
  • 分类:

图片

本文介绍了 云智慧Castrel AI（SRE 智能体）的核心设计理念，包括：假设驱动的调查方法、人机协同机制 和 业务知识沉淀。这一设计旨在帮助运维团队高效实现从“问题发现”到“根因定位或快速升级”的完整闭环。

在深入各模块之前，我们先来看一下云智慧Castrel AI的核心工作流程：

图片

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

AI 故障排查的效果，在很大程度上取决于它所能访问的上下文数据是否完整。而一个高质量的可观测性上下文，应覆盖可观测性数据 以及 系统拓扑关系 等关键维度。

图片

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

可观测上下文中包含 Metrics（指标）、Logs（日志） 和 Traces（链路追踪） 三类数据：

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

三者结合，才能形成完整的故障视图；而仅依赖任何单一数据类型，都难以高效完成故障排查。

下表总结了这三类数据的核心用途及典型来源：

image.png

系统拓扑关系

除了上述三类可观测性数据，AI 还需要理解系统的拓扑结构。这一结构主要由以下两类关系构成：

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

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

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

在实际实施中，我们建议按以下优先级逐步完善数据接入：

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

综上，数据完整性直接决定 AI 排障能力的上限：数据越完整，AI 分析越准确。缺失任一数据类型，都会显著降低排查效率。

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

传统的 AI 分析方式通常是一次性收集所有可观测数据，然后由模型生成摘要。这种“摘要引擎”式的做法存在明显局限：随着数据量增加，模型容易被无关信号干扰，输出质量反而下降。

更高效的方式是让 AI 像人类 SRE 一样思考。具体而言，这一过程遵循一个迭代式的调查循环，包含以下四个关键步骤：

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

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

图片

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

image.png

正因具备上述特性，假设驱动的调查方式使 AI 的分析过程透明、可追溯——每一个结论都有明确的数据支撑。

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

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

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

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

下面是一个典型的协作场景：

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

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

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

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

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

在复杂事件中，根因可能跨越多个系统，或需要多个步骤才能发现。假设驱动的方法允许 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 在首次遇到某些类型的问题时可能需要进行大量探索。但这些探索结果不应被浪费。

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

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

image.png

最后一项“业务语义”尤其依赖对客户业务的深入理解。例如：

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

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

从排查过程中积累知识

为解决上述挑战，当一次事件调查完成后，AI 可以将排查过程总结为知识条目：

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

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

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

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

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

场景示例

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

第一次排障：

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

第二次排障：

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

正如本节所述，因果验证的准确性依赖于对业务的深入理解。通过知识沉淀，团队的业务经验不再仅存在于个人头脑中，而成为 AI 判断因果关系的重要依据。

总结

综上所述，AIOps SRE Agent——云智慧 Castrel AI的事件排障能力可归纳为以下五个关键方面：

image.png

上述能力共同服务于一个核心目标：云智慧 Castrel AI 故障排查智能体并非旨在“AI 取代人类”，而是让人机协同的效率远超纯 AI 或纯人工的单独工作方式。

标签: none

添加新评论