医疗信息平台-灾备系统设计方案

1、医疗信息平台灾备系统设计方案 目 录 TOC o 1-3 h z u HYPERLINK l _Toc38734826 1、 总体设计方案 总体设计方案总体设计原则建设原则医疗保障信息平台建设项目应明确目标，找准方向，把握重点，规范有序开展工作。在项目建设过程中，要着重把握好以下建设原则：（一）统筹规划，分步推进为避免信息孤岛、重复建设等现象，医疗保障信息平台建设需进行“自上而下”的顶层规划设计，进行合理有序布局；通过“统一领导、统一规划、统一部署、统一标准”的统筹指导建设，集约管理，节约投资。同时，遵循“自下而上”的项目操作原则，立足现行管理体制与制度建设，打好基础，确立方向，稳步推进，均衡

2、发展，实现项目落地，并为下一步制度完善、管理提升留有空间。（二）需求导向、务求实效以医保各部门间信息共享与业务协同作为原始需求驱动，进行医保基础平台的规划建设。再以此为基础，逐步拓展数据资源与数据资源服务能力，进一步进行医保大数据分析挖掘等高级应用，完善与丰富贴近实战的大数据应用服务，从而形成良性循环，并尽快体现出阶段性效果。（三）统一协同，资源共享统一管理、统一规划，就必须有一套统一的标准规范作为基础支撑。标准与规范应向上符合国家的标准与规范，向下规范医保行业业务范围内大数据建设与应用。遵循统一的标准，各相关职能部门根据权限的不同，共享信息资源。同时，各级医保管理部门共同参与，既能保障数据同

3、步，也有利于实现信息共享和协同工作，实现资源的集约化管理。（四）整合共享，协作高效突破区域、部门之间的界限和体制性障碍，充分整合基础设施资源和智能终端获取的信息资源，通过医疗保障信息平台建设推进跨部门、跨领域的信息化协同共享，增强医疗保障的效率和决策能力，同时有效满足公众信息需求，提升医保资源的利用效率。（五）统一标准，开放接口通过明确和开放医疗信息平台的接口与标准，为后期其他相关行业的数据接入提供标准接口，最大限度地实现医保与政府、职能部门、医院、企业、百姓的信息对接。建设策略医疗保障信息平台应结合各级医疗保障部门职能划分、业务重构，发挥中央统筹管理效能，并为地方立足实践拓展服务功能留有空间

4、；最终以“弱干预经办、强共享协同”的策略，实现“搭平台、强标准、重应用、严考核”的效果。主要坚持以下建设策略：（1）坚持集约化建设。按照国家电子政务构建“大平台、大系统、大服务”的要求，在国家医疗保障局职责框架内，以打破信息系统碎片化，实现数据共享、业务协同、资源整合、能力聚合、服务开放为出发点，如基础信息管理系统、医保业务基础系统、药品和医用耗材招采管理系统、跨省异地就医管理系统、宏观决策大数据应用系统、基金运行及审计监管系统、医疗保障智能监管系统、信用评价管理系统等，由国家医疗保障局统一建设。软件开发由国家局统一组织，并为地方立足实际拓展功能留有空间，硬件购置则由国家局和地方局分级安排。（

5、2）坚持标准化建设。在国家医疗保障局职责框架内，建设基础性、基准性、全国性业务系统，支撑国家医保业务标准化制定与有效执行。如基础信息管理系统、医保业务基础系统、医疗服务价格管理系统、公共服务系统等。建设目标与内容建设目标国家医疗保障局以习近平新时代中国特色社会主义思想为指导，按照党中央、国务院的决策部署，面向医疗保障的重点领域和关键环节，持续推进全国医疗保障标准化、智能化和信息化。本项目重点加强顶层设计、统一业务标准、打造基础平台、做好数据汇集、强化协同共享，依托国家基础信息资源，国家统一电子政务网络及数据交换平台，建设全国统一的国家医疗保障信息平台，不断提高国家医保治理能力和服务水平，支撑消

6、解新常态下我国医疗保障领域重点、难点、热点问题，为国家医疗保障局构建更加公平、更加可持续的医疗保障体系，全面实施医疗保障精准扶贫，积极推进医保与医疗、医药“三医联动”，助力提高医改整体效能和实施健康中国战略提供信息化支撑。针对医疗保障全民覆盖、需求刚性、主体多元、业务复杂、发展不均衡及在线化服务要求高、专业化治理难度大等特点，国家医疗保障信息平台将致力于消除医疗保障信息化领域数据鸿沟、信息孤岛、技术壁垒、应用烟囱、部门藩篱等信息系统碎片化问题，注重顶层设计、标准引领、数据汇聚、资源整合、服务融合、平台建设及能力输出。医疗保障信息平台建成后将全面提高医疗保障标准化、智能化、信息化水平，有效支撑国

