使用CALISA加快企业创新的脚步

标签:CA互联网金融保险电子商务

访客:22063  发表于:2014-05-16 15:35:22

                            王志明   CA公司中国区应用交付事业单位解决方案客户经理

王志明:各位领导,下午好,基本上CA现在我们在国内,大概有400多个同事,接下来我会跟各位分享一下,延续刚才毕老师所说的一个概念,就是创新,我觉得现在创新是一件十分好的事情,但是当我们创新的时候,我们不要忘了说,现在支撑整个保险公司的业务的,其实都是IT,IT背后其实就是软件,现在我们相信各位都听到一个很大的挑战,如何快速把这个软件推出市场,或是把这个软件完成我们开发的工作,测试的工作,我觉得现在都在面临的问题。今天下午我也不多讲产品,我基本上跟大家分享一个新的概念,叫持续交付。也就是现在在欧美很流行的一个词,开发运维一个整体的概念。
    我们现在先介绍一下CA,CA在1976年成立,我们的总部在美国纽约,1995年进入中国市场,我们是全世界第一家大型软件公司进入中国的市场,已经挺多年了。而最近的数据,我们是全球第六大的纯软件的厂商,一年大概我们的营业额接近45亿到50亿美金左右。
    其实我们看这张图,我们看得出来,在每60秒内,其实在整个世界范围内,基本都会发生,我们看到有这么多数据的转换,其实这背后代表些什么东西呢,这背后代表了,其实我们是有很大很大的机会的。我们现在看这个趋势图,我们看右手绿色的趋势图这里,这是业务带来的需求,特别是现在的保险行业,我们外面所谓的保护,所谓的潜在客户,他们有很多种不同种类的需求,比如说现在我们开始推出的微信银行,是不是有必要说,我们在微信上面提供一个保护服务,我要保障在微信我的银行上面的,我的这个交易的安全性,我可能需要这样的保险。这些机会我们是不是有抓紧,其实答案我们大家都很清楚,其实很多时候我们抓不紧的,因为IT我们的创新已经停滞不前了。到底是什么阻止大家呢?抓紧这些机会,把这些机会转换为我们的盈利,然后市场占有率。
    其实说翻了就是一个复杂度,可能我们在公司内部,常常遇到的一些阻碍和状况。这是通常我们在一些IT部门常看到一些不同角色的同事,一些人员,我们有开发人员,测试人员,运维人员,开发人员常常会告诉我们说,我用70%的时间在等待,我要等待其他部门给我相关的资料,我在等待设计的完成,我在等待其他人把他的工作做好,我们才能一起做一个集成。测试人员也常常遇到这些温和,比如说环境准备,我的环境已经没有了,环境只有一套,通常在测试的时候,我们都会遇到这个问题。我们整体的平台,完整的平台可能只有一套。但同时间很多项目组需要争这个环境,需要用这个环境,我们应该怎么去解决?正常的做法就是,你就等吧,这个应用是第一名,这个应用是接下来的重点应用,其他项目组只能排队,等他做完才轮到你在用。比如我们的测试人员会告诉你,我们的测试环境一点都不真实,我们在测试的时候,我们的应用都无可避免的在今天,我们需要连接到很多不同的环境。有些环境是内部的,有些环境是外部的。很多时候我们遇到的特别是外部的环境,比如我们接到保监会,很多时候这些环境基本上不可以用的,所以这个往往造成的就坐在那边等,他什么事都不能做,就是协调环境去等。
    各位是不是做过一些统计,这些人等的时间,其实大大的多过他们实际在工作的一个时间。以运维人员常常会说,我不知道下一步什么东西,我常常都在救火。最一张业务部门的主观,常常都会我们说,你们IT在做什么事情,我今天这个应用是十分中的,这个是我们今年内部公司内部,这是一个指标性的,我能超过对手的这些保险公司,我就靠着这个应用,今年推出市长的速度来占有这个市场,或者推出一个没有人想到的应用。谁能想到,虽然想到,其实支付宝会推出余额宝,在推出之前没有任何人想到,如何的去应对这样的挑战,这个创新呢,其实成为今天不只是金融,金融已经遭遇了余额宝。再保险行业我相信不久的将来,会有这样突破性的产品出现。当如果遇到这样挑战的时候,我们内部本身的竞争,和它竞争的应用能快速的推出来,这是我们现在所需要考虑的一个问题。
    其实从这个图上我们可以看,我们经过客户的调研,我们发现说,绿色的部分是真的在使用的时间,灰色的部分是等待的时间,我们可以发现,其实很多不同的同事,很多时间他们都用在等待上,其实他们都没有在做应该做的事情,如何把这些等待的时间利用起来,如何加快同事们的效率呢?这是领导们所需要考虑的一件事情。
    接下来跟各位分享一个我们应该怎么做,我们先看一看,运维人员眼中的研发人烟,也就是这样的一个人,我们看一看,研发人员眼中的运维人员,你就每天跟机器打交道,每天跟网线打交道,这就是你的工作,其实这张图告诉我们什么呢?告诉我们的,其实开发人员与运维人员之间这双方整个IT部门里面,两大组主要的组成部分不同的同事,他们在思维模式上是有差别的。我们拿一个应用来说就好了,运维人员说我这个运用最好是十年不改变,我只要稳定就好,但是开发人员说,我必须把最炫的功能加在里面,我要让我的客户体验到,其实我们这个东西是很好用的,我们推出这个应用是很方便的。这个是开发人员和运维人员一个基本的差异点。
    我们可以看到这个词DevOps,开发与运维,这是在荷兰发生的运动,在欧美已经发生了,它最重要的概念,如何让这两大块,开发人员、运维人员,开发部门和运维部门如何更好的无缝的合作起来,最后达成了1+1不与2甚至大于2,1+1要等于5或者以等于10的效果出来,如何做到呢?就是我今天给大家分享的概念。
    CA来说,我们有自己的四个C的定义,这四个C的定义,第一个定义是无限制的开发环境,第二个C是持续的应用交付,我如何的在应用开发完成,测试完成之后,快速的交付到不同的环境上面去,第三个是我上线之后如何的很有效的去监管,去确保说我在各自工作当中,透过一个协作的方式,最后一个C把这个数据倒回去到开发上面去,有谁曾经想过,说我在生产的环境,比如我现在生产的环境上,或者我进行我测试的时候,我要做集成的时候,我找到哪一些问题,我能很有效的把这数据全部保留下来。回推到我们的开发人员手上去,让开发人员更有效的利用这些数据,更有效的进行修改。而不是使用现在的方式,再找问题在那里,再慢慢码我的代码也好,把问题找出来,其实这个是有办法做到的。
    第一个我这个事业单位图一个产品,我们叫服务虚拟化,基本上做的一些事情,就是把我们应用通常我们在测试的时候,我们所连接的第三方的环境,比如说刚才提到的保监会,银联都好,甚至内部的一些平台,我就透过一些手段,把它选出来,它做一个假的,把它上面的服务做出来,我们称之为服务虚拟化。当我做出来之后,我可以达成几个效应,第一个,我能让各个开发团队拥有自己要的环境,比如你今天需要连到保监会,我十个应用都连到保监会去,我把她看成一个很大的状况,每个项目组用到的所有的接口的环境,不管是内部外部,我都做出来一套给他,透过这个方式,我同时间把我们等待的时间去除。现在如果环境只有一套,每个环境都要等。每个项目组所需要用到的这些接口,这些核心的应用都好,我其他一些比如核心的交易都好,我就把它学习出来,我就给每个团队,透过这个方式,我就能达成真正的并行的开发跟并行的测试。这是第一部分,就是服务虚拟化。
    第二部分,自动化的发布,自动化发布所做的一件事,就是如何的把我们的应用当我们做好之后,如果的透过一件事的方式,把它从哪个环境,比如发布到我的生产当中去,来减少人所失误的操作,我不知道保险业的客户,但是我金融业的客户,常常会有这样的问题,我们的发布人员其实每天都在加班当中。如果没上到生产环境中,没办法快速部署到生产换取让他使用的,其实这等于做和需做是一样。
    第三个部分,我们有一整把的保障解决方案。数据挖掘和我们传统大家了解的大数据挖掘还有一点差一点,我们这个数据挖掘主推的,比如说今天在我的测试环境,在我的可能在做功能测试的时候,如何很的有效的,把我们测试人员发现的问题,背后所有的流程,把它挖掘出来,保留起来,把这个流程准确的让我们找出我们的问题到底发生在哪个点上,告诉我们的开发人员,开发人员可以针对这单一的点,进行修复。这特别对我们现在的很多我们的应用都是外包的状况底下,这特别有效。因为很多时候,我们做测试的这个外包商,未必是这个应用的开发商。可能这个整体大的应用有很多在里面,但是厂商有外包在里面做,他们不知道这个应用背后是什么在运行的,正常的状况就是我们找到问题的时候,我们再去找看到底是谁出问题,如果我们透过数据挖掘,我们就能很准确的,当发生问题点的时候,产生一个流程图,告诉我们的测试人员说,刚才执行的这笔交易到底走过了谁,走过了哪个阶段,到底调过哪一些代码,到底执行了那些,全部把它抓出来,投入流程图的方式,把这个流程图交给开发人员,它就能很快速的找出问题所在。这个是数据挖掘的部分。
    接下来这才是今天的比较重大的一点,也就是我今天最后一张的图。这个是我们在全世界范围内,我们一些大型的客户,达到的一个目的,他们所达到一个高度。我跟各位分享一件事,各位是否曾经有想过,一天之内你能在你的环境里面发布500次应用,这个或许现在任何人听到都会觉得吓一跳的事情,但是我们有几个事情一天能在整个环境里面,发布500次的应用,甚至有一家客户的ING,他跑来告诉我们说,我们打算在两年内,达到一天我要发布1000次应用。这个事有没有办法达到?其实大家今天听之前,或者国个觉得说,这个是天方夜谭,但是真的有很多大型公司也好,金融公司都好,他们已经做到了,我们来看这张图,看我们怎么来实现这样一个一天发布500次、1000次这样的目标。通常我们来做的时候,都有开发人员开始,我们会写我们的代码,写完代码之后,正常的做法就是把代码放在代码库里面,然后做的就是可能我们有一个持续集成的工具,比如说一些封装的工具来进行封装。到这一步为止,都是我们大家每天再的事情。
    接下来它导入的概念就是,当我们封装完之后,我们就把这些所产生的工件,我们再一个工件库里面,这也能当做一个版本库里面把这个工件当做一个版本。比如我是版本一、版本二、版本三的应用,我就放在工件库里面,下一步能做的,其实调用了我们刚才所说的自动化发布的这个工具,调它之后工具库做一些什么事情呢,会到工件库里面,把最新的工件抓出来,它会自动的,比如我们现在在测试环境,会自动的把这个环境发布到上面去,它会调用我们这个服务虚拟化的部分,我们这个工具能发起这个请求,测试用力到我们的应用上面去,发起请求可能透过网页的形式直接发起,或者我们通过直接连接的方式它也能做。甚至刚才我们新致的同事提出,做神行太保的这个。透过服务虚拟化我们发起测试,后面我们再模拟第三方外部的接口,来对我们SID上面的这个应用,进行我们的测试。当我们测试完之后,我们当然会告诉我们持续交付,这个自动化发布的工具,告诉他说OK我到底是不是测试完成了。当我们完成之后,下一步所有的工作,我们都一直在重复,就是我们透过我们这个自动化发布的工具,会持续不断的当我在SID环境里面做完之后跟我的测试的执行,全部都是自动化的做完。当我做完之后,相对的报告回来,如果是准确的,我能发布到下一个环境上面去的时候,我就投入自动化的方式,一步一步的往前走。不同的环境上面,我就使用这个方式来进行一个发布。当我发布完之后,要上生产环境之前,通常我们也能跟一些变更管理,一些解决方案,或者是一些配置管理,一些比如说基础架构的管理解决方案来做一个集成。
    当我们跟这些做完集成之后,通常的比如说你把这整个变更的这个步骤,设计的很自动化,把所有规则定义好,其实它是有能力做一个自动化的评估说,我这个应用到底能不能上生产环境,如果这个变更管理的工具配置好,做好之后,我们这个自动化工具沟通之后,发现说OK,我能上生产环境了,下一步要做的就是部署到环境上面去,但是这还没完,我们现在遇到一个问题,我们传统在发布应用到生产环境上面去的时候,我们发布上去为了验证这个软件,我们这个应用是不是发布成功,我们常常做的一件事就是我尝试登陆看一看,尝试点两个链接,如果没问题的话,我估计应用已经发布成功了。因为在生产环境上我们没办法做一些真实的交易来验证我们这个应用。
    所以在这个时候,我们可以透过服务虚拟化的部分,来做一些测试,在最终上生产环境,所有完成只求,我们这个自动化的工具,将会发邮件也好,寄给相关的领导,相关的同事们,然后说这个应用已经发布成功了。
    所以各位从这个图上面看到一点,开发人员从他把代码放到代码库,中间没有任何人的环节,我透过这个方式,我们的经验已经告诉我们,我们可以帮客户节省了大概60%到80%应用的上线的时间及因为我们发现,很多时候我们在做应用的时候,常常遇到的问题,其实总结只有一个,就是等待。我们大家都在等,如何把这个等待的时间去除,这是我们为了创新,就像我们毕老师所讲的我们为了创新,我们推出很多新的服务,甚至我想在座的各位都有统一的目标,如何快速提升我们的竞争力。
    但是如果我们不尝试,不去想如何解决应用,到最后上到生产,中间这个浪费时间的问题,我们将永远没有办法做到这一点,谢谢。

评论(0)

您可以在评论框内@您的好友一起参与讨论!

<--script type="text/javascript">BAIDU_CLB_fillSlot("927898");