敏捷与DevOps 在中信银行的落地与实践

未分类

作者简介

史立龙

我跟雪峰老师一样，也是今天第一次做直播，我先做一个简短的自我介绍，我是史立龙，来自于中信银行，我之前做开发，做测试，也做过敏捷管理，去年一直在做开发、测试、持续集成、敏捷跟DevOps。

今天给大家分享的这个主题是敏捷与DevOps在某银行的落地与实践，主要就是今天结合我去年一整年的推广跟落地的经验来给大家做一个输出，同时也会结合我们手机银行团队的实践的整个过程，来让在座的各位可以深入了解到我们中信银行还有团队是如何进行数字化转型的。

今天分享的议题主要是四个方面，第一方面会给大家简单介绍一下组织级敏捷转型的背景。第二部分会从组织级敏捷体系还有试点推广的两个维度，给大家介绍一下在我行的一个实践推广的过程。第三方面实际上是一个干货的分享，结合我们手机银行团队落地的经验跟大家做一个团队级的实践的经验分享。最后的话是2020年的转型思路。

1、组织级敏捷转型的背景

其实从整个金融行业的十三五规划，目前来看其实对于整个银行科技部门，就是我们一直提产能是非常重要。什么叫产能？产能就是快速交付业务需求，然后我们也是前期经过这种大量的摸索，我们也想通过敏捷跟精益这两点来提高我们的交互能力。主要是为了进行我们全行的数字化转型。这个阶梯来看我们在2016年开始初始敏捷，最早是在手机银行团队进行了Srcum敏捷实践，同年也获得银监会的科技风险创新奖。

2017年从我行很多部门我们也选取了一些团队做敏捷实践的尝试，我们也在一些大型的项目里面做了多团队的敏捷实践，比如我们手机银行4.0。2018年开始我们进行了多层看板的初探，同时我们也做了一相应的CI/CD的能力储备。直至到2019年上半年开始正式启动DevOps的项目建设，5月份开展了平台建设，同期7月份开始整个体系文化的建设，从9月份也就是我这边主要是牵头整个中信银行市场推广，这一块的工作，从9月份开始正式启动。

其实从整个去年来看我们全年到年底的时候收益还是比较大的，我们试点的团队有三个团队达到了三级评估的标准，同时我们也是以试点为抓手，充分验证了组织级的体系和平台的能力。

2、组织级敏捷在某银行的实践

其实我们在转型过程中遇到了很多的问题跟挑战，首先其实最主要的就是这个组织级敏捷管理体系，组织级敏捷管理体系目前我们已经输出了2.0的规范，当然也在持续的输出中，其实在落地验证的过程中，也发现很多问题，因此我们也是持续的一直在改进。第二部分我们的平台，我们也是以试点为突破口，通过试点团队的这些应用去不断完善我们的平台能力。

还有一个是试点推广，试点推广主要是我这边负责，其实很多这种大型企业我们做敏捷试点推广的时候我们都会感受到，其实前期我们需要花很多的时间还有精力去给团队还有部门还有领导做一些宣贯的动作，因为可能会跟他们一些传统的思维有碰撞，所以我们在整个转型过程中试点这一块我们也是投入了很多的精力。最后的话就是文化建设，因为主要还是在传统技术文化氛围的包围中我们怎么引入精益敏捷的思想。

整个我们组织级敏捷管理体系其实是采用了一个跟稳敏双态的一个模式，什么叫稳态开发模式？稳态开发模式其实从这个上面可以看到我们主要是基于传统的瀑布模式我们进行了一些精细化的改造，主要是为了支持需求稳定，还有维护改造行为这种项目的实施。

同时也引入了敏态的开发模式，主要是为了支持需求变化频繁还有市场一些不确定性比较高的项目建设。同时我们还提供了混合态的开发模式，主要是为了适应我行这种项目复杂，关联系统比较多的现状，我们同时也通过我们的精益看板进行了组织层还有项目层的透明化管理，从而我们去达到了我们系统间还有项目间的这种协同。

我作为试点的负责人，其实我们从去年整个全中心来看我们选取了9个试点团队，主要的目标也是通过敏捷实践和功能实践，去验证我们的平台跟体系，从而达到了一个可以提升我们团队的研发效能。

