活动背景：

为提高整体人社统筹层次，同时能实现跨地区业务服务，增强部、省两级数据中心对实时业务的服务支撑能力，各省人社希望可以借助数据集成和应用集成技术，构建统一的系统集成平台，提高各业务之间数据的共享能力和实时交换能力，形成部、省、市三级数据中心之间数据双向交换机制，实现数据信息纵向无障碍传输。为了能够实现整个省人社业务的数据大集中，需要先建立一个统一的集中业务平台，而这个平台建立的前提是要能首先实现整个业务数据的统一集中管理。据了解，该集中业务平台系统较为复杂，一方面系统内部署有小型机、x86服务器等异构的业务应用服务器，同时系统内还部署了多种品牌和型号的高端、中端存储，对数据的统一集中管理形成了极大的挑战。

同时，出于冗余性考虑，核心系统使用快照功能保障业务连续性，并使用虚拟带库系统进行数据备份保护。另外，出于数据安全考虑，在本地和异地各部署一套备份系统。人社整个业务系统应分为“生产中心互联网”区域和“生产中心业务网”区域，以及各自对应的备份中心区域，针对这些区域进行了相应的数据存储方案规划。扩展能力，能够满足客户未来3~5年因业务发展导致的容量扩展需求。

然而，业务平台需要处理结构化数据以及图片、表格等复杂的非结构数据，还需要根据数据的存取冷热程度和频率进行合理的数据存储优化。同时，在实现了整个数据的集中统一管理之后，还存在设备单点故障的风险，因此需要针对整套集中平台实现一套切实可行的容灾方案。总体来看，集中业务平台面临着异构存储、数据分层优化以及灾备等多重挑战。

为了帮助人社单位信息化建设转型的趋势下，在选型以及方案设计过程中提供一些借鉴和参考，社区组织了本次“在大集中趋势下，社保单位如何设计统一集中业务平台容灾方案避免设备单点故障风险？”线上探讨活动，社区力求通过本次活动能够给人社同业带来一些参考思路，以助大家能够理清思路、合理决策以及科学做好自己的规划建设工作。

问题总结：

本期活动基于大集中趋势下，社保行业如何设计统一集中业务平台容灾方案避免设备单点故障风险进行交流讨论，来自十余家社保行业IT专家和从业人员参与互动，现将本次活动中交流内容整理如下：

一、社保行业如何设计统一集中业务平台容灾建设方案

1.如何建设本省社保公共服务平台？

问题描述：人社部提出，2018年完成全国统一的社保公共服务平台总体规划，2019年底前各地区和有关部门信息平台与国家级信息平台对接。省级社保公共服务平台应该包含哪些内容？如何建设？

问题解答：公共服务平台在服务内容上主要包括社会保险服务、社会保障卡服务、公共就业和人才服务、教育培训服务、考试报名服务、专业技术人才服务、劳动关系服务、全省流动党员服务等内容。在服务渠道上，公共服务平台是经办大厅的延伸和补充，提供了包括互联网服务、自助服务、电话咨询服务、移动服务等多种服务渠道。这些渠道要做到统一入口、统一安全认证平台、统一标准规范、统一后台数据库、统一对外服务口径，做到既相互独立，又相互关联、相互依存。

2.数据大集中后，如何构建一个稳定、可靠的网络环境？

问题描述：数据大集中后，作为基层的经办机构，一个稳定、可靠的网络环境至关重要。提高网络可靠性的技术很多，如链路冗余、双机、VRRP、IRF/VSM虚拟化等。IRF/VSM虚拟化方案是网络设备厂商首推的提高设备系统可靠性的一个方案。对于采用IRF/VSM虚拟化技术方案的网络系统，如何解决设备版本升级不停机断网的问题？

问题解答：

