吉利汽车智能运维实践指南：从报警风暴到主动免疫
我是宋鸣，在吉利汽车负责用户数据中心的数据质量。如果问我，为什么一家车企会和云厂商把智能运维做这么深入，答案非常直接：当业务规模与复杂程度同步指数级增长，传统运维模式的天花板清晰可见。我们没有等待，而是主动用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的合作还会继续，方向也已经清楚了。