开始之前做个自我介绍,我在招行工作快16年了,见证了招行研发从200人到快5000人的规模。我到招行第一件事情就是搭建源码配置管理系统,然后是CMMI体系的二级三级评估,在几年前开始参与敏捷、看板、精益的研究推广。

陈展文

我本人主要负责DevOps的研究、推广和改进的相关工作。同时,除了实践推广,很重要的就是DevOps工具链,我们也是跟业界一起把工具链建设了出来。此外,现在正在参与招行的精益研发体系的建立和招行的数字化转型

今天我介绍的内容主要分这几块:一是业界对DevOps的理解;第二部分是我们招行对DevOps的理解;第三是分享招行DevOps实践和规模化推进经验;最后说一下我们参与DevOps标准评估情况的介绍。

第一部分是对DevOps的理解。相信大家都看过这一幅图,所谓的盲人摸象,不同的人站在不同的角度说DevOps是什么,有各种不同的说法。相信大家都会有这个困惑,包括我在一开始接触DevOps的时候也是这样。现在不同的人、不同的组织对DevOps都有不同的理解。维基百科中关于DevOps的定义说了很多,有几个点可以着重给大家分享一下。DevOps的目标是缩短开发周期,提高部署频率,更可靠地发布以及与业务目标一致。这一点最近我们特别有感受,就是你做的事情一定要跟业务目标一致,否则,你做的事情不是业务想要的,你做得再快,做得再多也没有用,所以这一点非常重要。

招行有一个Fintech基金,从三年前开始,每年从税前利润中拿1%,大概8亿元,作为Fintech基金,去年涨为营业收入的1%,大概25个亿,今年大概到28个亿。今天谈到的工具链建设,很大一部分都是依靠这个基金支持。在这个过程中,非常强调一点,就是注重MVP,你可以有很好的想法,但是一开始不要想的太大。你可以从一个小处开始做技术验证,如果OK继续投钱,但是如果发现做下来并不是你想要的,马上停止,这就是所谓的要跟业务目标一致。就是通过一些小的方式做试错、试验,确定是市场要的东西才往前走。

接下来给大家介绍一下结构方程式,这也是来自于《DevOps状态报告2017》。这个方程式为什么我一定要拿出来说,领导一般会问一个问题,投入产出比如何?在推DevOps的过程中,收益其实是很难直接衡量的。这个方程式讲了一件事情,就是首先企业要有变革领导力。我们的董事长、行长、总监都非常支持我们做这件事情,而且不是从口头上说的,是有资金的支持,这是非常重要的,支持我们变革,支持我们做这件事情。第二个我们要做各种实践,包括晓玲分享了很多体系里的实践,都是能够帮助我们做持续交付,把它做好。有什么好处呢,有一句话,当这件事让你很痛苦,你就会想各种办法减少它的痛苦。运维也一样,当你一个系统每年只部署一次,也许每次部署需要两天你也无所谓。但是如果一个系统要求你每天上线、上很多次线,再用以前的方法就不可行了。所以当你要减轻痛苦的时候,你就会做持续交付这件事了。做好持续交付这件事情以后,我们的电脑部就可以更好地响应业务的需求,更好地支持业务人员打市场,跟同业竞争。以前是跟各个银行竞争,现在我们直接要跟互联网企业竞争,怎么样跟他们竞争,这个非常重要。做好了以后,对招行这个组织效能和商誉上也会有所提升。我觉得这个方程式对我来说是一个很好的证明,我拿它来说服领导,或者告诉大家你为什么要做这件事情。

这是2018年的报告,在刚才的基础上加了一些新的东西,从运维的角度,从持续测试的角度加了一些内容。去年的报告里加了一个J型曲线,这个很像招行这几年在推进DevOps过程中的心路历程。一开始我们做了一些工具,让大家整个效率有所提升,大家的感受都不错,但是随着技术往前走进入了一个低谷。因为进入了深水区,工具已经做了自动化,但是有很多东西是需要开发人员做的,比如说写分层的自动化测试等等。这包括以前历史的债务,因为你以前很久才部署一次,原来的债务不改无所谓,现在要求你越来越快的发布了,以前留下的债会影响你继续往前走。也许看起来一个需求只要改一行代码就行,但上线需要一两天,或者一两周,这可能是受以前债的影响,我们在经历这样的过程。但是当我们往前走,突破这个过程以后,就会进入到一个新的高度,所以这个J型曲线也是非常贴切、适合我们的现状。

