不再为告警“救火”：AIOps 如何重塑腾讯音乐的智能运维体系

更新时间：2025-12-10 15:33  浏览量：1

作者｜边雪冬

编辑｜李忠良

策划｜AICon 全球人工智能开发与应用大会

在 AI 技术快速发展的浪潮下，企业如何在有限资源下提升效率、保障质量，并推动智能化运维成为行业关注的核心议题。InfoQ 荣幸邀请到了腾讯音乐 / 运维开发组组长边雪冬，他在 AICon 全球人工智能开发与应用大会·深圳站上分享了《AIOps 驱动下的 TME 腾讯音乐智能运维新范式》。

在本次分享中，他结合了腾讯音乐的实践经验，介绍团队如何通过 AI 优化告警、提升根因分析效率、构建专家库，并展望 AIOps 在智能问答、自动化执行与算法升级等方向上的演进路径，为业界提供思考与借鉴。

12 月 19～20 日的 AICon 北京站将锚定行业前沿，聚焦大模型训练与推理、AI Agent、研发新范式与组织革新，邀您共同深入探讨：如何构建起可信赖、可规模化、可商业化的 Agentic 操作系统，让 AI 真正成为企业降本增效、突破增长天花板的核心引擎。

详细日程见：

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

在腾讯音乐（TME）体系下，我们拥有多款面向不同用户群体的应用，包括全民 K 歌、QQ 音乐、酷狗和酷我。为了支撑这些业务的稳定、高效运行，背后有大量的开发团队在协同工作。而我们团队主要负责底层的基础保障能力建设，例如微服务体系、可观测性体系，以及 DevOps 和 K8s 平台的统一支撑。

随着 AI 时代的快速发展，公司也在不断推动我们在业务中探索更多基于 AI 的创新玩法，为用户带来更优质的产品体验。与此同时，我们在内部也积极尝试将 AI 与现有的基础技术体系进行结合，既服务业务创新，也反哺工程体系升级。

基于这样的背景，主要围绕两个方面展开：

第一，是关于 AI 时代的一些思考——在基础领域，我们如何更高效地与 AI 结合，并确保内部 ROI 能够保持正向发展，避免为了“用 AI 而用 AI”的无意义扩张。毕竟，人力和资源都是有限的，我们必须在合适的场景中找到真正具备价值、能够落地的突破点；第二，是围绕这些场景的实践探索——分享我们在实际应用中的一些效果和经验。

整体来看，我们对 AI 的探索，仍然是基于传统的三要素：质量、效率和成本。核心问题在于：如何利用 AI 在其中一个或多个维度上产生实实在在的价值，形成对整体体系的助力。

在具体实践中，我们主要从感知、决策和执行三个层面来推进落地，希望通过这三个环节的联动，真正发挥 AI 的能力，释放出可量化的效果。围绕这一目标，我们也对当前整体业务的基础架构进行了系统性的梳理。

在整体的基础架构中，首先是 DevOps，这可以说是最必要、也最底层的一环。从 CI（持续集成）、到 CD（持续交付 / 部署），再到 CO(持续运营)，形成一套完整的闭环能力。我们的目标非常明确：让研发同学尽可能专注于写代码，其他流程尽量交由平台和标准化机制来完成；

其次是 SRE 体系。在这套体系中，我们观察到，很多问题其实都源自于上线过程中的变更，因此核心之一就是：如何确保变更的有效性和可控性。同时，我们也在持续构建和完善 SLA 体系，以此来保障业务质量。

从故障发现、到根因排查、再到最终解决，通过提升响应效率和处理效率，来实现整体业务质量的提升；

最后是云原生体系。它为我们提供了一套更加稳固、弹性的基础底座。借助云的能力，我们希望将过去一些自建的、相对不规范的部分逐步标准化，并把这些规范和能力贯穿到各个环节之中，从而在整体上进一步提升系统的稳定性和质量。

AIOps 三大“未来式”应用

“听”出问题的“音乐雷达”

我们率先将 SLA 体系与 AI 相结合，因为 SLA 对业务质量的保障始终是最高优先级。

我借助 AI 生成了一张图，用来展示十年前我们工作的现状：当时每人每月平均需要处理约 3,000 个电话告警，折合下来每天超过 100 个，几乎每 10 分钟就会有一次告警来电。许多同事不得不一手拿着手机、一手操作鼠标，长期处于“救火”状态，AI 也将这一场景形象化为消防员。

