关停旧HIS的第一周，检验报告“消失”了

先讲一个真实的故事。

一家日均门诊量7000+、运行着300多个业务子系统的综合三甲医院，上线了新的HIS系统。新系统平稳运行一段时间后，信息中心按计划把老HIS下线。

当天，问题来了。

医生工作站看不到LIS的检验报告——LIS系统里明明有；患者做了CT，PACS里有影像，医生电脑和患者手机端都显示“没有报告”。

患者做了检查拿不到报告，医生没法判断病情，临床科室的反馈电话一个接一个打到信息中心。

排查的过程，是一场典型的“三不管”：

找LIS厂商——“数据已经发给HIS了”；

找HIS厂商——“没有收到LIS的数据”；

找PACS厂商——“影像已经推过去了”；

再问HIS——“同样没收到”。

三家厂商，都说自己没问题。可报告，就是看不到。

转机来自一个细节：信息中心的工程师注意到，问题恰好出现在老HIS关停之后。抱着试试看的想法，把老HIS重新启动——业务立刻恢复。

事后，几家厂商一起到现场定位，真相浮出水面：LIS和PACS有一部分接口，调用的仍然是老HIS的接口，切换时没有换到新HIS上。而之所以没换，是因为——没有人知道系统之间到底有哪些接口在调用、每个接口是干什么的。系统间的调用关系，对信息中心来说，完全是一个黑盒。

这家医院的信息负责人事后说了一句话：“这还只是很少的业务关联。现在各系统的关联关系、接口关系根本看不清，各厂商只负责自己的部分，没有人从全局去排查定位。”

这不是一家医院的问题

几位同行的心声：

某肿瘤专科三甲医院（日均门诊量2700，100+业务子系统）的信息中心主任：“我不怕已经梳理清楚的业务系统，最怕的是还有多少业务架构问题是不知道的。跨业务系统的故障排查非常麻烦，厂商间相互推诿，目前也没有人能牵头快速定位。”

某妇儿专科三甲医院的运维负责人：数据库死锁和慢SQL每周出现多次，手工梳理要1-2个小时才能找到源头，才能kill掉会话恢复业务。我们希望有工具能支持死锁和慢SQL的监测、诊断、一键kill。”

某日均门诊量11000的综合三甲医院运维负责人的期望更直接：“系统变动大，接口频繁增改，一旦坏了影响很广。希望能定位到具体哪条路径、哪个IP异常，不要再被动救火——先于临床发现风险，是信息中心的第一职责。”

三家医院，规模、系统、故障各不相同，却指向同一件事：信息中心手里，缺一个能看清全局的手段。

为什么业务故障越来越难定位？

根因一：业务互联化，牵一发而动全身

在电子病历评级、互联互通测评等政策推动下，医院通过集成平台、ESB、API把上百个系统深度耦合在一起，任何一个核心系统或关键接口出问题，都可能让依赖它的一串系统集体趴窝。

根因二：工具看不懂业务

传统运维工具检测的是基础设施指标——CPU、存储IO、网络健康度、数据库表空间占用。这些指标正常，不代表业务不卡、不慢、不断。至于系统间的接口关系？多数单位靠一份手工维护的Excel台账或静态架构图，系统一改就过期。

根因三：没有人能掌控全局

用户访问一次业务系统，要经过：终端→有线无线网络→安全设备→云/虚拟化→存储→中间件→数据库→应用程序→API接口→外部支付机构。链条上每一段属于不同厂商。信息中心无论从技术能力还是职责分工上，都不具备全局统筹的手段。

根因四：熟悉的运维模式失效了

过去业务系统独立，出问题找对应厂商就能解决。现在问题可能出在基础设施、上游系统，甚至外部支付机构——各厂商各自为政，都说自己没问题，客户被迫当裁判。

也想过上APM（应用性能管理）工具，但两条路都走不通：代码侵入式采集，医院基于信息安全考虑不接受；即便允许，APM的调用链、火焰图是给研发人员看的，驻场运维根本用不起来。

乐享3.0的解法：零侵入的全链路可观测

锐捷乐享3.0的核心主张是：

在不改动业务系统一行代码的前提下，让驻场运维人员实现业务故障的分钟级发现、分钟级定界，并把常见故障的预防变成日常巡检。

如何做到？乐享3.0通过四个关键能力，一一回应信息中心每天最想问的四个问题：

问题一：系统之间到底是怎么连的？

看不清，就永远不知道“黑盒”里有什么。乐享3.0用看清业务的能力来回应：不需要业务厂商配合，也不需要改一行代码，三种零侵入的采集方式并行，把“谁在调谁、调得好不好”摸清楚：