DevOps状态报告设定了几个指标去看企业里DevOps的水平到了哪里,这个比较简单,没有DevOps成熟度模型那么复杂,这是对我们一开始改进来说很重要的、跟世界所有企业对标的几个指标。前面两个指标更关注时间,后面两个指标更关注质量。我们自己对标此时的水平在哪里,这个是比较简单的对标。这幅图是来自《精益企业》,他讲到当我们发布频次不一样的时候,分支模型、测试方法、软件架构都不一样,这有点像DevOps标准里所谓的一级、二级、三级,比较抽象一点,让大家有一个感受,这个也是非常重要的一个图。刚才讲到很多业界的,或者说这几年对我们非常有影响的几个图。

讲讲我们自己对DevOps的研究,我们从2014年开始刚接触这个概念了,也是会尝试用商业的产品做一些实践。初步的尝试是在2015年,我们真正开始系统研究这个概念,同时跟很多咨询公司交流,包括到很多企业比如华为、BAT、平安看一下。同时也开始参加各种大会。这个时候开始学习,融入到我们的系统里,做一些试点。我们第一个尝试就是技术债,看看我们的水平在哪里,一开始惨不忍睹,但经过这几年逐步完善,已经到了一个相对较好的水平。

2016年是真正的起步,过去研究了很多,真正体系化的推进需要自己的方法论,自己的主张、想法。我们就开始试点,同时想到只实践不行,我们还要有工具,以前都是买各种商业的工具,当我们大规模用的时候就出现了很多问题。

2017年我们开始建立自己的DevOps成熟度模型,当然没有信通院的模型完善。我们有四五千人,怎么样用简单的语言告诉大家你要做什么,这也是不容易的事情。

2018年第一个比较重点建设的就是我们的流水线平台,把它做好了其他的就快了。第二步是研发流水线打通以后,要考虑怎么把我们的管理和研发关联在一起,实际做的和声称做的不是同一套。我们想通过这种方式把工具链、工程做起来以后,跟管理一定要结合在一起,你才能发现中间过程的问题,或者拿到相关问题的度量。今年我们还是在持续改进,对标优秀的企业,优化实践,持续改进,这是招行在推的过程中的几点内容。

接下来给大家介绍一下我们是如何大规模推进的。首先,要有高层领导的支持。正常会有两种模式,一个自底向上,高层领导觉得这是很重要的事情,然后就开始重视。但是真正去推动还是从下往上走,它有一些小成功,总结经验,高层支持。另外一种方式,就是高层领导很重视,成立工作组,在一个个试验小组推进,然后再在不同的团队里推进,最后到大规模。这两种方式没有对错,不同企业有不同的路径。我们招行更像第二种模式,领导很重视,自上而下推效率更高,我们高层一开始就很重视这件事情,真的是一把手工程,有很多东西如果没有高层领导支持是很难推的。所以这是非常重要的事情,你要获得领导的支持,领导不支持就很难。

第二就是建立开放的文化。我们参加各种技术大会,开始走出去。然后到不同企业沟通交流,参加各种社区的活动,走出去是一方面,但是很重要的是引进来,或者是变成我们企业的东西,我们自己也会搞一个技术的开放日,开始请外部的专家,现在开始在内部也有不同的话题,有不同的成果可以在内部呈现出来。当然我们一开始还是能请到一些国际知名专家,例如Martin Fowler(敏捷宣言21位发起者之一)。他两年前给我们讲的时候,就讲到了刚才的结构化方程式,他觉得这种研究方式是非常科学的。当时马丁看了以后,很希望他们把背后的理论讲出来,之后Jez humble(持续交付之父)真的写了这本书,把整个结构化方程式背后的一些理论的基础讲出来。这本书就是去年出版的《加速》,详细讲了结构化方程式背后的理论基础、统计学。为什么我刚才和大家分享这个图,包括这个报告,因个大牛马丁都非常认可,他说明了持续交付这件事情的重要性。我们也邀请过John Willis,他是《DevOps Handbook》的四个作者之一。通过这个方式让大家感受我们推的一些东西,我们内部也有一些DevOps资格认证,还有一些小的分享,还有各个团队自己都会举办各种的开放日,让大家感受这种氛围,内部分享等等。