7、家医疗保障局与地方医保部门规范、高效、科学履职，使信息化能在待遇保障、医药服务管理、医药价格和招标采购、基金监管、公共服务等方面发挥积极作用，促进建成更加公平、更加可持续的医疗保障体系，更好满足人民群众日益增长的医疗保障需求，增强人民群众的获得感。为逐步构建起全国医保便捷可及“大服务”、规范高效“大经办”、智能精准“大治理”、融合共享“大协作”、在线可用“大数据”、安全可靠“大支撑”信息化支撑体系，到2020年，通过本项目建设，拟实现以下具体目标：（1）建设国家医保基础信息库和基础信息管理系统，支撑对全国医疗保障服务对象、医药机构、医保三目及支付标准、重点医疗服务资源等信息实施统一信息管理。全

8、国医疗保障基础信息库覆盖全国95%医疗保障服务对象，覆盖100%建档立卡贫困人口、特困人口。确保全国医疗保障基础信息完整、准确、鲜活、可用，夯实医疗保障信息化全国统建和全域联动基础，支撑推进全国医疗保障跨区域、跨层级、跨业务、跨部门、跨系统的信息共享和业务协同。（2）建设国家医保业务基础系统，采用“弱化干预经办、强化共享协同”的策略，采集全国各地医保部门经办管理与经办服务信息，数据采集周期从1月缩短到1周，关键数据采集时限从1月缩短到1天，确保采集信息完整、准确、规范、可用，为规范指导全国各地医保部门的业务工作提供可靠信息化支撑环境，促进全国医保业务标准化、一体化及全域通办。（3）建设国家医保

9、医疗服务价格管理、支付方式管理系统，支撑实现对医疗服务价格、医保支付方式的全国统一信息管理，掌握全国32个省级医保部门的支付方式改革工作信息，支持对全国90%以上药品价格信息实施采集、监测及信息发布。（4）建设国家医保信用评价管理系统，建立依托全国医保大数据的医保信用评价与信息披露机制，支撑国家医疗保障局掌握全国90%以上公立医院医保信用信息，支撑国家医疗保障局规范指导全国各地医保部门对90%以上定点医药机构实施信用监管和分级服务。（5）建设国家医保药品和医用耗材招采管理系统，为国家医疗保障局提供国家级药品和医用耗材招标采购应用支持，对全国32个省级医保部门的药品和医用耗材招标采购实施统一信息

10、监测，支撑国家医疗保障局规范指导全国各地医保部门的药品和医用耗材招标采购工作。（6）建设国家医保公共服务系统，建立面向全国的医保公共服务统一入口，支撑构建面向全国的医保公共服务数据资源池、服务枢纽站、信息发布台。为跨省医保信息查询、资讯发布、证照流转、资格核验、异地就医服务备案等提供应用支持，支撑国家医疗保障局依法政务公开事项（法律法规、政策文件、办事指南等）网上公开率达100%。支撑国家医疗保障局规范指导全国32个省级、近400个市级医保部门按照国家医疗保障局业务标准开展公共服务体系构建。（7）升级改造跨省异地就医管理系统，支持将更多的基层医疗服务机构纳入跨省异地就医服务定点范围，支撑为外出

11、农民工和外来就业创业人员提供跨省异地就医直接结算服务，为门诊、门慢跨省异地就医直接结算提供可靠的信息化支撑环境，跨省异地就医直接结算率大幅度提升，全国100%三级以上定点医院接入该平台，确保100%全国医保经办机构、定点医疗机构、就医结算信息及备案情况网上可查询。（8）建设国家医保智能监管系统，支撑国家医疗保障局依托全国医保大数据开展医保智能监管工作。指导全国32个省级医保部门规范采集定点医疗机构的进销存、病案首页、电子病历及医保结算、费用明细信息，构建智能化医保监控能力体系。支撑建立全国范围内医保稽核管理机制，为国家医疗保障局与全国各地医保部门之间的疑点问题发现、重大问题督办、全域联动监管提

12、供大数据监控支撑环境。支撑建立与国家卫健委的医药机构及从业人员资格甄别机制，掌握全国90%以上执业医师、执业药师信息。（9）建设国家医保基金运行及审计监管系统，为国家医疗保障局提供医保基金监管和审计监管应用支持，对全国90%以上医保基金运行信息实施基金运行及审计监管。支撑国家医疗保障局规范指导全国32个省级医保部门开展标准化基金运行和审计监管工作。（10）建设国家医疗保障局医保运行监测系统、宏观决策大数据应用系统，支持国家医疗保障局从宏观、中观、微观三个层面，动态化掌握全国医疗保障制度运行情况，包括全国医疗保障目标达成、政策执行、资源配置、基金收支、待遇保障、医药服务管理、医药价格及招标采购、

13、公共服务等方面，初步形成支撑国家医疗保障局宏观决策分析大数据能力体系，包括评价、风控、测算、精算、预测、预警、模拟等方面。支持国家医疗保障局对全国90%以上地区医保制度运行情况实行动态监测，向全国90%以上省级医保部门输出开展宏观决策分析工作的大数据能力。（11）建设内部控制系统，支撑构建国家医疗保障局廉政风险防控体系，实现面向国家医疗保障局全业务、全岗位、全人员业务风险防控。（12）建设内部统一门户系统，为国家医疗保障局工作人员提供信息系统的统一登录入口、内部工作台和邮件服务，便于国家医疗保障局工作人员便捷、畅达开展日常工作。（13）建立国家医疗保障局与国家发展和改革委员会、财政部、公安部、

