前言：本文为中国太平运营管理处副处长何宁在青云QingCloud 保险沙龙上的技术分享整理而来。文中，何宁详细分享了太平保险集团独特的信息化建设之路，以及实现太平云建设的历程和多年积累的云计算实践经验，非常值得从业者借鉴与学习。

1: 私有云是一个伪命题

太平集团是国内金融界有点另类的集团性保险企业，作为第一家在境外上市的中资保险企业，是唯一一家管理总部设立在香港的中管金融保险集团。太平集团经营区域涉及中国内地、港澳、北美、欧洲、大洋洲及东南亚等国家和地区；业务范围涵盖寿险、财险、养老保险、再保险、再保险经纪、互联网保险、资产管理、证券经纪、金融租赁、不动产投资、养老、养老产业投资等领域，业务种类齐全，为客户提供一站式综合金融保险服务。

正是由于以上背景原因，太平集团的信息化建设之路可能与一般的保险公司有所差异，这样的差异对我们打造太平云也有着一定的影响。

我一直认为私有云是一个伪命题，可以从以下几个方面来看：

(1)从在线程度来看，公有云一定比私有云有更高度的在线程度；

(2)从数据流动产生信息从而生成价值的角度来看，公有云更有明显优势；

(3)从建设速度来说，公有云等于开箱即用，私有云需要部署、集成、调试步骤。

这种情况下，肯定要有人提及安全问题。

但是，从宏观角度来说，只要金融行业拥抱互联网，无论是公有云还是私有云，面临的安全问题都是一样的。去年的蠕虫病毒，公有云服务提供商没有受多大影响，但金融行业，不少企业的局域网里反而出现了不少问题。

从微观角度来看，有什么证据能说明金融机构做信息安全的能力可以高于专业提供资源服务供应商的能力呢？

当然，在公有云真正普及之前，未来的 5-8 年内，私有云还会在中国市场上生根发芽、枝繁叶茂，这是我们无法规避的阶段，就像社会主义初级阶段或者社会主义新阶段。

2:太平云建设规划：1 个目标，3 个要求

去年，集团开始规划要搭建太平云，制定了 1 个目标、3 个要求。

第一，这个云要建立在集团的范围内，不是只给某一个公司或者营业机构提供服务；

第二，这件事情的整个周期为 8 个月；

第三，最终衡量太平云平台的好坏不在于是否完成了建设，而是平台之上是否可以实现各种应用的价值。

我们当时做了一个计划，以太平集团旗下最大的太平人寿作为试点，试点成功后共享推广，最后形成真正的集团标准，在境内外使用。

第一期，我们主要以建设 IaaS 为主，基本满足虚拟化、SDN，实现在此之上部署一些 PaaS 服务。这些服务基本是面向应用开发部门，让大家可以快速高效地拥有完备的应用开发测试环境。

目前，太平云处在规划建设的 年阶段，建设中心是 I-PaaS ，我们更多的还是面向应用开发部门，为他们提供更好的 PaaS 服务，同时让更多的专业子公司使用这个平台。

我们现在在做科技太平的课题。明年，我们会往下一个阶段发展，转向提供面向业务应用的 B-PaaS 或者 SaaS服务。比如客户画像或者认知识别，将来很可能会通过 B-PaaS 的方式交付给集团下属各专业公司使用。

太平云的一期建设，从 2017 年 8 月份开始启动，12 月迎接第一次开门红，今年 3 月份收尾，用时 7 个月 30 天，比规划的要求提前了 1 天。

一期规划落地的时候，主要实现的是“两地三区域”，我们有上海数据中心、武汉数据中心。上海数据中心被我们划为生产区域，武汉有开发测试和生产区域。

去年，我们在上面使用了不少青云 OEM 的 PaaS 组件，目前匹配良好。我们把原来一些商务数据库上的东西迁移到 MySQL 上。

其实 MySQL 本身的一致性的问题不好解决，青云在这方面做很多优化与实现，帮我们解决了不少技术难点。除此之外，非关系型数据库、缓存、Hadoop 等东西都已经放在了上面。

在太平集团内部，私有云平台建设的出资方是太平人寿，托管给太平金科运营。其他公司，比如财险、寿险、养老、太寿香港等，他们做为用户方来租赁私有云。

这就像是集团内部公有云，太寿出钱，金科运维，其他公司租赁。从集团的角度考虑，如果想要把新生事物顺利推广到集团范围内，建立管理制度和技术标准非常重要，这个理念在整个行业或者信息产业内都是一致的。