敏捷实践这一块我们实际上基于我们组织级敏捷管理体系，从我们的培训、辅导、培养还有指导这几个方面去引领、带领这个团队做敏捷转型。工程实践我们也是从需求管理、配置管理、持续集成、自动化测试、持续交付这几个能力项去带着团队做我们整个工程能力的提升。

整个全年来看其实我们主要也是通过试点去一方面验证我们的体系还有平台，还有一方面我们也是从去年开始整个敏捷还有DevOps的转型，然后我们全年也是一直在培养我们的敏捷教练还有我们的工程教练。

我们是整个试点的实施进程主要分四个阶段，首先第一个阶段就是我们会先圈定整个试点的范围，前期也是根据内部团队的敏态的程度模式，去做了充分的调研还有差距分析。

启动阶段主要做团队还有部门级还有领导级的一些松土还有宣贯的动作，我们也是去办了一个大型的试点的启动会，同期我们也组织了整个敏捷方面还有工程方面的培训。

整个敏态稳态推广的阶段实际上就是由我们组织级的敏捷教练还有工程教练去带着团队去做我们的敏捷转型还有我们的工程能力的工具的接入。最后的话验收我们也是在去年年底举办了两期最佳实践分享会，同时我们也输出了我们自己银行内部的敏捷能力成熟度评估的模型，然后给更多的试点团队进行了试点的验收。

从去年整个试点来看，其实工程方面这块的收益可以简单说一下。持续集成方面就是我们通过我们的CI/CD还有我们的企业级DevOps平台，我们减少了项目组的人工投入的同时，也极大提升了我们的交付效率。另外这个今年一直在喊的就是内建质量，内建质量其实一方面我们在去年CI/CD流水线上我们有集成我们的质量门禁，还有测试化，就是安全扫描等这些措施，然后层层把关我们的代码质量。

我主要先说一下最后这个团队自驱，去年我们在建设DevOps平台的同时我们也是启动建设我行的一个度量平台，相当于在整个流水线或者持续集成的过程中所有的项目数据我们都可以通过我们的度量的平台做监控，项目团队拿到这些数据可以进行一个持续的改进跟优化。

其实这一页应该就是所有人比较感兴趣的，它是一个我们企业级DevOps工具链的全示图，我可以简单跟大家说一下，就是从需求处理阶段就是上面需求经理跟项目经理，我行主要是使用的PLMP这个工具去做项目协同。进入开发阶段实际上是所有的操作都在DevOps平台里面，主要提供了主要的两大功能，一个就是电子看板，精益看板，还有一部分功能就是持续集成CI/CD这个过程。

其实从开发人员来讲，在DevOps平台首先他的版本管理工具是用我们行里统一的Gitlab，就是这种版本库，我们的CI流水线也是集成多个节点，里面包括了我们的单元测试、代码扫描、安全扫描，还有SQL扫描。然后CI集成完了所有的制品我们会统一放到我们测试环境的JFrog的制品库里头。

CD的流水线我们行里也是统一测试环境和生产环境都是用的统一的Entegor工具，会从我们测试环境我们JFrog这个制品库去拉取我们的制品，然后去部署到我们对应的测试环境上。其实第六部分这一块我可以简单说一下，就是在我们的CD流水线成功部署到测试环境上，我们的一体化平台也会通过测试的服务云平台去调度我们的内部的这个接口仿真测试工具，实际上它就是一个我们自己研发的自动化接口测试工具，主要它在流水线里面的作用就是为了验证我们接口其实这种环境部署，就是相当于它会做一个测试的动作。

当我们的产品已经进入了投产准备工作，会移交到运维这一块，实际上这一块已经到数据中心了，数据中心这边我们的部署工具也跟测试环境一样，都是Entegor的测试工具，相应的制品我们也是由测试环境制品晋级过来的，Entegor生产的这个自动化部署工具会从我们生产的JFrog的库去拉取我们晋级过来的这个制品，然后部到对应的生产环境上。

三、手机银行团队的落地实践

下面的话会给大家主要讲一下我们手机银行团队的落地实践的分享。去年手机银行团队下半年一直在做三级评估，其实就是从这个可以看到，我们在做评估之前，其实之前也是几个专家给我们评估过，我们当时的分数是1.78，一直到最后是3.1。其实右边那个部分3.1的这些内容我觉得其实可以不用说，我想给大家描述一下1.78的时候我们团队当时是一个什么现状。