简单总结一下我们实施的框架路线图是这样子的,首先就是我们要从目标出发,我们就是要又快又好交付有价值的东西,这时候我们要建立适合自己的线路图。非常重要的战略就是要提高速度,质量要好。自动化一切可以自动化的东西,不断优化流程,更好响应业务需求,最后需要总结我们自己的模型。在这个基础上我们要推工具,从工具的角度来说,我们的工具链还是挺复杂的,一开始什么都有,各种环节都有,有不同的工具,大家用起来还是挺费劲的。我们在两三年前根据这个做了重新的规划,对照业界的一些标准参考,大概定义了这几大平台。第一个做的比较成熟的就是流水线平台,第二步就是协同工作平台,怎么把端到端连在一起,第三源码管理和相关的配置管理工具,第四就是广义测试工具,包括自动化测试、案例的管理、运力运维,这块也是我们建设的重点,最后是度量分析平台,怎么样把这个过程的数据进行很好的分析,带来运营管理上的改变。

我们再把持续交付流水线打开来看,第一步要做的事情是持续交付流水线这件事情,我们用简单的语言表达,真正要做到的事情很多。我们简单的称为三级,一级叫做自动化编译,发布制品和静态代码扫描;第二级是自动化部署;第三级是单元测试和自动化测试。因为背后隐含很多技术,真正推的时候很难让所有人都了解,我们就把它简化再简化,尽量很多事情让工具做。编译这个大家好理解,但却是最重要的一点,因为我们的流水线平台,我们的行业工具链,框架很多,以前就是编译环境很难准备,或者有一些竞争的资源,或者编译的版本太多,很复杂,这是我们管理的痛点。这个看起来很简单,真正在一个企业里落地,你会体会到这是很复杂的事情,我们通过工具简化了整个过程,平台里能自动识别你是什么语言,什么框架。第二就是静态扫描,技术债务,这个大家详细了解比较多,我不多介绍了。第三块特别讲讲我们的制品库,我们会发现,现在开源件用的容器,有很多编译的框架有很多依赖。最核心的一点,我们发现在推的时候,开发、测试和数据中心对于同一个系统或者同一个应用的定义都不统一,数据中心说的东西和测试说的系统和产品,跟研发中心说的,看似是同一个东西,但是他们本质上不是同一个东西,我们尝试怎么把这些术语统一,找到一个最原始的点。后来我们想到一个类似于发布单元的概念,它借用了Maven 的GAV三元组的定义,把所有的部署或者发布的基础单位都统一在这个框架下,其他都是排列组合。这个时候尝试把我们的术语统一了,在这个基础上做各种持续交付就更顺了。而且通过这个工具把原来散落在各个开发团队的管理方式,各种私有的依赖仓库、容器仓库统一起来。这看起来没有什么特别,但是在我们这起到了非常重要的作用,如果大家要在企业里大规模推的时候,这个库非常重要。

然后就是自动化测试,对于自动化测试来说,我们自己做的也不太好,特别是在要求部署时间越来越快的时候,原来累积了很多技术债,这也是我们努力的方向。

今天上午主题演讲讲到了开源,原来更多的是机会,现在更多的是风险。我们也看到了很多风险,我们也尝试把这个东西集成在流水线看一看,这个程序包里面有什么风险。

刚才讲到了很多模型,很多标准,我们推进的时候就要选择首先试验的场景要精心选择,一开始要选一些配合比较好的,而且即使出问题也不会影响太大的系统和团队去做试验。团队要相对技术能力比较强,思想要开放,系统相对要耦合,对业务连续性的要求会低一点,同时业务对开发的错误,效率的降低有一定的容忍程度。第二就是借外力、练内功,外来和尚会念经,我们还是舍得花一些钱去请外面的和尚念经的,这个也很重要。所以你知道可能没有你说的好。还有就是积极培养内部技术专家。