所以我们一方面建私有云平台，另一方面建立私有云管理办法和准则；在此之上建立运营细则树立运维标准，指导实际运营工作；在运营和运维细则基础上，我们建立一套财务细则，制定各公司和金科的月度结算流程和标准。

4：太平云建设的五个阶段性成果

太平云建设规划一期落地，实现了“太平云”平台的五个子目标，太平集团拥有了一个在架构和功能上都较完整、先进的，真正意义上的私有云。

第一，给集团各单位提供统一、快捷、按需申请的基础设施分配服务。

我们还有一个目标是建立能提供服务的基础上，还能用于支持服务配套管理制度体系。

第二，面向应用开发能够提供开箱即用的开发平台、应用支持、安全防护等 PaaS 服务。

此外，我们还制订了一套比较适合集团使用的服务目录，包括各个资源整合和分离的定价体系，嵌入了资源申请审批流程，增强了资源计费报表分析功能。这两部分比较贴近私有云而非公有云的客制化开发部分，要感谢青云的投入和产出。

第三，统一管理的多地域、多数据中心资源。

我们想做异地灾备，想在今年或者明年尝试一些跨域的互联互通应用。

第四，提供多租户方式下的调度管理和服务计费功能。

我们想做利旧。现在国内每年开门红会购置一批机器。开门红一过，60-70% 的机器就有闲置压力。

当我们有了平台和资源，开门红只有一两天，在那个时间段里可以尽可能压缩测试区域资源，把里面的资源全部投入到生产区域；结束之后，再把资源释放回来，放在开发测试区域使用，这样资源投入不会短时间大幅度增长，而且既能兼顾开门红业务，也不影响平日开发测试。

第五，满足现有虚拟化的资源需求，支持未来灵活的需求。

我们希望有一个平台，除了可以纳管云平台之下的资源，还能将 VMware 、裸机等系统统一在一起管理。这样集团可以清晰知道哪些资源在用、哪些闲置、哪些该扩容、哪些该撤销，往资源集约化、降本增效的方向运作。

5：太平云端的业务实践

平台落地后便是做应用，太平人寿成立了创新发展部，在云平台上做应用——太平云保就是这样一款互联网核心应用。

微销产品通过微信渠道销售各种各样的产品。这有点像众安的方式，但是众安的方式是以客户打通客户，微销则是通过代理打通代理和客户。

如上图所示，上面是微销平台，下面有互联网核心系统。互联网核心通过消息队列慢慢有序的递交到传统核心系统里。总的来说，底下基础架构有云平台支撑，中间有互联网核心，上面有应用层支持创新业务。

这件事挺有挑战，互联网核心平台去年 3 月份设计，6 月份完成，8 月 18 日启动私有云项目，9 月 4 日部署好上海站，经过两个月安全和压力测试，12 月初开始迎接开门红。

开门红那天，早上 11 点资源遇到瓶颈，我们在云平台上用 16 分钟，扩展出 20 个节点。大概 15分钟后，资源占用一下就下来了，直到当天晚上 11 点，再也没有出现资源紧张的情况。

一个新私有云平台加上一个新的互联网核心，在开门红的这一天，支撑了三分之一的保费。这还是比较有说服力的。

现在有了平台和应用，后续的计划主要分为四个维度：

第一，纵向，希望满足各公司资源需求，实现预设目标；横向，希望各个专业公司新建系统都要云化。

现在主要用的是寿险、金科，今年我们会把它推广到养老、太平香港、太寿香港、财险公司，目前资产公司也在运作中。更为重要的是，由于接入多、高并发业务多，我们希望青云私有云平台可以经受得住更激烈的考验。

第二，从应用来说，它有集成性，毕竟私有云平台是新的，我们要想办法把传统应用集成起来。

现在保险行业比较流行的做法比如秒赔、闪赔，要把非结构化的数据做前置，现在我们和青云合作也在探索如何把对象存储应用到这些业务中，把非结构化数据从后端移到前端。

第三是制度，第一次制定云平台制度，一定会有不满意不科学的地方，还有优化的空间。尤其是考虑到境外监管机构要求和国内要求不太一样，未来，我们也需要建立在国际上能通用的制度。

最后是创新，最重要的是开源创新。此外还有数据安全创新和基础网络部分的创新。

7：云平台建设中的 5 点思考

最后跟大家分享我们做规划和建设过程中的一些思考：

第一，平台价值的体现。

