AI Agent协作运维在新浪微博的落地与演进

整体宏观背景：运维的复杂度正在不断攀升。

第一个背景是云原生与微服务的全面应用。容器化、服务编排、服务网格等技术的引入，让系统架构的复杂性急剧上升。服务从最初的几十个，现在已经增长到 3000 多个服务。

第二个背景是多云体系。既有公有云、私有云，还有边缘计算等，网络拓扑结构变得非常复杂。跨云环境下的监控、故障的精准定位，难度也大幅提升。

这些变化导致传统运维模式出现了明显的瓶颈：

• 报警风暴频发

• 故障排障效率低下

• 严重依赖个人经验

右边是新浪微博当前的服务规模数据：日活跃用户 2.5 亿+，请求量百亿级，在线服务数 3000+，监控项达到千万级。

在这种规模下，一旦出现故障，需要查询的监控系统和报警页面非常多。当前遵循业界通行的 "1、5、10保障策略“——1分钟发现问题，5分钟定位问题，10分钟解决问题。但在很多场景下，这个目标其实很难实现。

与此同时，各公司对服务保障的要求越来越高。老板在"1、5、10"的基础上，总是会问：能不能更优化？能不能做到 "1、3、5"？

基于以上痛点，新浪微博开始升级传统的 AIOps。要升级，首先需要把多元数据进行统一。

先将指标数据、报警数据等六大类数据进行统一接入。只有数据全面且统一，上层的智能分析才能更准确、更有意义。

数据采集完成后，还需要进行数据清洗和质量校验——垃圾数据进来，垃圾数据出。只有高质量的数据，才能支撑准确的智能分析。

最后，将不同类型的数据分别落地到各自的存储仓库或实时计算引擎中，供智能算法在不同场景下调用。

右边是监控平台的架构图，主要包括：

• 实时指标仓库及相关系统

• 与研发共同建设的全链路压测系统（帮助更快定位问题）

• 可视化监控平台

这是上一代 AIOps 中比较流行的做法。整体架构分为：

• 数据源层：通过Agent、API和消息队列等多种方式将数据接入

• 数据处理层：同时文档规则层，包括SOP、经验规则等非结构化或半结构化数据。

• 分析层：通过各类 AIOps 算法实现根因分析、异常检测、容量规划等

• 最上层：运维系统，如报警中心、监控大盘、自动化编排、自愈系统等

这个架构在过去几年确实支撑了微博的运维智能化转型，也取得了一定的效果。但随着业务规模和技术栈的持续演进，它的天花板也逐渐显现。

取得的收益：

• 平均修复时间（MTTR）降低

• 报警准确率提升

• 报警风暴治理有效减少

• 人工介入率降低

但局限性依然存在：

• 数据孤岛：日志原文、变更系统、代码发布工单、文档等，没有被充分利用

• 经验流失：专家经验随着人员离职或调岗流失，没有沉淀积累下来

• 人机交互门槛高：每个业务有各自的系统，查问题时需要翻阅大量页面

• 单点模型泛化能力弱：缺乏模型间的联动，面对新型故障或跨域问题时，单点模型往往力不从心

基于以上问题，微博启动了 AI 体系的建设，整体分为三大步、五个关键阶段。

随着公司推进代码辅助编程，运维团队与研发一同探索如何提升效率。从最初的运维脚本自动化编写，到后来的自动化工具构建、运维系统开发，现在都能用 AI辅助开发来提效。运维系统的部分核心模块的代码覆盖率已经接近 100%。

同时构建了运维知识库，并将多年来积累的自动化平台和工具的能力，封装为 MCP 工具和 SKILL，作为基础能力来支撑上层的 AI Agent。

将传统运维保障中的高频的场景，逐步建设成运维 AI Agent，最终形成运维工具矩阵，全面提升运维效率。

在 AI 建设过程中发现：多年积累的运维经验、运维文档，是极其宝贵的财富。

于是建设了涵盖四个体系的知识库：

• 故障案例知识库

• SOP 操作手册库

• 业务逻辑知识库

• 专家经验知识库

知识库能够降低运维沟通和学习成本，有助于互备和轮岗，减少服务保障的单点风险——有些服务变更不频繁、重要性不高，可能只有一个人兼任，存在单点隐患。

将研发与运维共同使用的 PaaS 平台、DCP 混合云平台（适配多云架构）以及各类运维系统，将其核心能力封装为 AI 可以理解和调用的 MCP 工具，支撑上层的 AI Agent。

同时，将运维 MCP 工具集成到公司级的 MCP 平台上，方便业务间互相调用，并设置了权限管理，防止误用或滥用。

AI Agent是建设的核心。下面列举几个已建设完成、较有代表性的场景：

• 全站热点事件分析（重点场景，后面有详细案例）

• 根因分析类场景

• 接口异常分析

• 刷站分析

• 客户端 Crash 分析

• 故障舆情分析

这些是微博传统的高频运维场景，AI 的引入大幅提升了工作效率——因为这些分析往往不是单一步骤就能搞定的。