首先是我们的版本控制，我们当时手机银行团队因为当时扩充比较严重，目前已经有一百多人，里面主要包括前端、客户端还有服务端。我们上线频率也是非常频繁的，基本一周可能会上个2-3次，因此我们当时的版本分支我们并行的版本分支非常多，而且我们当时没有专职的办公管理人员，所以我们每次在发版的时候，至少要占用开发人员0.5天的资源。

另外的话就是我们的变更管理，我们的变更管理就是当时也提交代码，也没有办法追溯到我们的变更内容，还有构建与持续集成这一块当时也没有一个统一的构建部署的发布计划，而且当时集成经常报错，我们有时候会解决一个部署问题，可能一天测试人员都没有办法在测试环境上测试。测试管理的话基本上我们当时是很少有自动化测试接入，基本上都是纯靠人工测试为主。这个度量反馈因为所有的这些数据指标我们是没有体系去做监控的，所以当时基本上这块能力也是欠缺的。

其实我们今年一直在跟试点团队一直在说，其实敏捷转型，敏捷这部分主要还是工程能力，就是持续集成这一块，刚才雪峰老师也说它不光在CD，是一种一整套的完备的体系，从这张图也可以看到，通过我们CI/CD持续集成，可以缩短我们的拓展准备时间，而且它在每个环节都可以形成研发的闭环，我们也通过我们敏捷的实施的管理模式，也可以形成一个业务反馈的闭环。

这一页主要给大家介绍一下我们转型前的持续集成，其实这个图对于我来说非常有意义。就是说这个图因为是我们当时2018年的时候我们企业级还没有做DevOps平台，我们当时因为就是手机，我主要是负责手机银行产品线，我们当时业务需求非常多，基本上发布时间也比较不固定，然后我前面也说了，我们当时的现状基本上就是我们版本管理非常混乱，运行版本非常多，每次部署至少需要一天或者半天的时间，所以我当时也是基于这个开源工具，我自己搭了一套属于手机银行的持续集成平台。里边主要就是开发测试环境的流水线，里边覆盖的技术栈就是我们前端的VUE，还有中台的JAVA，然后还有IOS和安卓两个客户端。

主要的流水线节点也是所有的版本管理都是每个技术栈都是分户做管理，统一分到Gitlab上，然后里面的流水线我们当时也集成了一些静态检查，包括前端的Eslint，还有oclint、infer，还有JAVA的CheckStyle，同时我们也在流水线里边也集成的Sonar扫描，我们也同时一直补充我们的单元测试案例。自动构建其实就是传统这些构建工具，包括前端的WebPackage，Maven，Xcode，还有Gradle。

其实可以看到制品库这一块，因为当时我们2018年，企业级也没有做JFrog的制品库，我当时也是找了一台HTTP服务器，相当于充当我们测试环境的制品管理，所有这种客户端就是我们打出来的包我们都会放到HTTP的服务器上，可以让所有人去下。

然后测试环境部署这一块，当时行内的 Entegor 的工具也是不支持我们调用，所以当时我也是相当于绕了一个弯路，也是通过下游去部署测试环境。所以通过这个简单的流水线，相当于我们在2018年简单的实现了CI/CD，主要就是为了快速和高质量发布我们的手机银行相应的产品。

随后的话就是去年我们开始做企业级DevOps转型，我们也是相当于是试点团队中的一员，我们也是配合组织级的这些工具做了一个逐步的接入，里边其实可以看到，我们代码质量检查这一块的话也是集成了我们统一的工具，整个代码质量反馈比如说安全扫描，我们也是接了CHECKMARX，制品管理的话我们测试环境跟生产环境两套，都是JFrog制品库。然后一体化平台的使用就是这个是2019年我们重点建设的一体化平台。这个平台也是跟我们行内的这种比如说测试云平台还有接口反馈工具做了端到端的打通。然后整个度量平台就是前面也介绍过了，2019年我们同时也正式启动来建设我行自己内部的度量平台。

其实我当时在流水线设计的时候，主要考虑四个方面：一个就是分支策略，去年手机银行做认证评估的时候能力项不是太高，因为手机银行比较特殊，我们一周可能会发2-3个版本，所以分支策略一直是我们比较头疼的事，后边有一些具体的分支策略的介绍。