14、国家卫生健康委员会、人社部、教育部、民政部、国家市场监督管理总局、国家税务总局、国务院扶贫开发领导小组办公室、中国残疾人联合会等政府部门的信息共享与业务协同机制，共享交换国家人口库、国家法人库、经济社会发展宏观指标、医药服务资源、医保税务征收、扶贫工作、残疾人保障等数据。对应建立面向全国的医保服务对象身份、业务状态、待遇享受资格核查比对机制，支持实现医疗保障全民覆盖、应保尽保，同时有效控制基本医保的重复参保、重复享受待遇问题。（14）建立支持国家级层面的医保与医疗、医药“三医联动”数据共享、信息聚合、资源调度、业务协同信息支撑环境。支撑国家医疗保障局规范指导全国32个省级医保部门开展“三医联动

15、”信息化支撑环境建设。（15）建设国家医保信息平台信息基础设施和业务支撑云平台，基本形成国家医保信息平台基础支撑能力，包括计算、网络、存储、备份、安全、标准、运维、灾备及应用支撑。实现医疗保障交互类业务平均响应时间1，查询类业务平均响应时间2，交易接口类单条记录交易接口平均响应时间1，多条记录（100条）交易接口平均响应时间3，为全国医疗保障信息化数据共享、业务协同、资源整合、渠道融合、能力聚合、服务开放提供安全可靠的技术保障环境。建设内容本项目建设依托于国家医疗保障局政务目标，通过搭建基础平台及相关应用系统，统一采集全国32个省级医保局的经办业务数据，构建医保信息化的基础。同时，完成相关技术

16、、业务标准规范的建设，满足系统全生命周期内的标准规范要求。本次医疗保障信息平台建设工程分为以下几个方面建设内容：（1）标准规范建设建设国家医保标准化体系，建设包括应用建设标准、应用支撑平台标准、外部数据交换标准、网络标准、安全标准、项目管理标准、医保业务类标准、定点医药机构及人员标准、医疗保险机构及经办人员标准、电子病历类标准、设施管理规范、运维管理规范共13个标准，为医保业务互连互通、信息共享、业务协同提供坚实的基础。（2）技术支撑平台建设建设完整的支撑体系框架，基于通用服务组件提高系统互连互通互操作和信息共享的能力，为本项目进行系统开发、集成、部署、运行提供一体化的技术支撑体系。（3）应用

17、系统建设依托国家医疗保障局政务目标、业务目标及业务需求升级改造1个跨省异地就医管理系统，新建内部统一门户系统、基础信息管理系统、医保业务基础系统、药品和医用耗材招采管理系统、医疗服务价格管理系统、支付方式管理系统、信用评价管理系统、基金运行及审计监管系统、医疗保障智能监管系统、内部控制系统、运行监测系统、宏观决策大数据应用系统、公共服务系统共13个应用系统。（4）基础设施建设基于云计算、大数据技术以租代建方式建设国家医疗保障局数据中心，通过租用数据中心服务商物理机柜的方式进行软硬件部署，实现业务系统应用级容灾；建设监控中心，作为医保局信息化系统日常统一监控和运维场所。硬件方面新增X86服务器、

18、阵列、虚拟带库、网络设备、安全设备等，系统软件方面主要新增数据库、中间件、操作系统等。（5）运维安全体系建设搭建运维管理体系，建设云管理平台、运维监控平台实现对云资源的运营和所有IT资源的运维监控，针对运维组织、运维管理制度以及运维考核指标制定管理体系；基于国家网络安全法和等级保护第三级的网络安全保护要求，夯实网络安全基础防护工作，形成整体的网络安全管理、技术和运营体系。项目建设方案灾备系统设计容灾备份需求容灾建设必要性随着业务的飞速发展单位时间内的业务量、相关的资金密度不断提高，因此，业务的间断直接意味着经济上的损失，随着IT系统建设的不断发展，政府单位在享受IT支撑系统带来的高效率、高服务

19、的优势的同时，其业务运作也更加依赖于IT系统的稳定运行，一旦IT系统停止运行，那么关键业务系统将受到严重影响，用户信息、医保记录等也随之丢失。因此，小至一般性的硬件故障，大到区域性的自然灾害，从物理的设备不可用到逻辑的人为失误和破坏都可能造成整个信息系统的全面瘫痪，导致业务运营的停顿。灾难的定义也从过去的大面积自然灾害，转变为可造成IT系统应用不可用，产生的任何故障和灾害。如何才能保证尽量减少企业数据的丢失、将危险与灾难的损失降低到最小程度呢？这就需要建立容灾系统。容灾系统的核心就在于使用各种技术和管理手段将灾难化解，在实践中主要表现为两个方面：一是保证政府单位数据的安全；二是保证业务的连续性

20、。在生产中心和容灾中心需运行同样的系统（包括操作系统、基础数据库和应用软件），同时实现数据复制。假如生产中心发生灾难，不能再继续工作，容灾中心会将业务数据及时恢复到备用服务器上，并自动将业务切换到备用服务器，然后实现业务的远程切换，恢复系统不间断的运行，这个过程只需要很短的时间；在此基础上，在灾难过后，再将业务系统切换回正常的生产系统，实现业务的灾难恢复。因此，业务连续性和容灾建设的总体目标是为关键业务系统提供风险预防机制和灾难恢复措施，在确保数据安全的基础上提高业务连续运行能力，降低政府单位生产运营风险，将业务损失降低到可接受的程度，提升管理和服务质量。容灾类型选择容灾指在不同机房建立一套完

