（来源：twt社区 twt企业IT社区）

 摘要 

我院统一运维监控平台自2021年基于Zabbix部署运行，原底层操作系统CentOS已不满足信创政策要求。2026年6月，我们启动了平台基础架构升级工作，完成信创环境替换，适配国产openEuler操作系统并推行内部组件容器化部署。以全新升级的Zabbix+Grafana为基础，在算力服务器于2026年7月经专线接入医院网络后，一周内快速建成覆盖硬件层与调用层的AI算力精细化监控体系，实现对GPU运行状态与应用Token消耗的统一观测。本次升级同步扩展了全院网络设备配置自动备份、CMDB资产管理系统对接以及互联网云端对本地服务可用性的监控等能力，并在资产—安全策略关联查询方面取得初步成效。本文对升级过程中的架构设计、算力监控建设思路及阶段成效进行梳理总结，为同行在信创升级与AI基础设施运维方向的实践提供参考。

【作者】潍坊市人民医院信息网络管理办公室基础设施组 王培法 魏瑜帅 王士灿

一、引言：从“能用”到“好用”，运维平台的信创拐点

我院信网办基础设施组自2021年起基于Zabbix构建统一运维监控平台，对医院网络、服务器、存储及应用接口进行集中监控管理。笔者曾在文章《三甲医院信息系统运维难题破解：Zabbix + Grafana》中详细介绍过平台初期的架构设计、分布式部署方案以及Grafana可视化落地的关键技术细节。彼时，平台底层的操作系统还是CentOS。

五年过去，运维监控的命题已悄然发生变化。

外部环境上，信创政策从“鼓励试点”走向“刚性要求”。继续使用CentOS意味着安全补丁断供、合规风险累积。对于承载着医院核心业务监控的平台而言，操作系统的安全水位直接关系到整个运维体系的可靠性。与此同时，院内信息系统的信创替代也在分批次推进，运维监控平台作为信息化基础设施的底座，信创升级不再是可选项。

内部需求层面，运维监控平台的角色定位正经历深刻转变，从最初聚焦于故障发现与告警响应，逐步升级为保障业务系统持续可用的核心支撑。与此同时，随着医院AI应用的规模化落地，算力基础设施的可观测性变得至关重要。当前，医院算力资源来源日趋多元：院内本地算力服务器与外部数据中心算力服务器协同运作，由算力管理平台进行统一调度。这一架构在提升资源弹性的同时，也给信网办带来了全新问题，如何精确掌握算力的使用效率、去向分布与服务质量，实现算力资源的全局可视、可管、可控。

我们面临的不是一次简单的版本升级，而是一场运维监控体系从“能用”到“好用”的系统性跃迁。升级的目标是三个：合规，完成信创环境部署替换；扩能，将监控触角延伸至AI算力领域；增效，补齐配置管理、资产管理等运维基础能力的缺口。

二、Zabbix平台信创升级

2.1 openEuler＋容器化

操作系统层面，平台从CentOS整体迁移至国产openEuler系统，完成全栈信创环境部署替换。openEuler作为国产Linux发行版，在服务器场景下的生态成熟度与社区活跃度已具备生产级能力，且在应用源、用户态工具链上与CentOS保持了较好的兼容性，有效降低了运维团队的学习与迁移成本。

数据库层面，针对原数据库因长期运行迭代、缺少分表机制，在数据查询与清理时存在的性能瓶颈，Server端计划更换为PostgreSQL开源数据库，以提升监控平台的数据处理性能；Proxy端则计划采用SQLite，以降低资源占用。

部署模式层面，平台放弃原有的单体式部署，全面推行容器化部署。将Zabbix Server、数据库、Proxy、前端以及后续扩展的网络设备备份模块等各组件以容器形式独立运行，实现组件间解耦。改造后，新功能的部署简化为“拉取镜像、启动容器”的标准化流程，多个组件在同一虚拟机环境内以容器隔离运行，有效避免了软件冲突。