第二方面就是执行频率。执行频率其实从一方面可以反应出项目的敏捷实施程度，但是我一直觉得流水线的执行频率也不是说越高越好，我觉得主要得结合项目组具体的情况，去制定相应的一些集成还有部署的计划。

第四部分主要就是部署方式，因为之前实际上就是前面我们2018年做的一套流水线是有一点问题，我们在开发测试环境我们是通过ssh去部署，但是实际上我们的Entegor去部署的，这个部署方式我一直是觉得是持续集成流水线里面比较重要的环节，因为我当时一直跟团队说，生产我们用什么方式部署，测试我们就要用什么方式部署。我们所部署的这个制品包也要唯一，因为如果在这个中间有哪个卡点有问题的话，实际上我们投产上线是非常危险的。

这一页主要给大家介绍一下手机银行的版本分支模型。其实从图上可以看到，整体我们可以看到，其实不是一个传统的分支的模型，实际上可以理解为分支开发、分支发布，然后我先简单跟大家说一下。就是Master的分支实际上是我们的生产分支，我们的测试分支可能会并行开发有很多，因为我们上线比较频繁，大概目前疫情期间我们基本上最多一周会发四个版本，所以我们测试分支，我们可能会并行很多。同时我们也会有一个Dev的分支，这个Dev分支实际上是一个被保护的分支，所有的测试分支最终都会MR到这个Dev分支，咱们可以理解为Dev实际上就是一个主干分支。

然后还有一个就是我的debug分支，这个分支主要是为了给客户端，给开发人员打我们的不更新客户端，因为开发人员有的时候做前端的人比较了解，需要打这些不更新客户端去连测试环境，去验证它的功能。所有的这些分支我们都是使用流水线自动去追打，实际上从分支模型可以看到它都是MR往后去追，每个分支在发布以后我们也会通过MR的方式把Master的分支去合办。同时我们会发布打一个Tag。

这个是我们的一个提交构建流水线，然后主要也是可以覆盖了我们四个技术栈，基本上就是我们前端的web的VUE，还有我们中台前置的JAVA，还有IOS客户端跟安卓客户端，所有仓库的这些开发人员在提交代码以后都会自动触发我们提交构建流水线。然后里边主要就是其实就是常规的构建的节点，包括我们的经常检查，还有构建，还有一些单元测试。如果是说提交构建会导致整个版本的集成报错，我们也会通过系统给相应的责任人发邮件通知。

这个就是我们整个的流水线的模型，主要就是手机这边。其实我们主要看这个Version这个分支，我们可以看到，所有的流水线都是poline，里面主要是分三个流水线分支，一个就是前端web这一块，里面所有的节点也是包括我们的CI/CD，CI里面可能会集成Soncar Scan，Build，打包上传

。CD也是通过行内的工具去部署。PRE就是我们手机银行中台，跟前端不太一样的就是中台有持续的我们的案例。

还有客户端，这一块我们会先给客户端的做一个Sonar Scan扫描，同时再做一个前端H5的打包。因为客户端打包是基于H5签名的包打，所以这一块会有一些串行的任务。整个Dev分支跟提交构建分支是不一样的，跟我们测试环境的CI/CD的流水线是一致的，我就不再详述了。

这一页主要介绍一下流水线的执行频率和功能设计，主要给大家介绍一下我们测试环境的部署流水线，目前我们测试环境的部署流水线，因为每天都有测试人员去测，我们还涉及到中台，所以我不可能就是随时去给他部。所以我们目前定的就是工作日每天四个时间，而且还是非工作时间，基本上就是我们的一早上班前，中午休息，还有五点半下班的时候会给大家去部署。

然后这一页就是整个部署方式，我们的部署方式也可以看到我们是测试跟生产两套Artifactory测试库，我们手机端所有的技术栈的这些CI的制品我们都会传到制品库里头，生产跟测试环境我们也是通过我们的DevOps平台进行一个电子部署模块的编排，相当于我们测试环境跟生产环境用的部署工具还有部署模块都是一套。

