一次看似普通的系统升级
去年冬天，某三甲医院计划将内部的电子病历系统从旧版迁移到新版平台。表面上看，这只是常规的技术迭代，但项目启动两周后，门诊挂号系统突然瘫痪，持续超过4小时，大量患者无法就诊，现场排起长队，投诉电话被打爆。
问题出在哪儿？
事后复盘发现，根本原因不是软件本身有 bug，而是网络实施前的风险评估严重不足。新系统上线前，技术团队只做了功能测试，却忽略了对现有网络架构的压力模拟和依赖关系分析。
比如，新系统默认启用了 HTTPS 双向认证，而原有的负载均衡设备未配置对应证书策略。这一改动在测试环境没问题，因为测试网段隔离且流量小。但一接入生产网络，设备无法处理突增的 TLS 握手请求，导致连接池耗尽。
被忽视的依赖链
更麻烦的是，电子病历系统还依赖一个老旧的 LDAP 服务做身份验证。这个服务运行在一台十年前的物理服务器上，平时没人动它。新系统并发登录量是旧系统的三倍，直接把 LDAP 打满 CPU，响应延迟飙升到 8 秒以上。
这类“隐性依赖”在风险评估中经常被漏掉。很多单位只盯着主系统，却不梳理周边支撑组件的承载能力。等到上线才暴露，代价就是业务中断。
真正的风险评估该怎么做
后来医院请了第三方安全团队重新走了一遍流程。他们先画出完整的数据流图，标出所有通信路径、端口、协议和认证方式。然后用工具模拟真实用户行为，逐步加压，观察各节点表现。
其中一项关键操作是生成网络访问矩阵：
<?xml version="1.0" encoding="UTF-8"?>
<access-matrix>
<rule>
<source>EMR_New_Server</source>
<destination>LDAP_Old_Server</destination>
<port>636</port>
<protocol>TCP</protocol>
<expected_concurrent>500</expected_concurrent>
<risk_level>high</risk_level>
</rule>
</access-matrix>这张表明确列出每个交互环节的预期负载和风险等级。一旦某项标记为“high”，就必须提前验证或制定降级方案。
别忘了人为因素
还有个细节值得提：当时值班的运维人员并不清楚新系统的认证机制变化。故障发生时，他们按老经验排查防火墙规则，花了两个多小时才定位到证书问题。
真正的风险评估不能只停留在技术层面，还得包括人员培训、应急预案和变更通知是否到位。系统再稳，人不熟悉，照样出事。
现在他们怎么做的
这家医院现在搞系统变更，必须过五关：资产清点、依赖分析、压力测试、权限审查、应急演练。每次上线前，还得提交一份《网络影响说明书》，由信息科和临床科室共同签字确认。
有一次财务系统要接银联支付，光是网络策略评审就开了三次会。有人嫌烦，但没人敢跳步——毕竟吃过亏的人最怕再出事。