凌晨两点，XX医院。

主数据中心机房，突然停电。

不是演练，是真的——市电故障，加上UPS电池老化（三年没检测），未能及时切换到电池供电。

整个医院HIS系统，在零点17分，瞬间离线。

门诊挂号停摆，住院系统失联，药房发不了药，检验科做不了标本，急诊科只能手工记录。

值班工程师小吴发现异常，两分钟后，给老周打电话。

老周从床上跳起来，一边穿衣服一边想：四个月前的那次灾备演练，终于派上用场了。

那是去年12月的灾备演练，当时切换失败，备用数据中心检测不到，手动切换功能也没有。那次演练，暴露了三个问题。

这四个月，他们一直在整改。

而今天，真停电了。

1. 第一反应：不是”抢修”，是”切换”

老周在电话里问小吴：”主数据中心完全断电了吗？”

“是的，所有设备都断电了。UPS也耗光了。”

“备用数据中心呢？”

“还没检测到，我们在手动查。”

“用应急手动切换U盾！”老周吼道。

他记得四个月前那次教训——不能依赖自动切换。万一自动切换失败，必须有人工手段。

小吴跑向机房，从保险柜里取出那个黑色的U盾，插入备用数据中心的控制台。

手动切换流程，在预案里写得清清楚楚：

1. 登录备用数据中心管理后台

2. 点击”紧急接管”按钮

3. 确认切换（会强制把负载均衡指向备用数据中心）

4. 验证业务状态

小吴的手有点抖。他虽然是工程师，但这是第一次”实战切换”——不是演练，是真停电了。

点击”紧急接管”。

系统提示：”接管成功，预计30秒内生效。”

他盯着负载均衡的实时状态：

– 主数据中心IP：离线

– 备用数据中心IP：生效（绿色）

30秒后，护士站的小张刷新页面，看到系统回来了。

“能用了！”小张喊。

2. 切换后，数据一致吗？——那个0.02%的差异

老周赶到医院时，已经是凌晨三点。

信息科李主任在机房外走来走去，神色焦虑。

“周总，数据有没有丢？我们最怕这个。”

老周没直接回答，而是问：”切换后，有没有医生报错？”

“暂时没听说，但这才切换了不到一小时…”

老周打开备用数据中心的监控面板。

灾备系统的设计，是主数据中心实时同步数据到备用数据中心（异步 replication，延迟1-3秒）。理论上，数据应该是”零丢失”——主数据中心断电前最后的事务，应该已经同步到备用。

但他查数据对比：用脚本比对主库最后一次备份（昨晚00:00）和备用库当前数据，差异率是0.02%。

那0.02%是什么？

是断电前30秒内产生的数据——因为同步延迟，这部分还在主数据中心的内存里，没来得及写磁盘，就断电了。

切换后，这部分数据永久丢失了。

“有多少数据？”

“正在估算。挂号、医嘱、收费…大概几百条。”

李主任脸色变了：”几百条？”

“主要是挂号记录。”老周说，”如果病人在断电前刚挂上号，但还没缴费，数据丢失，他们会以为挂上了，但实际上没挂上。这会引发纠纷。”

李主任：”那怎么办？”

“我们有个预案：断电恢复后，主数据中心重启，会尝试从备用库同步回主库。如果同步成功，数据能补回一部分。但如果是事务中途断电，可能补不回来。”

老周决定：不等了，现在就去主数据中心，尝试恢复。

3. 主数据中心恢复：希望与绝望交织

早上五点半，市电恢复。

主数据中心可以通电了。

老周和李主任，带着运维团队，在主数据中心机房。

设备一台台启动：

– 网络设备

– 存储设备

– 数据库服务器

七点，数据库启动成功。

启动后的第一件事：尝试从备用数据中心，同步回主数据中心的数据。

同步开始。

但同步报错：主库的某些数据，已经被断电前的事务部分修改过，和备用库的版本冲突。

数据库自动冲突解决机制，选择了”以主库为准”——意味着主库的数据会覆盖备用库。

问题是：主库断电前的数据，本身就是不完整的（内存中的数据没持久化）。

这可能导致：备用库里有的数据，主库里因为断电前部分事务已经提交，反而”多”了一些数据；或者反过来，”少”了一些数据。

手动检查发现：

– 有大约200条记录，主库有、备用库没有（备用库没收到）