容器化带来的不仅是部署效率的提升，更重要的是一种架构理念的转变，将运维监控平台从“一块铁板”重塑为“一套积木”。运维与监控功能的扩展不再受限于一个虚拟机环境，不同运维能力模块可独立迭代、互不干扰，为后续快速接入算力服务器监控、扩展网络设备配置备份等能力打下了坚实的架构基础。

2.2 版本升级期间的业务连续性保障

对于医院而言，监控平台的运行与其他信息系统都有一个相同的前提：医院诊疗业务的连续性。HIS的告警通道哪怕缺失几分钟，都可能意味着一次故障的发现延迟，其代价不可承受。

为此，我们制定了“新旧并行、逐项验证、一次性切换”的切换策略。旧系统环境持续运行，直至新系统各项指标验证通过。验证覆盖三个维度：一是监控数据采集的完整性，逐一核对新旧系统采集到的同一设备指标值是否一致；二是告警通道的可用性，分别在两套系统中触发测试告警，确认微信、钉钉、电话等通道均正常送达；三是Grafana可视化看板的渲染效果，确保所有仪表盘在新版环境中正常加载数据展示。

在具体执行上，6月初启动升级计划，新环境与旧环境并行运行两周。期间通过调整Proxy监控策略，使新旧两套系统的Proxy同时执行监控任务，克隆定制的脚本监控与监控项，逐项比对数据采集的完整性与告警通道的可用性。经过两周并行验证，确认数据采集完整、告警通道正常后，于6月30日晚间低峰时段执行IP地址切换与旧环境下线，将旧的Proxy关停，Server保留一段时间以提供历史数据查询能力。

截至目前，新系统已稳定运行超过一个月。Zabbix统一运维监控平台在线监控对象已达1923台，自定义业务监控达到500余条，覆盖服务器、网络设备、存储设备、线路状态、应用服务等IT资产，监控覆盖面与系统稳定性在升级后得到充分验证。

1：Zabbix新版仪表盘，服务台监控大屏

三、AI算力精细化监控建设

如果说信创升级是“基础设施层面的合规补课”，那算力监控建设就是这次升级中最具创新性的增量价值。这件事的背景是：新增算力服务器于7月22日经专线接入医院网络，如何获取它们的运行状态和资源利用效率是我们基础设施组需要解决的问题。

我们要回答三个问题：算力用了多少，被谁用了，用得好不好？

3.1 设计思路：两层分治，从硬件到业务

基础设施组基于Zabbix平台，在一周内完成了算力服务器的专项监控开发。在设计算力监控体系时，我们没有试图用一个监控模板覆盖所有需求，而是采取了层次分离的思路：硬件GPU监控做“有没有问题”的健康检查，上层服务质量监控做“用得怎么样”的业务分析。

对算力服务器的操作系统运行状态，以及每台机器显卡的显存大小、利用率、温度、功耗等硬件指标进行采集和监控。采集方式以Zabbix Agent+自定义脚本为主，通过脚本执行显卡状态查询命令，周期性获取GPU状态信息数据，传入监控平台完成数据监控。

这一层的目标是掌握算力硬件的健康状态与资源余量。GPU的运行上限温度通常在85℃左右，持续高温不仅会触发降频保护，更会加速硬件老化；显存耗尽则直接导致推理请求排队或失败。在监控上线之前，这些风险对于算力管理平台是完全不可见的。

从最近一周（8月3日—8月10日）的运行数据看，服务器节点8张A100显卡的监控已能稳定捕捉真实负载与波动：显存使用率均值约71%，GPU温度保持在33—50℃健康区间，电源功率峰值约370W，算力调用高峰时段GPU利用率可冲至100%。这些数据表明，当前算力资源处于模型已部署，模型调用率不高，低负载、偶有峰值冲击的初期部署状态，GPU使用率与显存使用率的监控，是后续扩容论证的重要参考。