我们认为一个平台服务的价值绝对不是体现在平台本身，平台本身是一个非常基础的东西。它真正要体现的价值是建立在平台之上的应用，以及应用所能提供的服务价值。

第二，私有云和公有云的差异。

青云是一家对私有云和公有云差异性有清晰认知的公司。公有云和私有云真正放在企业里，概念是不太一样的。公有云没有真正流程的概念。企业有比较严谨的审批流程、合规流程，要经得起考验、稽核以及审计，不是每个人想申请资源，就有资源。而这些都是公有云上不会考虑的。

去年我们做了很多事情，把私有云独特的东西抽取出来，和青云做开发改进，青云也帮助我们解决了资源申请、费用结算等私有云比较独特的需求。

第三，平台周边系统关系处理。

太平集团的做法是一步步来，适合迁移的，我们可以逐步做迁移。现在没有实力、没有能力、没有精力、没有资金做迁移的，保持中庸的容忍。

在用户体验一致性层面，我们尽可能把青云和原来的体系通过某些定制化开发来实现平滑的过渡。对于用户来说，他对迁移的感知度极小。

网络层面来看，我们现在有两个数据中心，一个在上海，一个在武汉，中间是两根 1G 的带宽。如果你的底层核心在上海，你想让别的公司在武汉用，不解决网络问题，这件事很难推进。

现在网络成本比较高，我们今年可能会尝试用裸光纤或者其他方式解决两地城际网络的问题。我们预计同一平台下的“两地三区域”访问能达到 4G 的城际网水平，但这是一笔不小的支出。

第四，平台上的专业交流。

既然都在一个平台上，当大家对于同一个问题感兴趣的时候很方便组织沟通交流，比如去年财险和寿险对 Spring Cloud架构的沟通交流。我认为这是平台带来的另一个附加好处，各个公司可以在技术层面上有共同语言，大家有共同研究的契机。

第五，平台中沉淀的数据。

对于数据分析和生命周期管理，太平集团一直在做。目前，已经将寿险、财险、养老等客户信息集中在一起，我们希望有精准的客户画像，提高将来产品投放的精准度。之前那套系统比我们后面想在私有云平台上做困难很多，我们现在也希望逐步把它移到开源的体系中去。

芽叶云技术 很好， 技术效率高好多，项目做的特别满意，做你的这个项目应该没问题。

现在很多企业的数据都选择上云。然而，即便是将业务数据存放在国内外知名的云平台，也免不了掉链子。

2018年8月，腾讯云“数据丢失事件”在业界引起极大的关注，因腾讯云发生故障和人为操作失误，直接导致创业公司“前沿数控”数据全部丢失，公司面临业务停摆的威胁。

在腾讯云的复盘中发现，该故障缘起于因磁盘静默错误导致的单副本数据错误，再加上数据迁移过程中的两次不规范的操作，导致云盘的三副本安全机制失效，并最终导致客户数据完整性受损。

事实上，腾讯云并不是唯一出现过故障的云平台。2018年6月，阿里云因bug禁用内部IP导致链路不通，造成1000+公司业务瘫痪，损失过亿；2017年4月，全球知名云平台AWS发生大规模存储故障，导致大量全球知名业务中断。

以上是云平台自身原因引起的灾难性故障，其实还有外部因素导致的问题：

2017年5月，全球爆发的Wannacry勒索病毒，给网络带来了未有的挑战，云平台也不能完全幸免；

2018年1月，Intel芯片设计缺陷，给整个IT架构带来灾难性影响，云平台性能和安全受到极大的挑战。

除了暴露出的这些严重故障外，几乎每天都能听到发生在企业内部的私有云，因为软件缺陷、人员、电力异常等各种原因导致的业务中断、数据丢失，企业正常的生产受到极大的影响，损失无法估量。

这些内部、外部因素叠加在一起，实际上带来了几乎无法规避的现实：

云也会宕机，也会丢失数据。

很多企业对于存在一定误解，认为将数据放到云平台上就万无一失了。从的本质来看，它为企业提供的是一个低成本的计算资源共享池，它能帮助企业提升效率，减少成本，但这不代表它是一个不会出问题的服务。

目前，云服务商在提供服务时都会明确知会客户，因为当前人类技术水平的限制，服务商能够提供的服务的可用性、可靠性都做不到100%，大致能做到几个9(如99.9999%)。

因此，为了在此基础上继续提高数据的安全性，一般的解决方案是，同时使用该服务商不同区域的服务器，这样出问题的概率就会更低。此外，对于重要数据，不管是个人用户还是企业用户，都需要定期做好备份。如果使用云服务，快照、灾备、离线备份等多种方式都可实现数据备份。

