关于智能运维，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的合作还会继续，方向也已经清楚了。