21、整的与本地生产系统相当的备份应用及数据系统，出现机房级别的系统故障时，可以在规定时间内完成整体容灾切换，前台业务系统基本不受影响。容灾主要针对数据和应用两大类，根据提供基本的数据保护和提供不间断的应用服务来区分，一般情况下容灾体系可以分成数据级容灾、应用级容灾和业务级容灾三个级别。（1）数据级容灾数据级容灾是指通过建立一个异地数据系统作为本地数据的远程备份，能够保证业务数据的完整性、可靠性和最终一致性。数据级容灾的关注点在于数据本身，当本地由于意外导致系统停止工作时，确保原有的数据不会丢失或者遭到破坏，不过，在数据级容灾级别上，当本地发生灾难时，因相应的信息系统自身没有备份，用户的服务请求在灾

22、难中可能会中断，单纯的数据容灾无法保证业务持续性。在数据级容灾方式下，所建立的容灾中心可以简单地理解成一个远程的数据备份中心。数据级容灾的恢复时间比较长，但是其建设费用比较低，而且构建实施和运行维护也相对简单。（2）应用级容灾应用级容灾是在数据级容灾基础上的升级，通过在备份站点构建一套相同或缩小比例的应用系统，在本地系统由于意外而停止工作时，可以及时启用备用应用系统，保证关键应用在允许的时间范围内恢复运行，尽可能的减少因灾难带来的损失。应用级容灾一般在生产中心和容灾中心之间采用同步或异步的数据传输，但容灾中心也需要具有和生产中心类似的外部广域网资源，应用级容灾涉及到需要通过更多的软硬件来实现，

23、可以使多种应用在灾难发生时可以进行快速切换，确保业务的连续性。（3）业务级容灾业务级容灾是在数据级容灾和应用级容灾基础之上的一个更高级别的容灾，是应用级容灾的最高标准，生产中心和容灾中心对业务请求可以同时提供服务，在某一方灾难发生时，另一方可以保证所有的业务都是正常运行并可访问的，对于用户来讲是感受不到灾难影响，因此既能实现业务服务冗余分担，又能够确保业务持续可用。实现业务级容灾，不仅需要确保两地数据一致，还需要在数据管理层面、应用程序层面、访问通道层面都能够平滑切换，数据中心之间的距离也有较大限制，甚至主备中心最好具备对称的基础设施，以便一旦原有的办公场所遭到破坏，在备份场所也能正常的开展业

24、务。为保障在云上运行的各类业务系统的连续性和数据的高可靠性和可用性，本项目需要为国家医疗保障局建立一个同城的容灾中心，采用应用级容灾模式。容灾级别定级国家标准信息系统灾难恢复规范（GB/T20988-2007）规定了六个级别的容灾，下表分别针对每个级别的内容要求给出了相应的应对措施。容灾级别分类表 表 STYLEREF 2 s 2.1 SEQ 表 * ARABIC s 2 1级别内容措施Level 6数据零丢失和远程集群支持实现远程数据实时备份，实现零丢失；应用软件可以实现无缝切换；远程集群系统的实时监控和自动切换能力。Level 5实时数据传输及完整设备支持实现远程数据复制技术；备用网络也具

25、备自动或集中切换能力。Level 4电子传输及完整设备支持配置所需要的全部数据和通讯线路及网络设备，并处于就绪状态；7*24运行；更高的技术支持和运维管理。Level 3电子传输和部分设备支持配置部分数据通信线路和网络设备；每天实现多次的数据电子传输；备用场地配置专职的运行管理人员。Level 2备用场地支持预定时间调配数据通信线路和网络设备；备用场地管理制度；设备及网络紧急供货协议Level 1基本支持每周至少做一次完全数据备份；制定介质存取/验证和转储的管理制度；完整测试和演练的灾难恢复计划。遵循科学先进、实用高效、安全可靠、节能环保的设计理念，按照国家关于灾备系统能力的6级标准，结合国家

26、医疗保障局的实际情况，数据和应用恢复整体满足信息系统灾难恢复规范（GB/T20988-2007）的第5级要求。如果数据中心出现重大灾难性损失，可以达到信息系统数据基本不丢失。同时容灾中心建设在充分考虑可扩展性的条件下，与主数据中心设计能力相匹配，在主数据中心暂停服务期间，容灾中心能够提供基本的应用系统服务和数据查询工作。在信息系统灾难恢复方面，目前业界公认最关键的衡量指标为RTO和RPO。RPO（Recovery Point Objectiv）是指灾难发生后，容灾系统能把数据恢复到灾难发生前时间点的数据，它是衡量企业在灾难发生后会丢失多少生产数据的指标。RPO可简单的理解为能容忍的最大数据丢失