1）、首先网络是冗余的，服务器批量部署虚拟化，应用是集群化运行，这是基本有的目前现状，有条件可以有灾备机房，再升级时，采取应用负载较轻的时间段，停部分冗余设备进行升级，升级完成应用验证通过不影响业务正常运行，在升级另一部分。如果是灾备机房可以先升级灾备机房，再将业务迁移过去，再进行升级，总之避免不了要分两部分进行。
2）、如果已经采用了交换机“整机级”的虚拟化技术，那么对于设备大版本升级是必须要重启设备的。所以现在很多客户都采用“端口级”虚拟化技术，这样可以做到设备逐台升级。
3）、一个安全稳定可靠的网络平台体系架构，是信息系统正常运行的基本保障。前期平台体系架构设计很重要，在设计过程中 一要分层设计、并遵循本层的故障或切换不影响上下层故障或切换；二要进行场景故障的推演，做到做好，会直接影响到后期日常运营。

3.数据大集中后，如何构建一个安全、可靠、长久的数据存储系统？

问题描述：对于一个市级、县级的数据中心，数据量不是很大，存储系统的升级换代问题不是很大，但对于省级大集中后的数据中心，数据量以TB，甚至以PB计算，并且按照《社会保障法》的要求，业务数据需要永久保存；而作为数据存储的存储设备，使用寿命一般为8-10年，设备更新换代，数据迁移在所难免；数据量巨大，维护时间窗口有限；针对以上几个特点，请专家介绍一下数据大集中后，如何构建一个安全、可靠、长久的数据存储系统？重点关注电子档案数据的存储问题。

问题解答：

1）、可以从三个方面考虑，一是业务数据分层分级分类规划，如 动态数据、静态数据，在线数据、离线数据。二是要根据数据重要性、存取读写的冷热程度、访问频率、保留时间等指标，采用不同的存储方式将数据存储在不同性能、级别的高中低端存储设备上，实现分级存储并能具备自动迁移功能。三是采用一套成熟有效的虚拟化存储管理解决方案，比如IBM SVC ，支持业务在线不中断，异构平台之间数据透明迁移、灵活的数据复制，异构的数据容灾，智能分级存储等，完全能解决设备更新换代，数据迁移维护时间窗口有限等问题。

2）、根据自身业务需求并结合监管要求做好数据分层、分库，为核心生产库瘦身，降低迁移风险和迁移窗口。而大数据平台也提供了丰富的数据保护和迁移工具，在实际应用中首先要做好合理的项目规划，确保结构设计的合理性、可用性和可维护性等。大数据系统提供数据分层功能，通过合理的参数设置，可以将“冷、热”数据分布在不同的存储介质上（SAS/SSD），提高系统的运行效率。

3）、数据的安全始终是一个大问题，对于一个小的地级市来说，从金保一期开始就实现了数据全市的统一规划和部署，数据，业务都集中在市里。从2013年的金保工程二期新系统上线开始，到现在也有近5年的时间了，数据总体来看跟网上一些统计接近，大约在每2年翻一倍的这个情况，数据大约在3T左右。所以，要实现省级的大集中，数据量一定是BP级的，这个需要做出考虑。当时根据经济能力以及业务发展要求，做了一个基本的数据灾备环境，以尽可能确保数据的安全。

电子档案的系统，在规划设计中也有进行部署，但是后期业务部门没有很好使用，所以，数据并没有多少。业务并没有完全实现电子化，这个问题确实需要信息化建设管理部门（包括业务开发部门）与业务管理部门做深入交流才行，更需要上级主管部门的推动，否则很难开展推动相关工作。

4.复杂环境下，多品牌、多种设备的情况如何实现冗余？

问题解答：通过虚拟化技术可以很好的解决这一问题，例如通过存储虚拟化网关可以将不同厂家的存储设备资源池化，不但可以提高设备的利用率，而且可以提供更加灵活的数据保护策略。

5.互联网应用是否可以放置在公有云上，需要注意哪些地方？

问题解答：

1）、从功能来讲，人社相关互联网类型的应用可以放在公有云上，但需注意数据安全及敏感数据的保障，如果涉及到线下线上数据互通，还需做好防病毒及数据脱敏等安全工作。

