信通院郭雪:面向保险行业的云计算系列标准解读

2019-02-26    来源:多智时代

容器云强势上线!快速搭建集群,上万Linux镜像随意使用

  今天,我将对保险行业云计算系列标准进行解读,标准是由中国信通院牵头联合中国人寿、太平洋保险、安心财险、人保财险以及6家科技公司共同做的标准,在中国保险学会和CCSA立项,标准有几个特点:1、它是跨界的标准,保险行业科技的标准,是两个标准化协会的联合,这个标准可能会在日后进行联合发布。

  信通院郭雪:面向保险行业的云计算系列标准解读

在解读标准之前在此特别感谢中国保险学会给我们提供了跨界编订标准的平台,同时也为保险行业云计算标准提供了非常大的支持,举办了多次研讨会和评审会,在此也感谢保险学会对标准的支持。

我对标准的细节做一个介绍。首先,为什么我们要做云计算的标准,为什么不从大数据的标准、人工智能的标准开始做,先从云计算的标准开始做?由于中国信通院做云计算的基础比较多,我们依托可信云的品牌已经有了四五年的积累,另一方面其实我们也发现云计算逐渐从前两年大家认为的新兴技术,这两年已经开始转型到基础设施,包括上周五工信部发布企业上云的文,提到政府关于企业上云政策的支持和补贴,可以看到,国家层面都在鼓励中小企业包括大型企业从私有云上云的模式,鼓励中小企业包括金融行业使用云计算,之前保险“十三五”规划里面提到利用云计算做保险行业的创新,所以云计算有这样一个大的背景,国家层面是非常支持的。

另一方面,去年我们院做了调查报告发现,百万中小企业上云,冲在最前面的是政务云,政务云全国300多个地市级政务云现在落地的已经非常多了,其次非常靠前的行业是金融行业,但是在调研数据里面保险的应用跟银行相比还是稍欠缺的,这是去年的调研数据,今年还会做更新,也就是说保险行业云计算这种需求也是在稳步增长的。

另一方面国家层面也在做保险行业、金融行业云计算的相关标准,金标委做金融行业三个标准,目前是在征求意见稿。今天上午发布的银行类行业云的系列标准、保险类云计算的标准。这是目前整个金融云的标准体系。

保险行业云计算的现状,我们做了简单的调研,里面有些企业的数据在里面,当然没有隐私数据,保险行业上云,我们调研主要有三种模式,对于大型企业来说,可能私有云的模式,以集团数据中心也好、信息科技部门支撑集团的各个子公司做整个集团内部的私有云的形式为主;这是第一种模式,私有云比较适合大中型的保险公司。

第二种是行业云的模式,也就是说在我们内部提供内部私有云提供服务之后可以对外输出,目前比较典型的案例,银行兴业数金、招银云创是比较典型的案例,保险行业现在也有输出。

第三种是公有云的形式,公有云的形式是保险行业相比其他行业比较特殊的一点,在我们调研中银行业上公有云的比较少一些,但是我们发现中小型保险公司尤其互联网公司上公有云的比例比较多,主要是这三种模式。

在这样的背景下,保险行业云计算还面临问题和挑战:银保监合并之后,银行业的云计算的标准会不会影响保险行业的云计算的标准?毕竟监管部门有了一致性之后在下面落地的标准化和检查上面会有一些一致性的要求,保险行业的系列标准也是跟银行的标准做了对标的,慢慢的银行保险的标准会趋于统一。

另一方面保险行业涉及核心系统,试错比例比较高,这相当于是保险行业面临的问题和挑战,在这样一个大的背景之下开展了标准的制定,这个标准目前有9个标准,分了2次立项,共有5个标准征求意见稿,还有4个也会征求意见稿,再会提意见,大家有意见可以提给我,我们再修改。

总体架构标准,里面写了保险行业对云计算的需求、应用场景、总体要求和云计算架构。保险行业对供应商有哪些要求,云服务类的相当于对外部云服务的要求,写了保险行业云服务提供方能力要求的标准。软件类的目前只写了第一部分,对虚拟化软件的提供方提的要求。针对需求方的标准,这两个标准的名字是一样的,但是评估对象可以对内也可以对外,在保险公司内部有对保险提供方的要求,对集团内部的云服务提供方有能力要求。基于容器的平台架构和成熟度的两个标准是一套的,这个标准做的事是想评价需求方容器平台的成熟度。第三块针对微服务的技术能力要求和成熟度模型,这两个标准主要是用于评价需求方微服务的成熟度。最后一个是刚刚开始制定的标准,只有一个草案,是研发运营一体化的标准,目前我们也打算做成成熟度的标准,这是整个标准的大概框架。