– 有大约150条记录，备用库有、主库没有（主库内存丢失）

“这怎么搞？”李主任快要崩溃了。

老周说：”我们只能手工对比，确保一致性。”

他们制定了手动对账流程：

1. 导出主库的今日所有业务记录（时间范围：断电前24小时）

2. 导出备用库的同时间记录

3. 对比关键业务：挂号、住院登记、医嘱、收费

4. 发现差异，人工核查（查看业务日志、纸质记录）

5. 对无法确定的差异，标记为”待调查”，业务上补偿（比如给病人重新挂号）

这个流程，花了整整一天，八个人同时核对。

到晚上八点，对账完成：

– 挂号差异：37条，已人工补录

– 住院登记差异：5条，已补录

– 医嘱差异：0条（医嘱还没有产生，或已同步）

– 收费差异：12条，已财务手工调账

“业务基本恢复。”老周说，”但今天的数据，还有一部分在备用库，没同步回主库。明天早上还要做增量同步。”

李主任松了口气。

4. 事故分析：暴露了多少问题？

事故后第三天，老周主持了深度复盘。

参会者：软佳团队、信息科全体、医院领导。

发现的问题清单 (根本原因分析，5 Whys):

问题1：UPS电池老化，没有定期检测

– 为什么？——电池检测制度是”每半年一次”，但去年只做了一次

– 为什么没做？——没人跟踪执行

– 为什么没人跟踪？——运维清单不完整

问题2：主数据中心断电后，没有及时通知备用数据中心”已失去主中心”

– 备用数据中心靠心跳检测主中心状态，心跳没断（网络还通着，因为网络设备有UPS），所以备用中心不知道主中心已经断电

– 切换依赖”主中心故障+心跳丢失”双条件，但这次是主中心断电但网络设备还活着（有UPS），心跳没丢

– 手动切换救了命

问题3：数据同步延迟导致丢失

– 同步是异步的，延迟1-3秒

– 这1-3秒的数据，断电就丢了

– 要达到”零丢失”，必须用同步复制（但会影响性能，降低吞吐量30%）

问题4：主中心恢复后，数据冲突解决机制不合理

– 默认”以主库为准”，但主库断电是不正常状态

– 应该优先以备用库为准，因为备用是正常状态

– 应该在切换前记录”最后一致时间戳”，恢复时根据时间戳判断

问题5：没有”业务快速恢复”预案

– 数据不一致时，业务不知道怎么办

– 应该像银行一样，有”业务补偿流程”：数据不一致时，如何快速让病人看上病、用上药

5. 系统性整改：从”能切换”到”切换后业务无感”

老周和信息科一起，制定了整改计划，投入80万。

1. 基础设施升级（预算40万）

– UPS电池全部更换，半年检测制度（写进SOP）

– 主数据中心增加柴油发电机（支持8小时）

– 备用数据中心增加独立市电接入（双路市电）

– 增加环境监控（温湿度、漏水、门禁）

2. 灾备切换机制优化（预算15万）

– 心跳检测增加”电力状态”监控——如果主数据中心电力丢失，不管网络通不通，立即切换

– 增加”一键切换”按钮，贴在所有关键岗位墙上（物理按钮，防误操作）

– 每季度演练一次手动切换（真断电，不只是模拟）

3. 数据同步优化（预算10万）

– 评估”同步复制”可行性（可能性能下降20%，但保证零丢失）——决定保留异步，但优化

– 增加”断电前最后60秒日志缓存”，主中心断电前，把最后的事务先写入共享存储（SAN），备用中心可以先读这个

– 增加”切换点标记”，每次切换记录时间点，便于恢复

4. 主备恢复流程标准化（预算5万）

– 主中心恢复后，数据同步策略改为”以备用库为准”

– 对账流程自动化（每天凌晨自动比对核心业务数据）

– 差异处理流程文档化，包括业务补偿标准

5. 业务连续性保障（预算10万）

– 最坏情况预案：数据完全无法恢复，如何手工恢复业务？

– 方案：启用”应急纸质表单”，所有业务先手工登记，系统恢复后补录

– 这个方案要提前告知临床科室，让他们有心理准备

– 对医护人员进行”应急模式”培训

6. 一个月后，再次演练：从70分到95分

整改完成后，老周组织了”全真演练”。

