关于智能运维，AI究竟会取代多少运维工程师？这一话题早已被反复讨论。但深入一线后才发现，企业真正关心的并非数字本身，而是真实场景下的落地难题该如何破解：跨云环境中的数据如何打通？复杂系统的告警噪声如何治理？运维团队的角色又将向何方演变？ 我是宋鸣，在吉利汽车负责用户数据中心的数据质量。如果你好奇，为什么一家汽车制造商会与云厂商将智能运维合作推进得如此深入，答案其实很直接：当业务规模与复杂程度同步呈现指数级增长，传统运维模式的天花板已然触手可及。我们没有等待，而是主动运用AI重建了整套运维逻辑。这篇文章，就来分享吉利汽车基于阿里云全域智能运维平台STAROps的转型历程以及几个关键判断。 ## 曾经令人焦虑的「报警风暴」 吉利与阿里云自2021年开始建立紧密合作，极氪集团成立后，双方持续推动云原生改造。在车型发布会保障场景中，曾实现过50万QPS的瞬时并发峰值支撑——放眼整个行业，这一数字也相当亮眼。 然而，极氪正式并入吉利集团、核心应用逐步走向统一技术栈，所带来的运维复杂度直接跃升至另一个量级：数百个系统分布在多云、跨机房、跨业务线的环境中，拓扑结构完全是黑盒；各系统的日志、链路、指标各自独立，数据根本无法串联。线上稳定性由此成为每天优先级最高的难题。 大多数大型企业的运维团队都将“1分钟发现、5分钟定位、30分钟恢复”视为黄金SLA来追求。但在如此复杂的环境下，传统方法确实难以突破。一旦线上出现故障，监控屏上瞬间涌出数百条告警——你知道出了问题，却根本找不到源头。依靠人工逐层排查哪个系统最先报错，故障平均恢复时间往往长达一两个小时。对于面向实时业务的车企而言，这不再是无奈，而是不可接受。 归根结底，所有矛盾最终都指向一个核心问题：快速定位故障根因。这也是吉利选择STAROps的初衷。传统方式已触及极限，必须引入智能运维来破局。 ## 没有高质量的架构资产，就没有高质量的智能运维 回顾整个项目踩过最大的坑，并非技术选型，而是认知观念。大多数人会把智能运维产品想象成扫地机器人，买回来通电就能自动工作。实际落地才发现，如果没有一整套匹配的体系和规范，寸步难行。 起初团队也抱有类似预期——接触STAROps很早，一开始觉得，有了成熟的产品，系统间的资源关联、拓扑应该自动就能完成。但真正引入之后才看清，中间件、日志、调用链路……数据之间存在大量断点。 没有基础治理，AI根本无法识别谁是谁，哪些是干扰项、哪个才是根本问题。举两个具体场景： 有的系统为了高可用，跨机房甚至跨云部署，日志散落各处，如何将它们串联起来？系统之间数据库账号混用，出了故障又怎么判断是哪个服务引发的？ 踩完这些坑，团队得出一个重要判断——或许很多企业尚未意识到：运维的架构资产也是资产，数据质量也是资产。没有高质量的架构资产，就没有高质量的智能运维。必须先做好统一定义、补全架构、理清拓扑这些基础工作，AI才能真正发挥作用。 ## 共建数据底座的三步路径 可观测领域的数据复杂度尤其高：不同云平台、不同基础设施生成的数据，加上企业内部积累的数据，构成了高度异构的环境。与阿里云团队合作后，逐渐理解了STAROps的核心逻辑——不是简单地将一个产品交付到企业手中，而是从数据准备阶段开始，与客户共同构建整个体系。 第一步是统一数据。阿里云去年推出的云监控2.0，核心目标正是解决这个问题：将各处散落的异构数据统一存储、统一分析、统一查看。这是所有智能化能力的前提。 第二步是理解数据。数据统一之后，还需要让智能体读懂数据之间的关联关系。这一步依托的是阿里云的UModel（Unified Model），这也是团队认为非常有价值的一环。UModel能够自动为云上资源建模，更关键的是，这个建模体系是开放的。企业完全可以将自己内部沉淀的资源、拓扑、业务模型添加进去，让智能体真正“看懂”自己的IT世界，理解数据之间的关系。 第三步是持续共建。STAROps真正在做的事情，是与团队一起，将数据准备和数据分析的工作做扎实，让你向它提问时，它能给出准确的回答。许多实践中的难题，必须双方共同摸索、一起趟出来。 ## 运维从执行者到运营者的角色重塑 智能体接管了大量重复劳动之后，最直观的感受是，运维团队从执行者变成了运营者。 传统的运维是什么样子？接到开发或运营提交的工单，一单一单被动处理、被动响应。现在，许多单据、处理流程甚至问题，已经在体系治理的基础上实现了自动化和标准化。运维团队可以把线上整套环境当作自己经营的一块阵地。系统部署上来，团队提供从部署到稳定运行的一整套服务。大家不再是被动接报警的“工具人”，而是成为工具的构建者、流程的设计者、架构资产的维护者，能够将更多精力投入到架构规划、流程设计、制度制定上，确保平台上的所有系统可控、稳定运转。 当然，推进过程中一定会出现“两种声音”。 说实话，一线开发团队对智能体的接受度并不一致。在高压力排障时，很多人还是会本能地翻日志、用老办法，担心AI无法理解复杂的上下文，害怕它“胡说八道”反而添乱。 但“真香定律”来得很快。团队发现，AI确实能在一秒钟内过滤掉大量无用的报错信息，快速提供排查思路。现在已经有人提出，希望将监控报警全部接入AIOps的根因定位，甚至让AI自动执行应急恢复策略。 一个特别明显的例子是测试环境联调场景。团队搭建了生产与测试两套环境，测试联调时，一旦出问题直接抛给AI，团队之间的沟通协同成本被显著降低。这也是当前从STAROps上挖掘出的一个高性价比场景。更多玩法与想象空间仍在持续探索——这是一个信任逐步建立的过程。你先把它用在哪个场景里，这一点至关重要。 ## 智能运维应该成为AI时代的基础设施 团队认为，智能运维未来的边界不应只停留在运维人员范围内，而应真正武装到每一个开发人员手中，贯穿研发全流程。例如，在AI Coding过程中引入STAROps实现开发运维一体化；测试阶段AI发现问题能自动进行根因定位，并给出代码修复建议；灰度部署时能自动监控并触发回滚。 同时，也希望STAROps能够进一步“降门槛”“做下沉”。能力不局限于某一平台，而是能像插件一样开放，嵌入每一个开发同学的本地IDE，嵌入CI/CD流水线，与企业的整个研发体系深度集成。让它成为每个工程师随手可用的基础设施，而不仅仅是运维专家才能驾驭的工具。 与此同时，吉利也在同步推进自身建设。团队正在将治愈模块做成标准命令，让模型能够直接调用。企业侧构建资产、产品侧提供模型能力，两者拼在一起才能形成完整闭环。这是一个深度合作的过程。 ## 智能运维的终极目标，是消灭“运维焦虑” 智能运维的终极目标，不是消灭故障——故障永远会发生。它的目标，是消灭“运维焦虑”。当工程师能安心入睡、业务方不再被凌晨叫醒、团队精力从“猜故障”转向“创价值”，这才是技术真正传递的温度。 从“人找问题”到“问题找人”，从“经验驱动”到“数据+AI驱动”，这一路走来，三层迁移正在悄然发生。技术上，传统的“监控—报警—工单”链路，正在被“可观测数据—统一建模—智能体诊断—自动治愈”的新链路取代。组织上，运维团队从被动响应的“工单处理者”转向主动经营的“平台运营者”。观念上，每个企业的体系各不相同，智能体的能力需要与人类一起持续打磨优化——这本质上是一个以数据治理为底座、以产品能力为引擎、以组织协作为保障的系统工程。 吉利与阿里云STAROps的合作还会继续，方向也已经清晰了。