简介这份PDF资料围绕人工智能在运维中的实践展开面向金融行业运维工程师、SRE、监控平台建设者以及希望从传统运维、自动化运维向AIOps转型的技术管理者帮助梳理运维演进的阶段性痛点与智能化落地路径。全包共1个PDF文件约4.5MB为IBM云专业服务团队出品的演讲/白皮书式文档含清晰的架构图与场景示意。内容从纯人力运维、自动化运维、脚本化运维讲到智能化运维AIOps阐释ITOA与AIOps的定义与区别并展开智能运维设计思维工作坊中的告警过多、误报频发、基线效果欠佳、阈值配置繁琐、新型数据库与新指标支持不足等痛点。价值在于给出统一AI平台的赋能思路以及智能监控的TPRA框架趋势、预警、抢救、复盘与指标监控、SQL监控两个生产案例的具体做法与效果数据还涉及IBM Cloud Pak for Data等平台能力的介绍。目前已有1033人学习下载适合用来对齐概念、搭建方案框架与准备内部汇报。1. 从一张值班表说起人工智能在运维最先要解决的是什么一个监控范围刚过三千台的运维团队最先出问题的往往不是系统而是值班表。人工智能在运维里真正被提上日程多半不是因为想用算法做点新鲜事而是传统阈值告警在指标数量翻倍之后开始同时失控误报多到没人愿意看漏报又总在凌晨出现值班员凭经验判断的经验值又没法传承给下一班人。这套方案要解决的就是这件事——把监控从「配阈值、等告警、人肉判断」改成「模型给基线、链路给证据、人只做决策」。它适合手里攥着几千个实例、几十类指标、正在被告警淹没的运维团队也适合需要交一份完整智能运维设计的同学直接对照着搭结构、补模块、写验收。2. 需求盘点与技术选型从纯人力到 AIOps 的四级演进2.1 四级演进把现状先摆到台面上做智能运维最怕上来就谈算法。我一般的做法是先让团队把自己的现状对号入座看清楚现在站在哪一级再谈往上走一步需要补什么。运维能力的演进大致分四级每一级都有自己的瓶颈而瓶颈恰恰就是下一级的立项理由。第一级是纯人力运维。特征是平台能力弱、运维局部化、粗放且碎片化重复性劳动占比极高一个故障从发现到定位全靠人盯屏幕。这一级的团队通常不缺责任心缺的是可复用的手段。第二级是自动化运维。成熟运维系统上线流程标准化、技术规范化、管理智能化、业务可视化四件事同时推进值班从「救火」变成「按流程处置」。但这一级的天花板很快出现运维数据没有被有效利用大规模数据的配置成本高得离谱配一套规则要动几十个人。第三级是脚本化运维。基础能力脚本化之后重复劳动明显下降个别场景初步实现自动化。问题在于业务感知程度低、缺乏平台支撑脚本散落在各人手上谁写的谁维护人一走脚本就成了黑匣子。第四级才是智能化运维。流程智能化基本不需要人工预设决策数据驱动机器学习算法真正参与判断工具组件化、模块化、体系化数据库、应用、系统、网络全面覆盖多源异构数据能高效集成支撑大规模智能决策。阶段典型能力主要瓶颈往上走的抓手纯人力人工巡检、人工判断重复劳动多、经验不可复制流程标准化自动化成熟运维系统、流程闭环数据未利用、配置成本高数据采集与治理脚本化基础能力脚本化、局部自动业务感知弱、无平台统一平台与模型化智能化数据驱动、模型决策模型可信度与运营模型运营与反馈闭环这张表的价值不在分类而在于让评审方看清楚从第二级往第三级走是工程问题从第三级往第四级走是数据加模型问题两者的投入结构完全不同。很多方案在答辩时被问「你这算不算 AIOps」本质就是没把这条线划清楚。2.2 工作坊式盘点把「告警太多」翻译成可建模的问题痛点人人会说能翻译成模型问题的没几个。我习惯用一场半天的设计思维工作坊把这件事做完墙上贴现状场景图左边写 Doing现在实际在做什么右边写 Thinking做的时候在想什么中间标出 Steps流程节点然后沿着流程一个节点一个节点地问「这里卡在哪」。一场典型的工作坊会问出这样几个问题单指标场景下标准差到底设多少比较合适值班和开发的意见总是不一致谁说了算阈值配完上线试运行反馈回来又要改整改和正式投产之间没有闭环。这些问题听起来零散归并之后其实只有五类而每一类都能直接对应到一个建模任务。第一类是告警过多、无法及时处理且误报较多对应的是异常检测里的误报抑制问题可以用多模型投票加序列决策来解决。第二类是基线效果欠佳对应自适应基线建模核心是让模型自己跟着周期走而不是人每周手动调。第三类是算力耗费大对应模型粒度和部署粒度的取舍不是模型越细越好。第四类是阈值配置麻烦、调整频繁对应阈值自动生成把「配参数」变成「训模型」。第五类是健康大表无法覆盖所有指标、对新型数据库和新指标支持不足对应特征体系与冷启动策略。还有一个不算模型问题但必须一起解决的各平台系统各自为战没有统一有效的监控方式这是平台问题靠加模型解决不了。工作坊的产出物不是 PPT而是一张「痛点—场景—模型—验收口径」四列对照表。凡是填不满四列的痛点先不做。这条规矩帮我们省掉了很多事后返工的麻烦。2.3 平台选型为什么不能各团队各自造轮子痛点清单出来之后通常会面临三条路各团队自建、买一套商业套件、或者建一个统一的 AI 平台。前两条路在小规模下都走得通但在监控范围上千之后基本都会翻车。各自为战的直接后果是经验因人而异、配置成本高昂、重复工具开发、应用复杂度高。A 团队用孤立森林B 团队用 3-sigmaC 团队自己写了个滑动窗口三套结果对不上故障复盘时连「到底哪个准」都说不清。商业套件的问题在另一头模型是黑盒出了偏差改不动新型数据库和新指标接不进去只能等厂商排期。统一 AI 平台的思路是只做三件事但这三件必须做扎实。一是统一的监控数据摄取和治理机制采集、清洗、血缘、资产目录走同一条链路数据工程师只需要为 AI 组织一次数据。二是流水线式的模型开发和协同环境数据科学家在同一个工作台里建模、版本化、发布不用来回导数据。三是集中式的模型性能管理模型上线之后准确率漂移、公平性、可解释性都有地方看。这三件事合起来既提升了 AI 交付速度又把运维成本压了下来。选型时我会盯五个点能不能多云部署、模型能不能跨框架运行、有没有独立的模型运营组件、数据治理是不是平台内生而不是外挂、以及最关键的——新指标接入要不要写代码。最后一个点决定这套平台三年后还在不在用。3. 总体架构设计四层结构与两条数据流的职责划分3.1 四层职责划分整套架构我按四层来切每层只回答一个问题层与层之间靠标准接口衔接任何一层换实现都不影响其他层。第一层是数据摄取与治理层。负责从数据库、应用、系统、网络四类监控源采集指标、日志、调用链和 SQL 执行记录做概要分析、数据质量校验和血缘追踪最终形成可检索的资产目录。这一层的产出不是原始数据而是「可信、可查、可追溯」的建模数据集。很多项目在这里偷懒直接拿原始表喂模型后面模型效果不稳定八成原因在这。第二层是模型开发层。数据科学家在这一层做特征工程、算法选型、离线评估和模型版本管理。它需要支持主流的机器学习框架和可视化建模工具允许不同背景的人用不同方式产出模型——有人写 Python有人拖拽组件最终都要落到同一个模型仓库里。第三层是模型运行层。负责模型部署、版本灰度、实时推理和批量打分。这一层的关键指标是延迟和吞吐不是准确率。指标监控要求从采集到告警的端到端延迟控制在秒级所以推理服务的攒批窗口、副本数、模型分组方式都要在这里定。第四层是模型运营层。负责上线后的自动异常和漂移检测、业务指标关联、公平性与可解释性分析、以及根据输入持续演进的精确度验证与反馈。这一层最容易被砍掉也最容易被事后追责——模型不准的时候没有这一层就查不出是数据变了还是模型老了。四层的职责边界可以用一句话概括第一层保证数据对第二层保证模型能建出来第三层保证模型跑得动第四层保证模型一直对。3.2 两条数据流训练流与推理流架构图上看是四层跑起来其实是两条流很多人画图时把这两条混在一起实施阶段就会乱。训练流是低频的历史监控数据 → 治理层做质量校验和特征化 → 开发层按「实例 × 指标 × 粒度」切片训练 → 评估通过后进模型仓库 → 由运行层发布成推理服务。这条流的周期通常是天级或周级重的是数据量和特征质量。推理流是高频的实时采集 → 特征计算 → 推理服务打分 → 序列决策 → 告警或静默 → 结果回写到运营层做反馈。这条流的周期是秒级到分钟级重的是延迟和稳定性。两条流共用同一套特征定义这是架构上必须强制的约束。如果训练时用的窗口是 5 分钟均值、推理时算的是 1 分钟瞬时值模型在离线指标上再漂亮上线也会掉点。我一般会把特征定义做成配置中心里的一份声明训练和推理都从这里读改一处两边同时生效避免这种血泪教训。还有一条隐性的流反馈流。运营层把「告警被确认为误报」「告警被确认为真实故障」「告警被静默后仍然出了事故」三类结果回灌到训练流作为下一轮模型迭代的样本。没有这条流模型就是一次性的上线三个月后必然失准。3.3 与传统阈值平台的边界谁留下谁替换做智能运维最忌讳「一刀切替换」。阈值平台不是垃圾它在确定性场景下依然是最高效的工具比如磁盘使用率超过 90%、证书剩余有效期少于 7 天这类有明确物理含义的指标用规则比用模型靠谱得多。我的划分原则是按「是否有确定因果」来切。有确定因果、阈值有明确业务含义的保留规则告警没有确定因果、数值随业务周期大幅波动、人工调阈值调到崩溃的交给模型。前者大概占告警规则的三成后者占七成。边界划清之后两套系统要共用同一个告警出口和同一个事件中心否则值班员要在两个界面之间来回切体验反而更差。这一点在验收时会被重点问新平台上线后值班员是少开了一个系统还是多开了一个。3.4 规模与成本对照规模是这套架构能不能立住的关键变量。监控范围从几十台涨到几千台传统阈值方案的资源投入几乎线性增长因为每加一批实例就要加一批规则、加一批配置人力统一平台方案的边际成本则会随规模摊薄模型一次训练可以服务一批实例推理服务横向扩容即可。我在容量估算时一般按这几个口径来算供参考估算项口径经验做法推理开销单实例单指标每次打分按实际压测取值不按厂商标称值模型数量实例数 × 指标数 × 粒度组合先按核心指标收敛不要全量铺开服务副本峰值 QPS ÷ 单副本吞吐 × 1.5 冗余冗余系数低于 1.3 容易在业务高峰抖动训练窗口历史数据回刷周期天级训练 周级全量重训真正让成本失控的从来不是推理是模型数量。2234 个数据库、8 类核心指标按单指标多模型策略发布出去就是一万八千多个模型如果每个模型单独部署一个服务运维成本会直接压垮项目。所以架构上必须支持模型分组部署一组模型共用一个服务实例这一点在第 4 章讲部署时还会展开。4. 智能监控落地指标与 SQL 两个场景的模型设计4.1 TPRA 框架把监控拆成事后、事中、事前智能监控是整个智能运维里最关键的能力它要同时看两个视角事件视角看单次告警从产生到闭环的全过程整体视角看一类故障在一段时间内的分布。把这两个视角拉平就得到一套四段式的监控框架我把它记成 TPRA。T 是趋势Trend正常状态下的基线走势回答「现在是不是本来就这样」。P 是预测Prediction事前预警回答「接下来会不会出问题」。R 是抢救Rescue事中告警与处置回答「现在出问题了多快能恢复」。A 是复盘Analysis事后分析回答「为什么会出问题、下次怎么提前发现」。四段里最容易被忽略的是 T 和 A。没有 T模型分不清业务高峰和真实异常早上九点的流量爬升会被打成故障没有 A同一类故障会反复发生团队永远在救火。而 P 和 R 是最容易被过度设计的很多方案把精力全砸在预测上结果预测准确率上不去抢救链路也没打通最后两边都不落地。我的实施顺序通常是先补 A有数据可复盘再稳 T基线准了误报才降然后做 R告警链路打通最后才是 P预测需要前面积累的样本。倒过来做大概率翻车。4.2 指标监控单指标多模型与自适应基线指标监控的核心矛盾很朴素一个指标在不同时间段该有的样子不一样用一条固定阈值去卡不是误报就是漏报。解决办法是给每个「实例 × 指标」组合训一组模型让基线自己跟着周期走。单指标多模型的意思是同一个指标同时训练多个粒度和多个周期组合的模型比如 1 分钟粒度看日内周期、5 分钟粒度看周内周期、1 小时粒度看月度趋势运行时由多个模型的打分共同决定要不要告警。这样单点抖动会被短周期模型吸收缓慢劣化会被长周期模型抓到。# 单指标多模型生成每个 (实例, 指标) 组合产出多个候选模型按粒度和周期切片训练 CYCLE {1min: 1440, 5min: 288, 1h: 24} # 一天内的采样点数决定模型粒度 SEASON {day: 7, week: 4} # 周期项日内周期 周内周期 def build_models(series, metric, instance): models [] for gran, points in CYCLE.items(): for season, cycles in SEASON.items(): # 样本不足直接跳过避免欠拟合模型上线后疯狂误报 if len(series) points * cycles * 2: continue m fit_seasonal_baseline(series, periodpoints, cyclescycles) models.append({ key: f{instance}:{metric}:{gran}:{season}, upper: m.mean 3 * m.sigma, # 上基线3 sigma 只是起步值后续由反馈层调整 lower: m.mean - 3 * m.sigma, score: m.residual_score, # 残差评分多模型择优时用它排序 }) return models这段代码里有两个参数值得展开。CYCLE决定模型的时间分辨率粒度越细越能抓瞬时异常但模型数量也随之翻倍SEASON决定模型认不认周期加了周内周期之后周一早高峰和周末凌晨就不会被同一个基线误判。3 * m.sigma中的系数不是拍脑袋定死的它会在反馈流里根据误报和漏报的比例做自适应调整起步用 3 倍标准差只是为了让第一版能跑起来。第二个关键设计是序列决策。单窗口超阈值就告警误报率一定高因为监控数据里天然有毛刺。我的做法是看最近 K 个窗口的累积证据而不是看单点# 序列决策对最近 K 个窗口的异常打分做累积抑制单点抖动造成的误报 def decide(scores, k3, theta0.7): acc 0.0 for s in scores[-k:]: # 只看最近 k 个窗口历史更早的分数不再影响判断 acc 1 if s theta else -1 # 超阈值加分未超减分形成拉锯 return acc k - 1 # 累积证据达标才升级为正式告警k是决策窗口数theta是单窗口异常阈值。把k从 1 调到 3误报会明显下降代价是告警延迟增加两到三个采集周期这个取舍要和值班团队一起定不能由算法侧单方面决定。实测下来在保持同等检出率的前提下这类序列决策能把误报率相对传统阈值平台再压下去约一成这个数字在验收时是最有说服力的一条。4.3 SQL 监控聚类降维、类内倾斜与性能趋势指标监控看的是「数值长什么样」SQL 监控看的是「语句跑得好不好」后者对核心系统的下移改造意义更大因为它能提供 SQL 级别的监控能力而不是只到数据库级别。难点在于 SQL 数量太大。同一条业务逻辑参数不同就是一条新 SQL 文本逐条建模既不可能也没必要。我的做法是先聚类再分析把海量 SQL 压成有限个「类」在类内做倾斜分析和趋势分析。# SQL 聚类把执行记录压成向量再做类内倾斜分析 FEATURES [elapsed_ms, rows_examined, rows_sent, cpu_ms, io_mb, plan_hash] def vectorize(sql_record): # 量纲统一避免 rows_examined 的数量级压过 cpu_ms vec [normalize(sql_record[f]) for f in FEATURES] # 文本相似度分桶替代全量文本向量化成本低且够用 vec.append(edit_distance_bucket(sql_record[sql_text])) return vec特征里放plan_hash是为了让执行计划变化能被聚类感知——同一条 SQL 换了执行计划性能特征会整体漂移如果还归在原来的类里趋势分析就会失真。文本相似度用分桶而不是全量向量化是成本和效果的折中分桶粒度粗一点没关系因为后面还有数值特征兜底。聚类之后做两件事。一是类内数据倾斜分析看同一类 SQL 在不同实例、不同分片上的耗时分布是否严重不均倾斜识别准确率做到 95% 以上基本可以直接指导分片键调整。二是性能趋势分析对每个类的时间序列做上升趋势判断灵敏度要高——性能劣化往往是缓慢爬升等到超过固定阈值时已经影响业务了。这一类趋势判断的误报率可以控制在 0.2% 以下因为它依赖的是类内统计而不是单条 SQL 的抖动。分析之外还要有复盘视角。把 SQL 的性能变化和数据库的变更记录、版本发布记录对齐就能回答「这次劣化是哪次上线带来的」这是纯阈值平台给不出的结论。4.4 部署与横向扩展让一万八千个模型跑得动模型建出来只是开始能不能低成本跑起来才是分水岭。前文提过2234 个数据库、8 类核心指标按单指标多模型策略铺开模型总数会超过一万八千个。如果每个模型一个服务光是服务治理就能把团队拖垮。我的做法是三层收敛。第一层按「指标类型」分组8 类核心指标收敛成 8 个模型组组内模型共享同一个推理进程和同一份特征缓存。第二层按「实例规模」分片把实例按业务域切成若干片每片对应一组推理副本故障隔离在片内。第三层是动态扩缩按峰值 QPS 和延迟预算反推副本数而不是按平均值配。# 实时推理服务模型组独立副本按监控实例规模水平扩展 service: metric-inference replicas: 6 # 起步副本数按 3000 台监控范围压测后调整 batch_window_ms: 200 # 攒批窗口太短吃不满 CPU太长拖慢告警时延 model_group: - name: db-core-8metrics # 8 类核心指标共用一个服务避免每组单独部署 max_latency_ms: 800 # 从采集到告警的端到端延迟预算batch_window_ms是最需要反复调的参数。设成 50 毫秒CPU 利用率上不去副本数得翻倍设成 500 毫秒端到端延迟超标告警就失去了抢救价值。200 毫秒是在延迟预算 800 毫秒的前提下试出来的平衡点不同团队的采集频率不一样这个值必须自己压测。实时计算的运行模式带来的直接好处是异常告警的反应速度更快配合横向扩展监控范围从几百台涨到几千台时架构不需要重做只加副本。5. 避坑与现场排查五类最容易在上线后翻车的问题5.1 告警量降了值班员反而不信了现象新平台上线第一周告警量下降六成但值班员开始在群里手工补告警说「这个肯定有问题模型没报」。原因模型把一批真实故障也一起静默了而静默记录没有对外暴露。值班员看不到「模型认为正常」的依据只能凭经验补补着补着就对平台失去信任。这是最常见的一类翻车技术指标好看用户体验崩了。解决所有被模型判定为正常但分数接近阈值的事件全部落到一张「灰区事件表」里值班界面提供入口可查并且允许值班员一键「升级为告警」升级动作直接进反馈流当训练样本。灰区阈值一般设在正式阈值的三分之二处宁可多存一点数据也不要让模型变成黑匣子。5.2 基线在业务高峰集体失真现象每月初和每次大促指标监控集体误报一天几百条全是同一个模式。原因训练数据里缺少这类高峰样本或者有样本但周期项没覆盖到。基线模型学的是「平常的样子」遇到周期性但低频的高峰就判定为异常。解决两条路一起走。短期靠业务日历把已知的高峰时段作为特征喂进模型让它知道「这个点是允许高的」长期靠反馈流把高峰期间被确认误报的样本单独加权重训。我一般还会加一条兜底规则高峰时段内告警自动降级为静默观察只记录不推送事后统一复盘。5.3 模型数量爆炸算力账单比人力账单还贵现象项目验收时效果不错运行三个月后算力成本超过原来的人力成本财务开始质疑项目价值。原因模型按最小粒度铺开每个实例每个指标每个粒度都单独训练单独部署推理服务利用率长期在 20% 以下。这是典型的「技术上正确、经济上不可行」。解决回到 4.4 的分组部署同时做模型裁剪——同类指标里残差评分最低的那批模型直接下线只保留每类里表现最好的若干个。上线前先算一遍单模型推理开销乘以模型数量把这个数和原有的人力成本摆在一起看账算不过来就先收敛范围别全量铺。5.4 新数据库、新指标接不进来现象平台上线半年业务方新增了一种数据库监控接不进去理由是「模型不支持的指标类型」。原因特征体系是硬编码的模型训练依赖固定的指标清单新增一类指标要改代码、重训、重新发布排期一拖就是两个月。解决把特征定义从代码里抽出来做成配置化的声明新增指标只需要声明它的类型、周期性和量纲平台按类型自动匹配已有的模型模板做冷启动。冷启动阶段的模型用规则兜底积累够样本再切换成学习模型。这一条在做架构设计时就要定事后补代价极大。5.5 离线指标漂亮一上线就掉点现象离线评估准确率 95%上线一周实际检出率不到七成误报倒是一堆。原因训练和推理的特征口径不一致最常见的是时间窗口对齐问题——训练用整点对齐的 5 分钟窗口推理用滑动窗口同一时刻算出来的值不一样。另一个原因是数据延迟推理时读取的指标可能还没落库拿到的是空值或旧值。解决强制训练和推理共用一份特征声明这是架构层面的约束推理侧对空值和延迟数据做显式标记不允许静默填充成 0上线前跑一遍「影子模式」新旧两套逻辑并行输出但不影响生产比对一周再切流量。6. 验收与答辩怎么证明这套 AIOps 真的比阈值强验收这件事最怕拿「模型准确率」一项指标去交差。评审方真正关心的是三件事能力有没有补上、效果有没有量化、成本有没有下降。我一般按三层来组织验收材料。验收层级指标口径参考目标能力层覆盖范围纳入智能监控的实例数与指标类数核心库全量、8 类核心指标能力层场景完整度TPRA 四段是否都打通四段均有可演示链路效果层误报率相对传统阈值平台的变化再降约 10%效果层趋势误报率SQL 性能趋势判断的误报比例0.2% 以下效果层倾斜识别准确率类内倾斜判定与人工核对的一致率95% 以上成本层单位监控成本单实例单指标月均算力开销随规模上升而下降答辩时被追问最多的三个问题答法要提前准备好。第一个是「数据从哪来、质量怎么保证」答案要落到治理层的概要分析、质量校验和血缘追踪说清楚脏数据在进模型之前被拦在哪一层而不是笼统地说做过清洗。第二个是「模型多久更新一次、谁来负责」答案要落到反馈闭环——哪些事件会进样本池、重训周期是多少、模型下线由谁签字。第三个是「模型误判造成业务影响谁担责」这个问题不能躲答案是灰区事件可查、告警可人工升级、静默有兜底规则把决策权始终留在人手里模型只提供证据。还有一个容易被忽略的加分项现场演示。挑一个历史真实故障把当时的指标曲线回放一遍让评审看到模型在第几个采集点报出来、传统阈值在第几个采集点报出来、中间差了多少分钟。这个差距比任何准确率数字都有说服力。从那以后我每次做这类方案验收材料一定在项目开始时就写好初稿而不是等上线后再补——因为验收口径定不下来中间所有的模型设计和部署取舍就没有依据做到一半才发现方向偏了返工的成本是立项时的好几倍。希望帮到你。本文还有配套的精品资源点击获取