企业官网建设流程全解析

简介：面向运维工程师、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~10000；write_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 <NUM>ms

逻辑说明：先替换粒度细的模式（IP、UUID），再替换通用数字，顺序反了会把 IP 里的数字先吃掉。参数说明：PATTERNS需要按业务定制，日志里高频出现的业务 ID（订单号、请求号）应加入占位符，否则模板会无限膨胀。模板化之后，同一模板的频次突增就是天然的告警信号，比逐条匹配关键词稳得多。

2.4 三类数据的统一标签与时间对齐

三源数据能联动的前提是标签一致。百度这类业务里常见的做法是强制三套约定：service（服务名）、cluster（集群）、env（环境）作为公共标签，trace id 在日志里作为字段保留，指标里作为 exemplar 关联。时间对齐上，指标通常 15 秒一个点，日志是事件时间，链路是请求级，做相关性分析前需要统一到同一时间窗（常见 1 分钟）。

注意：标签基数（cardinality）是时序库的隐形杀手，user_id、request_id这类高基数标签不要进指标，放进日志或链路更合适。

3. 告警收敛与异常检测：动态基线替代静态阈值

3.1 静态阈值为什么在规模化场景必然失效

静态阈值的问题不是"配得不准"，而是"跟不上变化"。业务有早晚高峰、有大促、有版本发布，CPU 80% 在凌晨可能是异常，在午间可能正常。运维工程师最常见的工作量不是处理故障，而是反复调整阈值并处理误报。AIOps 里异常检测的第一步就是把"阈值"换成"基线"：用历史同期数据算出这条曲线在该时刻应该是什么样，再把实际值与之比较。

3.2 EWMA 与分位数：两种可落地的动态基线

动态基线不需要一上来就上深度学习。常见做法是先上 EWMA（指数加权移动平均）加标准差做残差判定，再叠加同周期（例如过去 7 天同一时刻）分位数做二次校验。这两种方法实现简单、可解释、便于排错，适合作为基线系统的第一版。

import numpy as np def ewma_baseline(series, alpha=0.3, k=3.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.4；k是灵敏度倍数，3.0 偏保守，2.0 偏激进，需要按误报率调。分位数方法则取过去 7 天同一时刻的 P50 与 P99，把 P99 作为上界，适合有明显日周期的业务。

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_lag=5): """ 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字段是排查里最容易被忽略的一环，多数线上故障由变更引入，把它塞进上下文能大幅提升命中率。

注意：大模型输出只能作为"候选列表"，不能直接触发自动变更，自动执行必须经过规则校验与灰度。

5. 百度级 AIOps 落地的工程技巧：灰度、降级与效果量化

5.1 新检测规则先影子运行再上线

AIOps 里最贵的错误不是漏报，而是新规则上线后误报把值班人员淹没，导致团队对整套系统失去信任。我一般的做法是：新基线规则先只记录不告警，跑一到两周，统计误报率与漏报率，达标后再切到真实告警通道。切换时也只覆盖单个服务或单个集群，用一张表跟踪每个服务当前所处的阶段。

5.2 降级路径必须比检测路径先设计

任何检测链路都会遇到数据延迟、模型超时、时序库抖动。常见做法是给 AIOps 系统设计三级降级：一级用基线检测，二级回落到静态阈值，三级只保留原始告警展示。降级要自动化触发，不能靠人工判断，否则故障期间没人有空切。检测超时阈值通常设成采样周期的 2~3 倍，超过就降级。

5.3 用"信号比"而不是准确率衡量效果

单看准确率容易自欺欺人，因为故障样本本身稀疏。我一般会盯三个数：信号比（收敛后告警数 / 原始告警数）、根因命中率（Top3 候选中含真实根因的比例）、平均定位时长（从首条告警到确认根因的分钟数）。信号比能直接反映运维体感，命中率反映诊断链路质量，定位时长是最终业务价值。三个指标一起看，才能判断这套 AIOps 体系是不是真的在帮忙，而不是换个方式制造噪声。持续优化时优先调信号比，别一上来就追准召，误报降下来之后再压漏报，节奏更稳。

本文还有配套的精品资源，点击获取