• 业务运维助手

为每个业务建立了专属运维助手，可完成：

• 日常巡检

• 单机处置

• 扩容等常规场景

• 代码发布辅助

在核心或常规服务上线时，除了监控报警，还要检查日志是否有异常（不只是 4xx/5xx 等简单判断）。将这部分人工判断工作交给 AI，提升了运维效率。

背景： 

微博产品的用户最常用的场景就是"吃瓜"。一旦出现热点新闻，大量用户同时涌入访问，给服务带来巨大峰值。根据峰值下 QPS 的浮动定义热度等级。热点可能发生在凌晨、上下班路上，或者周末。

传统应对方式：

热度高时，值班人员可能接到多个电话。服务可能会有自动降级、自动扩容报警，但扩容不及时就会导致资源性能问题。此时还要搞清楚：流量为什么突然涨了？造成流量突增的原因？核心服务当前的流量情况如何？扩容是否及时？降级状况如何？网关兜底情况怎么样？

与此同时，运营同事会问："能继续铺量吗？扛得住吗？"

传统模式下，虽然有各种自动化报警和通知，但还是需要人工去判断哪个是热点、当前情况如何。值班人员能力参差不齐时，就会影响判断，错过最佳应对时机。

AI Agent 方案：

Agent 自动收集数据、进行聚合分析，帮助判断：

• 当前热点是什么

• 流量趋势如何

• 关键时间节点

• 最后用大模型给出操作建议

这个自动化流程大幅缩短了响应时间——热点从出现到发酵的时间非常短，一旦错过就可能造成服务损伤。

实际案例展示（右侧）：

• 热点原因摘要：Agent 收集各类数据，分析出当前热度原因，生成摘要

• 流量特征分析：主要分析核心场景，输出流量特征、时间、流量趋势

• 全服务热度概览：包括其它等核心服务的流量、扩容、降级情况

• 起量时间校验：判断当前起量时间与铺量时间是否吻合，区分真实流量与刷站

• 操作建议：给出具体处置建议（后续计划将建议与处置动作关联，实现自动扩容、降级）

效果： 用了 AI Agent 之后，分析热点不用拍、不用猜、不用等，直接给出结论，保障效率大幅提升。

背景： 

微博用户有一个习惯——不太打客服电话或私信小秘书，而是直接在微博里发帖，比如"微博 崩了""iOS 客户端异常""安卓客户端异常"，在话题下描述遇到的问题。

传统应对方式： 

客服团队零零散散地收集这些反馈，找出共性问题，判断是偶发还是普遍情况，再交给运维人员分析，复杂的话还要拉上研发人员一起，整个过程比较慢。

AI Agent 方案：

建设 AI Agent 后，系统自动获取当前监控情况，同步分析客户端、网关、后端接口成功率，用多维特征下钻和数据锤子分析等手段，综合判断故障异常原因。

实时分析报告输出（右侧案例）：

• 舆情浏览情况与整体影响

• 影响的功能模块

• 用户投诉摘要

• 系统指标验证

• 根因分析

• 处理建议

• 自动关联工单系统、变更记录、代码发布

关键洞察：

绝大多数问题（90%以上）都是由变更引起的——没有变更就没有故障。业务庞大后，变更内容非常多，传统人工查看的方式很吃力，AI Agent 的方式效率更高。

客户端问题是处理起来最麻烦的一类——端上日志既多又大，碎片化严重。

平均处理时间比前两个场景更长。基于 AI 分析流程，效率提升非常明显。右侧也展示了具体案例。

AIOps 体系基于公司内部开发的 Wegent平台 进行建设。在该平台上：

• 注册 MCP 工具

• 搭建自己的 AI Agent 产品

• 借助平台的 AI Agent API 能力（如 Crash 分析、流量突增诊断、代码 Review 等常规应用，在不改变传统运维习惯的情况下，也能享受 AI 赋能

• 利用平台的多 Agent 系统编排能力，将单一 Agent 组合成复杂工作流，提升运维效率

• 经验一：不必所有场景都用大模型

在建设过程中发现：有的场景无论从效率还是成本角度，并不是必须用大模型。用 AI 去优化自动化策略，反而更高效、更节约成本。

于是内部提出了 "AI 增强机制"——不需要大模型的场景就优化掉。

• 经验二：数据清洗与成本控制

只给 AI Agent 传递必要的数据，避免成本浪费。

• 经验三：人机协同应对幻觉

涉及破坏性操作时，引入人机协同机制，增加确认环节，确保安全。目前还在逐步推进中。

• 经验四：小模型辅助

一些小规模的运维数据标注任务，使用小模型来处理，既提升效率，又节约成本。

整体上，AI + AIOps 能力分为三层：

• 第一层：AI 辅助开发，提升运维开发效率

• 第二层：知识库 + MCP 工具 + API 体系，作为 AI 的基础能力底座

• 第三层：AI Agent 辅助决策 + AI 辅助增强