2）、如果严格按照金保工程的相关要求来实施的，实现起来并不是很难，理论上讲这是没有问题的，但应该做好公共服务区与生产，交换区的安全问题考虑。特别是数据的安全问题，应严格执行等级保护和安全法的相关要求，应该多加考虑，并认真落实到位。比如一般在公共服务区域（互联网区域）到交换区域（专网区域）之间应该部署有安全网闸，那这个数据交换的策略，数据内容等等，都需要做好各方面的安全考虑。

3）、在技术上是可行的，重点如何保障数据的安全以及满足合规标准。

6.有没有开源能实现多活，并且是开源免费的产品可供用于灾备实施？

问题解答：灾备系统建设是一个复杂的系统工程，在工程建设、运维、演练和切换过程中需要得到原厂的技术支持。而开源软件提供的初始功能都很单一、管理功能也不健全，这意味着客户如果没有强大的技术开发和支持能力是很难采用这种方案的，这也是目前绝大多数灾备系统建设仍然采用成熟的商业解决方案的原因。

其他解答观点：

所有实现方案的总体成本都是差不多的：付费产品，有良好的技术支持和售后服务，说白了，就是花钱买服务。免费产品，需要有人才和技术储备，也就是花钱养人；在现有体制下，第一条是可行之路。需要强大的自我维护能力及较高的人力成本。

7.在当前环境下，数据灾备的建设要求都有那些？

问题描述：在当前环境下，数据灾备的建设要求都有那些？根据当前数据安全要求，如何选择，建设数据灾备系统，才能满足基本的数据安全要求。比如：建设方案的选择，建设过程中的注意事项，系统的日常运维管理方面等等。

问题解答：目前客户都非常重视灾备系统的建设，考虑到站点级的业务切换概率相对较低，所以在系统建设时，首先还是要优先保证本地系统的可靠性、稳定性及高可用性。特别是对于业务连续性要求较高的核心业务系统优先选择可靠性较高的企业级服务器产品，例如企业级Power服务器等。利用Power服务器可靠的硬件平台、稳定的操作系统及HA软件，可以在生产中心内处理、解决绝大多数软、硬件故障所引发的业务风险。

在同城/异地灾备系统建设中，要充分结合自身的实际业务需求，根据不同的业务需求制定各自的灾备建设方案，例如对于核心业务系统，可考虑采用基于Power的双活数据中心方案、保障业务连续性；对于一些非关键业务可采用基于Power的GDR方案，可为客户提供最佳性价比的灾备方案。

8.如何以经济的方式实现基本的灾备建设方案？

问题描述：如何以经济的方式实现基本的灾备方案。现在各地都已经建立了相应的计算机管理系统，数据的安全就明显越来越重要了。灾备环境的建设也就越来越重要了。但是如何以实现数据安全要求，却是各自有各自的理解和认识。如何以经济的方式实现基本的数据安全保护，也就成为灾备建设方案的选择难度。数据安全要求，设备的选型，线路传输和安全等方面的选择等等，都是一些考验。

问题解答：主要还是从业务的需求、运维管理能力、IT投入等多方面综合去考虑。可根据业务不同的重要级别，分别建立包括Active-Active、Active-Standby和一般数据备份等不同的灾备保护机制。在国家信息系统灾难恢复规范20988-2007里针对不同业务安全级别的要求也有明确的阐述。

9.数据交换区针对不同的数据类型如何分类？

问题解答：

1）、交换区的数据交换主要包括三种类型的交换：横向与同级业务部门的数据交换，如税务、银行、财政、公安等业务系统的数据交换；纵向与部数据中心劳动社保业务的数据交换；另外还有和金保工程其它系统的数据交换，如卡系统、公共服务系统、决策支持系统等。

2）、从功能角度讲，数据流向分为业务区到外网区，外网区到业务区以及内网区到其他部门间的数据交换，从技术角度又分为，文件传输，数据库传输，API调用及消息传递四种方式，可针对每个数据流向分别创建多种技术实现手段，保障数据合理高效进行交换。