2：算力服务器GPU温度／利用率／显存／功耗综合监控视图

在硬件监控之上，进一步实现“算力调用”的业务级监控。通过对接算力管理平台的API接口，对每一次AI模型推理调用的数据进行采集、统计与告警。采集的指标包括：调用请求次数、输入Token数、输出Token数、首Token响应时延、端到端响应时延（平均/P95/最大值）、流式请求占比、请求成功率、并发连接数等。

这一层的目标是回答“算力被谁用了、用了多少、用得好不好”，这也是医院管理层和业务科室最关心的问题。当科主任问“上个月AI花了多少钱”或者“病历质控为什么响应变慢了”，我们需要用数据而非经验来回答。

截至目前，围绕算力资源已建成监控指标637项、告警规则139条，覆盖硬件与调用两个层面。

3：算力资源监控总览，调用成功率／时延／吞吐率等

3.2 算力Token调用监控：让“黑盒”变得透明

在算力监控建设之前，各业务系统调用大模型消耗了多少Token，哪些应用是算力消耗大户，服务质量是否存在瓶颈，这些问题主要靠“感觉”和“估算”。这种状况在扩容论证、预算编制时尤为被动，没有数据，就无法做出理性的决策。

接入Token调用监控后，我们获得了四个维度的能力提升：

第一，算力使用“可计量”。以最近一周（2026年8月3日—8月10日）的采集数据统计，医院日均算力调用约3.9万次，日均Token消耗量约1.28亿。其中输入Token占比高达约88%，输出Token仅占12%。这个结构清晰地表明：当前医院AI应用以病历、文书等长文本的理解与结构化处理为主，而非开放式内容生成。

这个发现的意义超出了运维层面，它直接影响了后续算力扩容的方向。输入Token占比高意味着对显存容量和带宽的需求远大于对单卡浮点算力的需求，在GPU选型时，大显存型号的优先级应高于高算力型号。如果没有这些数据，选型决策就只能依赖厂商推荐，而不是业务实际。

第二，算力去向“可追溯”。我们按模型、应用系统两个维度对算力消耗进行了拆分统计。以近一周累计数据（2026年8月3日—8月10日）为例：

数据揭示了两层信息。首先是优先级，病案智能编码和VTE智能辅助合计消耗了78.8%的算力资源，这两项必须作为算力保障的第一梯队。其次是效率差异，dify应用平台虽然调用次数仅5,379次，但单次平均消耗高达20,703 Token，是病案智能编码的近9倍，意味着该平台的Prompt设计可能存在精简空间，值得深入排查。特别值得关注的是数据分类分级应用，作为新接入的AI场景，目前消耗虽处于低位（占1.0%），但其单次消耗（4,391 Token）已与病历质控相当，需持续关注其增长趋势。

4：算力管理平台各应用系统调用成功率／响应时延／用量对比

模型侧的数据同样可以分析对比：

qwen3-32b承担了42.6%的请求量，却消耗了67.7%的算力；而qwen3-14b结构化模型承担了53.1%的请求量，仅消耗12.7%的算力。两者的效率差距超过5倍。这为“大小模型分流、按场景匹配模型”的优化思路提供了量化依据，将结构化处理类任务（如病案编码的ICD编码匹配、VTE风险评估表单填写）导向qwen3-14b，仅在复杂推理场景（如病历内涵质控、多学科会诊摘要生成）调用qwen3-32b，有望在不降低服务质量的前提下，将整体算力成本显著降低。

5：算力管理平台各模型调用成功率／响应时延／吞吐率对比

6：算力管理平台各服务提供方调用成功率／响应时延／吞吐量对比

