保险应用上云趋势下，如何规划云上应用灾备？

1、应用灾备云的确是趋势，可以省去很多成本开销，包括机房自建、动力、网络、暖通和后续运维等成本，同时也起到了灾备的效果。当然这个云不是企业私有云而是公有云，在公有云上部署应用，并通过公网DNS进行负载或引流，让公有云上应用也活起来，比较适合互联网类的应用，对于非互联网类的应用，还需要考虑将营业厅/网点/机构到数据中心的传统的专线改为公网，或者专线和公网并行。
2、保证生产和灾备数据的一致性的问题，我在其他问题中也有提到，可以参考：
有两种方式，一种是技术上，一种是流程上。
技术上有两种方式：
一是通过克隆，例如VMWARE SRM+VP（VMWARE软件复制）/存储复制，来保证主中心和灾备中心的虚拟机的一致性，应用也就一致了，只需要用SRM切换即可。这时灾备节点和生产节点都是完全一样的（OS/IP/应用等）。
二是灾备节点完全重新搭建，生产和灾备应用没有任何复制关系，借助自动化平台和工具等手段去检测两端的一致性，并批量同步变更生产节点和灾备节点。这时灾备节点和生产节点除了应用是一致的，OS/IP等都不一样。
流程上也有两种方式：
一是从变更流程上去保证同步，在设计变更流程时需要考虑到灾备节点的同步变更，落实到流程节点中的责任人，并在变更步骤中体现详细的变更操作，并具备专人审核。
二是从真实演练中去发现是否同步，通过上面的技术方式仅仅是从行为上保证了一致性，灾备节点真正是否可以真实有效接管业务，依旧需要每年多次的演练去保证，发现问题可以反过来去优化流程、优化自动化监测手段和自动化投产工具，相互相成，同时也可以完善应急预案。

数据的完整性和可靠性，我们主要通过两方面
一是存储级的数据复制，作为最可靠的保证。
另一个数数据库级的高可用，包括rac、HA、一主两从等。
上云的一般都是偏互联网的应用，代表着敏捷、快速迭代，传统保险公司要上云本身就是一个漫长的过程，所有人都没有办法一下就完成上云这个动作，自有的灾备机房和云上的灾备本身定位就不同，相辅相成。尤其是在过渡阶段。