3）、这个问题，对于目前的人社信息建设管理部门来说有些难度，或者根本达不到这个层面。首先目前的人社信息建设管理部门根本没有这个能力来做此项工作，基本都是由外包开发公司来完成，他们只能做一些管理工作。建议此项工作应该由人社部统一出台相关标准和要求，让各地人社信息建设管理部门来执行比较好一些，否则，只能按照开发公司自己的理解来落实了，效果如何，主要看硬件有支持，后续的运维管理水平了。

10.数据大集中过程数据库服务器选择标准是什么？是基于Power小型机还是高端X86？

问题解答：

1）、数据库服务器承载着核心数据，是关键运行平台，对可靠性、可用性及可维护性都有非常高的要求，而这些恰好是Power小型机的优势所在，这也是绝大多数社保客户选择Power小型机的理由。

2）、数据对于系统来说是非常重要的，所以从数据的安全性，可靠性，业务以及管理连续性等多个方面综合考虑，比如在金保工程二期建设中，其架构是采用三层架构，数据库服务器由专门处理，保存数据，采用的是POWER系列小型机，基于3-5年的寿命考虑，再考虑到地市级的环境和经济性考虑，还采用了虚拟化的部署。业务应用部分主要是采用的X86架构，以VMware环境为主。前端采用的负载均衡设备（A10或者F5等）。这样，不论从区域规划，IP地址的规划，访问管理的规划等方面都比较方便。也便于后续的运维管理工作。

3）、目前power小型机的优势主要在稳定性，主要看数据库服务器上承载着什么类型的系统，对稳定性要求比较高的话，可以选择小型机。

4）、数据库不赞成采用虚拟化，还是专机专用比较好，应用服务器可以考虑采用虚拟化技术。

11.大数据集中后，海量的数据情况下，如何做设备选型？

问题解答：

1）、量数据的情况下，可以考虑逐步建立分级存储，将从设备角度的思考往从功能及业务角度思考转变，NAS、SAN逐步向分布式存储、云存储转变。

2）、根据具体的业务类型选择合适的硬件设备。例如对于核心数据库平台可采用企业级集中存储设备、对于大数据系统可采用分布式存储

二、大集中趋势下的社保行业统一集中业务平台运维问题

1.信息共享和业务协同过程中如果出现单方面修改数据，其他数据合作方如何应对？

问题描述：信息共享和业务协同过程中，某方（假设为A方）业务系统发现数据错误，于是更改了共享平台上的数据，而其他共享方（假设为B方、C方、D方）在A方更改前已将该数据作为自己办理业务依据，进行相应的业务操作。现在A方突然修改数据，一是是否需要告知B方、C方、D方？如何告知？二是B方、C方、D方以此前数据为依据办理的业务操作如何处理？是否必须回溯检查和撤销？三是这个过程中A方更改数据不告知B方、C方、D方带来的风险B方、C方、D方如何防范？

问题解答：

1）、首先是管理方面存在问题。比如说A方需要跟各个合作方（可以称为B方C方D方）共同完成一个信息系统的建设，出现这类的情况，建议甲方应该着手协调各方召开一个协调会议，统一大家的工作思路和工作方式方法。这个也是一个规范管理的过程，需要甲方出面统一组织协调才行。起码从此以后避免再出现类似的问题。比较规范的方式，应该成立一个项目管理机构，定期协调解决各方在实施过程中存在的一些问题，从始之终跟踪项目的建设过程，直到项目交付，验收，这样做，起码不会出现影响较大的问题。
其次是具体问题处理方式。
一是如果A方修改数据，是需要告知B方C方D方，否则必定影响系统建设的整体。任何一方不应该随意更改任何数据，需要更改的必须要有统一的管理办法。
规范一些的做法，甲方应该要求如各方（包括甲方自己）做任何改变，大家都走业务变更流程，才会尽量减少类似的问题发生。（就目前的环境来说，还是有相当困难的，必须先提高大家的认识）
二是如果此前数据B方C方D方以此数据完成的业务操作，建议（甲方）由领导参与并拍板（大家共同协商结果，由领导来拍板）以前可以这样，以后不应该再这样了。是否必须回溯检查和撤销，应该首先考虑，这个业务操作的影响面有多大；是否跟既定政策有明显冲突？做好问题评估后再做决定。
三是这个过程中A方更改数据而不告知B方，C方，D方所带来的风险是明显的和显而易见的，至于风险情况还要对具体情况做适当的评估才能清楚。如何防范？其实就是没有按照规范管理要求来进行操作的原因。以上面甲方如提前组织了类似的协调会议，统一大家的认识，基本是可以有效防范可能出现的问题。至于出现了问题，可能因此造成无法估量的影响（特别是社会影响）；各方还会相互推脱自己的责任。所以，这类问题的出现影响最大的应该是甲方，甲方前期应该多做一些准备工作才行，更是甲方应该防范的问题。

