简介：《人工智能在运维中的实践》面向金融行业运维人员、IT 架构师及 AIOps 学习者，围绕运维从纯人力、自动化、脚本化迈向智能化的演进，讨论运维数据利用不足、平台能力薄弱、告警误报多等现实问题。内容结合 ITOA 与 AIOps 的概念差异，梳理统一 AI 平台在数据摄取治理、模型开发流水线、模型性能管理中的作用，并通过设计思维工作坊、TPRA 智能监控框架、指标监控与 SQL 监控案例，呈现机器学习在异常预警、告警压缩、趋势判断和数据倾斜识别中的落地方式。资料为 1 个 PDF 文件，压缩包约 4.5MB，适合按章节通读，并可作为方案汇报或项目立项的参考底稿。已有 1033 人学习，可从中了解 IBM Cloud Pak for Data 等平台的能力边界，借鉴 2234 个数据库、8 类核心指标、18000 余个模型等实践数据，形成可复用的智能运维建设框架。

1. 从人力值守到模型值守：一份运维 AI 材料里最扎眼的三个数字

人工智能在运维这个方向上，概念演示多，能拿出生产环境数字的少。这份《人工智能在运维中的实践》里最扎眼的是三个数字：2234 个数据库、18000 多个监控模型、误报率再降 10%。这不是一次 PoC，而是一套已经跑在核心系统旁的监控体系，覆盖 8 类核心指标，按「单指标多模型」的方式铺开。它说明 AIOps 已经从「汇报材料里的智能运维」落到「值班表上的智能运维」——一条告警进来，先判断它的是模型，不是凭手感的老值班员。对一线来说，信号不在于算法多新，而在于规模化建模这条路被验证能走通；对管理者来说，它给出的是一道可以算的账：资源投入和监控范围怎么同步放大，才不会在某一天突然撑不住。

2. 四级台阶：为什么 2018 年被称作金融智能运维元年

材料把运维的演进切成四段：纯人力运维、自动化运维、脚本化运维、智能化运维。这个切法看着像常规的行业综述，但它真正的价值在于标出了每一级「卡在哪」，以及为什么 2018 年会被拿出来单独标注。四级台阶不是四个时代，而是四种并存的状态——一家机构里，核心交易库可能已经跑到第四级，外围系统还在第二级，边缘业务甚至停在第一级。看懂这种并存，才能看懂后面所有落地动作的节奏。

2.1 纯人力、自动化、脚本化、AIOps 之间的能力断层

纯人力运维的画像很清晰：平台能力需求弱、运维局部化、粗放、碎片化、重复性劳动多。这四条不是并列的缺点，而是互为因果——因为没有平台，所以只能局部化；因为局部化，所以只能粗放；因为粗放，重复劳动就必然多。这个循环靠加人解不开，只能靠加系统。

自动化运维阶段解决了前一半：成熟的运维系统、流程标准化、技术规范化、管理智能化、业务可视化。但材料同时点了两条遗留问题——运维数据未得到有效利用，大规模数据的配置成本高昂。这两条恰恰是通往下一级的门槛。系统上线之后，每天产生海量指标、日志、调用链数据，但这些数据在自动化阶段只被用来「触发规则」，没有被用来「形成判断」。

脚本化运维是自动化的一个中间形态：基础能力脚本化，减少了重复劳动，个别场景初步实现了自动化。局限也很直白——业务感知程度低，缺乏平台支持。脚本的本质是把人的操作固化成命令序列，它回答的是「怎么执行」，不回答「该不该执行」。所以脚本越多，维护成本越高，一旦业务形态变了，脚本本身就成了负债。

智能化运维的目标形态是另一套描述：流程智能化，基本无需人工决策与预置；数据驱动，机器学习算法赋能的运维技术；组件化、模块化、体系化的运维工具；数据库、应用、系统、网络全面覆盖的运维场景；高效集成多源异构数据，支撑大规模智能决策。注意这里的关键词是「集成」和「支撑」——AIOps 不是再造一套监控，而是把已经散在各处的监控数据收拢起来，让决策有依据。

