“服务器还没到？”
信息科李主任的声音，让项目经理小张头皮发麻。
距离V4.0系统在XX医院正式上线，还有10天。
部署清单上，第一批要进场的设备：
– 数据库服务器 2台（高端，双路CPU）
– 应用服务器 3台（中端）
– 存储设备 1台（全闪存阵列）
– 网络交换机 1台
这些都还没到货。
供应商说：因为芯片短缺，交货期延迟三周。
“有没有替代方案？”李主任问。
“暂时没有。”小张硬着头皮说。原计划是全新硬件，软硬一体方案。
李主任摔了电话。
1. 部署方案被颠覆：从”搭新房子”变成”旧房改造”
小张连夜找周总商量。
周总也急了：”我们是软硬件一体方案，服务器都是定制配置，换其他品牌不行吗？”
“客户已经指定品牌了，合同里写了’原厂设备’。”
“那能不能先用云服务器过渡？”
“医院不允许数据上云，安全合规过不了。”
两人面面相觑。
原计划：
“`
新硬件到货 → 上架 → 装系统 → 装软件 → 测试 → 数据迁移 → 上线
“`
现在，第一步就卡住了。
周总说：”别慌，我们还有B计划。”
“什么B计划？”
“用现有设备升级——把V3.0的老服务器，扩容后跑V4.0。”
小张眼睛一亮。
但随即又摇头：”老服务器是五年前的配置，跑V4.0会不会太慢？而且，V3.0还在跑，不能停。”
“那就做虚拟化——老物理机上架虚拟化平台，再开虚拟机跑V4.0。”
“有风险…”
“但有总比没有强。”
2. 从”新建数据中心”到”旧房改造”：风险的维度
方案变了。
原来的”新建数据中心”变成”旧房改造”。
小张带着团队，做了三天的技术评估，结论是：
可以运行，但有风险：
1. 老硬件性能不足（CPU是五年前的E5-2620，V4.0推荐配置是E5-2680），V4.0是微服务，组件多，资源消耗大，预计性能打七折
2. V3.0还在跑，不能停机，迁移时要”热迁”或双跑——两个系统同时运行，隔离要求高
3. 老系统的数据迁移复杂，新旧系统数据结构差异大（V4.0重构了数据模型）
4. 老硬件稳定性堪忧（硬盘用了五年，有免保期，但随时可能坏），万一上线后崩了…
小张的评估报告里写：
> 建议：如果两周内新硬件到不了，再考虑此方案。否则建议延期。
但两周后新硬件也到不了——全球芯片短缺至少持续三个月。
周总拍板：”干。”
3. 部署前，我们做了”预演”：仿真环境的生死测试
小张知道，这次部署，无路可退。
他做了一件 normally 不会做的事：在全仿真环境，完整演练一遍部署流程。
仿真环境，是用VMware搭的，配置尽量接近生产环境（虽然实际生产是老硬件）。
演练的内容：
1. 硬件上架（模拟）
2. 安装虚拟化平台（VMware ESXi 6.7）
3. 创建虚拟机网络（隔离V3.0和V4.0）
4. 部署V4.0所有微服务（18个）
5. 数据迁移（从V3.0到V4.0）
6. 验证业务功能
7. 切换流量
演练了三遍，发现一堆问题：
问题1：虚拟机网络配置错误
– V3.0和V4.0的虚拟网络，应该完全隔离（不同VLAN，无路由）
– 但配置时，有一个vSwitch连错了，导致两个虚拟网络互通
– 如果真这么部署，V4.0流量会冲击V3.0，导致老系统崩溃
问题2：数据迁移脚本性能不足
– 测试数据只有1/10（80万 vs 800万）
– 迁移100万条记录要30分钟
– 生产环境有800万条，要4小时
– 但业务窗口只有2小时（深夜到凌晨）
– 需要优化
问题3：回滚方案缺失
– 如果迁移一半失败，怎么回滚？
– 不能简单删V4.0数据库，因为V3.0还在跑，数据可能不一致
– 要有”双向数据同步”机制——迁移失败后，能回到V3.0状态
问题太多，小张头皮发麻。
第三遍演练，加了回滚。
4. 真正的部署日：如履薄冰的72小时
部署日，周五晚上。
小张带着四个工程师， arrive 信息科机房。
李主任也在，盯着看。
第一步：物理检查。
– 确认老服务器状态正常（5年没关机，但昨天剛做了硬件诊断，OK）
– 确认网络连通
– 确认UPS供电正常（电压稳定）
第二步：安装虚拟化平台。
– 在每台服务器上装ESXi（旧版本）
– 配置vCenter统一管理
– 创建资源池：一半给V3.0（不能动），一半给V4.0（新建）
– 这一步花了两个小时。服务器老旧，安装速度比预期慢。
第三步：网络隔离。
– 创建两个vSwitch，一个连V3.0虚拟机，一个连V4.0虚拟机
– 两个vSwitch之间不通，防火墙策略确认
– 发现：有一个端口组配置错了，导致V4.0的某个管理网卡能ping通V3.0——危险，修正。
第四步：部署V4.0微服务。
– 有20多个微服务，每个都要部署、配置、启动
– 用Ansible自动化部署，但老服务器性能差，Ansible执行慢
– 遇到一个服务启动失败：MySQL连接超时。因为数据库还没迁完，但应用已经起来在连数据库。
“能不能调整启动顺序，先起数据库，后起应用？”工程师问。
“调整，数据库服务设为’启动后30秒再启动应用’。”
第五步：数据迁移。
这是最关键、风险最大的一步。
开始迁移。
前两个模块（用户、权限）顺利。
第三个模块（门诊挂号），出现数据冲突：
– V3.0有一个挂号记录，患者ID为12345，就诊ID为abc
– V4.0里，患者ID变了（新的患者表主键重新生成，使用UUID），但V3.0数据里还是老ID（自增整数）
– 迁移时，映射关系找不到
“停。”小张喊。
问题出在”患者ID映射表”——这个表在迁移过程中生成，但因为某个中间步骤数据量大（800万条），内存不足，没生成全。
部分患者，在新库里的ID映射丢失了。
“现场生成映射。”小吴说。
他写了一个脚本，根据姓名、身份证号、就诊日期，去V3.0里查，生成映射关系。
又花了40分钟。
此时已是凌晨四点。
5. 凌晨五点的抉择：强行”双跑”
迁移到早上五点，进度85%。
还剩核心模块：医嘱、住院登记、收费。
但时间只剩一小时了——七点门诊要开始。
小吴说：”来不及了。”
小张知道，来不及了。
他做了个冒险的决定：强行切换，不迁完。
“把医嘱、住院、收费模块的迁移，放到上线后做渐进式迁移。”
意思是：上线时，这几个模块用V3.0的数据，但V4.0的服务也起来，V3.0和V4.0并行运行，V4.0慢慢接数据。
这是个”双跑”方案，风险高，但没别的选择。
他给李主任打电话：”李主任，我们方案有变。核心模块不能一次性迁完，要分两天。但门诊可以先开V4.0，不影响。”
李主任语气很冲：”你敢在上线日不迁完？”
“迁不完硬迁，数据错了更麻烦。”小张说，”双跑是唯一选择。”
李主任沉默几秒：”出问题你负责。”
七点，门诊开始。
小张紧张地盯着监控。
挂号正常（V4.0）、医生开医嘱正常（V3.0）、护士执行正常（V3.0）——V3.0和V4.0在共存。
“这也能行？”李主任惊了。
“临时方案，风险是数据不一致。但至少门诊没堵。”
6. 上线后48小时：在”拆炸弹”
小张知道，双跑方案是把达摩克利斯之剑悬在头上。
V3.0和V4.0的数据，必须尽快合并，不能长期双跑。
但合并不简单：有些数据在V4.0产生（如挂号），有些在V3.0产生（如医嘱），要保证合并后不丢、不错。
小张团队用了48小时，做”渐进式整合”：
– 第一天，把V4.0已经有的数据，合并回V3.0（作为备份）
– 第二天，所有新产生的业务，强制使用V4.0，V3.0只读
– 第三天，停V3.0，全部切到V4.0
每一步都有验证。
周一早上，全部完成。
系统终于”单飞”了。
李主任问小张：”这次部署，虽然惊险，但最后成功了。关键是什么？”
7. 小张的复盘：没有完美的计划，但有充分的预案
小张说：”没有完美的计划，但有充分的预案。”
– 我们有B计划（旧硬件升级），不然第一天就卡死
– 我们有仿真演练，不然网络配置会错
– 我们有回滚预案，不然迁移一半失败就完了
– 我们有”双跑”应急方案，不然上线日就崩了
“但最关键的，是敢于’不完美’上线。”
“什么意思？”
“我们原计划是100%数据迁完再切换。但时间不允许，我们选择了85%+双跑方案。”
“虽然不完美，但业务没受影响——门诊能挂号，医生能开医嘱，药房能发药。”
“如果死磕100%完美，可能拖到下午才能上线，影响更大。”
有时候，接受”可用但不完美”，比追求”完美但不可用”，更重要。
8. 周总的总结：系统稳定性是”冗余”堆出来的
老周后来总结这次部署：
– 硬件不靠谱（老服务器），就用软件方案补（虚拟化、双跑）
– 时间不够（10天），就用策略补（分阶段上线）
– 数据不一致风险，就用验证补（每步验证）
– 人员紧张，就用预案补（演练）
(“系统稳定性，不是’设计出来’的，是’冗余出来的”)。
冗余不仅是硬件冗余，更是方案冗余、时间冗余、人力冗余。
没有B计划的部署，是赌博。
有B计划，哪怕B计划看起来不完美，也能保底。
9. 这次部署的”五个教训”
老周把这次经历写成案例，给公司所有实施人员培训：
教训一：永远要有B计划
– 硬件不靠谱，怎么办？
– 时间不够，怎么办？
– 人员生病，怎么办？
教训二：仿真演练不能省
– 这次发现的问题，如果在生产环境才发现，就是灾难
– 演练不是”走过场”，是”找问题”
– 演练一遍不够，要演练三遍
教训三：接受”不完美”的上线
– 不是所有功能一次搞定
– 分阶段上线，保证核心业务先跑
– “可用”优先于”完美”
教训四：回滚方案必须提前测试
– 不能光有计划，要演练回滚
– 回滚失败比不迁更糟
教训五：客户沟通要透明
– 小张一开始没告诉李主任”85%方案”，差点被骂
– 后来说明了，李主任理解了
– 透明能降低客户焦虑
10. 给所有实施人员的建议：预案做到极致
最后，老周说：
“实施工作，本质上是在’不确定性中寻找确定性’。”
– 时间不确定（会不会延迟？）
– 资源不确定（人手够不够？）
– 客户态度不确定（验收会不会卡？）
– 环境不确定（网络通不通？）
我们能做的，就是把确定性做到极致：
– 预案做全
– 演练做实
– 沟通做透
– 方案做细
“这次部署，我们准备了一份70页的部署手册，但只用上了20页。那50页是’可能用不上’的预案。”
“但真出事时，那50页，救了我们。”
互动话题
你经历过最惊险的一次系统部署/上线是什么情况？最后是怎么挺过来的？
> 基于真实医院场景改编，人物均为化名
立即免费试用门诊系统：https://app.kmhis.com/
International Version：https://app.kmhis.com/multi/
了解软佳门诊管理系统详情：https://www.kmhis.com/outpatient-management-system.html
手机扫码试用患者预约。请勿输入个人真实信息（点击图片可查看原图）
支持8种语言：简体中文、繁体中文、香港中文、English、藏文、泰文、老挝语、越南语
说真的。这类问题我见过太多了。每次看到医院同事为选型头疼。我就想，要是早点有人把这些经验分享出来就好了。毕竟。选择不对。后面全是麻烦。选择对了。省心省力。还能提升整个机构的运行效率。希望这篇能帮到正在纠结的你。
你如果有具体需求。也可以去 www.kmhis.com 看看。那里有更详细的技术方案和案例。