2）、可以从关系平台所采用的技术手段考虑，如果数据保存在关系型数据库里，基于ACID原则，当同一份数据被A用户修改时，其他用户是无法访问该数据的！而对于其他技术手段都很难完全杜绝此情况，建议还是多从业务方面入手，制定合理的业务耦合关系和业务流程。

2.在大集中趋势下，如果保障云平台本身的安全性与稳定性？

问题描述：在大集中趋势下，使用虚拟化、云平台已是必然趋势，本身纯设备的故障，即单点故障已经很难会影响业务服务连续性，如何保障虚拟化、云平台或者是其他的基础平台系统本身的安全与稳定？

问题解答：

1）、云平台建设与设备自身的高可靠、高稳定性并不冲突。相反一个具备高可靠、高稳定的设备本身就为平台建设提供了一个良好的基础，有利于将云平台的优势最大化。

2）、云平台的建设，可以理解为虚拟化+智能化管理软件，虚拟化技术发展许多年，已经很成熟，只要采用市场上成熟的虚拟化软件技术，问题都不大，重点是在智能化管理软件的成熟度上。

社保业务系统属于电子政务，一定会部署在政务云平台，除了健全安全管理体制和机制，灾备中心的建设或者双活多活中心的建设一定考虑。

3）、云平台本身都自带高可用技术，通过虚拟化和存储复制来实现HA及DR保障。

3.数据中心虚拟化后，因大面积故障带来的问题如何预防？

问题描述：在数据中心建设初期，已实现虚拟化双活中心建设，虽然避免了许多服务器单点故障对业务的影响，但有次因电源浪涌导致其中一个数据中心全部短时间停电，VC在大量虚拟服务器迁移过程中内存溢出崩溃，VC数据库也出现了混乱。这种问题应使用什么方案预防？

问题解答：这与软件的结构设计有关。Vmware软件自身需要占用较多的物理资源，当处理大批量虚机迁移时还需要征用更多的临时资源，当资源不足时就有可能引发各种问题。建议可以将一些比较重要的应用部署到power资源池上，Power平台不但可以提供更好的稳定性，而且通过GDR灾备技术可以同时支持上百个虚机的批量迁移。

4.如何做好基本的数据灾备环境下的运维工作？

问题描述：如何做好基本的数据灾备环境下的运维工作？我们的信息化系统已经有了基本的数据安全保护环境，在日常的运维管理中，对于这一部一般情况下都需要做到那些基本的运维管理工作？

问题解答：
灾备系统的运维管理都是一个体系化工程，主要注意以下几个方面：
1、以灾备业务的实际需要出发，设立明确的关键岗位，将职责明确到人，给予做够的业务和技能培训并与绩效考核挂钩；
2、结合企业的实际情况，制订合理的突发事件应急处理流程，通过定期/不定期的桌面推演、灾备演练不断对流程进行优化；
3、运维过程中对工具的使用也很重要，可以很好的减轻运维压力。例如采用综合监控平台可以对软、硬件设备及网络做到实时监控和故障报警！

5.数据大集中后，如何保证系统稳定运行？

