亿级用户背后的智能诊断：多模态数据融合与实时诊断实践

如果无法正常显示，请先停止浏览器的去广告插件。

1. 亿级用户背后的智能诊断：多模态数据融合与实时诊断实践徐建伟

2. 目录 01 从"人肉排查"到"AI诊断"：bilibili 的痛点与机遇 02 智能诊断核心架构和演进思路 03 核心场景的 AI 化改造实践 04 技术演进方向与实践展望

4. 01 从"人肉排查"到"AI诊断" bilibili 的痛点与机遇

5. 亿级用户背景下的故障挑战：复杂度指数级增长当故障发生时，监控系统会几百个服务，成千上万的组件中瞬间产生海量的、多维度的原始数据数据洪流与信息过载规模庞大、组件繁多、交互关系错综复杂，而依赖的传递性与放大效应会导致排查困难系统复杂度与依赖黑洞微服务之间都是网状调用，一个服务挂了，所有依赖它的服务都可能被拖垮，形成雪崩效应故障发生时，多个团队（网络、基础设施、应用、数据库）在高压下如何快速协同，避免扯皮和信息混乱。爆炸半径与隔离难度组织协同与沟通成本

6. 传统线上排障的三大瓶颈时间成本准确率知识传承手动排查，流程串联依赖经验，易误判知识隐性，难复制拉群、查日志、口头同步 MTTR （平均恢复时间）过长，业务损失拉群、查日志、口头同步处理方案无效，甚至扩大故障 “大神”的直觉和经验人员变动导致运维能力断崖式下跌

7. AI 技术带来的机遇：数据驱动 + 智能推理数据高质量、统一的可观测性数据基础领域知识与AI技术的深度融合反馈稳定性建设持续学习与反馈优化能力知识与运维系统和办公协同软件集成协同

8. 02 根因分析核心架构和演进思路

9. 场景化分析模型整体架构多模态知识图谱模型分析日志 CMDB 关联图谱业务下跌链路接口上下游，强弱图谱请求异常场景指标 event 数据库关联图谱慢请求场景 profiling 缓存关联图谱异步消息图谱数据延迟

10. 多模态数据融合 1 2 3 4 Metric & alarm 按照一段时间聚合（默认30秒）， Trace 明细采样数据，微服务之间的调用关系明细 Log ，明细数据，记录一些关键信息和异常信息 Event & Profiling 关联数据，相互印证可能的原因

11. 知识图谱构建多源数据集成知识抽取与实体关系定义将来自不同源头、不同格式的监控数据（主要是指标、日志、追踪）进行采集、对齐、关联和融合，形成一个统一的、具有上下文的视图多源异构的运维数据中，自动识别和提取出关键的、结构化的信息片段，这些信息片段将成为知识图谱中的“实体”和“属性” 知识存储与图谱构建在线推理与自动处置规则注入与图谱增强选择了为关系查询而生的图数据库作为最佳载体，将散落的知识点有机地整合成一张映射真实系统架构的语义网络知识应用与智能推理利用已经构建好的、结构化的知识库（知识图谱），通过模拟人类专家的思维过程，对实时故障数据进行自动分析、推理和决策抽象归纳与规则定义案例沉淀与模式发现

12. 大小模型分析自然语言处理 + 时序分析的深度融合时序算法分析时序分析算法（如异常检测模型）检测到某个服务的P99 延迟指标在10:05:00出现一个尖峰（异常点）。. 多模态数据关联与上下文构建系统根据触发异常的时间点和实体，自动拉取相关时间段内的所有关联数据，并将其组织成一个结构化的“上下文窗口” 大模型推理与分析准备好的多模态上下文信息，精心构造成提示词（Prompt ），提交给大模型（如GPT - 4, LLaMA , 或领域微调的模型）进行分析

13. 数据提纯：打造高信噪比的诊断燃料清洗去重，无效值处理，噪音过滤，格式化 1 对齐时间对齐（时间同步，时间窗口划分）实体对齐（标签统一，拓扑关联） 2 增强富化（添加更多描述性标签）衍生指标计算（从原始指标中计算出更有业务意义的表现力指标）模式发现（发现频繁出现的错误模式） 3 去芜存菁，得到原材料大幅减少数据量，只保留与本次故障强相关的数据片段。这是降低噪音的关键一步。搭建骨架，建立数据之间的时空关联对过滤后的数据进行分组、统计和模式识别，将零散的个体异常汇总成群体性规律，从而发现共性问题。画龙点睛，注入业务语义和上下文将不同来源（日志、指标、追踪）和不同组件的数据进行交叉关联，为故障点补充完整的上下文，最终定位根因。这一步是“为什么”的关键。