这是标准整个的研讨过程,有两次非常重要的立项会是6月份和8月份在保险学会做的立项,前期已经研讨非常多次了,大概有5-6次的研讨会,在座很多专家都给我们做了很多支持做标准的讨论工作。

下面我对标准做详细的介绍。

1、云计算的场景和整体架构。这个标准我们想梳理保险行业对云计算的需求场景有哪些,一些宏观要求有哪些,标准的目的,也是参与单位,由我们院牵头,由保险公司联合参与编写的。我们标准的脑图,梳理金融机构的云计算需求,这部分是讨论最激烈的部分,哪些场景是适合上云的,每次都在这一块打架,后来我们梳理了一致性比较高的场景:新型保险公司新开业的需求;移动服务、互联网服务可能涉及到上云;灾备场景的比较适合上云;如果将现有的信息系统已经有的信息系统、非云的系统上云改造,要考虑它的技术架构适不适合,还要考虑数据敏感度,承载的重要性能否上在云端。这是需求场景部分。

部署模式,以公有云、行业云、私有云、混合云的模式为主,架构特性列了一些通用的要求,包括合规性要满足银保监会的合规要求,高弹性是云计算通用的特性、高可用也是通用的特性、强部署性、开发性、安全性,开放性是我们提到的性能,也涉及到多渠道、多业务性的对接,所以多业务性是我们提到的一点。

云计算的架构,这个架构和其他行业的云计算架构没有区别。

最后说一下应用场景包括开发测试、生产化灾备,这是整个架构的图,云计算的架构体系我们把它的列车在上面了,这是通用的云计算的架构体系没有针对保险行业重新画,从底层的数据中心到上层的IaaS、PaaS、SaaS包括数据管理和信息安全,在我们看来是通用性的云计算的体系架构。这是第一个标准,做指导用的,不做落地评估。

2、第二个标准我们重点做的标准云服务提供方的能力要求,适用对象是对内对外两类,对内如果是内部私有云可能拿它评价集团内部信息科技部门或者内部的云服务提供方,如果涉及到公有云,涉及到外部的公有云服务,也就是说没有写云服务商,写的云服务提供方,也就是说我们的对象是两大类,内部和外部的。

由于行业特性,各个行业的行业特性第一个非常大的区别是监管要求;安全要求不同、对接的业务系统不同可能会有特殊性的需求。所以我们首先还是列了资质的要求,资质要求包括内部云服务提供方资质要求数据中心要满足一些建设标准、数据安全要满足一些要求,包括风险管理的一些要求。外部要求比较多一些,因为云服务有些牌照的要求、经营年限的要求、建设标准、行业应用的情况。

第二部分,云服务如果提供服务需要有甲乙双方签订的范本,也就是服务协议需要做标准化,保证云服务提供方给用户提供什么质量的服务,在这一块相当于有整个服务协议的参考框架。

第三部分是整个服务能力的要求,我们列了十几类的要求,大概包括数据的要求、数据要保证它不丢,如果用户想销毁可以销毁,想迁走可以迁走,还有传输和存储加密,知情权用户需要知道存储的位置,可审查性,有些特殊场景需要做审查是可以提供这个支撑的,还有一些功能性的要求,满足一些特定功能的需求,可用性在我们看来是比较重要的,金融行业尤其保险行业云计算对可用性要求高一些,这里列的是99.95%,因为在可信云评估过程中,整个标准的基础是可信云评估,可信云评估过程中99.95%的标准线是中等偏上的水平。

资源调配能力,虚拟机、存储能量调配、网络弹性、和资源扩充。还有恢复能力要有告警和恢复技术和应急响应的机制,网络接入能力,要接入带宽,是不是可以并行接入。安全能力也要做一些承诺,至少同城双中心灾备,还有计量计费的要求,云服务要有准确的记录,最后是服务的规范性,这是整个云服务提供方标准的架构。