27、量。RTO（Recovery Time Objectiv）则是指灾难发生后，从系统宕机导致业务停顿之刻开始，到系统恢复至可以支持业务运作，业务恢复运营之时，此两点之间的时间。RTO可简单的理解为能容忍的业务中断时间。两者的含义如下图所示：图 STYLEREF 2 s 2.1 SEQ 图 * ARABIC s 2 1 RTO与RPO对比图RPO是反映恢复数据完整性的指标，它与主备数据中心间的数据同步方式有关。在半同步数据复制方式下，RPO等于数据传输延时的时间；在异步数据复制方式下，RPO为异步传输数据排队及传输延时的时间。在实际应用中，同步模式下，RPO一般可以认为是0，而在非同步模式下，考虑

28、到数据传输因素，业务数据库与容灾备份数据库的一致性是不相同的，RPO主要体现业务数据与灾备数据的时间差。换句话说，发生灾难后，启动容灾系统完成数据恢复，RPO就是新恢复业务系统的数据损失量。RTO是反映业务恢复及时性的指标，其值越小，代表容灾系统的业务恢复能力越强。不同的容灾等级和解决方案的RTO有较大差别，比如业务级容灾的RTO值远小于应用级容灾的RTO值，基于光通道技术的同步数据复制必然比基于普通磁带备份的RTO小。国家医疗保障局医疗保障信息平台各业务系统灾备能力定级如下：主要业务系统灾备能力定级表 表 STYLEREF 2 s 2.1 SEQ 表 * ARABIC s 2 2序号信息系统

29、名称最大数据丢失量（RPO）业务中断时间（RTO）容灾模式1跨省异地就医管理系统3分钟30分钟应用级容灾2药品和医用耗材招采管理系统3分钟30分钟应用级容灾3公共服务系统3分钟30分钟应用级容灾4基础信息管理系统10分钟2天以上 数据级容灾5医保业务基础系统10分钟2天以上 数据级容灾6内部统一门户系统10分钟2天以上 数据级容灾7运行监测系统10分钟2天以上 数据级容灾8内部控制系统10分钟2天以上数据级容灾9医疗服务价格管理系统10分钟2天以上数据级容灾10支付方式管理系统10分钟2天以上数据级容灾11信用评价管理系统10分钟2天以上数据级容灾12基金运行及审计监管系统10分钟2天以上数据

30、级容灾13医疗保障智能监管系统10分钟2天以上数据级容灾14宏观决策大数据应用系统无鉴于宏观决策大数据应用系统依赖的大数据平台只在一个数据中心建立，因此宏观决策大数据应用系统只考虑本地高可用。备份需求医保业务系统会产生大量的多样化的数据，对于业务系统而言数据就是根本，任何操作、分析、结算等都从数据库中提取。医保业务系统在面对人为操作失误、病毒木马侵袭和黑客攻击、设备硬件故障、系统故障、管理疏忽、自然灾害等意外事件时，极易造成数据丢失。另外当操作系统发生重大故障发生时，需要先重新安装操作系统、重装所有应用程序，然后才能恢复数据，耗费相当长的时间才能够重新恢复应用。为保证数据系统的安全，确保在应急

31、情况下的紧急处理，必须对业务数据库及操作系统制定备份和恢复机制。各数据中心的数据在本地备份，在系统数据出现问题的时候，通过数据恢复系统，对损坏的数据进行恢复。 容灾建设方案建设目标为有效地应对灾难事件对医疗保障信息平台的冲击，确保各应用系统的高可用性，在项目建设的同时，同步考虑了建设相应的灾备体系，使其具备抵御大规模区域性灾难的能力，本项目将实现10个系统的数据级容灾（宏观决策大数据应用系统考虑本地高可用），通过异地数据复制技术，将数据中心A数据远程复制到数据中心B，数据级容灾的数据恢复点目标RPO10分钟时，同时实现3个系统的应用级容灾，保证灾难时应用和数据可用，应用级容灾的数据恢复点目标R

32、PO3分钟。建设原则利用专门建设的信息传输链路实现灾备数据传输，应统一标准、明确管理界面，建设一套可兼容多种异构平台的容灾系统。在系统设计上应遵循国家相关技术规范和标准，从多方面考虑整个系统安全性，提供相应的安全防范措施。具体要求如下：第一，考虑容灾系统建设对原有业务系统带来的影响。比如，采用数据复制技术对系统I/O带来的延迟，应用数据同步对日常业务处理系统带来的压力等。因此需通过周密的测试和分析来规避容灾系统建设时带来的这些风险，以保证业务系统不会因容灾系统的建设而出现在处理性能上下降的问题。第二，数据状态要保持同步。为保证在灾难发生时，业务可以成功地切换到容灾中心，就必须保证容灾系统数据同

33、步机制的可靠性。因此，建立可靠的数据同步校验机制是必须的；同时需考虑建立定时的、自动的数据同步核查对比机制，以检验两个中心数据的一致性。第三，容灾系统的日常维护工作要尽可能轻，并能承担部分业务处理和测试的工作。容灾系统的维护和管理是容灾切换成功的重要保证，在系统建设中，就必须要考虑系统的维护管理流程。生产中心任何业务处理过程的改变都必须完整地复制到容灾中心；所有新业务系统上线时，必须通知容灾中心，并在容灾中心配置好数据同步机制；对原程序的改动也必须保证两个中心同时上线。第四，系统恢复时间要尽可能短。容灾系统主要是为了实现在主中心系统发生灾难时，可以在规定时间切换到容灾中心，保证数据不会丢失，并