在历史最初的业务架构中，各类监控数据量极为庞大。例如，Web 层就有四种不同的监控方式。但哪种监控更有效？这些监控点大多是开发和运维同事在一次次“救火”过程中不断补充出来的，最终形成了一个庞杂的体系。

为此，我们首先着力提升监控数据的有效性，确保在正确的时间触发告警，避免误告。我们引入了 3-Sigma 算法，将告警波动转换为波动幅度，并以幅度深度为依据生成整体告警。过去的告警依赖各业务自行设定阈值，例如 98% 触发告警，但 95% 或 99% 是否需要告警并无统一标准，往往还掺杂失败趋势。

我们也引入了同比和环比等指标，生成相对基准值，并结合波动幅度和深度来判定是否需要触发告警。在此基础上，我们进一步制定策略：当波动幅度达到一定深度时，能够更快地帮助业务发现问题；当波动恢复平稳并持续一段时间时，则判定业务已恢复正常；若处于抖动期，则将深度重置为 0，再重新判断是否需要告警。

通过这一算法的底层支撑，我们已将用户接收到的月度告警电话数从 3,000 余次减少至 200 余次，大幅降低了告警负担。

自愈式运营: 系统自己“调准音”

接下来面临的问题是告警种类过于繁多。举例来说，某次业务发生成功率下降的告警，同时运维侧又收到内存上升的告警，那么如何将二者关联起来并找到真正的根因？在大模型应用的初期，我们基于 AI 构建了一套分析的工作流（workflow）。

当数据进入后，首先由 AI 进行问题分析与反馈，随后调用相关插件并完成重写；在此基础上，再结合内部知识库与文档进行检索与构造，并通过大模型补充信息，最终生成问答建议与问题定位。围绕这一流程，我们还开发了多种工具，例如容量检测，以及微服务中的熔断、限流、染色等能力。

自去年起，我们开始尝试使用 Dify 来简化这一工作流。借助 Dify，我们可以在 workflow 中灵活选择 Hugging Face 上的主流模型，并结合已有的知识库开展定向翻译。

例如，针对种类繁多的业务返回码，我们能够自动完成统一翻译。同时，利用其闲聊能力，我们构建了运维机器人，帮助业务同学更快速地解决问题。最后，再结合 DeepSeek 的深度思考，生成最终的解决方案，用于回复用户或辅助完成告警分析。

在单条告警分析思路的基础上，我们逐步向外扩展，覆盖了基础类与业务类的全部场景。目前，从业务日志采集、组件发布到变更等各个环节，均已经整合进 AIOps 体系。

在链路分析方面，我们结合 Trace、Metric 与 Log 三要素，同时利用业务上报的主调与被调关系，构建关系网络，实现链路的全景分析。

最终，我们通过链路分析实现了上下游的扩展，对请求量、耗时、聚集以及变更情况进行可视化呈现。

在这套体系下，我们对告警的处理已经更加高效。举个例子，当时线上出现了高低异常的情况，分析器识别出这是由部分内存异常引起的业务问题，并进一步定位到具体涉及的 IP，以及各个 IP 上的异常增长情况。对于单条告警（比如 CPU 告警），我们会统一采集所有设备的快照，再通过快照分析，更准确地发现和还原业务问题。

在另一个案例中，我们首先发现了业务告警，随后结合代码仓库中的 AICR 能力进行分析。AICR 能够聚合每次提交的 commit 信息，识别出修改和删除的代码位置，并检查其中是否存在潜在隐患。

例如，在某次提交中，就在最后一行代码里发现了边界问题，可能导致线上故障。一旦问题发生，AI 能够快速给出综合性的结论，显著缩短问题定位的时间。

基于这一整套体系，我们对所有告警进行了整体分类，并由 AI 自动打标。结果显示：业务逻辑错误约占 40%，IP 聚集问题约占 20%。有了这样的分类依据，我们就可以制定更具针对性的处理策略。

例如，在容器化或 CVM 场景下，对于这类问题可以直接采取自愈措施：当告警出现时，自动剔除异常路由，或者销毁并重建容器，从而实现快速恢复，避免故障范围进一步扩散。

同时，我们还需要重点推进专家库的建设。目前，约 40% 的告警属于业务逻辑错误，另有约 16% 属于未知原因，这两类问题合计占比已经超过一半，其背后的核心原因在于专家库的积累仍然不足。

