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