最后,在成功的基础上我们进行全员推动,比如我们的静态代码扫描作为门禁推了两年,不满足条件就不给上线,一开始大家反应很强烈,但是后来慢慢就习惯了,静态代码扫描作为UAT的质量门禁。制品仓库替代FTP,并与应用CMDB积极配合,应用发布自动化部署率超过90%,开放平台全部使用DevOps流水线。逐步加强单元测试、自动化测试、开源管理等等。

培养习惯、建立度量、持续改进,静态代码扫描,技术债、违规项、复杂度、重复率,我们会把一些重要的数据呈现给他们,不直接说你好不好,只是摆在一起,我们觉得这几个比较关注,但是谁好不好我们不评价。我们会有很多度量的指标,但是我们在不同的阶段,当我们推进不同事情的时候,我们会有不同的侧重,比如说技术债,我们重点关注技术债改进情况的时候,就会着重讲技术债的情况。这个就是一些指标,都是业界的好的事件,

最后我花点时间讲讲我们行参加DevOps评估标准第三部分评估的情况,去年11月份参加了第一次评估,我们有四个项目通过了。今年我们领导给我们更大的要求,我们要分四批参加评估,也是第三部分持续交付,我们目标就是对标业界的标准,找出我们推DevOps的差距,持续改进。我们自己的准备过程大概是这样的,对2018年评估的情况进行回顾,对一些弱项进行重点的分享,然后对分析报告里提到改进的建议,我们也是积极的改工具链,修改工具,同时我们也会集中学习第三部分的标准,同时参考标准和工具改进,在各项工作中重点提升相关的能力。

最后做一个小结。第一个就是高层领导的支持最重要,这就成功了一半,没有基本成功不了,高层领导支持非常重要,能有多高就多高。第二个就是努力建立开放的文化,走出去引进来。第三就是消化吸收,建立适合本企业的DevOps实施框架和路线图。第四就是从痛点入手,选择合适的试验田。第五就是在成功经验的基础上,全员推动。第六就是培养习惯、建立度量、持续改进。包括我们现在,我们的工具链相对比较成熟了,也感觉还可以了,但是具体团队去执行的时候,其实也是有一些执行不到位的地方,这时候力只能不断的度量,不断的改进,不断培养大家习惯,刻意练习。

以上就是我今天的分享,谢谢大家。

关注中国IDC圈官方微信:idc-quan 我们将定期推送IDC产业最新资讯

查看心情排 行你看到此篇文章的感受是:


  • 支持

  • 高兴

  • 震惊

  • 愤怒

  • 无聊

  • 无奈

  • 谎言

  • 枪稿

  • 不解

  • 标题党
2022-07-20 21:15:00
云资讯 剧透 | 2022可信云大会明日召开,八大精彩亮点一览
本届可信云大会以“云赋新能 算向未来”为主题,共设2个主论坛、10个分论坛。大会邀请了云计算行业专家学者、企业代表、行业大咖齐聚一堂,从软件工程、云治理、容灾、多云 <详情>
2022-07-13 10:52:00
云资讯 2022可信云大会 | 中国信通院云上软件工程评估结果即将发布
随着云计算应用的不断深入,软件研发正逐渐向架构分布式、流程自动化、应用轻量化的形态发展。 <详情>
2021-11-09 16:50:18
互联网 Akamai发布新解决方案,应对日益增长的API安全威胁
今年九月,Akamai在Gartner“Web应用程序和API保护魔力象限”(Gartner MagicQuadrant for Web Application and API Protection)报告中被认定为领导者。 <详情>
2021-07-29 17:22:56
云资讯 可信云大会官宣,腾讯iOA获中国首个零信任产品测评认证
腾讯积极推动工作组的标准化成果与行业其他相关标准的互认工作,促进不同厂商的产品互联互通,为产业协同发展贡献力量。 <详情>
2021-06-23 18:35:00