数据库厂商×运维厂商：如何共建可演进的智能运维新范式

1. 运维厂商和数据库厂商联手，为什么开口先谈"可演进"

一家做IT运维平台的老牌厂商，一家做关系型数据库的厂商，坐在一起说要"共筑生态、合作共赢"，还要共建一个新范式。这个组合放在三年前，多半会停在战略签约和几个兼容性认证证书上。北塔软件与瀚高股份这次合作的消息里，最让我愿意多看两眼的，不是签约本身，而是后半句里的"可演进智能运维"。

先别急着把"可演进"当成宣传话术。我这些年接触过不少运维平台项目，一个真实的痛点是：很多系统的建设是按"一锤子买卖"的思路设计的，第一年功能演示很漂亮，第三年就慢慢变成一张没人敢动的旧地图。新设备纳管不进来，新数据库类型不认识，告警规则还是上线时手工配的那几十条，业务都翻了几番，容量模型却还在用老参数。所谓智能运维，最后退化成了监控大屏上永远冒红点、但没人知道从哪查起的一堆告警。

为什么这种问题难解决？因为平台的监控模型、对象模型、接口标准没有跟技术栈同步演进。数据库不是单纯的"一个进程+几个端口"，它有自己的实例结构、会话模型、存储引擎、日志体系、主从复制机制。如果运维平台只把数据库当成"主机上的一个进程"来管理，那它做得再智能，也够不到数据库内部真正的问题。反过来，数据库厂商如果只考虑内核功能，不考虑可观测性接口，运维方拿到再强的算法也没数据可用。

这正是北塔软件与瀚高股份合作的想象空间所在。北塔软件在IT基础设施管理、网络和业务运维领域有很长的产品线积累，擅长把零散的监控数据整理成可用的运维视图；瀚高股份则是国内关系型数据库赛道的核心厂商之一，产品跟PostgreSQL有清晰的技术血缘，在数据库内核、迁移、调优和运行生态上有自己的积累。两家如果只是签个协议，价值不大；但如果能共同定义一套面向数据库对象的监控数据模型，把数据库内部指标、运行日志、元数据、SQL画像持续地开放给上层的智能分析能力，那才叫真正贴近"可演进"。

1.1 "可演进"不只是版本能升级，更是模型能生长

我对"可演进"的理解，可以拆成三层。

第一层是接口能演进。运维平台采集数据库指标，不能靠某一版脚本和固定SQL凑合，必须有一份公开、稳定、可持续升级的指标接口，数据库版本升级后，采集协议不能崩。很多合作做到后面断掉，就是死在这一层：数据库厂商发了一个新版本，运维平台的采集探针不支持，两边都认为是对方的问题。

第二层是数据模型能演进。今天你纳管的是50个数据库实例，明天可能是500个，后天可能是分布在多个机房、多个云环境的混合部署。如果CMDB里的关系模型是写死的，新增一种部署形态就要改一遍数据库表，那这套系统天然不具备演进性。可演进的平台必须把设备、实例、服务、业务、配置项之间的一切关系都对象化、实体化，新增对象类型时不需要推翻原来的模型。

第三层是知识库能演进。真正的智能运维不是刚开始能自动发现一个大问题，而是系统里沉淀的规则、基线、诊断路径、处置预案能随着数据库版本和业务特征持续调整。瀚高这类数据库在项目里可能有不同版本、不同参数组、不同业务负载，如果知识库不能增量更新，智能就是静态的。

1.2 传统运维系统的"三年魔咒"到底卡在哪

很多人以为运维系统生命周期短是技术不行，我在项目里看到更多的是机制问题。平台建设完毕，运维团队自己也忙，没有人力持续录入新对象；厂商的项目经理撤场后，文档和脚本交接不完整；数据库管理员又不愿意把自己脑子里那些排障经验轻易放到运维平台的规则库里，因为告警规则一旦覆盖不了真实场景，反而会变成"狼来了"。

