4. 故障演练体系设计

故障演练不是一次性活动，而是一套需要长期运营的工程能力。很多医院信息科在第一次做演练时，往往直接拉上所有人做一次“拔网线、切数据库”的实战，结果要么因为准备不足导致真实业务中断，要么因为范围太大、目标模糊，演练结束后没人说得清到底验证了什么。要避免这种局面，必须先设计体系，再选择演练形式。本节围绕演练目标、范围、类型、频率、组织角色与成熟度模型六个维度展开，并给出从桌面推演到全链路实战的演进方法。

一、演练目标：先定义“验证什么”，再决定“怎么演”

演练目标决定了后续所有设计。常见目标可分为四类：验证预案有效性（如HIS主库宕机切换预案是否可执行）、检验人员熟练度（值班工程师能否在15分钟内完成切换）、发现架构薄弱点（如双活链路是否存在单点）、满足合规与评审要求（等级医院评审、等保、电子病历评级）。目标必须可度量，例如“RTO≤30分钟、RPO≤5分钟、切换后门诊挂号成功率≥99%”，而不是“提升应急能力”这类无法验证的表述。

目标还应分层：业务目标（保障急诊、门诊、住院核心业务连续）、技术目标（验证数据库切换、存储双活、网络冗余）、管理目标（检验指挥链、信息通报、对外沟通）。一次演练可以聚焦1～2个目标，贪多会导致观测点分散、结论模糊。

二、演练范围：按业务链路与系统边界划定

范围界定要回答三个问题：涉及哪些业务系统（HIS、LIS、PACS、EMR、医保接口）、涉及哪些基础设施（服务器、存储、网络、数据库、中间件）、涉及哪些院区与科室。建议用“业务链路”而非“系统清单”来划范围，因为故障影响是沿链路传播的。例如“门诊挂号—收费—发药”链路会同时牵动HIS、医保接口、自助机、叫号系统。范围过大则风险高、组织难；过小则验证不充分。初次演练建议选择单链路、非高峰时段、可回退的范围。

三、演练类型与频率：分层递进

演练类型从轻到重可分为：桌面推演（Tabletop）、模拟演练（Simulation）、局部切换演练、全链路实战演练、无预告盲演。频率应遵循“高风险高频、低风险低频”原则：桌面推演每季度1次，局部切换每半年1次，全链路实战每年1～2次，盲演在成熟度较高后每年1次。频率不是越高越好，关键是每次演练都要有明确的验证点和改进闭环。

四、组织角色：指挥、执行、观察、保障四线分离

演练组织必须避免“既当运动员又当裁判员”。建议设置：演练指挥组（总指挥、副总指挥，负责决策与叫停）、执行组（按预案操作，记录时间戳）、观察评估组（独立记录现象、判定是否达标，不参与操作）、保障组（负责回退、监控、业务兜底）。此外还需业务代表（临床科室确认业务可用性）和厂商支持（数据库、存储、网络厂商待命）。角色分离是演练可信度的基础。

五、成熟度模型：五级演进路径

可参考五级成熟度：L1 初始级（无预案、无演练）、L2 文档级（有预案但未验证）、L3 桌面推演级（能走通流程、发现预案漏洞）、L4 局部实战级（单系统切换成功、RTO/RPO可测）、L5 全链路实战级（多系统联动、盲演、自动化切换、持续度量）。多数医院处于L2～L3，向L4演进的关键是建立可回退的演练环境和独立评估机制。

六、从桌面推演到全链路实战的演进方法

演进不是简单地把演练规模做大，而是按“先验证流程、再验证技术、最后验证联动”的顺序推进。第一步桌面推演起步：召集指挥组、执行组、业务代表围桌讨论，由主持人注入故障场景（如“HIS主库所在存储阵列双控制器同时故障”），各角色口述应对动作，观察组记录预案中缺失的步骤、职责不清的环节和联系不上的岗位。桌面推演成本低、风险低，适合每季度做一次，重点输出预案修订清单。

第二步局部切换验证：选择单系统或单链路，在测试环境或非高峰时段真实执行切换与回退。例如验证LIS数据库主备切换，记录从故障注入到业务恢复的实际时间，与RTO目标对比。此阶段必须准备回退预案，并安排保障组全程监控。关键产出是RTO/RPO实测值和操作耗时分解，用于识别瓶颈环节。

第三步全链路联动：将多个系统、多个院区纳入同一场景，例如模拟“中心机房断电，门诊挂号—收费—发药链路切换至备用院区”。此时业务代表需在临床端确认业务可用性，观察组独立评估，指挥组拥有叫停权。全链路演练每年1～2次，重点验证跨系统依赖、数据一致性和指挥链效率。

第四步盲演与自动化：在成熟度达到L4后，可开展不预告时间、不预告故障点的盲演，检验真实应急响应能力。同时将高频切换操作脚本化、自动化，缩短人工操作时间。盲演风险极高，必须确保回退机制可靠、指挥链清晰，且提前完成风险评估与审批。

七、演练设计检查表示例

以下检查表可用于每次演练前的方案评审，字段可根据实际调整：

演练体系设计的本质，是把“应急能力”从个人经验转化为组织能力。目标决定方向，范围控制风险，类型与频率匹配成熟度，角色分离保证可信，成熟度模型提供演进路线。医院信息科可先从季度桌面推演做起，逐步积累预案修订与实测数据，再向局部切换和全链路实战过渡。每一次演练都应留下可验证的改进项，让下一次演练站在上一次的肩膀上，而不是重复同样的起点。