第三，服务质量“可预警”。对成功率、响应时延（平均/P95/最大）、流式请求占比等质量指标持续采集并设置多级告警。其中P95推理延迟是一个关键指标，它表示95%的请求响应时间不高于该值，只有5%的“长尾请求”会更慢，能有效反映绝大多数用户的实际体验。当前调用请求成功率维持在96%以上，显卡显存平均使用率约71%。P95端到端时延的告警阈值设置为5秒，当P95时延超过此值时触发一般严重告警，表示可能存在模型服务性能退化或请求排队加剧。

这套预警机制的意义在于将故障发现的时间窗口从“用户投诉驱动”压缩到“系统主动探知”。以往，当医生在病历质控界面感到“卡”的时候，故障可能已经持续了十几分钟；现在，告警在P95时延开始恶化时就已触发，运维团队可以在业务感知到异常之前启动排查。

第四，运行态势“可视化”。面向日常巡检与管理汇报两类场景，通过Grafana可视化看板集中呈现实时性能卡片、趋势对比图与分维度明细。日常巡检由“逐项查询”变为“一屏看全”，管理汇报也无需再临时导数、制表，直接投屏实时数据即可说明问题。

从实践效果看，这四项能力分别解决了不同角色的需求：运维人员关心“有没有出问题”（可预警），信息中心主任关心“花了多少钱、花到哪里去了”（可计量、可追溯），分管院长关心“投入产出比”（可视化呈现趋势）。一套算力使用监控体系服务三层决策，这是本次运维监控平台升级在效率之外的附加价值。

四、运维管理能力的同步建设

如果算力监控是这次升级的“主角”，网络设备配置自动备份、CMDB资产管理和互联网云监控则是运维人员自用的瑞士军刀。三者分别补齐了运维平台在配置管理、资产治理和外部视角上的能力短板。

4.1 网络设备配置自动备份

网络设备配置管理长期以来是一个“手工活”，依靠工程师手动导出，配置被分散存放在个人电脑或共享文件夹中。版本不全、时点不准、人员变动后无从查找是常态。厂商专用的网络管理系统通常配备了配置备份功能，原生的Zabbix并不提供配置备份能力，一旦交换机或防火墙发生硬件故障需要更换或重配，缺少准确的配置底稿将直接拉长业务中断时间。笔者此前在《十年历程：某三甲医院网络系统三次改造的实践分享》中提到过，人为因素已是网络故障的重要诱因之一，而配置管理的混乱本质上是“人的不可靠性”在运维层面的投射。

我们在Zabbix平台的内外网区域嵌入部署了网络设备配置备份模块，实现了四项核心能力：

• 多厂商纳管：支持思科、华为、华三等主流厂商设备，通过表格批量导入设备资产并按分组、标签组织管理，无需为不同厂商安装不同的管理工具；

• 自动化定时备份：每日定时调度备份任务，任务失败自动重试，确保备份的连续性与完整性；

• 配置版本对比与变更追踪：内置差异比对视图，直观展示任意两个版本之间的配置差异，并提供配置变更时间轴与变更频率统计，这让非计划变更具备了可追溯性；

• 可视化看板与安全审计：实时展示备份成功率、失败任务列表与备份趋势图，具备角色权限分级、凭据加密存储与操作审计能力。

7：外网区网络设备配置备份仪表盘

目前全院内网、外网网络设备已实现每日自动配置备份。发生设备故障时，可即时调取历史时点的准确配置文件用于设备替换或配置回滚。

4.2 CMDB资产管理系统化

数据中心资产配置管理此前依靠多份Excel表格维护，存在“多人多版本、更新不同步、查询靠翻找”的典型问题。更关键的是，资产信息与其对应的安全策略（防火墙规则、ACL、VPN策略等）相互割裂，需要排查某台服务器的安全策略时，运维人员要先后打开资产表和防火墙策略表，人工比对IP地址和端口号，效率极低且容易遗漏。

信网办安全组于2025年开发的CMDB系统经过部署、测试、资产模型字段设计与验证后已正式启用，核心价值在于为数据中心建立了唯一、准确、可关联的资产数据底座：