于是三年后，运维平台成了两层皮。大屏上啥都有，真正出了数据库故障，工程师还是打开自己的命令行手工排查。这不能全怪运维工程师，因为平台连数据库的等待事件都采不回来，又怎么让我信任你的"智能分析"？

这也是为什么我认为，数据库厂商与运维平台厂商的合作，一定要从产品设计阶段就打通"对象模型"，不能停留在"支持纳管"的口号上。拿到一个数据库实例，至少要识别出它是什么版本、什么角色、主从关系怎样、运行了哪些关键业务，再往下还要知道它在干什么——当前活动会话、锁等待、慢SQL、提交回滚比。没有这层深度，所有上层智能都是空转。

2. 数据库场景里的智能运维，"智能"到底指什么

聊到智能运维，很多人第一反应是机器学习、异常检测、根因分析。算法确实重要，但在数据库场景里，算法之前还有一个基础问题：你连数据库里正在发生什么都不知道，算法做什么？

传统通用监控能回答的问题非常有限。它告诉你数据库主机的CPU利用率95%，内存用了90%，磁盘读写很高。但如果数据库响应慢，是因为一条全表扫描SQL把I/O打满了，还是因为锁等待把会话全堵住了，又或者是因为主从复制延迟导致读取走了备库、数据不一致，传统监控基本说不出来。

到了PG技术路线的数据库上，要回答这些问题，必须深入到数据库的统计体系里去。运维平台至少要能读懂这样几类信息：

• pg_stat_database里的提交数、回滚数、缓存命中率，看整个数据库实例的健康度；
• pg_stat_activity里每个会话的当前状态和等待事件，看业务到底卡在哪儿；
• pg_stat_statements里的归一化SQL统计，看哪些SQL模板消耗了绝大多数资源；
• autovacuum相关信息，看垃圾数据膨胀和清理是不是出了问题；
• pg_stat_replication里的主从延迟和复制状态，判断高可用链路的稳定性。

这些指标不是纯粹给DBA看的，它们是智能运维判断问题的依据。比如一个数据库实例的CPU不忙、磁盘不忙，但业务总是偶发超时，如果只做主机监控，这个问题几乎永远发现不了；但如果你能看到会话在锁上等待，等待事件长时间停留在某个锁类型上，基本就能把范围缩小到应用层的事务处理问题。

2.1 我眼中的数据库可观测性：四层信息缺一不可

做数据库运维久了，我习惯把信息分成四层。

第一层是基础指标层。实例存活、连接数、CPU、内存、磁盘空间、复制延迟、TPS/QPS。这些适合做秒级或分钟级采集，用来判断大体状态。

第二层是日志与审计层。错误日志、慢查询日志、审计日志，解决的是"某段时间内到底发生了什么"的问题。日志必须能按时间倒查，必须有统一的解析格式，否则很难做关联分析。

第三层是SQL画像层。按SQL模板粒度聚合的耗时、扫描行数、返回行数、执行次数。通过归一化处理，可以知道一套业务系统里哪些SQL是常态消耗，哪些SQL是突然冒出来的，这个是数据库智能优化和故障预测真正不可替代的底层数据。

第四层是元数据与拓扑层。表结构、索引、主从关系、分区策略，以及数据库实例挂在哪台主机、支撑哪些业务系统。没有这一层，平台连"这个实例变更会导致哪些应用受影响"都判断不了。

如果北塔和瀚高的合作能把这四层数据在模型层面打通，我认为比单纯增加两个采集器有价值得多。因为"智能"不是模型参数有多复杂，而是你在面对问题时，能不能把任意一条线索沿着拓扑、日志、SQL、指标串出一条可以验证的因果链。

2.2 PG血缘给智能运维留下了"抓手"

做智能运维，最怕的是基础软件完全不对外开放运行数据。关系型数据库虽然都会提供性能视图，但不同实现的完整性差异很大。