34、且继续向用户提供服务。但往往在灾难发生时，主要技术人员不能及时到达现场，为了顺利实现系统间的切换，应该让系统切换操作尽可能地简单；并建立固定化的、标准化的切换流程，要求维护人员在切换演习时严格按照流程的指导步骤进行操作。第五，可实现部分业务系统的切换和回切。当人事变动、业务变化、IT设施变化以及其他可能引起恢复规划文档失效的变化发生时，应及时更新各恢复规划文档，并在必要时启动模拟测试或演习，确保系统的业务连续性。建设思路同城建设两个数据中心（数据中心A为生产端，数据中心B为容灾端），考虑到全国32个省级机构的医保工作人员、参保人员以及各类相关机构人员对医疗保障信息平台的大规模接入访问，为降低接

35、入压力，本项目将基于全局负载均衡技术实现两个数据中心业务的负荷分担，业务划分维度可以基于地域，同时兼顾考虑各省级的业务量。底层数据基于数据远程复制技术实现数据容灾，在此基础上，针对基础信息管理系统、跨省异地就医管理系统、医保业务基础系统、内部统一门户系统、公共服务系统、药品和医用耗材招采管理系统共六个系统在两个数据中心各构建一套相同的备用应用系统，在本地系统由于意外而停止工作时，可以及时启用备用应用系统，保证关键应用在允许的时间范围内恢复运行，尽可能的减少因灾难带来的损失。容灾系统设计容灾系统是指在数据中心B部署的用于支撑业务运行的备用计算机、外围设备和软件，是实现容灾的前提条件。容灾系统总体

36、部署架构示意图如下：图 STYLEREF 2 s 2.1 SEQ 图 * ARABIC s 2 2 容灾系统设计示意图每个数据中心划分公共服务区与核心业务区，公共服务区与核心业务区之间通过安全设备隔离，所有网络与主机设备完全独立。（一）服务器部署设计从运维管理角度数据中心B的服务器品牌和架构应与数据中心A相同，保证系统平台的兼容性同时具备可扩展性；容灾服务器上使用的操作系统应与生产系统完全一致，保证应用在数据中心B可以正常使用。在应用前端部署负载均衡产品，相同应用部署在至少两台不同数据中心的服务器或虚拟机，或者是使用弹性伸缩技术，根据自定义服务器或虚拟机自身资源的使用规则来进行弹性扩容。这样即

37、便其中一个数据中心的服务器宕机，请求会被另一个数据中心的服务器接管，不会使医保的服务对外终止。（二）存储部署设计鉴于数据中心采用集中式和分布式两种存储方式，对于存储部署设计如下：1、集中式存储主要基于磁盘阵列自身的底层数据复制技术。执行方为磁盘阵列，复制的粒度为存储系统接受到来自服务器的IO更新操作，复制涉及的范围为存放在磁盘阵列中的所有信息，包括应用程序、数据库、文件系统、数据卷等。2、分布式存储主要指部分系统基于本地盘做数据库存储，采用基于数据库的远程复制技术。执行方为数据库管理系统的辅助程序，复制的粒度是数据库内数据操纵动作（Data Manipulation Operation），复制

38、涉及的范围为单个数据库。数据库管理系统在执行数据操纵动作过程中，将需要整体完成的动作集合作为交易来管理；利用联机日志（Online Logs）记录交易的执行情况，利用归档日志（Archive Logs）定期将联机日志进行一定期限的保留。其同步方式为同时传输归档日志和联机日志，保持容灾中心和生产中心的数据库中已提交的交易的执行的一致性；其异步方式为只传输归档日志。（三）应用系统部署设计应用软件需要与生产系统完全一致，以保证灾难发生后业务能够在数据中心B顺利运行，包括数据库、中间件等软件版本和部署方式的一致性。容灾资源配置根据容灾建设思路和需求以及5.11.1.3容灾级别说明，基础信息管理系统、跨

39、省异地就医管理系统、药品和医用耗材招采管理系统、公共服务系统数、医保业务基础系统、内部统一门户系统等六个系统应具备应用级容灾能力，其余系统（除宏观决策大数据应用系统）应具备数据级容灾能力，数据中心B部署应包含所需的数据存储设备及进行恢复所需的主机资源。（一）数据库/应用服务器估算（1）应用级容灾对于应用级容灾的系统，设备配置、数量与数据中心A相同，根据5.6.1.3节测算具体如下：系统名称数据库服务器数量（台）应用服务器数量（台）部署区域跨省异地就医管理系统24核心业务区公共服务系统427公共服务区药品和医用耗材招采管理系统23公共服务区合计834（2）数据级容灾对于数据级容灾的系统，在进行计

40、算资源测算时，参照生产中心主机能力，数据库服务器按照一定比例（参考类似项目经验，X86服务器按照80%）估算，因此，根据5.6.1.3节测算，9个数据级容灾的系统数据库服务器配置18台，数据中心B需要配置14台。其中医保业务基础系统在局本级不做业务经办，无需配置数据库和应用服务器，省里根据局本级发布的医保业务基础系统软件进行本地化实施，省级产生的数据需要采集到局本级中央集中库，以检查省级对局本级系统规范的执行情况，因此按照每个省配置1台X86服务器用于省级医保数据采集，总计需配置32台采集服务器。（二）中间件服务器估算中间件服务器为应用系统运行提供基础的分布式缓存、分布式消息、中间件共享等服务