• 资产管理：终端、服务器、网络设备、存储与网络安全设备、安全策略等资产的统一录入、维护与全生命周期管理，支持按资产类型、所属系统、物理位置等多维度查询；

• 资产—安全策略关联：以资产为维度关联查询其对应的安全策略信息，形成“资产—策略”关联视图。例如查询一台HIS数据库服务器的详情时，可同步看到其对应的防火墙、网闸的策略规则和ACL条目；

• 统一查询与追溯：提供统一检索入口，支持按IP地址、主机名、所属系统、负责人等条件快速定位资产。

8：CMDB平台查询主机信息与关联安全策略

降维视角：CMDB本质上是在做一件事，将分散在多个Excel文件、多个人脑中的“高维混沌”资产信息，降维为系统中“低维有序”的结构化数据。这种降维带来的效率提升在两类场景中最为显著：日常资产查询从“翻找表格”变为“系统检索”，响应时间从分钟级降至秒级；安全合规核查从“人工逐条比对”变为“以资产为锚点关联查询”，策略遗漏与误开放的风险大幅降低。运维资产数据进入CMDB后，为下一步的智能体运维分析提供了有效的数据底座，可推动AIOPS的落地。

4.3 互联网云监控：补上“院外视角”

院内监控系统有一个结构性的盲区：当医院出口链路中断或告警系统本身不可用时，内部视角的监控也就失去了作用，如何感知外部用户是否能访问服务？笔者在2024年8月遇到过某运营商主干光缆被挖断导致7条关键线路同时中断的故障，正是因为缺乏院外视角的监控，故障初期的判断完全依赖院内告警和用户电话报修。如果具备院外监控，我们可以直观地判断出是某一运营商的线路同时出现故障。

针对这一盲区，我们引入了云监控机制，从院外互联网侧对关键服务链路进行实时拨测。参考主流公有云服务商服务监控页的设计思路，我们同步建设了院外独立的服务健康状态总览页面，将各关键业务链路的拨测结果以直观的可视化方式集中呈现，使运维团队能够一目了然地掌握所有对外服务的实时健康状况，快速识别异常节点。具体建设内容包括：

• 多维度服务拨测：对门户网站、互联网医院、预约挂号、移动支付、停车管理及各类专线等关键对外服务节点进行高频次健康检查，拨测频率为每分钟一次；

• SSL证书生命周期管理：自动监测各业务域名的HTTPS证书有效期，防止因证书过期导致的服务中断与页面告警；

• 独立告警通道：建立独立于院内网络的告警触达机制，使用外部监控服务自身的告警通知通道发送告警，确保即使院内系统全部不可用，运维人员仍能通过外部渠道第一时间感知故障。

9：院外互联网健康监控界面，关键服务节点实时拨测状态

监控模式由“被动等待用户报修”转变为“主动发现潜在隐患”。特别是对于支付接口和挂号系统等高敏感业务，外部监控能够以分钟级捕捉访问延迟与可用性波动，在患者投诉前快速响应处置。配合此前建成的双运营商出口和智能DNS解析切换体系，现在我们设计的故障响应链路已经形成了闭环：外部监控发现异常 → 云告警独立触发 → DNS解析自动切换解析生效 → 运维团队介入处置，全链路在10分钟以内完成。

五、阶段性成效与反思

从数据层面看，本次建设带来的转变可以概括为“三个转变”：

坦诚地说，当前也留下了几个待解决的问题：

一是算力监控目前仅覆盖英伟达与华为算力节点，其他类型算力显卡（例如寒武纪）的监控还未适配支持。随着医院AI应用场景的扩展，自建算力节点的规模将持续增长，监控覆盖面必须同步跟进。

二是 Token消耗数据的分析仍以人工导出报表为主，尚未实现自动化的异常检测与趋势预测。未来对于监控数据的消费利用，让AI来分析AI的使用数据，会提供更有价值的判断，当前的AI分析能力停留在告警解读，尚未延伸到数据分析层面。通过智能体对接Zabbix API可以进行批量数据的查询分析与配置调整，已具有初步的系统分析能力。