瀚高这类跟PostgreSQL有血缘关系的数据库，有个天然优势：继承了非常完整的动态性能视图体系。内核把会话、等待事件、表级统计、索引使用情况、复制状态、垃圾元组数量都暴露出来了。这意味着做运维平台时，不是从零开始造数据，而是要考虑怎么把这些开源内核能力组织成面向业务的可观测性视图。

我经常给做监控的同学一个类比：数据库性能视图是诊断仪表盘，智能运维平台是仪表盘上方的自动导航。仪表盘越完整，导航才越有可能给出正确路线。但如果导航和仪表盘是完全两家厂做的，连接线没接好，数据口径对不上，那导航给的路线就是拍脑袋。

两个角色需要形成一种协作关系：数据库厂商把底层观测点做得更完整，运维平台厂商把观测数据翻译成运维动作。这种协作如果没有共同的数据字典和标准接口，每做一个项目都要靠贴脚本去临时对接，那就谈不上"范式"了。

3. 建一套能演进的新范式，应该按什么顺序落地

从口号到可落地，中间隔着大量工程细节。按照我在多个数据库运维项目里的实操经验，一套能演进、能被用户真正信任的运维体系，至少要经过四个阶段，顺序不能乱。

3.1 阶段一：做对象化统一纳管，而不是继续堆"监控菜单"

很多运维平台的采集能力是按厂商和型号做的下拉菜单，新增一种数据库版本，要等平台厂商下次迭代。可演进的做法是：把每个被纳管对象建成"配置项+运行实例+采集任务"的结构化模型。

数据库实例被纳管后，平台应该能自动识别实例类型和版本，自动建立与主机、集群、业务系统的关系。不是让人工在界面上选一个模板，而是对象注册进来后，平台自己能判断应该给这个对象分配哪几类采集任务、哪些默认告警策略。这套逻辑做扎实，后面新增几十个实例时才不会手忙脚乱。

验收标准也很简单：你增加一个数据库实例，从注册入库到看到指标数据，能不能在几分钟内完成，过程中是否需要改代码或手工改数据表。

3.2 阶段二：采集层做能力分层，关键指标必须能追溯

基础监控可以做通用的进程、端口、主机资源采集，但数据库内部指标必须单独设计采集链路。我的建议是至少分三层：

• 高频心跳数据，比如存活状态、复制状态，间隔建议10到30秒；
• 中频性能数据，比如会话数、活跃SQL数、锁等待等，1分钟采集一次，用于告警和趋势；
• 低频画像数据，比如SQL聚合统计、表统计信息，5到10分钟聚合一次即可，不需要实时。

指标采集不是越频繁越好。数据库性能视图本身有开销，尤其pg_stat_statements如果采样粒度过细，在高并发生产库上反而会增加负担。这个度需要跟数据库厂商确认，最好能做不同实例规格下的采集压力测试。

在这个阶段，日志也是大头。数据库错误日志要能被平台解析成结构化事件，慢查询日志要有统一格式。很多智能诊断场景，指标里看不到根因，但日志里的一条错误信息就能直接定位问题。

3.3 阶段三：告警模型要结合上下文，而不是继续搞静态阈值

传统监控喜欢给所有数据库设同一个CPU阈值和连接数阈值，这个做法对数据库来说几乎一定出错。一个跑批系统和一个高并发交易系统，健康基线完全不同。

可演进的告警模型，第一步要按数据库实例的角色和业务负载分组；第二步要为每个分组建立动态基线，通过历史数据学习周期规律；第三步是做告警收敛，把同一拓扑下的关联告警合并成一个"事件"。

例如，主从切换发生时，复制延迟告警、连接数波动告警、应用超时告警往往会同时爆发。如果没有上下文关联，值班工程师会收到几十条消息，但真正的问题只有一个：主库发生了切换。智能运维平台的职责不是增加更多告警，而是把事件解释清楚。