41、，设备配置、数量与数据中心A相同。数据中心B中间件服务器配置统计表 表 STYLEREF 2 s 2.1 SEQ 表 * ARABIC s 2 3服务器名称核心业务区（台）公共服务区（台）分布式缓存服务器44流计算服务器100分布式日志服务器44分布式消息服务器44分布式数据库服务器33全局事务管理服务器00中间件共享服务器44合计2919（三）其他服务器估算（1）云管理服务器云管理服务器负责承载所有云产品的管理虚拟机，并负责整个云平台设备的性能指标采集，所以台数与云产品数量和服务器规模相关。核心业务区需要28台服务器，包括3台服务器做性能指标采集，23台服务器承载管理虚拟机，2台服务器存储云

42、平台管理数据。公共服务区需要18台服务器，包括2台服务器做性能指标采集，14台服务器承载管理虚拟机，2台服务器存储云平台管理数据。（2）负载均衡服务器用于各安全区（核心业务区和公共服务区）内服务器间的负载均衡，每个区域配置6台。（3）安全服务器主要用于安全软件的部署，包括应用可视化审计系统、虚拟化运维系统等，核心业务区和公共服务区各配置12台。（4）SDN服务器部署SDN控制器软件作为SDN控制，基于OpenFlow协议实现对网络功能的自定义和部署。参考业界经验，核心业务区和公共服务区各配置4台。综上所述，其他服务器统计如下：数据中心B其他服务器配置统计表 表 STYLEREF 2 s 2.1

43、 SEQ 表 * ARABIC s 2 4服务器名称核心业务区（台）公共服务区（台）云管理服务器2618负载均衡服务器66安全服务器1212SDN服务器44合计4840（四）存储资源估算本项目将针对各应用系统数据进行总容量1:1的容灾。1、集中式存储：参考5.6.1.5配置，存储裸容量需求为12TB2、分布式存储：按照2副本考虑。根据表5.6-7需要存储的数据如下：（1）核心业务区类型有效容量（TB）数据结构中央集中库887 结构化日志数据375 结构化非结构化业务数据(药材和医用耗材招采管理系统、基础信息管理系统)485 非结构化结构化业务数据(基础信息管理系统)28 结构化考虑2副本、存储

44、利用率80%以及当前主流单台X86服务器磁盘裸容量为12*8=96TB，需配置服务器数量以中央集中库为例计算如下：中央集中库所需存储服务器数量=有效容量*2副本/存储利用率80%/单台服务器存储容量96TB=887*2*/80%/96=23台，其他存储容量按照同样算法统计如下：类型X86服务器数量（台，单台96TB）数据结构中央集中库23结构化日志数据10结构化非结构化业务数据(药材和医用耗材招采管理系统、基础信息管理系统)12非结构化结构化业务数据(基础信息管理系统)1结构化合计46（二）公共服务区考虑到公共服务系统、药品和医用耗材招采管理系统属于面向大众提供服务的系统，根据3.4.2节测算

45、，访问量相对较高，为确保访问性能，分布式存储建议采用SSD。根据表5.6-4，公共服务系统、药品和医用耗材招采管理系统需要存储的结构化业务数据量如下：系统有效容量（TB）数据结构公共服务系统123 结构化药品和医用耗材招采管理系统1结构化考虑2副本，存储利用率80%以及当前主流单台X86服务器磁盘裸容量为12*800GB/1024=9TB，需配置服务器数量以公共服务系统为例计算如下：公共服务系统所需存储服务器数量=有效容量*2副本/存储利用率80%/单台服务器存储容量9TB=123*2/80%/9=33台，其他存储容量按照同样算法统计如下：类型X86服务器数量（台，单台9TB）数据结构公共服务

46、系统33结构化药品和医用耗材招采管理系统1结构化合计34容灾切换方案容灾系统的建设目标是对数据平台进行完整保护，同时对部分（或全部）关键业务种类所依赖的业务平台和接入平台进行保护。在生产中心发生严重故障，系统无法在业务可以容忍的中断时间内予以恢复的情况下，将生产中心系统切换至异地中心，使关键业务能够在异地及时地被接管，并继续正常的运行。对容灾备份系统而言，切换工作是将处于保护状态的异地中心系统变更为生产状态的过程。另外，当发生灾难的原生产中心的运行环境恢复后，还要将关键业务由异地中心回切到原生产中心，使得业务系统又回复到灾难前的状态。（一）系统切换系统切换是指在主生产中心发生计算机系统严重故障

