开始之前做个自我介绍，我在招行工作快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实施框架和路线图。第四就是从痛点入手，选择合适的试验田。第五就是在成功经验的基础上，全员推动。第六就是培养习惯、建立度量、持续改进。包括我们现在，我们的工具链相对比较成熟了，也感觉还可以了，但是具体团队去执行的时候，其实也是有一些执行不到位的地方，这时候力只能不断的度量，不断的改进，不断培养大家习惯，刻意练习。
以上就是我今天的分享，谢谢大家。
热门专题