自动化接口测试也是去年才开始接到我们的流水线里头，因为其实我们去年在做实践的时候，我们开始本来想补单元测试案例，但是单元测试案例实际来看第一维护成本比较大，第二需要开发人员的要求比较高，因为对他的业务逻辑代码要非常清楚。

所以就是我去年也是跟我们的测试规划沟通，相当于我做了一个自动化接口工具，他也是相当于是模拟我们的前端，往我们的中台去发这种HTTP的报文，然后去年精益测试来看，我们从生产上去查了差不多一百个接口，基本上可以占的就是这一百个接口占到全天交易量的90%以上。

我们把这些接口形成具体的自动化测试案例，放到流水线里头，基本覆盖率目前可以达到70%左右，相当于每次我们的流水线做CI/CD的时候，在部署成功以后我们都会自动触发接口测试这个平台，去验证我们测试环境的冒烟。

流水线里边这个质量门禁其实你们可以简单看一下，其实这个例子主要就是我们中台的流水线，里边主要是包括我们的Sonar扫描，还有质量门禁。

主持人：大家稍等一下，史立龙老师的电脑关机了，正好这个过程大家有一些问题刚才有提到，就是我可以跟大家一块交流一下。刚刚有提到，有一个问提问给史立龙老师，我之前也跟他交流过同样的问题，所以我把答案给大家做一下说明。就是说制品库从开发环境到生产环境是怎么传递的？最主要指我们怎么打破这个开发中心和数据中心的网络隔离，尤其是在金融行业，这边最主要的点是说在史立龙老师的案例当中，没有采用Artifactory作为制品管理系统，然后制品管理系统在开发中心有一套，在数据中心有一套，这两套之间是从开发中心到数据中心是实时同步的。同步的目录是受配置的，主要是针对我们要晋级以及测试通过的制品，会实时同步到生产数据中心的Artifactory当中。所以最终部署的时候他们实际上选择的目录结构是一模一样的，所以在测试环境的部署和到生产环境的部署也都是保持一致的，这个也是像史立龙老师在案例当中做的比较好的地方，就相当于制品保证了它是统一的，也是保证它是完整的。因为从开发中心到数据中心，会把制品做完整性的交验，会避免原来我们传统的UFTB（音）这种模式，就是说最终传过去的包，可能会存在这个包在传递过程当中的故障，比如说有损坏，最终部署会失败等等。我看史立龙老师已经连接上了，大家稍等。

我下面接着跟大家说一下我们整个团队在度量团队改进上怎么做实践的。因为前面也有跟大家介绍到我们整个开发中心去年也有做度量平台，相当于在开发跟上线阶段我们这些数字化的指标监控都可以在我们的度量平台里面做相应的监控。我们这一页可以看到从我们的度量平台我可以实时监控我们手机银行网络技术栈的单元测试覆盖率，我们团队也会根据这些指标监控形成相应的迭代任务放在迭代计划里头，形成一个快速的持续改进的闭环。

其实前面也有给大家介绍过，我之前也是做测试，因为其实测试也是我们今年敏捷推广的重点，因为我们前期也是跟很多测试人员也做过沟通，就是可以看到我们今天提得最多是内建质量四个字，从左边我们可以看到，左边就是持续集成1.0里面的图，我们做了一个演进。我们调整了一下我们自动化分层测试的策略，从上面可以看到，我们在这个金字塔最顶端是UI自动化测试，UI自动化测试集成做测试的人应该知道，很多人都会问，我可以通过我的自动化测试去弥补或者完全覆盖、替代我的手工测试案例吗？我觉得通过我们多年的实践经验来看，我觉得可能性基本为零。有几个方面：

第一我们前期也花了很多精力做UI自动化测试案例，而且我们也跑得比较好，但是在这个过程中我们遇到的监控性问题非常多。而且我们可能在去年做整个前中框架重构的时候，相当于我们之前做的这些UI自动化测试案例基本上已经废了。所以就是说它基于以上两点这种情况，所以在整个测试分层的策略里面我们UI自动化测试可以小范围的去弥补。

其实主要的来看我们的策略就是优先推行接口测试，为什么？因为它的维护成本非常低。我当时也有做统计，开发人员在写一个接口自动化测试，其实对于他的操作来说，他实际上就是在我们前面那个自动化接口测试平台我们去做一些上述的报文的配置，可能维护起来只需要5-10分钟，但是如果写一个单元测试案例，可能至少需要一个小时，所以我们也是经过这些测试，或者是我们通过这些实践，我们调整后的策略就是优先推行我们的自动化接口测试。