10：智能体调用Zabbix数据生成分析

三是 CMDB与Zabbix平台的数据互通仍处于初期阶段，资产变更与监控告警的联动尚未打通。理想状态下，当CMDB中记录某台服务器的信息更新后，Zabbix应自动触发一轮完整的基础监控校验；当Zabbix检测到某设备持续离线，CMDB应自动将该设备标记为“待确认”状态并推送信息确认工单。这个闭环目前还是断的。

六、下一阶段展望

基于本次信创升级打下的基础，我们明确了统一运维监控平台后续三个方向的演进路径：

资产自动发现与CMDB深度融合。当前CMDB的资产录入仍依赖人工维护，效率瓶颈明显，新增一台服务器或更换一台交换机，需要运维人员手动在CMDB中创建条目、填写属性，遗漏和滞后是大概率事件。下一步将引入资产自动发现能力：通过自动发现功能结合自定义脚本，自动探测网络内的服务器、网络设备及虚拟化资源，并深入操作系统层面检测已安装的软件名称与版本信息，将发现结果自动同步至CMDB进行统一管理。目标是实现从“人工录入”到“自动发现、人工确认”的转变，使资产数据的完整性和时效性不再依赖运维人员的记忆和自觉。

基于AI Agent的根因分析框架。我们在前期工作中已积累了Zabbix联动本地大模型进行告警解读的经验，但当时的能力止步于对单个告警的孤立解读，大模型只能基于告警文本本身给出通用建议，缺乏对具体环境和上下游依赖的理解。下一阶段的方向是构建AI Agent调度框架：以Zabbix的监控数据、CMDB的资产与配置信息为上下文、日志中心的时序日志数据为佐证，由AI Agent三端联动进行跨系统的根因关联分析。

具体来说，当一个告警触发时，Agent不再是孤立地解读告警文本，而是主动执行以下步骤：通过CMDB查询告警主机的业务归属、软件版本和近期变更记录；通过日志中心检索同一时段该主机及其上下游依赖服务的异常日志；综合判断故障的真实根因，是硬件性能瓶颈、软件版本缺陷、配置变更引入还是外部依赖故障，并给出具体的处置建议。实现从“告诉我们出问题了”到“告诉我们为什么出问题、该怎么做”的跃升。这个方向的核心挑战在于多源数据的标准化接入和Agent推理链路的可靠性验证，我们将在后续实践中持续探索。

AI算力的数据驱动运营。算力Token监控已经让我们看清了“用了多少”和“被谁用了”，下一步的关键是让这些数据产生持续的决策价值。我们将围绕算力管理平台建立数据管理与分析能力，一方面，基于历史调用数据（调用次数、Token消耗、并发峰值）构建各业务系统的算力消耗模型，预测未来3—6个月的算力需求增长曲线，辅助资源扩容的提前规划和预算编制；另一方面，结合业务优先级和模型性能数据，制定差异化的算力资源分配策略，在保障关键业务服务质量的同时，对低频高耗场景进行限流或错峰调度。让算力管理从被动供给走向主动运营。

七、结语

从最初基于Zabbix＋Grafana构建的运维监控体系，到如今完成信创升级、覆盖AI算力精细化监控、集成网络配置备份与CMDB的统一运维管理平台，我院基础设施运维能力在不断地强化和完善。“看得见”解决的是有没有监控的问题，“看得清”解决的是数据够不够细的问题，“看得懂”解决的是数据背后的意义。本次升级通过算力Token分析、模型侧消耗对比、服务质量的主动预警，让数据开始说话。下一阶段的目标是用AI Agent打通监控、资产、日志三域数据，实现根因的自动定位。这个递进过程折射出一个趋势：医院信息运维正在从“保障不断线”走向“驱动决策优化”，从“设备运维”走向“业务运维”。