本文来自微信公众号“twt企业IT社区（talkwithtrend.com）”，【作者】某证券行业用户。
导读
信创环境与传统环境并行期间，AIOps平台如何做到统一告警、统一视图、统一排障入口而不增加运维团队双倍负担？双栈监控采集Agent是否需要两套？告警规则和AI模型是否需要分别训练和调优？双栈并行期额外存储与计算成本如何控制？
·来自企业IT应用趋势项目创新联盟·“证券AIOps智能运维与故障自愈系统”项目
信创和传统环境双栈并行，是咱们券商现在普遍踩坑的阶段，最核心的矛盾不是简单搭两套监控，而是不能把运维拆成两套独立工作流，不然人、规则、算力全部翻倍，运维直接扛不住。先说统一告警、统一视图、统一排障入口这件事，我的实操思路不是把两套环境硬拉成完全一致的底层采集，而是在AIOps平台层做聚合收敛，采集层可以分开，但上层的告警、工单、拓扑、排障界面只给运维一套。
简单讲，底层可以有两套采集Agent，但平台中台层只保留一个统一入口。视图不是两套页面切换，是在同一个大屏、同一个工单里做标签隔离，用环境标签区分信创栈和X86传统栈。告警进来之后，先在平台做归一化：把两边不同格式的指标、事件、日志，清洗成一套标准字段，再进入告警降噪、去重、抑制。运维人员日常排障，不用切两套系统，点开告警就能看到归属环境，同一业务链路里信创节点和传统节点的拓扑是画在一张图上的，故障根因检索也在同一个入口。这样做的目的就是运维人的操作习惯不变，工作流不变，不会被迫维护两套工作台，从根源减少双倍负担。当然这里有个前提，要提前梳理业务链路，很多券商一开始只分别监控两边，业务链路被切成两段，排查跨栈故障特别痛苦，这点一定要提前做链路贯通。
再说说Agent要不要两套这个问题。从实际落地看，绝大多数场景需要两套采集Agent，不要强行用同一个Agent去兼容双栈。传统X86的采集组件跑了很多年，适配成熟；信创服务器芯片、操作系统、中间件版本不一样，内核接口、命令、日志输出都有差异，老Agent装上去经常丢指标、采集不稳定，甚至有兼容性风险。但两套Agent不等于两套运维管理，Agent的版本管理、下发、启停、配置管理，全部交给AIOps平台统一管控。运维不用分别登录两套平台去部署Agent，在一个控制台里，选择目标环境，推送对应版本的采集包就行。采集上来的数据打上环境标签，送入同一个数据管道，底层采集分开，管理入口合并，这是平衡稳定性和运维工作量的办法。
然后是告警规则和AI模型这块，很多团队直接做两套规则、两套模型，最后维护成本爆炸，这是最常见的误区。告警规则可以拆成公共通用规则+环境特有规则。像业务响应超时、端口存活、磁盘使用率这类通用指标，只写一套规则，通过标签过滤，同时作用在双栈数据上；只有信创专属的OS内核指标、国产中间件特有监控项，单独新增少量特有规则，不用把所有规则复制一份。
AI根因分析、异常检测模型思路类似，不用完全分开训练两套模型。基础的时序异常检测、告警聚类模型，底层算法逻辑不变，训练数据集同时包含传统环境和信创环境样本，模型学习的时候自动识别不同栈的指标基线差异。只需要针对信创特有组件单独补充样本微调，而不是从零重新训练。举个例子，传统数据库和国产数据库的慢查询特征不一样，不用训练两个根因大模型，只需要扩充知识库，补充国产中间件、操作系统的故障案例，让模型能识别信创栈特有的故障特征。如果直接两套独立模型，后续调优、版本迭代、案例维护都是双倍工作量，运维和算法团队根本吃不消。
最后聊双栈带来的存储和计算成本控制，这块是业务上线后持续烧资源的地方，要从采集源头、数据流转、分层存储三个地方控，不能等数据入库了再想办法。第一，采集侧做按需采集，信创节点不要全量采集所有指标，梳理核心业务链路，非核心指标降低采集频率，日志做前置过滤，把无用日志直接丢弃，不要全部传到平台。第二，数据接入之后做分级处理，原始细粒度指标短期保留，聚合后的统计指标长期存储，冷热数据分离，冷数据归档到低成本存储。第三，计算侧做资源复用，告警计算、AI推理任务是一套算力集群服务双栈数据，不单独搭一套计算集群。另外还要做标签化的资源配额管理，给信创栈单独设指标、日志的容量上限，定期做资源审计，及时下线已经迁移完成的传统环境采集任务。
整体总结下来，双栈并行的AIOps建设，核心思路一句话：采集层按需分离，平台层统一收口；规则模型复用为主、少量差异化补充；资源从源头限流，避免全盘复制一套系统。目标不是消除底层环境差异，而是把差异屏蔽在平台底层，运维人员面对的始终是一套工作台，才不会出现双倍运维负担。