eBPF Agent：在操作系统内核层采集数据，覆盖虚拟化内部和容器的东西向流量——系统与系统之间的横向调用靠它看。轻量、零侵入，占用系统资源低于5%，支持HTTP/HTTPS/TCP/DNS/RPC/SQL等主流协议；

网络流量镜像：通过交换机旁路镜像采集南北向流量——终端访问业务系统靠它看，对业务零影响；

进程关系发现：通过SSH识别进程间的TCP调用关系，连Agent都不用装。

而且这张调用地图是“活”的：系统自动识别业务系统边界、自动发现接口及互访关系和调用质量，接口的新增、变更、参数变化都能自动跟上——信息中心不用再依赖那份永远赶不上变更的手工接口台账。

问题二：出问题，能不能比临床更早知道？

很多故障，信息中心不是第一个知道的。故障的第一发现人，决定了信息中心是“主动处置”还是“被动挨批”。乐享3.0用及时感知的能力来回应：让系统替信息中心站岗。两类故障，两种机制：

可用性故障（业务打不开）：外置拨测点对业务系统持续仿真探测，最快1分钟内收到告警；

卡慢故障：基于用户体验指标持续观测，为避免“闪断”造成误报，持续观测5-10分钟后触发告警。

体验类故障快速准确发现识别

问题三：问题到底出在哪一段、是谁的责任？

故障定位难，一半难在“说不清是谁的问题”。乐享3.0用智能定界的能力来回应：故障发生时，1-3分钟内给出结论——问题在网络、应用，还是基础资源，把信息中心从“被迫当裁判”的位置上解放出来。

SLE（Service Level Expectation，服务水平期望）用户体验指标体系是整个方案的技术内核。它不看资源，看体验——用四组指标（网络连接成功率、网络连接时延、应用响应成功率、应用交易时延）衡量业务运行健康度：

故障发生时，SLE指标关联分析器自动关联异常指标、自动计算各原因的占比、直接给出定界结论——问题出在哪个边界：

指向网络：DNS解析异常、TCP建连异常、网络拥塞丢包导致的无法访问或访问慢；

指向应用：访问无响应、访问错误、响应时延高；

指向基础资源：操作系统CPU/内存瓶颈、中间件连接池不足、数据库死锁或慢SQL。

基于SLE业务故障诊断模型的故障根因快速定界定位分析

定界给出方向之后，还有两件事决定故障能不能真正闭环：

一类是“复现不了”的疑难杂症。故障发生时不在现场，等厂商到场已经“好了”，一句“复现不了”就能把问题挡回来。这类故障怎么破？乐享3.0把原始用户访问数据留存7天，任意时刻的异常都能下钻回溯完整会话——是哪个五元组、哪个请求、错在哪里，全程有据可查。

另一类是数据库死锁和慢SQL等“老毛病”的自动化处理。系统零侵入地自动捕获锁与慢SQL清单，智能分析源头锁、关联锁，支持锁溯源和一键KILL。

数据库深度分析

问题四：能不能让故障根本不发生？

乐享3.0用主动预防的能力来回应。预防难在哪？隐患在出事前根本看不见。死锁、慢SQL这类问题，第一次出现前没有任何征兆；等它们变成“每周都来”的老问题，信息中心其实已经反复救火很久了。

乐享3.0靠两个自动化的日常动作：

风险预防检查项：内置覆盖常见数据库（锁、慢SQL、超时SQL）、操作系统、网络设备及链路的预防检查项，后台自动巡检，在死锁造成业务中断之前规避风险；

接口质量劣化检测：对接口的响应时间、成功率、调用频率、超时率做多指标趋势分析——不是等接口“坏”，而是在它“正在变坏”的时候就预警。

这两套自动化跑起来，很多故障会在发生之前就被拦下。

风险隐患健康检查，防患故障于未然

实战检验

福建省人民医院（综合三甲，80多个子系统）

移动查房系统早高峰卡顿，PAD上打不开、一直转圈，网络厂商与软件厂商相互推诿近一个月没有结论，护士长把投诉电话打到了主任那里。

引入乐享3.0后，通过全链路追踪，几分钟内锁定根因——服务器TCP连接未释放，研发一周内解决。

目前，该院复杂故障平均处理时长从120分钟降至20分钟，故障处理从“多方线下会诊”转变为“一人线上闭环”。

结语

业务系统不会越来越少，调用关系不会越来越简单。业务连续性的本质，是有人站在全局看业务。

锐捷乐享3.0致力于：让信息中心拥有站在全局看业务的手段——看清调用关系，先于临床感知，分钟级定界，日常化预防。