14. 模型迭代：动态调整推理边界 1 执行诊断与产生证据模型基于当前的推理边界（如：只检查直接依赖的服务）对故障进行初步分析，并输出诊断结果（如：根因是服务A ）和支持该结果的证据链（如：因为服务A 的延迟飙升，且错误日志显示XXX ） 2 3 推理边界调整分析 3 1 根据反馈，系统会分析上次推理的不足，并决定如何调整边界 4 4 模型与知识库更新和重跑验证 2 结果验证与反馈获取描述：诊断结果需要接受验证。这可以通过两种方式：人工反馈：运维专家确认或驳回结论。自动化验证：系统执行修复动作（如重启服务A ）后，观察指标是否恢复正常。关键：这个反馈是模型迭代的“黄金标准”。将分析后的调整策略应用到模型和知识库中。让 AI 学会“灰度思考带着更新后的、调整了推理边界的模型，对这次故障进行重新诊断，验证结果

15. 工单即训练集：每一次人工复盘都是模型的进化机会在此过程中，所有操作、观察点和时间线都被系统化地记录（如通过统一的运维平台），为后续复盘提供原始数据发生故障与人工处置 1 生成高质量工单与复盘报告 4 故障解决后，负责人撰写复盘报告。这份报告是监督学习中的“标注数据” 2 报告解析与知识提炼 3 AIOps 系统利用NLP 技术（如大模型）自动解析复盘报告，将其中的非结构化文本转化为结构化的知识模型更新与进化将上一步提炼出的结构化知识注入到各类模型中，模型从“新知识”中学习，实现了进化

16. 03 核心场景的 AI 化改造实践

17. 视频播放异常：从告警到根因定位的 3 分钟闭环现象定界定位 Dolor ex consectetuer ea dolor no takimata aliquam ipsum in iriure iriure ut labore. 触发可用率告警后自动触发根因分析，30 秒后推出根因分析，快速定位

18. 场景化分析模型领域知识库构建和因子关联 mysql SLO 接口异常/耗时长缓存慢查询/长查询 mq 数据连接异常- > 连接池打满，网络连通情况，服务端运行健康状态慢sql- > 扫描行数，索引使用，锁占用物理机cpu 、内存、io出现瓶颈或者故障消费者延迟或消息堆积上游请求变化下游异常波动客户端检测连接池使用情况（连接池慢，或者未正确关闭） Producer 生产速率服务端写入情况采样trace/log的详情容器/主机异常，运行时异常查找/扫描记录（识别大key，大命令） Consumer 的消费速率 Consumer 资源变化情况关联变更资源使用情况（内存耗尽，内存碎片等） Rebalance 日志

19. 推荐系统降级：多组件级联故障的智能溯源现象定界定位

20. 04 技术演进方向与实践展望

21. 场景覆盖的扩展降低用户领域知识到根因模型的转化门槛业务特定场景基础硬件和系统层中间件服务端应用SLO 中间件服务端微服务可用率对应用相关的指标，链路，日志进行分析，找到可用率下跌的原因对数据库，缓存，消息中心等基础组件进行根因分析。比如常见的慢sql问题，缓存击穿等系统层或者硬件层对网络，物理机，容器，系统层等进行根因分析，比如节点与硬件故障，网络故障，oom ，oomkiller 业务场景对业务自身的逻辑进行问题定位，尤其是一些客服召回的比如说交易下跌，直播在线人数突降，弹幕事实同步下降

22. •准确率的持续提升从问题定界向精准定根因的技术深化演化知识库推导优化多根因方式定界，有一个命中就算成功集成强弱依赖特征增强变更明细因果关系第一根因准确定界才算成功异常归类根因链路合并第三方接口集成第一根因从定界到定位通用库日志集成历史数据因果特征构造

23.

24. THANKS 大模型正在重新定义软件 Large Language Model Is Redefining The Software