做好灾备，提高数据安全性

数据备份的任务与意义就在于，当事故发生后，通过备份的数据完整、快速、简捷、可靠地恢复原有系统，而备份数据可用性的高低是企业灾难恢复的根本。

目前来看，主要的数据备份方式如下：

包括远程磁带库、光盘库备份和远程关键数据+磁带备份。

就是在与主数据库所在生产机相分离的备份机上建立主数据库的一个拷贝。

这种方式是对生产系统的数据库数据和所需跟踪的重要目标文件的更新进行监控与跟踪，并将更新日志实时通过网络传送到备份系统，备份系统则根据日志对磁盘进行更新。

通过高速光纤通道线路和磁盘控制技术将镜像磁盘延伸到远离生产机的地方，镜像磁盘数据与主磁盘数据完全一致，更新方式为同步或异步。

这些措施能够在系统发生故障后进行系统恢复，但是这些措施一般只能处理计算机单点故障，对区域性、毁灭性灾难比如：

地震、火灾等则束手无策，也不具备灾难恢复能力。

所以，我们就需要建立异地容灾中心，做数据的远程备份，在灾难发生之后要确保原有的数据不会丢失或者遭到破坏。建立的异地容灾中心可以简单地把它理解成一个远程的数据备份中心。

数据容灾的恢复时间比较长，但是相比其他容灾级别来讲它的费用比较低，而且构建实施也相对简单。主要的实施方法如下：

当主中心的数据库内容被修改时，备份中心的数据库内容实时地被修改，此种复制方式对网络可靠性要求高。

当主中心的数据库内容被修改时，备份中心的数据库内容会按照时间间隔，周期性地按照主中心的更新情况进行刷新，时间间隔可长(几天或几个月)可短(几分钟或几秒钟)。

当主中心的数据库内容被修改时，主中心的数据库服务器会先将修改操作Log存储于本地，待时机成熟再转发给备份中心。

综上所述，业界一般提到的灾备技术，就是指在一个发生故障或灾难的情况下，其他数据中心可以正常运行并对关键业务或全部业务实现接管，达到互为备份的效果。好的灾备技术可以实现用户的“故障无感知”。

在国外，DRaaS（灾难恢复即服务）已经十分盛行。Forrester的数据显示，2014年，国外23%的中小企业已经在使用DRaaS，提供DRaaS服务的玩家也比较多。IDC预测，到2020年，中国的DRaaS市场将达到百亿元的规模。

中国DRaaS市场的爆发点很难预测，因为它与公有云的成熟度密切相关。只有公有云的生态体系逐渐成熟和完善，DRaaS的价值才能真正体现出来。

除了灾备系统，灾备演练不可少

那么是否做好灾备系统的建设就可以大功告成了呢？大多数企业其实忽略了灾备演练这个重要环节。

现在很多灾备公司都不太重视灾备的演练，很多一年也没有做到一次，不能完全发现灾备中心的缺陷。

容灾系统的业务连续性是企业的关键业务在灾难发生时的应对能力和恢复能力，即通过尽可能快速的、全面的企业业务恢复运作，将因灾难造成的损失降低到最小程度。

灾备演练是验证灾难发生时，业务系统能否有效联动切换的极为重要的手段。没有灾备的演练计划和手段，往往无法预知灾难发生时生产中心和灾备中心的数据一致性，也无法预知灾备中心是否具有了业务接管的一切必要条件。灾备的演练计划有以下几种方式：

灾难恢复计划要求建立业务连续性管理团队，不仅涉及IT部门，而且关联众多业务部门，为减少演练对于生产的影响，可以将恢复计划细化到很小的单位或者模块，逐个应用进行接管验证。当模块都成功通过测试后，测试的范围可以扩充到更多的模块。

在灾备系统全面完成并且制定了全面的恢复计划后，可以在进行了一定备份的情况下安排突发性的测试。当然，业务连续性管理小组需要确保业务不会因为突发性测试造成不可接受的损失和业务中断。

演练对于提高团队的恢复经验和协作能力以及确保灾难恢复计划的可行性是至关重要的。所有的演练结果都要进行评估、记录、并且生成到容灾流程里。

数据安全无小事，无论是在传统IT还是云计算时代，对于业务系统的安全性和稳定性是永远不变的前提，而未来云计算也一定是朝着“多云备份，云上容灾”多重的基础保障策略发展的。