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

目录

一、宏观背景:运维复杂度越来越高

二、传统 AIOps 的建设

三、AI 体系建设:三大步与五个关键阶段

四、AI 基础能力建设——知识库

五、AI Agent 建设——代表性场景

六、场景实践详解

七、建设经验总结

八、AI + AIOps 能力分层总结

一、宏观背景:运维复杂度越来越高

图片图片

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

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

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

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

  • 报警风暴频发
  • 故障排障效率低下
  • 严重依赖个人经验

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

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

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

二、传统 AIOps 的建设

图片图片

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

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

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

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

右边是监控平台的架构图,主要包括:

  • 实时指标仓库及相关系统
  • 与研发共同建设的全链路压测系统(帮助更快定位问题)
  • 可视化监控平台

图片图片

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

  • 数据源层:通过Agent、API和消息队列等多种方式将数据接入
  • 数据处理层:同时文档规则层,包括SOP、经验规则等非结构化或半结构化数据。
  • 分析层:通过各类 AIOps 算法实现根因分析、异常检测、容量规划等
  • 最上层:运维系统,如报警中心、监控大盘、自动化编排、自愈系统等

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

传统 AIOps 的收益与局限

图片图片

取得的收益:

  • 平均修复时间(MTTR)降低
  • 报警准确率提升
  • 报警风暴治理有效减少
  • 人工介入率降低

但局限性依然存在:

  • 数据孤岛:日志原文、变更系统、代码发布工单、文档等,没有被充分利用
  • 经验流失:专家经验随着人员离职或调岗流失,没有沉淀积累下来
  • 人机交互门槛高:每个业务有各自的系统,查问题时需要翻阅大量页面
  • 单点模型泛化能力弱:缺乏模型间的联动,面对新型故障或跨域问题时,单点模型往往力不从心

三、AI 体系建设:三大步与五个关键阶段

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

图片图片

第一步:AI 辅助编程

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

第二步:基础能力建设

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

第三步:AI Agent 建设

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

四、AI 基础能力建设——知识库

图片图片

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

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

  • 故障案例知识库
  • SOP 操作手册库
  • 业务逻辑知识库
  • 专家经验知识库

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

MCP 工具封装

图片图片

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

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

五、AI Agent 建设——代表性场景

图片图片

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

1.全站热点事件分析(重点场景,后面有详细案例)

2.根因分析类场景

  • 接口异常分析
  • 刷站分析
  • 客户端 Crash 分析
  • 故障舆情分析

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

3.业务运维助手

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

  • 日常巡检
  • 单机处置
  • 扩容等常规场景

4.代码发布辅助

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

六、场景实践详解

案例一:热点应对 AI Agent

图片图片

背景:

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

传统应对方式:

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

与此同时,运营同事会问:”能继续铺量吗?扛得住吗?”

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

AI Agent 方案:

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

  • 当前热点是什么
  • 流量趋势如何
  • 关键时间节点
  • 最后用大模型给出操作建议

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

实际案例展示(右侧):

  • 热点原因摘要:Agent 收集各类数据,分析出当前热度原因,生成摘要
  • 流量特征分析:主要分析核心场景,输出流量特征、时间、流量趋势
  • 全服务热度概览:包括其它等核心服务的流量、扩容、降级情况
  • 起量时间校验:判断当前起量时间与铺量时间是否吻合,区分真实流量与刷站
  • 操作建议:给出具体处置建议(后续计划将建议与处置动作关联,实现自动扩容、降级)

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

案例二:根因分析——舆情分析

图片图片

背景:

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

传统应对方式:

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

AI Agent 方案:

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

实时分析报告输出(右侧案例):

  • 舆情浏览情况与整体影响
  • 影响的功能模块
  • 用户投诉摘要
  • 系统指标验证
  • 根因分析
  • 处理建议
  • 自动关联工单系统、变更记录、代码发布

关键洞察:

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

案例三:客户端根因分析

图片图片

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

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

七、建设经验总结

1、AIOps 体系的整体建设平台

图片图片

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

  • 注册 MCP 工具
  • 搭建自己的 AI Agent 产品
  • 借助平台的 AI Agent API 能力(如 Crash 分析、流量突增诊断、代码 Review 等常规应用,在不改变传统运维习惯的情况下,也能享受 AI 赋能
  • 利用平台的多 Agent 系统编排能力,将单一 Agent 组合成复杂工作流,提升运维效率

2、建设心得与思考

图片图片

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

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

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

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

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

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

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

  • 经验四:小模型辅助

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

八、AI + AIOps 能力分层总结

图片图片

整体上,AI + AIOps 能力分为三层:

  • 第一层:AI 辅助开发,提升运维开发效率
  • 第二层:知识库 + MCP 工具 + API 体系,作为 AI 的基础能力底座
  • 第三层:AI Agent 辅助决策 + AI 辅助增强

图片

作者介绍

马朕,新浪微博研发中心基础平台负责人,负责新浪微博DevOps、SRE和AIOps等方向工作,参与微博热点流量应对体系、DCP混合云平台、PaaS平台、AIOps运维体系的创立与建设。

文章来自:51CTO

Loading

作者 yinhua

发表回复