北塔在做上层运维平台，瀚高手里有大量数据库实际运行场景和内核经验，如果双方能在告警上下文里共用一套"数据库事件词典"，就能避免现在常见的告警语焉不详的问题。平台不说"连接数过高"，而说"多个应用会话在等待同一行锁，疑似热点数据更新冲突"，这个信息量对值班人员是完全不同的。

3.4 阶段四：诊断和自愈必须闭环，但要留得住审计记录

再往前一步就是自愈。数据库场景下，能自动做的操作其实不少：连接池耗尽时启动临时扩容、SQL限流、慢查询熔断、日志清理等。但这一步最考厂商的边界感，因为数据库是核心系统，操作错了代价极大。

应该遵循的路径是：先做"辅助诊断"——告诉运维人员问题最可能出在哪，基于什么证据；再做"半自动处置"——系统给出操作建议，一键执行但还是由人来点最终确认；最后在部分充分验证过的场景里跑"受控自愈"——系统自动执行，但每一步都写入审计日志，并且要有回滚预案。

值得注意的是，自愈能力不能单独由运维平台厂商闭门开发，最好能跟数据库厂商对内核行为做联合验证。比如，你怎么判断一个会话是无用的空闲连接还是长事务？杀了会不会导致应用异常？这些判断标准，必须有数据库内核和运维经验的深度参与。这正是"共建"第二层含义：把工程问题拉到一起解决。

4. 联合方案到了真实现场，最容易翻车的是这四关

合作消息让人兴奋，但做过交付的人都明白，联合解决方案从官网宣传到客户机房落地，中间沟壑比一般人想的大得多。我挑几个现场最常见的坑聊聊。

4.1 版本和部署形态远比宣传材料更碎片化

数据库厂商官网往往会列几个主力大版本，但用户的真实环境常年是这样的：核心系统用一个稳定版本，新业务系统用另一个兼容版本，还有几套从其他数据库迁移过来的老业务用了不同的字符集或兼容模式。所有实例看起来都是"瀚高数据库"，内核能力、视图字段、参数名称却不一定完全一样。

运维平台如果只在最早的版本上做过适配认证，后面遇到新版本时，采集SQL很可能直接报错，或者字段含义发生了变化。所以我特别在意合作双方有没有版本矩阵测试机制：数据库厂商发新版本前，运维平台的关键采集器能不能在测试环境里先跑一遍回归。如果不能，那"可演进"就是一句空话。

4.2 监控账号权限到底给多大，两边要有一个统一口径

数据库安全的底线很清晰：监控账号绝不能做成超级管理员。但实际操作里，平台要采集SQL统计和会话视图，需要一定的系统视图权限；要做一些诊断，甚至要能执行explain查看执行计划。权限太小，数据采不全；权限太大，安全审计过不了。

我的建议是，运维平台和数据库厂商应该联合发布一个"最小权限采集规范"，明确哪类监控需求对应哪几个数据库角色和视图权限。像pg_stat_activity一类信息用只读系统视图就能看，SQL统计需要pg_stat_statements的读权限，执行计划分析则要单独解释其行为。把这些权限模型做到产品向导里，交付时才不用每次靠DBA现场手动授权。

4.3 拓扑和CMDB跟不上高可用架构的变化

数据库不是孤立的，它通常跑在主从、集群、共享存储这类高可用架构里。主从切换发生后，VIP会漂移，实例角色会变化。如果运维平台只监控IP地址和端口，那么在切换发生后，平台看到的是"旧主机上的服务失联"，而不是"实例角色已经切换"。

很多告警级联和误报都来自这个信息差。平台知道的是主机A上的数据库停了，但不知道集群已经自动把流量切换到主机B。于是值班人员被叫起来处理一个根本不存在的故障，而真正需要观察的复制延迟和业务恢复情况，平台反而没有提示。

这类问题靠一两次对接解决不了，需要两边的元数据模型深度打通。瀚高如果在产品里能把自己的集群角色切换事件实时发布出来，北塔的CMDB能自动刷新实例归属关系，再配合事件关联，值守体验才会发生质变。