下面给大家介绍一下我们手机银行的灰度发布机制。我们手机银行发布机制目前主要支持几种：

第一种是菜单灰度。就是你打开我们中信银行手机银行在全部服务里面某一个菜单你不想看到，或者你想要让谁看到，我们都可以通过我们的后台内管做相应的配置。

还有第二个机制实际上是我们用得比较多的就是灰度客户端的发布。因为手机银行有一些重点功能我们在做商店之前业务人员都希望，就是我们会先走一个重测的流程，就相当于我们会组织我们各个分行，下级分行的业务人员去先做一个初步的验证，其实对于我们手机银行产品线我们团队给到业务验证人员实际上是我们把一个灰度客户端，灰度客户端你可以理解为不是我们对外发布的，但是实际上链的环境可以链我们生产的地址。

右边这一块就是我们手机银行APP测试的机制，可以看我们在生产上也是有我们常规对外的集群，也有灰度集群，我们全都是放在生产H5上。

我们去年其实手机银行从2016年开始初始敏捷，到去年一直完成的目前已经按照推行团队划分。我们手机银行团队目前来看就是因为我们大致有一百多人，大概是有按技术栈分，可能会分到六七个团队，目前来看所有的团队都用敏态的开发模式去做项目实施，我们也是基于比如说（1：32：02）这种测试模型，我们也有做迭代评审会或者日常评审，我们目前基本上都是按敏态的模式实施的。

然后看板这一块我们有用物理看板和电子看板。电子看板就是提到平台里面也有提供的电子看板功能，我们所有的这些迭代的开发任务就是竖性的任务我们统一都按团队级去降我们迭代的看板。每天我们团队会开晨会，晨会主要是以物理看看板为主，主要是把一些没有领取的任务按照优先级让团队成员去领。

其实这一页跟大家主要说一下，目前已经输出组织级敏捷管理体系2.0规范。我这边主要也是结合手机银行团队的实际情况，也是基于我们敏捷体系输出了一份团队级的输出管理规范，也是从敏捷的模式、实施的工艺，还有过程管理公益这几个维度，然后去定义这个团队就相当于给团队一个敏态的实施模式的一个指南，里边其实不光包含敏捷这些，里面还有一些比如说开发类的东西是有跟CI/CD做结合的。

4、2020的转型思路

最后的话主要跟大家可以探讨一下2020年的转型思路。其实这一页昨天我比较想放一个组织级的转型思路，但是可能考虑到每一个企业的实际状况不太一样，所以我把组织级敏捷转型的那一页去掉，其实这一页是从整个部门级考虑。因为其实银行业跟互联网还不太一样，就是之前我在工行也是，一个大部门至少要一百到两百人，但是实际上整个从全行角度来看，对于开发中心这种组织机构里边可能有几十个人做这个开发中心的敏捷，或者是效率的提升，这个实际上我们今年在做试点的时候也发现，资源是严重不够的。所以我也在跟我们从部门的角度去思考这个事，就是我建议我们今年的做法就是在部门内部形成了部门的转型小组，主要的工作就是跟我们组织级的工程技术栈做对接。他这个部门内的转型小组主要是在整个部门做横向的推广，具体的推广这些能力项可以结合DevOps的三级标准去做相应的能力提升。

最后这一块其实就是一个工程教练的培养，我觉得是今年转型的重点。工程教练我这边定义三层，因为以前只是这种工程教练的形式，三层什么意思？就是在原有工程教练的职责范围内我们仔细定义了系统级工程教练跟团队级工程教练，比如拿手机银行来举例，我们下边可能有7-8个团队，实际上对于我们整个手机银行系统来说，是有一个系统级工程教练，因为系统级工程教练一方面是为了结合性能特点制定系统级的流水线的策略还有分支策略，还有一方面可能需要掌握相应的版本管理还有持续集成的一些能力，对于团队来说，每一个团队都要有自己的工程教练，他一方面可能是负责团队内的迭代分支的管理还有流水线执行，还有一大部分的工作是需要结合我们相应的度量指标监控，去带着或者引领我们这个团队级去做一个工程的持续改进。

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