当AI能比资深工程师更快定位故障根源，运维领域将迎来怎样的范式革命？

快猫星云CTO华明认为，随着大模型时代的到来，所有产品都值得用大模型重做一遍，运维相关的工具和产品也一样，智能闭环或高度自治的运维阶段是一个或近或远的未来。

Flashcat目前在努力推进运维和可观测性进入智能辅助阶段，并且取得了相当明显的进步。整体而言，Flashcat在可观测性方向上，致力于为人和AI解决两个问题：

• 如何让人和AI更好的理解你的系统？

• 如何让人和AI无障碍的读取你的观测数据？

6月21日，快猫星云CTO华明将出席OSC源创会·北京站线下沙龙，发表《可观测性智能化愿景：Flashcat的方法、实践和效果》主题演讲。在演讲正式开始前，先来简单聊聊智能运维与可观测技术的发展变化。

AI 运维「开挂」指南 OSC源创会·北京·114期

时间：2025-06-21 14:00 至 17:30

地点：北京 海淀 海淀大街甲36号439号中关村创业大街12号楼5层

报名地址：https://www.oschina.net/event/8596707

OSCHINA：当前运维领域与大模型结合的核心难点是什么？预计能带来什么样的价值？

华明：

大模型与各个行业结合的难点都是如何与现有的软件和生产系统实现平滑的连接。具体到运维领域，就是如何让大模型理解复杂的生产系统，以及如何让大模型从海量的运维数据中获得有限、有效的信息进行分析，最终高效输出真正有价值的洞见。

如果大模型解决了与现有软件系统的对接以及理解复杂生产系统的难点，将会在故障定位、运维提效等运维领域的关键难题上取得突破，给未来的运维模式带来颠覆性的影响。

OSCHINA：信通院将运维发展分为“自动化→小模型→大模型”三阶段，Flashcat如何定义自身的智能化演进路径？是否已接近L4（部分自治运维）或L5（高度自治运维）层级？

华明：

我们偏向认为运维的发展与小模型、大模型的划分关系不大，可能的路径是：自动化 -> 智能辅助 -> 智能闭环。

其实自动化时代也只能实现部分自动化，完全的自动化依赖智能化。随着容器化、云计算技术的发展和成熟，当前常规的自动化基本已经到头，运维行业处于探索进入智能辅助的阶段，即探索如何利用大模型来加速解决运维领域的关键难题。

而智能闭环或高度自治的运维阶段是一个或近或远的未来，我倾向于认为还有不少时间，这个时间点到来的标志将是：线上系统的代码完全由AI自主完成编写和发布，人已经不需要编写其中的任何一行代码。AI能够自主完成系统代码的编写，那配套的运维将会被AI自动考虑其中，形成一个完成自治的闭环。

Flashcat 目前在努力推进运维和可观测性进入智能辅助阶段，我们已经取得了相当明显的进步，而且我们相信我们正走在正确的路上，相信不久智能化将会是Flashcat的一大亮点。

OSCHINA：传统监控被比喻为“苍蝇复眼”，而现代可观测性系统如同“人类双眼”。Flashcat如何通过智能化实现从“低效告警”到“主动洞察”的跨越？

华明：

我们认为下一阶段AI能够明显发挥价值的方式是：加速原本人可以完成的复杂分析工作。如果一个分析工作人是能够完成的，只是分析效率低，那AI就很有可能可以极大的加速这个分析过程。“主动洞察”的价值可能还在这之后。

比如，针对一个故障的诊断，人可能要花费很多的时间，查询好几个平台的数据才能分析出根因。如果把生产环境的描述、异常信息的描述、多个平台数据的查询能力提供给AI，那AI大概率可以从这些有限、有效的信息集合中快速分析出有效的结论。

换言之，如果一个技术工程师能够“无障碍”的获取生产环境的信息、得到故障相关数据的关联、掌握各个观测平台数据的查询权限和方法，那问题根因的定位除了“智商”和“手速”的问题外，就没有了“硬伤”。把相同的能力给到AI，那AI就能比所有人都做的更快、更好。

Flashcat其实一开始是奔着让人“无障碍”的获取故障分析定位的信息和能力去努力的，但后来发现，这个路径其实也正是运维可观测性通向智能化的道路。

总结起来Flashcat在可观测性方向上，致力于为人和AI解决两个问题：

• 如何让人和AI更好的理解你的系统

• 如何让人和AI无障碍的读取你的观测数据

OSCHINA：Flashcat在实现可观测性智能化时，如何处理海量时序数据（如日志、指标、链路）的实时分析与关联？是否依赖统一数据引擎？

华明：

如何让AI从海量的运维数据中获得有限而有效的数据，以输出有价值的洞见，确实是运维领域落地AI的一大难点。否则AI再强也是老虎吃天，无从下嘴。