4.4 数据库厂商和运维平台厂商的SLA边界

这个坑是商务层面的，但影响非常大。客户买到的是"北塔+瀚高"的联合方案，出了问题该找谁？

数据库故障常有这样的场景：监控平台报警说复制延迟增加，DBA查了一遍觉得内核配置没有问题，反过来质疑监控指标采得不准；监控厂商说是数据库某个后台进程导致的；数据库厂商说你是采集器干扰了实例。两边如果事前没有定好诊断流程和事件升级机制，最后买单的是客户。

我做项目时最看重两份文档：接口责任矩阵和故障升级路径。哪一层数据由谁负责解释，数据库日志由谁定期分析，发现异常先联系哪一方，双方承诺在多长时间内响应，最好在合作产品落地前就白纸黑字定清楚。否则再好的技术底座，也会在商务撕扯中把客户耐心磨没。

5. 怎么判断这种合作是真的产品融合，还是又一场PPT签约

我参加过不少厂商战略合作的发布会，现场都很热闹，真正让我判断合作成色的，不是台上的口号，而是会后敢不敢回答下面几个尖锐问题。

5.1 有没有带版本号的长期互测矩阵

一个共建的可演进范式，至少要经得起"数据库新发一个大版本，运维平台能承诺多久完成适配"这一问。如果回答是"我们一直在做兼容测试，具体时间看项目需求"，那基本还是没有稳定机制。靠谱的合作会在契约里定义：每次版本更新都会触发联合回归，关键采集SQL、接口、告警模板的兼容性测试会同步进版本发布流程。

5.2 指标字典是统一的还是各说各话

监控一个数据库，可能有一个指标叫"连接数"。看上去简单，但不同人的统计口径根本不一样：是当前活跃连接，还是包括空闲连接？是否包含后台进程？连接池里的连接算不算？如果数据库产品和运维平台的指标字典没有对齐，那么平台展示的每个数字，到DBA手里都可能存在理解偏差。

这个工作不性感，但要花大量时间把每个指标的定义、单位、采集来源、计算方式逐项拉齐。我判断合作产品是不是真的融合，第一条就是看指标字典文档写得细不细。

5.3 有没有真的故障库沉淀和知识回流

智能运维的核心资产不是代码，是知识。一次数据库故障处理结束后，双方有没有机制把根因、现象、处置方案沉淀进运维知识库？有没有用这些历史故障来验证和优化告警模型？

数据库厂商内部通常有大量服务一线的故障案例，运维平台厂商则有大量客户环境的监控数据。如果能把这些案例清洗成结构化的故障场景——比如"高并发更新同一行导致的锁等待阻塞"，然后输入到智能诊断模块——这个系统才会越用越聪明。可演进的价值就体现在这里。

5.4 现场出了疑难杂症，双方能不能开通联合支持通道

再好的监控，也不能替厂商兜底所有内核层的疑难杂症。客户真正需要的，是出问题后，监控平台能快速给出"这事可能出在内核层，建议数据库原厂介入"的判断，并且能把相关性能快照、日志、会话信息自动打包起来，直接传给数据库原厂支持人员。

这一步如果做好了，客户体感是天壤之别。以前是DBA接到报警后手工收集半天材料，再联系原厂，原厂再远程查半天；现在是平台直接生成诊断包，数据库原厂一打开就知道大概发生了什么。所谓生态协同，在这一刻才有真实意义。

我估计很多人会问：那这套合作到底什么时候能全面落地？我的看法是，比起问时间点，不如盯住上面这些机制有没有逐步形成。哪个项目先完成指标字典对齐，哪个项目能实现版本矩阵回归，哪个团队愿意把故障知识库共享出来，这些才是新范式从新闻稿走进生产环境的真实脚印。做运维这一行，被无数华丽的架构图教育过之后，我反而更相信用一张张最小权限授权表、一页页指标定义文档堆出来的合作才走得远。