简介面向运维工程师、SRE及技术管理者的AIOps体系构建参考资料以百度在智能运维方向的落地实践为主线梳理从数据采集、异常检测到故障预测的完整链条。内容围绕机器学习、自然语言处理与数据挖掘等技术在IT运维中的结合方式展开涉及日志、性能、配置等多源数据的接入与处理思路以及监督学习、无监督学习、半监督学习等算法的选型考量并对数据质量、算法选择、模型可解释性等落地难点给出相应应对措施。资源包仅含1个PDF文档大小约16.91MB页面完整便于离线阅读、逐页批注与团队内部分享。目前已有245人学习下载。适合希望了解大型互联网公司AIOps架构演进、为自建智能运维平台做技术选型或方案调研的读者参考可从中获取体系分层、能力模块划分、算法应用场景与运维自动化收益等具体线索用于对照自身运维现状查漏补缺。1. AIOps 到底是什么从告警风暴到根因定位的运维分水岭凌晨两点值班手机在十五分钟内弹出四百条告警——CPU、延迟、错误率、连接数全红运维工程师第一反应不是哪个服务挂了而是先看哪一条。这不是监控能力不足而是信号处理能力被淹没。AIOps智能运维解决的正是这个问题它不承诺AI 自动修故障而是把指标、日志、链路三类数据沉淀成可计算底座再叠加异常检测、告警收敛、根因定位这条链路把人力从海量噪声里解放出来。百度这类体量的业务AIOps 体系的本质是一次方法论升级——从人盯静态阈值转向机器算动态基线、人来定策略从单点告警转向拓扑级诊断。它适合已经具备基础监控、告警量开始失控、想把运维从被动响应推向主动预防的团队如果连指标都还没采全先补数据采集比上算法更划算。2. AIOps 数据底座指标、日志、链路三源采集与统一建模2.1 为什么百度级 AIOps 先补数据而不是先上算法很多团队做 AIOps 的第一反应是找个异常检测算法接进去结果模型跑出来的告警比原来的还吵。原因不在算法而在数据指标采样粒度不齐、日志字段没归一、链路没有统一 trace id模型拿到的是一堆无法对齐的碎片。百度这类体量下常见做法是先做三件事——统一采集口径、统一标签体系、统一时间对齐再去谈检测与定位。数据底座的三个数据源各有取舍指标适合做趋势与基线日志适合做事件与上下文链路适合做因果与依赖。三者缺一根因定位就会退化成猜。2.2 指标采集从本地存储到远程写入与降采样指标是 AIOps 里最规整的一类数据也是最容易被低估的。常见做法是用 Prometheus 做采集与短期存储通过 remote write 把数据投到长期时序库如 Victoriametrics、Thanos 之类的常见方案再做分层降采样。原始 15 秒精度保留 15 天1 分钟精度保留 90 天5 分钟精度保留一年这样既能支撑实时基线也能支撑季度趋势回溯。# prometheus remote_write 配置示例 remote_write: - url: http://tsdb-gateway:8480/api/v1/write # 长期时序库写入端点 queue_config: max_samples_per_send: 10000 # 单批样本上限过大易触发超时 capacity: 25000 # 队列容量按写入抖动调整 max_shards: 200 # 分片数写入瓶颈时优先调这个 write_relabel_configs: - source_labels: [__name__] regex: go_.*|process_.* # 剔除无业务意义的运行时指标 action: drop逻辑说明remote_write是 Prometheus 把本地样本转发到远端存储的标准通道queue_config控制发送吞吐写入抖动大的环境下max_shards通常比capacity更能解决堆积。参数说明max_samples_per_send与网络 RTT 相关内网通常 5000~10000write_relabel_configs用来在写入前做标签裁剪减少存储成本。降采样在远端存储侧做Prometheus 本身不负责长期降采样。注意remote write 不是越多越好写放大是小集群常见的隐性成本先算清楚每天新增样本数再决定保留策略。2.3 日志结构化从正则到模板提取日志比指标脏得多。同一个错误在不同版本里可能写成connect timeout、connection timed out、conn timeout直接喂给模型只会得到噪声。常见做法是先做模板提取——把变量部分IP、数字、UUID替换成占位符得到稳定的日志模板再做聚合与频次统计。import re # 常见变量的占位符规则按业务补充 PATTERNS [ (re.compile(r\b\d{1,3}(\.\d{1,3}){3}\b), IP), # IPv4 (re.compile(r[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}), UUID), (re.compile(r\b\d\b), NUM), # 纯数字 ] def to_template(line: str) - str: for pat, ph in PATTERNS: line pat.sub(ph, line) return line.strip() # 示例 print(to_template(2024-05-11 connect timeout to 10.2.3.4 after 3000ms)) # 输出: connect timeout to IP after NUMms逻辑说明先替换粒度细的模式IP、UUID再替换通用数字顺序反了会把 IP 里的数字先吃掉。参数说明PATTERNS需要按业务定制日志里高频出现的业务 ID订单号、请求号应加入占位符否则模板会无限膨胀。模板化之后同一模板的频次突增就是天然的告警信号比逐条匹配关键词稳得多。2.4 三类数据的统一标签与时间对齐三源数据能联动的前提是标签一致。百度这类业务里常见的做法是强制三套约定service服务名、cluster集群、env环境作为公共标签trace id 在日志里作为字段保留指标里作为 exemplar 关联。时间对齐上指标通常 15 秒一个点日志是事件时间链路是请求级做相关性分析前需要统一到同一时间窗常见 1 分钟。数据类型采集方式公共标签时间粒度主要用途指标Prometheus / remote writeservice, cluster, env15s ~ 5min趋势、基线、异常检测日志Filebeat / 采集 Agentservice, cluster, env事件级上下文、模板频次链路OpenTelemetry SDKservice, cluster, env请求级依赖、因果、耗时分布注意标签基数cardinality是时序库的隐形杀手user_id、request_id这类高基数标签不要进指标放进日志或链路更合适。3. 告警收敛与异常检测动态基线替代静态阈值3.1 静态阈值为什么在规模化场景必然失效静态阈值的问题不是配得不准而是跟不上变化。业务有早晚高峰、有大促、有版本发布CPU 80% 在凌晨可能是异常在午间可能正常。运维工程师最常见的工作量不是处理故障而是反复调整阈值并处理误报。AIOps 里异常检测的第一步就是把阈值换成基线用历史同期数据算出这条曲线在该时刻应该是什么样再把实际值与之比较。3.2 EWMA 与分位数两种可落地的动态基线动态基线不需要一上来就上深度学习。常见做法是先上 EWMA指数加权移动平均加标准差做残差判定再叠加同周期例如过去 7 天同一时刻分位数做二次校验。这两种方法实现简单、可解释、便于排错适合作为基线系统的第一版。import numpy as np def ewma_baseline(series, alpha0.3, k3.0): series: 历史指标序列按时间排序 返回: (基线, 上界, 下界) baseline [series[0]] for x in series[1:]: baseline.append(alpha * x (1 - alpha) * baseline[-1]) baseline np.array(baseline) residual series - baseline sigma residual.std() return baseline, baseline k * sigma, baseline - k * sigma # 判定实际值超出上下界即为异常逻辑说明EWMA 对新数据加权能快速跟随业务变化同时避免单点毛刺污染基线残差标准差给出动态带宽。参数说明alpha越大越灵敏常见 0.2~0.4k是灵敏度倍数3.0 偏保守2.0 偏激进需要按误报率调。分位数方法则取过去 7 天同一时刻的 P50 与 P99把 P99 作为上界适合有明显日周期的业务。方法灵敏度抗噪适用场景EWMA k·sigma中强无强周期、波动平缓的指标同周期分位数中强有明显日/周周期的业务指标固定阈值低弱容量类硬上限如磁盘剩余3.3 告警收敛时间窗聚类与拓扑去重基线解决该不该报收敛解决报多少条。一次数据库抖动可能同时触发几十个下游服务的延迟告警人工看到的是几十条根因只有一条。常见做法是两步一是时间窗聚类把同窗口内同一service的告警合并二是拓扑去重按调用关系保留最上游或最下游的告警作为代表。-- 按分钟窗口聚合告警统计每个服务在窗口内的告警数 SELECT service, date_trunc(minute, alert_time) AS win, count(*) AS alert_cnt, min(alert_time) AS first_seen FROM alerts WHERE alert_time now() - interval 10 minutes GROUP BY service, win HAVING count(*) 1 ORDER BY win DESC, alert_cnt DESC;逻辑说明date_trunc把告警落到分钟窗count得到窗口内密度高密度服务优先展示结合拓扑表再判定该服务是否为上游是则保留、否则折叠进关联告警。参数说明窗口大小按业务容忍度定秒级抖动用 1 分钟窗慢故障用 5 分钟窗更好。注意收敛规则不要做成永久压制要带自动过期时间否则关键告警会被历史规则吃掉。4. 根因定位拓扑建模、相关性分析与大模型诊断链路4.1 服务拓扑与依赖图谱构建根因定位的骨架是拓扑。百度这类体量下拓扑来源一般有三处链路数据里的调用关系、注册中心里的服务发现、配置里的依赖声明。三者交叉校验能避免单源错误。常见做法是把拓扑建成有向图节点是服务或实例边是调用关系边上挂 QPS、延迟、错误率作为权重。故障发生时从告警节点沿边向上游回溯缩小候选范围。4.2 时序相关性用皮尔逊与滞后互相关筛候选根因拓扑给出可能相关相关性分析给出哪个更相关。常见做法是对告警服务的上游逐个做时序相关性计算并考虑滞后下游延迟通常滞后于上游异常用滞后互相关找最大相关点。import numpy as np from scipy.signal import correlate def lead_lag_corr(a, b, max_lag5): a: 上游服务指标序列 b: 下游服务指标序列 max_lag: 最大滞后点数 返回: (最佳滞后, 相关系数) a (a - a.mean()) / (a.std() 1e-9) b (b - b.mean()) / (b.std() 1e-9) best_lag, best_corr 0, -1 for lag in range(0, max_lag 1): c np.corrcoef(a[:len(a)-lag], b[lag:])[0, 1] if c best_corr: best_lag, best_corr lag, c return best_lag, best_corr # 上游异常领先下游 lag 个采样点则上游是根因的可能性更高逻辑说明先做标准化消除量纲差异再滑动比较不同滞后下的相关系数取最大者。参数说明max_lag按采样粒度设1 分钟粒度下 5 表示最多考虑 5 分钟传播延迟。相关系数只是排序依据不能单独定根因需要结合拓扑方向一起看。4.3 大模型接入诊断链路AI Agent 与提示词设计AI 大模型在 AIOps 里最实用的位置不是替代检测算法而是做诊断链路中的信息归并与解释。百度这类场景常见做法是把拓扑、相关告警、日志模板、近期变更记录打包成上下文交给 AI Agent智能体生成诊断建议。提示词要让模型只看证据、只给候选、不给绝对结论避免模型编造。PROMPT_TEMPLATE 你是运维诊断助手。以下是一次告警的上下文 - 触发服务{service} - 时间窗{window} - 关联告警拓扑上游到下游{alerts} - 相关日志模板及频次{log_templates} - 近期变更{changes} 请只根据以上信息 1. 列出最多 3 个候选根因按可能性排序 2. 每条给出判断依据引用了哪条证据 3. 不要编造未提供的组件名或时间。 # 调用大模型接口时传入格式化后的上下文即可逻辑说明把模型约束在证据驱动框架内可显著降低幻觉把拓扑方向作为上下文的一部分模型给出的候选顺序会更贴近真实根因。参数说明changes字段是排查里最容易被忽略的一环多数线上故障由变更引入把它塞进上下文能大幅提升命中率。环节传统方式引入 AI Agent 后告警归并规则去重语义归并同一故障不同措辞可合并根因候选人工排查拓扑自动排序候选并给出依据变更关联人工翻发布记录上下文自动注入直接给出关联变更注意大模型输出只能作为候选列表不能直接触发自动变更自动执行必须经过规则校验与灰度。5. 百度级 AIOps 落地的工程技巧灰度、降级与效果量化5.1 新检测规则先影子运行再上线AIOps 里最贵的错误不是漏报而是新规则上线后误报把值班人员淹没导致团队对整套系统失去信任。我一般的做法是新基线规则先只记录不告警跑一到两周统计误报率与漏报率达标后再切到真实告警通道。切换时也只覆盖单个服务或单个集群用一张表跟踪每个服务当前所处的阶段。阶段是否告警观察指标放量条件影子否误报率、覆盖服务数误报率 5%灰度是值班反馈、收敛比值班投诉下降全量是平均修复时长稳定 2 周5.2 降级路径必须比检测路径先设计任何检测链路都会遇到数据延迟、模型超时、时序库抖动。常见做法是给 AIOps 系统设计三级降级一级用基线检测二级回落到静态阈值三级只保留原始告警展示。降级要自动化触发不能靠人工判断否则故障期间没人有空切。检测超时阈值通常设成采样周期的 2~3 倍超过就降级。5.3 用信号比而不是准确率衡量效果单看准确率容易自欺欺人因为故障样本本身稀疏。我一般会盯三个数信号比收敛后告警数 / 原始告警数、根因命中率Top3 候选中含真实根因的比例、平均定位时长从首条告警到确认根因的分钟数。信号比能直接反映运维体感命中率反映诊断链路质量定位时长是最终业务价值。三个指标一起看才能判断这套 AIOps 体系是不是真的在帮忙而不是换个方式制造噪声。持续优化时优先调信号比别一上来就追准召误报降下来之后再压漏报节奏更稳。本文还有配套的精品资源点击获取