医院核心网络设备应急演练脚本.docx

医院核心网络设备应急演练脚本一、演练背景与目标：近期，甲地医院管理中心发布关键信息化设备安全隐患排查整改的通知，以优化关键节点设备的备份切换机制、完善应急响应机制，确保设备冗余备份机制在故障发生时能及时发挥作用，确保网络的稳定性和可靠性，保障业务的持续运行。因此，阳光医院于2024年7月14日（星期日）组织并成功实施了一场针对内网、外网及无线网三网核心网络设备的冗余演练。本次演练的主要目标设定为：1、验证核心交换机冗余机制的有效性。2、检验网络运维团队在核心交换机故障时的应急响应能力和处理流程。3、发现并解决潜在的问题，优化网络架构和应急预案。二、演练筹备阶段：为了确保演练的顺利进行，信息部成立应急演练小组，成员包括信息部技术团队、厂家工程师和线上专家。演练小组全面负责演练的策划、组织、协调和评估工作。在筹备过程中，信息部技术团队首先对医院的核心网络架构进行了详细的梳理和分析，明确了关键的网络设备、链路以及可能的故障点。在此基础上，制定了严谨、细致的演练方案，涵盖了演练的场景设计、步骤流程、预期结果以及可能出现的风险和应对措施。为了最大程度地减少演练对正常医疗业务的影响，演练时间特意选择在了医院业务相对较轻松的时间段，并提前向全院各科室发布了演练通知，详细说明了演练的目的、时间、可能造成的影响以及相关注意事项。三、场景设计：本次演练模拟核心交换机硬件故障的场景，检验核心网络设备的冗余能力和应急响应机制。设计场景为：模拟医院主核心交换机出现严重硬件故障，导致无法正常工作；在此情况下，检验备用核心交换机能否自动接管网络通信，以及网络切换过程中的数据丢失情况和业务中断时间。四、演练步骤：（一）无线核心演练：1、2024年7月14日（星期日）上午8点，演练正式拉开帷幕，各参与人员按照预定分工和流程准备应对可能出现的故障。8：19演练前准备：技术人员对核心设备进行信息采集、设备自检、配置保存等操作。2、上午8:30演练开始，按照演练方案，对无线网主核心交换机进行“电源关闭”操作，模拟主核心交换机硬件故障，同步监控设备状态。3、在模拟故障发生后，通过核心交换机的冗余机制，备用核心交换机自动接管网络通信，开始承担起数据传输的重任。同时，网络监控系统产生告警。在8:30-8:45期间，各监控人员根据应急预案流程，密切关注数据传输情况和业务系统运行状态。设备切换期间，网络和业务全部测试正常。4、8:45,按照演练计划对主核心交换机进行“电源开启”操作，模拟集群恢复，同时监控设备状态。5、8:55,集群状态恢复。监控结果显示，集群恢复期间，数据传输情况和业务系统运行状态全部正常。6、9:00,按照演练计划对无线网备核心交换机进行“电源关闭”操作，模拟备核心交换机硬件故障，同步监控设备状态。7、在模拟故障发生后，通过核心交换机的冗余机制，“主”用核心设备自动接管网络通信，开始承担起数据传输的重任。同时，网络监控系统产生告警。在9:00-9:10期间，各监控人员密切关注数据传输情况和业务系统运行状态。切换期间，网络和业务全部测试正常。8、9:20,按照演练计划对备核心进行“电源开启”操作，模拟集群恢复，同步监控设备状态。9、9:30,集群状态恢复。集群恢复期间，监控数据传输情况和业务系统运行状态，监控结果全部正常，无线网核心演练结束。（二）内网核心演练：1、9:15,厂家工程师对内网核心交换机信息信息采集和配置备份。2、9:35,按照演练计划对内网主核心交换机进行“关闭电源”操作，模拟主核心交换机硬件故障，同步监控设备状态。3、在模拟故障发生后，通过核心交换机的冗余机制，备用核心设备自动接管网络通信，开始承担起数据传输的重任。同时，网络监控系统产生告警。在9:35-10:10期间，各监控人员根据应急预案流程，密切关注数据传输情况和业务系统运行状态。切换期间，网络和业务全部测试正常。4、10:10,按照演练计划对主核心交换机进行“电源开启”操作，模拟集群恢复，同步监控设备状态。5、10:29,内网集群恢复，同步监控设备状态和业务状态。6、10:40,对内网备核心交换机进行“关闭电源”操作，模拟备核心交换机硬件故障，同步监控设备状态。7、在模拟故障发生后，通过核心交换机的冗余机制，“主”核心设备自动接管网络通信，开始承担起数据传输的重任。同时，网络监控系统产生告警。在10:40-11:10期间，各监控人员密切关注数据传输情况和业务系统运行状态。切换期间，部分外网映射到内网的业务出现问题，初步判断是切换到主防火墙后导致。8>11:10,按照演练计划对备核心交换机进行“电源开启”操作，模拟集群恢复，同步监控设备状态。9、11:30,将内外网防火墙进行切换，外网映射到内网的业务恢复正常。（三）外网核心演练：1、13:50,对外网核心进行信息采集和配置备份。2、14:00,按照演练计划对外网主核心交换机进行“关闭电源”操作，模拟主核心交换机硬件故障，同步监控设备状态，测试过程发现外网业务中断，后续排查发现是主出口防火墙未切换到备防火墙导致业务中断，手动将主防火墙切换为备防火墙后，业务恢复正常。3、14:15,对主外网核心交换机进行“电源开启”操作，模拟集群恢复。14:15-14:23期间，同步监控设备状态。4、14：23,对备外网核心交换机进行“电源关闭”操作，模拟备核心交换机故障，同步监控设备状态。5、14：23-15:00,监控业务状态并完成结果登记，内网部分外网业务故障复现，抓包排查未发现具体故障原因。6、15:00,按照演练计划对备核心交换机进行“电源开启”操作，模拟集群恢复，同步监控设备状态。7、15:12,监控业务状态并完成结果登记，外网业务正常，但外网集群无法恢复。15:12,联系华为线上保障工程师协助排查问题。8、15:30,华为工程师联系研发进一步排查故障原因。15:31,华为400来电，准备远程环境，排查问题。9、19:38,故障处理完成。故障原因是备核心9槽位主控板故障，导致其他板卡无法注册，从而设备无法使用。拔出故障板卡后，设备正常启用，集群恢复正常。故障处理期间，同步对设备进行软件版本升级。五、演练结果:（一）无线核心应急演练：1、主备核心交换机切换期间，双方都能正常自动接管对方工作，网络通信未出现中断，切换时间在预期范围内。2、关键业务系统在切换过程中能够保持正常运行，未出现服务中断的情况。3、网络监控系统能够反映网络拓扑及链路变化，为故障诊断和处理提供了有力支持；设备集群状态监控存在问题，需要厂家工程师处理。4、无线核心演练结果符合预期。（二）内网核心应急演练：1、主备核心交换机切换期间，双方都能正常自动接管对方工作，网络通信未出现中断，切换时间在预期范围内。2、HlS关键业务系统在切换过程中能够保持正常运行，未出现服务中断的情况。3、部分外网映射到内网的业务存在问题，初步判断原因是内外网防火墙问题，已联系维保公司协助排查。4、网络监控系统能够反映网络拓扑及链路变化，为故障诊断和处理提供了有力支持；设备集群状态监控存在问题，需要厂家工程师处理。5、内网核心演练结果基本符合预期。（三）外网核心应急演练:1、主核心交换机故障后，备核心交换机能够迅速自动接管工作，切换时间在预期范围内。2、由于主核心交换机和主出口防火墙之间存在上网行为设备，当主核心交换机关机后，主防火墙与上网行为之间的链路物理状态未发生变化，导致主防火墙未检测到链路异常，从而未发生切换。虽然备核心交换机接管了业务，由于出口防火墙未切换，导致无法访问互联网业务。3、备核心交换机在断电恢复期间出现故障，导致集群未正常恢复，通过排查是备核心9槽位主控板故障导致核心无法正常启动；拔出该故障板后，设备正常启动，集群恢复正常。4、备核心交换机在断电恢复期间，部分外网映射到内网的业务再次出现，原因同上。5、网络监控系统能够反映网络拓扑及链路变化，为故障诊断和处理提供了有力支持；设备集群状态监控存在问题，需要厂家工程师处理。6、外网核心演练结果偏离预期，存在多个问题，需要进一步整改。六、问题与改进措施：（一）外网备核心板卡故障：1、故障现象：备外网核心交换机加电后，设备未正常启动，集群无法恢复。2、故障原因：通过排查，是备核心9槽位主控板故障导致核心无法正常启动，拔出该故障板后设备正常启动，集群恢复正常。3、解决办法：演练前已建立了线上厂家保障群，发现问题后第一时间联系线上专家协助排查该问题，最终发现故障原因并及时完成故障处理；后续查询设备还在维保期，已联系备件发货和更换，于7月17日下午完成板卡更换，集群状态恢复正常。（二）内外网防火墙故障：1、故障现象：业务切换后，部分内电脑无法访问内网OA地址和工会系统，部分外网映射到内网的业务受到影响。2、故障原因：主备防火墙会话同步异常，导致会话无法完全同步，部分业务受到影响。3、解决办法：工程师到现场进行测试故障复现，经过现场分析是防火墙OA系统MAC地址学习存在异常，同时联系设备厂家研发人员，共同排查问题，最终排查结果是主备防火墙会话同步异常，导致会话无法完全同步。配置快速同步命令后，问题解决，该问题已于7月22日完成整改。（三）VPN、官网WAF直连交换机存在单链路问题：1、故障现象：主外网核心交换机关机后，VPN、官网业务无法使用。2、故障原因：由于VPN设备只有一条链路连接到主核心交换机，主核心交换机关机后，VPN业务无法使用；两台WAF上链到一台接入交换机上，该接入交换机只有一条链路接入到核心交换机，存在单链路故障隐患。3、解决办法：将WAF直接连的交换机增加一条上联链路，并且将上联设备调整为汇聚设备，不与核心直连，然后将VPN上链到该交换机上，从而解决该问题。该问题已于8月9日完成整改。（四）外网出口防火墙故障：1、故障现象：主外网核心交换机关机、业务切换到备外网核心后，外网业务中断，无法访问互联网。2、故障原因：由于主核心交换机和主出口防火墙之间存在上网行为设备，当主核心交换机关机后，主防火墙与上网行为之间的链路物理状态未发生变化，导致主防火墙未检测到链路异常，从而未发生切换。虽然备核心交换机接管了业务，由于出口防火墙未切换，导致无法访问互联网业务。3、解决办法：将上网行为连接防火墙和核心交换的两个网口配置联动策略，实现任意一端口物理状态变更后另一个端口同步变更状态，从而实现防火墙的切换。7月16日，完成整改，联动测试结果正常。（五）监控平台故障：1、故障现象：集群切换期间，监控拓扑图上未显示集群故障。2、故障原因：IRF成员的工作状态为“其他”，判断逻辑由于断电或供电后状态无变化，导致未产生告警；CCS设备断电后状态为“-"，没有相对应的无值逻辑，导致未产生告警。3、解决办法：已沟通厂家各方研发人员，商讨解决当前问题，于7月16日完成监控策略优化。（六）流程和沟通：1、时间规划不足：本次测试3个核心网络设备，每部分规划时间为1小时。实际演练过程中，由于测试和设备启动时间较长（无线核心交换机加电到集群恢复需要大约15分钟、内网核心交换机加电到集群恢复需要大约20分钟）和其他故障，规划的演练时间不足。如本次内网和外网演练存在部分问题，导致演练时间拉长。2、人员规划问题：（1）本次演练未在临床科室安排信息部内部测试人员，需要临床科室人员配合测试。门诊楼周末值班人员少，用在电话沟通联系上的时间较多，耽误了测试进程。（2）临床科室人员对相关IT专业知识掌握不多，不能准确给出测试结果，甚至给出了错误的测试结果，对测试进程造成影响。（3）由于测试次数较多，临床科室的配合度较低。（七）改进措施：1、增加各个阶段的测试时长。2