1. 医疗系统故障演练与应急工程导论
医疗信息系统与普通互联网业务最大的区别，在于它的可用性直接关联到患者生命安全。挂号、医嘱、检验、影像、收费、手术麻醉、重症监护等环节一旦中断，影响的不只是业务收入，而是诊疗行为的连续性与临床决策的可靠性。因此，本课程讨论的"故障演练与应急工程"，不是一次性的应急演练活动，而是一套围绕医疗业务连续性构建的工程能力体系。
课程定位：从"能恢复"到"可证明能恢复"
传统运维往往把高可用寄托在冗余架构和备份策略上，认为"做了双机、做了备份"就等于"系统不会长时间中断"。但真实故障中，问题常常出在：备份从未验证过可恢复、切换脚本依赖的账号已过期、数据库主从延迟导致切换后数据不一致、临床科室不知道降级流程该走哪条路径。故障演练与应急工程要解决的，正是这种"纸面高可用"与"实际可恢复"之间的落差。
本课程定位为面向医疗信息化从业者的工程实践课，覆盖三类角色关注点：运维与SRE关注故障注入、监控告警与切换验证；研发关注系统在依赖失效时的降级与容错设计；临床信息科与业务管理者关注应急响应组织、降级诊疗流程与复盘改进。三者共同构成医疗系统应急能力的完整闭环。
医疗系统的高可用与安全目标
医疗系统的高可用目标不能只用一个"99.9%"概括，而应按业务关键度分层设定。以下为教学示例参数，用于说明分层思路，并非某家医院的实测指标：
| 业务等级 | 典型系统 | 可接受中断时长（示例） | 恢复目标（示例） |
|---|---|---|---|
| 一级（生命相关） | 重症监护、手术麻醉、急诊医嘱 | ≤ 5 分钟 | RTO ≤ 5 min，RPO ≈ 0 |
| 二级（诊疗核心） | HIS、电子病历、LIS、PACS | ≤ 30 分钟 | RTO ≤ 30 min，RPO ≤ 5 min |
| 三级（支撑业务） | 预约、收费、报表、办公 | ≤ 4 小时 | RTO ≤ 4 h，RPO ≤ 1 h |
这里涉及两个核心术语：RTO（Recovery Time Objective，恢复时间目标）指业务从中断到恢复可用的最长可接受时间；RPO（Recovery Point Objective，恢复点目标）指可接受的数据丢失时间窗口。医疗场景中，RPO 往往比 RTO 更敏感——医嘱、检验结果、影像报告一旦丢失，可能直接影响诊疗判断，因此一级系统通常要求 RPO 接近 0，即采用同步复制或强一致写入。
安全目标则包含三个维度：可用性（系统持续可访问）、完整性（数据不被篡改或丢失）、保密性（患者隐私不泄露）。应急工程不能为了快速恢复而牺牲后两者，例如临时启用未加密的旁路通道、使用共享账号登录，都会在恢复业务的同时引入新的合规风险。
故障演练与应急工程的关系
故障演练是"主动制造故障、观察系统反应"的手段，应急工程是"设计、建设、验证、改进应急能力"的体系。二者关系可以概括为：演练是应急工程的验证环节，应急工程是演练的设计依据与改进归宿。没有演练，应急方案无法证明有效；没有应急工程，演练就退化为"为了演练而演练"。
下图展示了一个医疗系统故障演练与应急工程的闭环结构，包含演练设计、故障注入、系统响应、应急切换、业务降级、复盘改进六个环节，以及贯穿其中的监控告警与数据一致性校验两条支撑链。
核心术语与整体学习路径
在进入后续章节前，需要先统一几个高频术语：
- 故障注入（Fault Injection）：主动向系统引入可控故障，如杀死进程、断开网络、注入延迟、模拟磁盘满，用于观察系统在异常下的真实行为。
- 混沌工程（Chaos Engineering）：在分布式系统上以受控实验方式验证系统韧性的方法论，强调假设、最小爆炸半径、可回滚。
- RTO / RPO：恢复时间目标与恢复点目标，是应急能力量化的两个基本坐标。
- 降级（Degradation）：在核心依赖不可用时，主动关闭非关键功能或切换到简化流程，保住核心诊疗业务。
- 熔断与限流：当下游依赖错误率或延迟超过阈值时，快速失败并保护上游，避免级联雪崩。
- 演练爆炸半径（Blast Radius）：一次演练可能影响的最大范围，医疗场景必须严格控制，避免演练本身造成真实诊疗中断。
整体学习路径按"认知—设计—实施—验证—改进"推进：先建立医疗高可用与安全目标的分层认知，再学习故障场景建模与演练方案设计；随后进入具体技术手段，包括基础设施层、数据库层、应用层与网络层的故障注入与应急切换；再覆盖临床业务降级流程与应急响应组织；最后通过复盘方法与持续改进机制，把单次演练转化为组织能力。