这张表的用法不是背下来，而是拿去做自检：一家机构现在真实处在哪一格，卡点是不是表里那一条。很多团队以为自己已经在第三格，实际上是把第二格的系统用脚本包了一层，业务感知依然是零。

2.2 ITOA 与 AIOps 差的不是算法，是「判断权」

材料引用了国际分析机构对 ITOA 的定义：对大量 IT 运维数据进行采集、存储、展现、进行演绎和/或归纳推理的技术或者服务。AIOps 则是 IT 运营分析和管理体系与大数据、人工智能技术结合的产物，以 ITOA/ITOM 系统采集的运维大数据为基础，用机器学习算法做深入分析，覆盖 IT 监控、应用性能管理、外网监控、日志分析、系统安全等方面。

这段定义最容易被读成「AIOps = ITOA + 算法」，但它真正的差异在判断权。ITOA 把数据整理好摆到人面前，人来下结论；AIOps 把结论的一部分先做出来，人来做复核。判断权从人转移到模型，这个动作带来的连锁反应远超技术层面：告警该不该发、发出来谁先看、看了之后信几分、不信的时候怎么反馈——每一条都是组织问题，不是算法问题。材料里工作坊的痛点清单中有一条特别真实：值班与开发意见不一致。这不是沟通问题，是判断权没有归属。

为什么偏偏是 2018 年？从行业角度看，是三条线同时到位：一是监控数据积累到了可用量级，指标、日志、调用链不再是稀缺品；二是算力成本降到了可以常态化跑模型的水平；三是异常检测、序列预测这类算法在工程上成熟到可以封装成组件。三条线交汇之前，做智能运维是玄学，交汇之后，它才变成一个可以排期、可以验收的工程。

这个节点对从业者的影响是技能栈的重排。过去运维工程师的核心竞争力是「知道哪条告警该信」，靠的是血泪经验；之后的核心竞争力变成「知道怎么把这条经验定义成可学习的样本」——会打标签、会做特征、会看模型评估指标、会判断一次误报是模型的问题还是数据的问题。经验没有贬值，但它必须换一种表达方式才能继续起作用。

3. 数字拆解：2234 个库、18000 个模型，成本究竟花在哪

材料给出的指标监控案例里有几组数字值得单独拎出来看：用自适应算法模型配置了 2234 个数据库的 8 类核心指标，依靠单指标多模型策略，发布超过 18000 个模型；应用序列决策算法，把误报率相比传统运维平台进一步降低 10%；借助统一的云原生数据与 AI 平台实现多模型快速部署和计算服务横向扩展；实时计算的运行模式让异常告警反应更快。

按 2234 乘以 8 推算，规模在 1.8 万这个量级，和「超过 18000 个模型」基本对得上——也就是每个「库 × 指标」的组合都有独立模型。这个设计选择值得展开，因为它直接决定了成本结构。

3.1 单指标多模型：为什么不用一个大模型通吃

外行的第一反应通常是：18000 个模型多浪费，训一个大模型全搞定不行吗。答案在数据分布里。同一个指标，在不同类型的库上形态完全不同：交易库的 CPU 曲线是白天双峰、夜间低谷；报表库反过来，凌晨批量跑数时顶到天花板；归档库可能几周都是平的，一动就是异常。如果把这几类库的样本混在一起训一个模型，模型学到的是「平均形态」，对每一类都不准，于是要么漏报，要么天天误报。

单指标多模型的做法是反过来的：先切分，再建模。每个模型只学一种形态，样本纯度高，收敛快，冷启动也容易——新库上线，先跑一段基线期，模型就能自己找到节奏。代价是模型数量爆炸，以及随之而来的三件事：模型要能批量训练、要能批量部署、要能批量监控性能。这三件事没有平台承接，模型数量一上去就是灾难。材料里反复强调「统一 AI 平台赋能智能化运维」，逻辑就在这里：不是先有平台再有模型，而是模型规模逼出了平台。

材料还列了传统竖井式 AI 应用的几条通病：经验因人而异、配置成本高昂、重复工具开发、应用复杂度高。这四条和模型数量爆炸是同一件事的两面。每个团队自己写一套异常检测脚本，短期看很快，长期看你会有 N 套互不兼容的实现，N 套各自的阈值口径，以及一个没人说得清到底哪套准的现状。