问题描述：目前人社大数据集中进行时，数据大集中后，机房设备做不到立马采购，就算采购预算有限，如何尽量利用现有资源，做到高可用，高效率。

问题解答：

1）、在设备无法到位或预算有限的情况下，要优先确保核心平台的稳定运行，做好核心服务器、存储及网络设备的升级与加固，满足数据大集中的需要。

2）、可以先统计下现网生产环境资源，通过虚拟化技术做整合。

三、大集中趋势下社保行业统一集中业务平台标准与创新

1.在当前数据省级大集中的趋势下，如何解决标准化与业务创新的关系问题？

问题描述：数据大集中，标准化是关键，俗话说的好，“没有规矩不成方园”，统一的政策规定、统一的业务流程、统一的数据格式，是数据集中的基础。业务创新，是社保业务适应社会经济环境，适应改革发展的需要，是业务变革的重要源泉。请专家介绍下，在当前数据省级大集中的趋势下，如何解决标准化与业务创新的关系问题？

问题解答：

1）、数据大集中是信息化发展的需要，也是各类业务灵活开展的基础，是大势所趋。“数据大集中，标准化是关键，俗话说的好，“没有规矩不成方园”，统一的政策规定、统一的业务流程、统一的数据格式，是数据集中的基础。”
人社部金保二期建设规划中就提出了实现省级大集中的一些要求和标准，只是由于各地的情况差别较大，实现起来困难很多，很多地区到现在也没有实现。
统一数据格式，这才是数据集中的基础。现在人社部也出台了参保基础数据信息的标准，先从参保基础数据信息入手，各地先应该按照这个标准要求，做好本地的参保基础数据信息的核对，尽可能做到这些信息的准确（此项工作应该已经完成了，效果如何不是很清楚）。这是数据基础信息的基础，也是数据在集中的基础。
又因各地参保基础数据信息由于各种历史的原因，造成的信息不准确，各地领导也就没有信心去做共享的考虑（根本不敢考虑共享）。也就会影响其他方面的发展，比如“互联网+”的一些应用。
信息化应用的深化，以及“互联网+”应用的快速发展，数据这个基础（根本）性问题在一些地方还没有能够做到准确统一，也就无法去考虑如“互联网+”这类应用的发展，即便在一些地区实现了，也不是从统一规划，统一建设这个方面考虑的。这些提法在金保工程中都提出过（从金保工程一开始就有提出），只是各地没有认真执行而已。

2）、数据大集中，由于涉及部门权利、经济利益、没有建立一套完整有效的信息共享交换平台、缺乏保障数据安全的机制等因素，像社保、医保等公共资源信息，各个政府相关部门信息是不愿共享、不敢共享、不能共享。这就导致了我国电子政务信息标准化的建设十分缓慢。加上之前部、省、市三级数据中心之间数据共享交换机制是数据不落地的，使数据资源不能充分开发利用，不过这两年国家已经重视数据集中后，对政府信息开放、数据资源共享开发利用，对政务标准化政策的制定，比如 “互联网+政务服务”，“全国异地就医结算”，基于业务创新，我们可以挖掘社保、医保数据资源，使其将全民医保向全民医疗转变、全民社保到居家养老转变等等。

其他解答观点：
1）、做数据大集中，有时必须要有铁的手段 ，比如身份 证号码重号的问题，业务部门只关心业务能够正常运行，并不关心数据问题，IT部门如果迁就业务，允许重号人员参保，也就放任了重复参保，后续数据校验将是一个十分头痛的问题。

2）、这个问题，其实也就是省中心和市、县社保经办机构的分工和关系问题。作为基层的IT人，对数据大集中是既爱又恨，爱的是，大集中后，不用再提心掉胆的担心数据的问题了，恨的是恨铁不成钢，不满足、不适应基层的业务需求，求天天不应，还得自己想办法解决，不仅要解决业务需求问题，还要考虑数据同步问题，如同风箱中的老鼠，两头受气。