这次，他们模拟的场景是：主数据中心断电且断网（比上次更难）。

发现的新问题：

– 备用数据中心启动时间比预期长（15分钟 vs 目标5分钟）——因为存储阵列自检慢

– 业务验证脚本跑不通（有些功能依赖主数据中心的环境变量，没考虑到）

– 切换后，财务科发现”当日收入统计”不准（因为数据延迟，部分收入不在统计窗口内）

继续改。

第二次演练，完美。

老周给信息科的评分：从70分提升到95分。

李主任说：”现在我们不怕停电了，就怕不演练。”

7. 杨院长的话：选择合作伙伴，不是选价格，是选关键时刻靠得住

事故后一个月，杨院长在一次全院大会上说：

“信息系统，是我们医院的神经系统。这个神经系统，不能只有一个大脑，要有备份。这次停电，我们见识了备份的价值。

但更重要的是，我们见识了我们的信息科和软佳团队的专业和负责。凌晨三点，周总带着人赶到医院；四十八小时，没睡过一个整觉；对账、补数据、恢复业务…

选择合作伙伴，不是选价格最便宜的，是选关键时刻靠得住的。”

周总坐在台下，没说话，但记住了这句话。

8. 灾备的”本质”：不是”有”，是”能用”

老周后来在多个场合分享这次经历。

他的核心观点：

灾备系统，不是”买一个放在那里”就行，而是要让它”用过”。

只有演练过，才知道切换按钮在哪里；只有演练过，才知道数据对账流程有多复杂；只有演练过，才知道业务部门需要什么预案。

“很多单位，灾备系统建好了，五年没启用过，美其名曰’系统稳定，没机会用’。但真出事的时候，发现这也不会、那也不熟，灾备系统等于没有。”

灾备的价值，不在于备用，在于能用。

软佳现在的做法：

– 每季度一次真刀真枪的演练（部分业务切换到备用中心，半小时后再切回）

– 每年一次全站演练（主中心完全断电）

– 每次演练后写报告，改进流程

客户一开始嫌麻烦，现在主动要求演练——因为他们 seeing 了价值。

9. 灾备的”成本”与”风险”权衡

有客户问老周：”灾备这么贵（软佳的灾备方案加价30%），值吗？”

老周反问：”你们醫院一年营业额多少？”

“大概10亿。”

“如果系统瘫痪三天，损失多少？”

客户算了算：门诊停三天，损失至少3000万。还不算声誉损失、病人流失、卫健委处罚。

“灾备花300万，保3000万，值吗？”

客户不说话了。

“而且，灾备不是’一次投入’，是持续投入——每年演练、每年升级、每年测试。”

“但比起系统瘫痪的代价，还是划算的。”

10. 给所有技术负责人的建议：不要等出事才后悔

老周最后的总结：

① 灾备不是选择题，是必答题

– 只要系统在生产环境运行，就必须有灾备

– 特别是医疗、金融、政务系统，不能承受数据丢失

② 灾备的”可用性”比”存在”更重要

– 有灾备但不演练 = 没有

– 定期演练，确保切换按钮有人会按、流程有人懂

③ 灾备要有”业务视角”

– 不是”数据能恢复”就行，是”业务能继续”

– 要有业务补偿方案（手工登记、应急表单）

– 要让临床科室参与演练

④ 灾备的”成本”是投资，不是开销

– 一次事故的损失，可能超过十年灾备投入

– 保险思维：小额确定性支出，对冲大额不确定性损失

互动话题

你的系统有灾备吗？演练过吗？实战用过吗？

> 基于真实医院场景改编，人物均为化名

---

立即免费试用门诊系统：https://app.kmhis.com/
International Version：https://app.kmhis.com/multi/
了解软佳门诊管理系统详情：https://www.kmhis.com/outpatient-management-system.html

支持8种语言：简体中文、繁体中文、香港中文、English、藏文、泰文、老挝语、越南语

---

说真的。这类问题我见过太多了。每次看到医院同事为选型头疼。我就想，要是早点有人把这些经验分享出来就好了。毕竟。选择不对。后面全是麻烦。选择对了。省心省力。还能提升整个机构的运行效率。希望这篇能帮到正在纠结的你。

你如果有具体需求。也可以去 www.kmhis.com 看看。那里有更详细的技术方案和案例。