3、针对软件,保险行业涉及到私有云的话,涉及到软件的要求,这是针对提供方的要求,这个在里面细分了5个部分,包括总体的要求,右上部分是总体要求、安全性要求、可先役要求,分别针对计算虚拟化、网络虚拟化、存储虚拟化提了要求,这个在我们看来供应方有可能是打包提供也可能是分别提供,我们分别列了4类的要求,主要是从功能完备性、兼容性、可靠性、扩展性、迁移性几个角度列的。虚拟化管理软件列的指标比较多,功能完备性涉及虚拟机、存储、镜像、网络、租户、多复本或者备份。具体指标不念了。

4、针对基于容器的云计算架构,容器是一个有一定应用场景,我们针对容器做了标准,这个标准日后想做成熟度评估,需求方的成熟度评估。如图这是整个标准的体系架构,第一部分还是先解决哪些场景适合容器的适用场景,列了开发测试环境、CICD、自动化运维、微服务四大场景。下边分别对每个模块提出了它的要求,包括平台层能力要求、基础设施层能力要求、分域治理、高可用架构、安全性能的要求。我们当时在标准里面列了容器的云计算平台架构图,涉及到基础设施,负责整个容器平台网络存储,基础资源的管理,涉及到网络平台层、高可用、监控和安全,大概这几个模块。

标准里面比较细的项目,专家会关心每一层提要求,容器管理平台层的要求,要求具有统一的门户、要具备资源集群服务调度能力、容器注册能力、获取容器节点信息、具有容器发现能力、企业私有镜像仓库、集中管理容器应用的配置属性;支持常驻服务和批处理服务,相当于对每一层的要求都提了比较细化的要求。

5、微服务的标准,这个标准也是针对需求方提的想做成熟读的评估,这个标准也是涉及到了几大块,业务框架,微服务框架能力要求、治理能力、微服务架构应用的安全要求、微服务架构应用的质量要求、微服务支撑技术能力需求共这几个方面的能力要求。

当时画微服务的架构图也是从底层基础设施层承载微服务的预载环境包括支撑技术,支撑层要求要具备配置中心、消息中心、日志中心、电容电路管理、监控管理、保持数据一致性、CICD。还包括服务框架,实现微服务架构应用的基座,提供应用的构建运营管理能力,再往上是服务治理,包括公共服务和行业领域的服务。

有三个标准还没有完成,一个是基于容器的成熟度模型,这个标准还在制定中,我们会基于容器的云计算平台架构标准,继续扩充基于云计算的成熟度模型的标准,这个标准和刚才介绍的基于云计算架构标准的区别是什么,一方面考虑了技术架构的能力要求,另一方面会考察需求方的部署应用情况,会考察部署规模。这个应用系统迁上容器的概率,也就是说相当于从应用角度考察它的成熟度。

另外一个标准在制定的是微服务架构成熟度的模型,同样除了基于刚才微服务架构的标准之外还会考查业务的应用情况,部署规模。

目前正在做研发运营一体化,因为业内关注度比较高,所以目前已经成功立项,应该会在接下来两三个月集中做。智能运维方向、私有云成熟度、数据服务都是我们下面重点考虑的方向,大家如果有标准需求可以提给我们,我们标准立项以企业需求为主,同时调研整个市场的情况做整体牵头立项。这是第一步,下半年继续做标准。另一方面会做评估测试,评估测试共五个标准,其中保险行业云服务提供方的要求可以针对甲乙双方都做评估,虚拟化软件主要针对供应商做评估。成熟度针对需求方做评估。

在不久的将来,云计算一定会彻底走入我们的生活,有兴趣入行未来前沿产业的朋友,可以收藏云计算,及时获取人工智能、大数据、云计算和物联网的前沿资讯和基础知识,让我们一起携手,引领人工智能的未来!

标签: 安全 大数据 服务商 工信部 公有云 互联网 互联网服务 互联网公司 金融 网络 信息安全 云服务 云计算 云计算架构 云计算平台 政务 转型

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点!
本站所提供的图片等素材,版权归原作者所有,如需使用,请与原作者联系。

上一篇:云数据存储怎样解决数据寻址安全问题?

下一篇:专业技术畅游在云计算风口浪尖