3）、要从源头开始，先要有一个人领头，统一集中所以数据，统一部署，禁止下级或者相关业务单独进行，现在正在部署的电子政务云，互联网+就是一个很好的例子。迁移所有的应用过去。统一办理。

2.数据集中后，怎么展现数据让领导积极主动前卫制定政策？

问题描述：领导多数没有很好计算机造诣，数据集中后，有了很好的大数据分析基础，但是大数据展现一般是:领导突然想到想看什么数据，或者社会上什么问题比较突出，让领导想看看这些数据的情况，然后制定对应的政策，被动又延迟。怎样展现数据让人在未有方向和目的测前能留意到数据中的异常呢？

问题解答：

1）、首先数据的准备要充分、标准要统一，为今后的大数据分析打下良好的基础；另外不同领导的关注点有所不同，需要针对不同领导兴趣点提前做好相关的准备，通过建立实时流分析平台也可提高数据分析效率。

2）、这个问题是该好好考虑的时候了，从现在情况看，不论从各项技术以及实现的方式上都有很多选择。其实，在金保工程的建设中人社部都有这方面的规划，比如决策分析区域的规划建设（建议多研究一下人社部金保工程规划建设要求等资料），就是为此项需求准备的。如果按照这个规划来设计部署，有了标准统一的数据，再结合新的技术应用，实现起来并不是很困难。

其他解答观点：

可以将大数据与AI进行结合，做些线性回归针对某些场景做预测，或者对于连续数据中的异常点做识别。

3.面对新的政策导向、新业务需求及新技术的不断衍进，如何它们权衡之间的关系及观点分享？

**问题描述：为实现部、省、市三级业务数据的共享及互联互通的业务需求，需建设统一、稳定的集中业务平台，而此建设过程中涉及的软件业务模块偏多、错综复杂，硬件架构设备异构、管理繁琐，同时还需业务创新、技术衍变和新技术引进等，后续还会进一步考验运维工具和人员的综合服务能力，面对如此的环境现有以下几点问题：
1、为了避免设备单点故障，自己的经验一般是做对应用主机做高可用或前端挂负载（有商业方案和开源方案可选取），对Oracle数据库主机做RAC\Mysql做MHA等，并定期做备份，大家还有那些好的技术分享？
2、对该平台业务做灾备，采用的复制技术有主机层面的镜像、存储方面的复制（PPRC\HAM\HUR...）、数据库层面（Oracle OGG\ADG或是DSG...），可以一起探讨一下自己的应用场景和最佳实践案例？
3、面对新技术的衍进是否对后续新的业务采用微服务的架构，并可借助Docker和Kubernetes等容器云平台或编配工具进行落地，可进一步保证业务的连续性和弹性扩展等需求，但无形中对实施和运维人员、工具的考验很大，技能水平要求进一步提升，我们可以进一步探讨？**

问题解答：通过对基础环境的标准化可以有效的降低管理难度，提升效率。例如通过以K1 Power服务器（核心数据库）和OpenPOWER服务器（应用资源池&分布式系统）为基础构建核心业务平台不但可以通过统一的云管平台PowerVC进行管理，还可以接受第三方云平台，例如VMWare vRealize的纳管，与x86组成异构云平台环境。以Power为基础构建的业务云平台可以为客户提供更多的高可用解决方案及快速的业务部署能力。例如针对核心数据库系统，通过Power+PowerHA Hyperswap+Oracle RAC的组合可以提供双活数据中心方案；针对非关键业务可以通过GDR技术，为客户提供最优性价比的灾备方案。此外Power平台还提供活动分区迁移（LPM）和远程启动（Remote Restart）功能为客户解决了计划内和计划外业务快速迁移/恢复的解决方案。

在虚拟化和云计算方面，无论是Power还是OpenPOWER都可以对包括Docker和Kubernetes提供非常好的支持，通过PowerVC可以实现对资源的灵活调度和快速部署、将传统以天为计算单位的实施周期最快缩短到“分钟”级，极大简化了客户的实施难度、减轻了管理压力。