生产环境中的服务数量非常庞大，仅 QQ 音乐的生产服务就超过一万个，如何对这些服务进行标准化治理，依然是一项非常重要且长期的课题。

此外，每次故障的复盘报告也至关重要。只有通过持续复盘并将报告进行标准化，AI 才能真正“理解”故障产生的根因。基于这些沉淀，AI 才可以在下一次类似问题出现时提供有效参考，辅助完成定位和分析。

因此，我们优先推进的是业务体系的标准化建设，尤其是返回码的规范。在返回码处理上，首先需要明确其类型：是成功、失败，还是逻辑失败。其中，逻辑失败是指不影响整体服务质量，且具备兜底保障的情况。

其次，要为返回码建立统一的命名规则和处理建议。当某一返回码出现时，AI 能够识别其含义，并给出对应的处理方式。通过这一过程，我们也在逐步完善专家库的建设。

个性化运维：为不同业务“定制乐谱”

除了基础告警和通用类告警外，我们还涉及更多定制化的告警类型，例如海外的 JOOX 平台告警、各业务线定制化告警、会员收入告警等。如何让模型理解这些告警的含义，并能够给出整体的解决思路，是我们当前重点关注的问题。

这里的核心依然是数据，AI 与数据始终是紧密相连的。目前，我们已经构建了一套完整的数据银行体系：从数据上报、Flink 处理，到源数据入库，再到结合 OLAP 数据库生成结果。

运营数据可以由运营或 BI 同学通过 SuperSet、Chart BI 进行回收和分析；开发同学则可以通过 Grafana 进行定制化配置。同时，我们将基础数据与自定义数据统一采集，最终在 AIOps 体系中与监控告警打通，形成整体的根因分析能力。

例如，当我们在 JOOX 音乐平台收到告警后，首先通过总结分析发现，某一版本的 APP 在某个城市的特定运营商处出现了大规模失败。进一步由 AI 分析并定位到具体的运营商 IP，从而反推问题是否源于接入点覆盖不足。

如果确实存在覆盖不足，我们会及时完善接入点的布局。在海外场景下，如果问题出在当地运营商本身的网络连接，我们会下沉到当地业务，与运营商协同解决，确保中间通路顺畅，提升用户体验。

同时，对于业务自定义上报的告警，我们也引入了波动幅度算法进行智能分析，并结合 AI 快速判断数据在处理过程中的异常情况。当上报数据中包含关键指标时，还会与基础指标进行关联分析。

例如，在流量、报文量或内存上升时，进一步分析是否导致了 CPU 异常，并追踪到具体进程及其原因，从而形成完整的数据治理闭环。

AIOps 总结与探索

当前，我们已基于 AI 对 SLA 体系进行了全面保障，下一步重点在以下几个方面：

第一，智能问答。通过问答机制提升协作效率，将“人找人”的模式转变为“人找 AI，AI 找人”的模式，实现更高效的衔接；

第二，自动化执行。AI 在分析中能够给出明确结论，我们计划基于这些结论驱动 SDK 自动化操作。针对幻觉问题，我们的思路是为 AI 提供明确结果和充足数据，禁止发散，让其输出针对性结论，再由系统据此执行具体动作；

第三，算法升级。目前的波动幅度算法仅依赖当前数值进行告警判断，未来将结合业务特性进一步优化。例如在音乐场景中，节假日或演唱会直播等活动会引起带宽与业务量的显著增长，需要通过 3-SIGMA 与特征提取算法结合，提升告警的准确性与有效性；

最后，集团战略是一体两翼，从内容线到平台线深度融合。同样，我们在建设 AIOps 体系也采用“一体两翼”的战略：以云原生和智能分析为基础，打造更先进、更智能的体系，让 AI 在其中发挥更高价值。

AI 重塑组织的浪潮已至，Agentic 企业时代正式开启！当 AI 不再是单纯的辅助工具，而是深度融入业务核心、驱动组织形态与运作逻辑全面革新的核心力量。

把握行业变革关键节点，12 月 19 日 - 20 日，AICon 全球人工智能开发与应用大会（北京站） 即将重磅启幕！本届大会精准锚定行业前沿，聚焦大模型训练与推理、AI Agent、研发新范式与组织革新，邀您共同深入探讨：如何构建起可信赖、可规模化、可商业化的 Agentic 操作系统，让 AI 真正成为企业降本增效、突破增长天花板的核心引擎。