3.2 SQL 监控的 0.2%：误报率降到什么程度才敢放手

指标监控回答的是「这台库不对劲」，SQL 监控回答的是「哪条语句在拖、拖在哪个环节」。材料给出的能力清单是：SQL 聚类、聚类后类内数据倾斜分析、SQL 性能趋势分析；对全行所有数据库的 SQL 进行分析监控，为数据库运维提供 SQL 级别的监控能力；性能上升趋势判断十分灵敏，误报率在 0.2% 以下；数据倾斜识别准确率达 95% 以上。

0.2% 这个数字要放到值班场景里才有意义。假设一天产生 1000 条 SQL 相关的告警，其中 2 条是假的——这个量级下，值班的人还会认真看每一条。如果误报率是 5%，一天 50 条假告警，一周之后所有人都会形成「先扫一眼，看着不像就划掉」的习惯，真正的故障就藏在那一眼里。告警疲劳不是态度问题，是比例问题。误报率降到某个阈值以下，人才会重新信任告警；信任恢复不了，再准的模型也白搭。

95% 的倾斜识别准确率对应的是另一类价值。数据倾斜是那种「不报错、但慢得莫名其妙」的问题，靠人工看执行计划，一天看不了几条；靠规则匹配，写不全也维护不动。模型能把它批量捞出来，等于把一类长期靠运气的排查变成了常规动作。

三层的关系是从「现象」到「原因」再到「影响」。很多团队只做第一层就宣布自己上了 AIOps，结果是告警更准了，但排查时间没缩短，因为从「这台库不对劲」到「这条 SQL 有问题」这一段还是靠人。

4. 四个常见误读：AIOps 落地时最容易被想歪的地方

智能运维这个词被用得太多，以至于它周围的误解比共识还多。下面四条是这类项目里出现频率最高、代价也最大的读偏方式，每一条都值得在立项会上先摊开说清楚。

4.1 误读一：以为 AIOps 就是一套更聪明的告警工具

误判点：把智能运维理解成「在现有监控上加一层算法」，目标是把告警变准。

为什么：因为告警是最痛、最可见的环节，项目立项时最容易从这儿切入，切进去之后就顺着做下去了。但材料里的目标形态写得很清楚——流程智能化、组件化模块化体系化、数据库应用系统网络全面覆盖、高效集成多源异构数据支撑大规模智能决策。这是一套体系，不是一层插件。

怎么看：判断一个项目是不是真 AIOps，看它有没有动数据链路。如果监控数据还是各平台各存各的、口径对不上、标签体系没有，那再准的模型也只能在单点生效。材料里把「统一监控数据摄取和治理机制」放在平台能力的第一条，顺序不是随便排的。

4.2 误读二：以为模型上线那天就是项目交付那天

误判点：模型训练完、准确率达标、上线跑通，项目就算完成了。

为什么：算法项目的验收习惯是看离线指标，而运维场景的价值是在线的、持续的。模型上线只是开始，业务形态在变、库在扩、新指标在加，模型会漂移。材料在平台能力里专门列了自动异常和漂移检测、业务指标联动、精确度验证与反馈，这一整块就是为上线之后准备的。

怎么看：把「模型性能管理」当成和「模型开发」同等重要的模块来立项，配置对应的人力和流程。没有这一块，第一年效果好，第二年就开始有人抱怨「这模型还不如阈值」。

4.3 误读三：以为阈值配置可以被彻底消灭

误判点：上了模型，阈值这套东西就该淘汰了。

为什么：材料里工作坊的痛点清单明确写着「阈值配置麻烦，调整频繁」「标准差多少比较合适」「基线效果欠佳」。这些痛点是真实的，但结论不是取消阈值，而是把阈值从「人工拍脑袋的固定值」换成「模型算出来的动态基线」。

怎么看：阈值不会消失，它只是换了产生方式——从人配变成模型给。所以真正要建设的能力是「基线的可信度评估」：这条基线在业务高峰期还稳不稳，新指标接进来之后多久能收敛出可用基线。材料提到「健康大表无法涵盖所有指标，对新型数据库与新指标支持不足」，说的就是固定口径的天花板。