解决这一问题，Flashcat依赖内部的“灭火图”系统。灭火图系统是Flashcat构建服务元信息和全面观测服务状态的系统。灭火图能够帮助用户将IT基础设施分解为结构化、立体的观测对象，如底层网络/DNS等基础设施、MySQL/Redis等标准中间件、Kubernetes微服务、功能接口等，并量化其中每个观测对象的健康度，呈现出“着火”和健康的两种红/绿状态。让用户一眼就看清整个IT系统的对象极其健康状态。

同时，每个对象都可以下钻遍历其相关的观测数据，如指标、日志、链路、事件、仪表盘等。而这些数据Flashcat通过数据集成的方式为用户自动调取，数据来源对用户是透明的，相关数据可能来自用户生产环境中已有的各个观测平台，如Prometheus、Elasticsearch、SLS、Skywalking等。

灭火图已经积累了大量的模板和规则为用户快速创建灭火图，将整个IT系统的所有元信息和关联信息呈现到用户面前。

灭火图相对AI来说，就是这个统一的数据引擎，可以为AI提供服务的元信息和数据的关联信息，让AI理解你的系统。同时也为AI提供了查询数据的通道和能力，让AI能够查询你的数据。

OSCHINA：能否分享一个Flashcat通过智能化能力解决难题的典型案例？

华明：

我们搭建了一套典型的服务架构：用户流量->网关接口->后端server->Redis->DB。在这个框架中我们将Redis进行重启，这个动作会使得相应的灭火图出现多处“着火”，比如网关上的某个接口、微服务server、Redis集群。

这时候我们让AI从两个角度进行分析：

1. 从网关的接口上开始分析：AI会下钻分析该异常接口的三个黄金指标：流量、成功率、响应延迟，再下钻分析相应的日志、仪表盘、链路。最后AI准确的得出了结论，异常的根因是：Redis实例 ip:port 出现异常导致。

2. 在灭火图首页上进行全局分析：AI 通过灭火图的全局信息和分层结构，掌握了全部的异常信息，以及异常信息之间的层次关系，分别分析异常点后，也综合得出了redis实例宕机是根因的准确结论。

虽然实际的生产环境会比这个典型框架复杂很多，但只要提供的元信息、关联信息足够准确，相信AI同样可以得出准确的结论，这个过程相比人来分析会快速的多，体现了智能化的价值。

我们下一步将在客户的大型环境中进一步验证打磨。同时还有很多故障定位的思路我们也正在通过AI输出实现，目前看可行性非常之大，期待我们的研发进一步呈现相关的效果。

OSCHINA：智能化是否会导致运维人员“躺平”？运维团队需掌握哪些新技能以适应新范式？有没有给运维人的建议？

华明：

智能化的实现将会极大的解放人力，但如前所述，我们的下一个阶段是智能辅助阶段，这个阶段人的参与仍然是不可或缺的。那在智能化的新范式下，运维人员应该掌握哪些新技能呢？

我认为有几点：

1. 理解AI以及AI的能力边界，参与到将企业系统连接AI的建设工作中来，为AI建设和提供准确、高质量的元信息和观测数据。

2. 观测数据的标准化和质量建设，观测数据极其标准化和数据质量的建设将会变得愈发重要。因为对AI来说Garbage in Garbage out，再好的AI，如果吃的数据是垃圾，吐出来的也只能是垃圾。

3. 针对很多具体的故障场景和分析场景，运维老司机最了解分析的要素和思路是什么，如何将这些经验转化为AI的输入，也将会是运维的核心竞争力之一。

OSCHINA：当前企业推进智能化运维的最大障碍是数据孤岛、算力成本还是技术信任？Flashcat的解决方案是什么？

华明：

如前所述，我们认为当前企业运维实现智能化最大的障碍是两个：

① 如何让人和AI更好的理解你的系统

② 如何让人和AI无障碍的读取你的观测数据

这其中数据孤岛问题就是问题②中最关键和最普遍的问题，Flashcat 通过持续集成市面上的开源和公有云上的观测系统实现了对数据孤岛的打通，并把这个能力提供给了AI，在Flashcat中，数据不再是孤岛，而是丰富的数据查询通道。

算力成本问题，我认为不是当前的重点，目前使用AI的成本在持续下降，企业甚至只要开通一个公有云的大模型账号就可以使用到AI的能力，而不必都自建大模型集群。就我们观察，当前大部分企业在成本和探索价值的取舍上都倾向于愿意付出这部分成本。Flashcat 会内置一个小模型，只要少量的资源即可完成部署，同时能够便利的集成企业内部的大模型集群接口，也可以方便的集成企业提供的公有云大模型接口，实现和企业已有模型基础设施的对接，最大化降低推进的成本。

确实有很多企业还在观望当前AI技术的实际价值，对AI效果的落地存在信任问题。但大家对AI将实现运维智能化这个预期是基本肯定的，只是所预期的时间长短问题。而当前如果试错的成本足够低，很多企业是愿意甚至是积极的想参与的。Flashcat 通过从海量数据中提取有限的信息，并打通已有观测数据孤岛，以及集成企业现成的大模型能力，整体上推进运维智能化的尝试的成本已经非常之低，结合已有的智能化效果，很多企业是愿意放下信任问题，选择一起探索尝试的。