凌晨两点，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 看看。那里有更详细的技术方案和案例。