4.4 误读四：以为准确率越高越划算

误判点：模型指标往死里优化，准确率越高越好。

为什么：运维场景里，漏报和误报的代价不对称，而且随场景变化。核心交易库漏报一次可能是一次事故，误报一百次只是烦；边缘系统反过来，误报太多会把人耗死。单看一个准确率数字，等于把这两种代价混为一谈。

怎么看：按场景定容忍度，而不是按模型定。核心链路宁可误报多一点，保证不漏；外围系统宁可漏一点，保证不吵。材料里指标监控用序列决策算法把误报率再降 10%，SQL 监控把误报压到 0.2% 以下——两个数字不一样，是因为两个场景的代价结构不一样，不是后一个模型更先进。

5. 工作坊那半天：把「告警描述」翻译成「模型输入」为什么这么难

材料里有一段容易被跳过的内容：智能运维设计思维工作坊。步骤是定义监控目标、设置阈值、上线试运行、正式投产上线、反馈修订；讨论的素材是平台参数、生产案例、事件分析、单指标场景、告警描述、应对方式。痛点清单也很具体：告警过多无法及时处理且误报较多、基线效果欠佳、算力耗费大、阈值配置麻烦调整频繁、健康大表对新型数据库与新指标支持不足、各平台系统各自为战、人力成本各自为战。

这段看起来是最不技术的部分，实际上决定了项目能不能落地。

5.1 现状场景图：从监控目标到反馈修订的闭环

工作坊真正产出不是模型，是一张把「谁在什么情况下做什么」写清楚的图。定义监控目标这一步，多数团队会写成「监控数据库 CPU、内存、连接数」，这是指标清单，不是目标。目标应该是「在交易失败率上升之前，提前 10 分钟知道是哪台库、哪个环节」。两者的差别在于后者可以验收，前者不能。

设置阈值这一步，痛点在材料里写得很直白：标准差多少比较合适。这是典型的统计口径问题——用几个标准差做边界，取决于这个指标本身的波动特性，而波动特性又随业务周期变化。所以工作坊里出现「值班与开发意见不一致」几乎是必然的：开发看的是模型输出的分布，值班看的是实际被打断的次数，两边都没错，只是评价维度不同。这张图的价值就是把这两个维度摆到同一张纸上。

上线试运行和反馈修订这两步，是最容易被砍掉的。项目排期紧的时候，试运行会被压缩成「跑两天看看」，反馈修订直接省略。结果就是模型上线即定型，三个月后开始漂移，半年后没人再看它的输出。从行业角度看，这一段被砍掉的项目，失败率远高于模型本身不够准的项目。

5.2 统一平台要解决的三件事：数据摄取、模型流水线、性能管理

材料把平台能力归纳成三条：统一监控数据摄取和治理机制、流水线式模型开发和协同环境、集中式的模型性能管理。三条合起来的效果是既提升 AI 交付速度，又降低运维成本。

第一条解决的是「数据在哪、能不能用」。多源异构数据分散在各监控系统里，标签口径不统一，同一台机器在不同系统里叫不同名字，这种情况下建模的第一步就卡住了。统一摄取和治理不是把数据搬到一处存起来那么简单，是要建立一致的资产目录、数据质量和血缘关系，让「这个指标来自哪、经过哪些加工、影响了哪些模型」能查得到。

第二条解决的是「模型怎么批量做出来」。18000 个模型不可能靠人一个个调，必须有流水线：特征工程、训练、评估、发布、回滚都标准化。协同环境的意思是数据科学家和运维工程师在同一套环境里工作，而不是各自导出数据、各自跑 notebook。

第三条解决的是「模型上线之后谁来管」。集中式的性能管理意味着所有模型的准确率、漂移、业务影响在一个地方可见。没有这一条，模型数量一多就变成黑匣子——你知道它在跑，但不知道它准不准。

下面这段代码是自适应基线的最小实现，用来说明「模型给出的阈值」和「人配的阈值」在逻辑上差在哪：