47、或灾难时，为了尽可能减少对业务造成的损失，而制定的故障定位与隔离措施、异地接管步骤和方法等。系统切换是控制风险的一种有效方法，是容灾备份系统的一个重要组成部分。系统切换的内容应尽量详尽，易于操作。1、切换原则当主生产中心发生的故障或灾难影响到业务系统的正常运行时，应首先对业务系统的受影响程度进行检查，尽可能快速定位业务系统的故障部位。分别对机房受损程度、机房电源、计算机网络、系统硬件、操作系统、数据库、应用系统等进行检查，评估恢复时间，然后由相应人员决策是否进行系统切换，应考虑以下因素和原则：（1）故障影响程度，可以分为两大类：业务停顿，但故障范围明确，并且可在可忍受的时间内修复，不需要异地切

48、换。例如：电源发生故障、软硬件故障、消防系统和空调系统等机房环境告警、人为因素误操作的情况，应建立相应的本地高可用性系统、备份策略，管理流程，采用专业服务支持、基础设施的防护等措施，来预防和避免故障对业务系统连续性运行的影响。数据中心系统在可忍受的时间内无法恢复或彻底破坏，必须进行容灾切换（2）优先选择本地恢复原则当无法判定生产中心的业务系统修复所需时间时，应在继续恢复生产中心的系统的同时，在容灾中心开始进行切换的准备工作。只要生产中心的业务系统在可容忍时间内有恢复的可能，就应优先选择本地恢复。（3）优先恢复关键性业务原则对于各个系统，根据停机时间所造成的影响和损失的大小的不同，优先恢复关键性

49、核心业务。当生产中心的主机、网络等资源不足时，优先提供给关键性核心业务使用。2、切换必要性确认应分别对原生产中心的机房环境、计算机网络、系统硬件、操作系统、数据库、应用系统等方面的损害程度和可恢复程度进行评估，当原生产中心不可恢复或恢复时间超过了业务系统停机所能承受的范围，就应采取切换措施。如：以下情况需要执行系统切换，机房环境：灾难导致机房内部无法进行工作，如火灾、水灾、地震；机房电源：电源故障导致机房没有电源供应，备用发电系统不能工作；计算机网络：主数据中心和外部系统之间的所有通信链路全部中断；系统硬件：运行业务系统主机、存储硬件及其备用系统同时发生严重损坏；操作系统、数据库、应用系统：同

50、时被破坏，且需要的恢复时间过长等等。3、切换可行性确认在进行切换必要性确认的同时，必须进行切换可行性确认。切换可行性确认的工作包括：（1）明确需要切换的业务种类。（2）在异地中心标识为需切换业务种类提供支持的BOSS系统的业务平台、数据平台和接入平台。（3）确认数据平台保护的RPO指标满足容灾备份系统设计的要求。（4）确认业务平台冗余配置的正确，评估其处理能力满足容灾备份系统设计的要求。（5）确认接入平台的连接正确。（二）回切当主生产中心的系统恢复以后，就应将业务系统由容灾中心回切到主生产中心。回切过程中要保证两中心的数据的一致性。1、回切原则（1）业务影响最小原则系统回切不同于系统切换，由于

51、灾难发生的随机性和不确定性，系统切换都是在被动的情况下发生的，有可能造成业务数据的丢失和切换时间较长，对业务的正常进行会造成严重影响。而系统的回切是可以按照事先的计划来实现的，因此在系统回切计划中，应选择业务量较小时候，采用最简化的步骤回切；（2）及时性原则业务系统由主数据中心切换到备份中心后，核心数据不再有容灾保护，因此应尽快恢复主数据中心，并将业务系统回切到主中心，使核心数据重新得到容灾保护；（3）数据一致性原则系统回切前需将数据由备份中心复制到主中心，并保持严格的一致性。2、回切可行性确认应分别对生产中心的机房环境、机房电源、计算机网络、系统硬件、操作系统、数据库、应用系统等方面的恢复程

52、度进行评估，当容灾中心已经完全具备生产条件，就要制定回切计划并启动回切流程。备份建设方案数据备份是指为了防止由于操作失误、系统故障等人为因素或意外原因导致数据丢失，而将整个系统的数据或者一部分关键数据通过一定的方法从主计算机系统的存储设备中复制到其它存储设备的过程。当主计算机系统的数据由于某种原因丢失或不可用时，可以利用复制的数据进行恢复，从而保持数据的完整与业务的正常进行。因此，可以说，数据备份主要解决的是数据的可用性问题。医疗保障信息平台是国家医疗保障局信息化的核心和基础，平台中的数据是核心中的核心，数据的安全性关系到整个系统能否正常的运行，最终关系到医疗保障局能否向政府、公众、企业提供正

53、常的服务，所以建设一套可靠的备份系统，对医疗保障信息平台内数据安全保护是至关重要的。建设思路本项目将在两个数据中心本地分别建设备份系统，每个数据中心的公共服务区和核心业务区分别部署备份设备，网络示意图如下所示：图 STYLEREF 2 s 2.1 SEQ 图 * ARABIC s 2 3备份架构设计示意图（单一数据中心示例）建设原则根据以往建设大型数据中心备份系统的经验，在系统的设计与建设过程中遵循如下原则：（1）高效管理的原则为保证数据存储空间的可管理性和减少结构的复杂性，要减少管理的复杂性。应可以通过先进的备份软件对各种操作系统及常见数据库的自动备份和恢复，实现对系统的统一备份，降低管理维护成本。（2）可用性原则备份系统的建设目标是一旦发生各种软硬件错误、人