import numpy as np def adaptive_baseline(series, window=96, k=3.0): """ series: 单指标历史序列，按固定采集间隔排列（如 5 分钟一个点） window: 回看窗口长度，96 个点约等于 8 小时（5 分钟粒度） k: 偏离倍数，越大越保守，误报越少、漏报越多 """ recent = np.asarray(series[-window:], dtype=float) base = np.median(recent) # 中位数做基线，抗尖刺 mad = np.median(np.abs(recent - base)) # 绝对中位差，抗离群点 sigma = 1.4826 * mad # MAD 换算成标准差的稳健估计 return base, base - k * sigma, base + k * sigma # 判定逻辑：最新点越界才告警；连续两个点越界才升级为工单

三个参数各有对应关系。window对应业务周期，配小了基线跟着噪声跑，配大了对突变反应迟钝，一般取一个完整业务周期到一个半周期。k对应误报容忍度，核心链路可以调到 4 以上求稳，外围系统放到 2.5 求灵敏。1.4826是 MAD 到标准差的换算系数，在正态假设下成立，作用是让阈值单位回到大家熟悉的标准差上，方便和旧口径对齐。

用中位数和绝对中位差、不用均值和标准差，原因在告警风暴场景里特别明显：故障发生时指标会突然顶高，均值和标准差都会被这几个异常点拉偏，导致基线自己跟着涨，反而把异常「吃」掉了。稳健统计量对这个不敏感，这是模型基线比人工阈值可靠的技术前提之一。当然，这只是最小实现，真实场景里还要叠加周期分解、多指标联动和冷启动保护，材料里说的「单指标多模型」就是在这一层展开的。

6. 趋势判断：从「事后抢救」走向「事前预测」，运维岗位表会怎么变

材料用了一个四象限框架来描述智能监控：正常趋势、事前预警预测、事中告警抢救、事后分析复盘。四个格子合起来是一件事——监控的时间轴被拉长了。传统运维的重心压在「事中」和「事后」，模型进来之后，重心开始往「事前」移。

这个移动带来的第一个变化是评价指标变了。过去衡量监控好坏看覆盖率、看告警数量；之后要看提前量——平均提前多少分钟发现问题，以及复盘时能不能给出根因假设。提前量这个指标一旦进考核，很多过去「能用」的方案会立刻显出不适应，因为它们的设计目标本来就是「出事了能看见」。

第二个变化是岗位分工的重新切分。值班岗的工作内容会从「判断哪条告警该信」转向「复核模型的判断并给出反馈」，这个转变听着轻，实际要求更高——你得知道模型为什么这么判，才能判断它这次是不是错了。与此同时会新增一类角色：既懂运维场景又懂建模边界的人，负责把场景翻译成可学习的问题。这类人在市场上很稀缺，多数团队的做法是从内部培养，让懂运维的人去学建模，而不是反过来。

第三个变化是成本结构。传统监控的成本随节点数线性涨，智能监控的成本里，模型训练和推理占一块，平台占一块，人力占一块，前两块可以随规模摊薄，第三块不行。材料里「资源投入与监控范围」的对照关系说明的就是这件事：规模上去之后，靠加人已经无法维持，只能靠平台。

对从业者来说，接下来两三年最值得投入的不是学某个具体算法，而是三件更基础的事：把所在环境的监控数据口径统一起来，把标签体系建起来，把每一次误报都当成一次可回收的反馈而不是一次抱怨。这三件事做了，模型换哪家都能跑；不做，换什么模型都是原地打转。

材料本身的价值也在这里。它不是一本算法书，而是把一条完整路径摊开给你看：从四级台阶的判断，到 2234 个库的规模账，到工作坊里那些看起来不技术的分歧，再到四象限框架下的能力重排。做方案的人可以拿它对齐内部认知，做执行的人可以拿它对照自己卡在第几步。

从那以后，我每接一个监控相关的需求，都会强制先写一句话：这条告警进来之后，谁在几分钟内做什么。写不出来就先不建模——因为那句话写不出来的地方，模型再准也只是把噪声换了个形式发出来而已。希望帮到你。

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