大型企业实施 DevOps 的经验总结

白凡

我今天的分享主要分成三大块：一是工行为什么要做DevOps；二是DevOps做了将近两年，做DevOps过程中的落地实践；三是后续规划。

一、背景

我分为两个方面：首先是外部挑战。其实前两年传统的银行业受到互联网的冲击非常大，特别是四大国有银行，当然可能有五大，工行也号称宇宙第一大行，其实做任何转型的时候，因为体量太大了，转身非常费劲。所以说，任何转型都非常困难。

银行进入4.0时代，我们整个都在变化。不变化，怎么办？要么等死，要么转型，其实大家可能觉得等死说的有点言过其实，但我们跟互联网企业特别是BAT有特别大的差距，尽管努力还是非常大的差距，但如果我们一直原地踏步的话，差距会越来越大，所以没有办法，迫使我们转型。

再一个是银行业从传统的金融服务开始向产品、场景、平台等“多位一体”服务转型，这是一个经营环境的变化。再是同业竞争越来越激烈，今天中行、农行、中信都在，其实几大银行之间也在竞争。其实现在在银行业，业务肯定比科技更有地位，这一点银行业的同事都有共鸣，为什么？因为整个银行业靠金融、靠金融业务赚钱，金融科技干什么？金融科技在底下做支撑，所以其实现在金融业务发展到一定程度，大家不断竞争，基本上已经定性了。但金融科技这一块，可能几大银行竞争更加激烈，相当于几大银行除了建行，其他几大银行都在做DevOps转型。

再一点是技术变革加快演进，业界新的技术、整个软件行业的新的技术越来越多，包括物联网、生物识别、区块链、大数据、人工智能、云计算，其实日新月异的在变化，我们整个互联网行业也好，银行业也好，其实都在加紧步伐跟着技术往前走，现在工行内部针对几大热门领域也专门成立实验室，目的就是我们也要跟业界对标，关注业界的最新动态，来不断发展我们自己的技能，要不然就会被甩在后头。

再一个是银行业面对的监管要求越来越严，首先是强监管、严问责，所有银行业的一切活动要在银监会指导下进行，不能乱来。再一个是安全形势，其实新的技术引入的时候一定会有一些风险，当然对于银行业来说数据方面的安全的确面临非常大的挑战。一方面我们要研究新技术、使用新技术，但是安全永远放在我们的第一位，这是现在银行业面临的外部挑战。

内部挑战。我说一下工行的情况，工行科技机构非常多，我们以前是“一部三中心”，今年又新成立科技公司，新成立金融研究院，现在形成了整个金融科技的一部三中心、一个科技公司、一个研究院的局面，目的就是为了支撑科技向前发展，为了支撑业务更好的拓展。我简单说一下“三中心”，因为后面说DevOps落地的时候会涉及到：一个是开发中心，我主要来自于开发中心，主要是接到业务的需求，我们去做研发和测试，然后给到测试中心，测试中心做验收测试，最后给到生产中心进行部署上线，所以这里涉及多个机构。

我们行内的特点是应用非常多，其实我们现在会按照业务领域分成很多业务方向，包括银行卡、个金、电子银行等很多方向，但对每一个业务领域的方向下面又分很多应用，现在行内应用近400个。再一个是版本非常多，当然我们现在在不断转型，其实我们前期的话，像今年我们会规划明年的版本情况，相当于每年12个版本，一个月一个版本。

版本，我规划一个大的集中交付点、一个集中投产点，集中交付点就是开发中心给到测试中心，测试中心做验收测试，然后在一个大的时间点，测试中心给到生产去部署上线。当然我们有一些大的时间点，但也有一些特殊情况，比如说因为监管要求或者政策性项目，所以我们可能有一些特殊的点，但整体上按照这个大的节奏在走。刚才说机构多，跟业务部门也好，三大中心也好，机构一多，沟通协同成本必然很大。

因为业务部门提需求，刚才讲我们有应用的概念，我们还有项目的观念，我们是按照项目进行管理。项目这一块的话，如果我来一个项目，涉及多部门的应有，跨部门之间的沟通成本特别大。再一个是研发链条长、管理层级多，研发链条长这里有开发中心，开发中心内部来了需求，先做需求分析，然后做设计、编码，我们内部现在在不断整合，我们内部还有单元测试、功能测试、流程测试，然后给到测试中心做验收测试，然后部署上线，所以说研发链条非常长，所以我们现在在解决这个问题。再一个是管理层级多，大家也清楚传统银行业各种审批非常多。我们领导在下面坐着，这一块不展开讲了。

这是面临的外部和内部的挑战，就要迫使我们不断转型，所以下一块我说一下这么多年的变化。

二、工作组织方式

首先说一下DevOps探索。其实在2009年之前，我们完全靠手工的方式去打包，通过FTP到服务器，打包部署完全依赖人工，没有统一规范。说句不好听的，就可能是作坊式的。一直到2010年到2013年之间，我们开始有意识做工具，开始工具化，我们自己研发构建与部署的工具。当然这个阶段好在哪里？我至少有工具做了，当然肯定很多还是要依赖于人力。

因为我们刚才涉及到三中心，所以我至少在三中心之间规范相对统一，不是各玩各的，这一套工具三个中心都在用。再一个是2013年到2018年，我们通过Jenkins1.0把整个构建与部署串联起来，开始开展持续集成。我觉得攻防科技这么多年，我觉得2013年到2018年是非常关键的五年，虽然在这个阶段，我们通过持续集成，我们开展了代码检测、自动化测试，这一块后面也会提到，这些都是应该实施DevOps的基础，相当于我们在2013年-2018年还是打下了相对比较好的基础，特别是自动化测试在这五年蓬勃发展。

当然现在距离我们的理想状况还是有比较大的差距，至少在一步步往前走。到了2018年1月份，因为DevOps的概念提出也比较早了，但是从我们工行的角度来说，我们从2018年1月份才开始接触DevOps的概念，其实我们的工具非常多，各个阶段的工具大部分是自研的，因为现在工行开发中心将近有八千人，所以现在工具都在自研，相当于这一块的工具也有，那一块的工具也有，那个领域的工具也有，但没有有机串联起来，正好借DevOps的概念，我们把整个工具链打通了。打通以后，现在整体上的工具链基本贯通，但因为工行体量大，有各种各样的特殊情况，我们适配的不是特别好，我们也在不断优化。

现在的流水线平台，我们也在行内逐步推广，现在推广的也差不多了，当然可能有一些特殊场景的支持不是特别好，我们也在逐步做。2019年10月份，前两个月刚刚开始的，这也是我们一项关键的措施：按需交付，其实我们今年也在做认证，工行一共是2个项目过了3级，特别是一个项目达到3.6，整体来说比较理想。但从评估过程暴露出一个非常大的问题，就是说我们的版本节奏，一个月一个版本。其实我后面也会提虽然一个月一个版本，但大家以为需求是否过了一个月就上线？远远不是这样，其实我们的需求都不一样，每个月有一个点，但上线的需求可能是三个月之前提的，所以这就造成业务不满意的主要原因，所以说按需交付在后面还会做。

接下来我从两个方面说：一个是企业基础支撑能力，再一个是团队能力。我前面提到流水线平台在自建和自研，正好借助DevOps的认证，我们自己也进一步夯实了。其实我们自研的人很少，加上PaaS也就四五十人在做，所以相对来说做的不是特别好。所以我们在做的过程中也不能只焖做，其实跟阿里云效、腾讯蓝鲸、华为开发云不断对标，看别人哪里做的好，我们去学习，找出我们的不足，这样才有的放矢。

企业基础支撑能力。我们都在做流水线平台，可能有一些同学专门负责流水线平台的建设。我们在这里面看一下最下面的流水线，业界的流水线基本上都长的差不多，即使不看别人做，有几本书说，什么《持续交付》《持续交付2.0》基本都是这个套路。持续集成以外包括代码扫描、构建、部署、测试，我们这个有点特殊，我们这个是交付。交付的动作，其实这里面的绿色的点都在开发中心做，交付之后灰色的几个点就是到了测试中心，到测试中心那边还有它的适应性测试环境，因为它的适应性测试环境跟生产环境更类似，所以到它那里做验收测试，所以到它那儿做自动化的验收测试，然后投产交接，完了之后生产投产一直到完成。

下面这一条是我们的交付流水线。还有一条流水线是提交构建流水线，相当于代码一提交之后，就没有触发做质量门禁，所以我增加了一条提交构建流水线，假如我提交代码就触发这条流水线，做代码扫描和单测。因为我设置了质量门槛，这个过程中如果有问题，相当于打回来，不让我的代码跟其他人的代码合并，不往服务器上推了。这一点很关键，至少在前期把你特别差的代码拦截一道，这样在后面跟其他人的代码做集成的时候相对来说好很多。

其实我们的流水线有几种情况，因为我们场景比较多，我刚才说的是常规情况，相当于我们开发完之后给到测试中心做测试，然后上生产。我们还有一种情况是直接发布，，相当于有一些产品是我们跟测试中心、生产协商好了，其实在开发中心开发完了以后我们做一轮测试直接上了生产，所以我们对这种类型也有专门的流水线来支撑。

这一张片子还是说流水线，我把里面各个环节再什么列了一下。

首先看一下代码管理，我们现在也是用开源工具Git管理。我这里说一下程序变更提交关联任务或者问题，其实在早期Git管代码，我们有专门的JIRA工具去管需求、任务，相当于我没有给它俩做有效的关联，相当于我本次修改的代码是解决什么样的问题，或者说实现什么样的需求，其实我们不清楚。现在回想起来，其实这一点很致命，其实现在又强调代码审核，你推送过去，假如我提交代码给张三审核，张三看这个代码，你想实现什么需求都不清楚，所以这样不太好。所以我把程序提交时会关联JIRA或DCM号（问题），这样的话假如我推送给别人做审核的时候，至少这个知道我本次修改代码具体要实现什么功能、实现什么需求、解决什么问题。

接着是提交构建，就跟我讲的提交构建流水线是一码事，就是提交构建的时候会触发，主要是针对个人分支代码进行扫描。再一个是做单测，遇到问题会做精准通知，相当于有问题及时解决。

再是持续集成环节，持续集成相当于可能是多个人的代码合并到主干上，就是对主干分支进行代码扫描、做单测、自动部署测试环境、遇到问题精准通知。其实我们在做3级认证的时候，这一块是有问题精准通知，相当于构建有问题怎么精准通知到人，我们就是通过日志，可能我看R的日志来分析日志，找到最近一次提交人来推送到他那里。但其实这一次不仅仅是因为他推送出现问题，也可能是别人的问题，但为什么我推到他那里？相当于暂时没有找到更好的办法推送到别人那里，对于这种情况我只能推送到最近一次提交代码的人，也什么问题，他就牵头分析了。
完了之后是交付，交付之后再到适应性测试，这方面是做自动部署、自动化测试。再是交接，这是从测试中心到生产中心的交接动作，一方面交接版本包，还有交接网络或者是相关参数，相当于把版本包和相关的参数都通过镜像包直接传递过去了。交接还有一个很重要的环节，就是编写投产流程，每一次部署上线可能涉及服务器的启停，在我们内部还有几个园区，相当于要部署到这个园区、部署到那个园区，这一切都是在投产策略里明确，这样才能到生产，最后一键部署。

这一块是刚才提的每一次代码变更与需求的关联关系。所以我这里抓了几张图。左边是Git端，提交代码的时候我先获取JIRA信息，假如这次代码是我提交的，我一获取JIRA信息，我可能把挂在我名下的一些开发任务发现出来，然后勾选这一次代码提交跟哪个任务相关联，这样的话这边有一个自动解析，然后往上推送。其实你看这里面我们一直强调关联和JIRA关联又跟问题号关联，这是四个标准强调的变更来源要统一，这是我们现在做的不到位的。你看我们有一些需求来了，我们是在JIRA中管理。有一些测试问题，包括开发中心自己的测试问题，还包括测试中心的测试问题，都是通过DCM在管，这是我们内部自研的系统。再一个是生产上线的生产问题，我们又可能在另外一个系统在管，所以这是我们接下来要张罗的事情，就是看看怎么把各个渠道来源的问题和需求，其实问题也是需求的一种，我们都要涉及改代码，相当于是怎么统一纳入到JIRA中去管。

刚才有的同学专门做度量。应该说度量是整个DevOps领域持续交付中很重要的一块内容，相当于持续交付领域几大块内容当中很重要的一块。度量的话，工行早期做CMI也在强调度量，其实我们当时做了很多度量的指标，不断往下推动的运行过程中效果非常不理想，为什么不理想？假如有一个测试问题，测试和开发同学天天吵架、天天扯皮，内耗非常严重。为什么内耗这么严重？可能跟一些考核导向和领导关注也有一定的关系，所以我们基本上把那套指标全费了，后来整个企业只关注两个指标：效率、质量，效率看什么？就看需求到上线的时间，即所谓的研发轴心；质量这一块只看生产上线的问题，相当于中间过程中，你哪怕再烂，只要生产上线没有问题，说明你这个是OK的。所以说这两个指标，大家感觉到应该都是一些滞后性的指标，相当于整个项目结束之后我才能知道我的情况，特别是上线之后才知道有生产问题，你不上线哪知道有生产问题。所以从团队的角度来讲还有很大的问题，团队执行整个过程中没有一面镜子去对照，我没有办法去改进。所以，我们相当于借DevOps的契机，把内部的度量平台搭建起来了。因为我们在做两个项目过程中，我们也不断对度量平台进行优化和演进。

我这里抓了几张片子，来简单说一下。首先看一下左侧，我们整个度量，3级也好，4级也好，我一直强调度量要有层次，哪些是团队层面看，哪些是企业层面看，哪些是部门层面看？我们现在也针对团队层面可能看的更细，针对领导层面我们看的更宏观的指标，所以我这里抓的片子基本上都是从团队层面抓的。我前面提到有应用的概念，上面就包括了应用的基本信息，包括有效代码行数、程序数，包括应用有多少自动化测试脚本，上面是一些基本信息。下面是发布分支，相当于最近部署上线的频率，发布分支每一个都带有日期，这个日期就代表应用上线的日期，这里面按上线日期进行排序。右侧这一块相当于指标，一共有40多个指标。如果指标在一个企业太多，你全面抓的话就很难，你全面抓和全面不抓的效果差不多，相当于关注多了，大家从团队的角度来说，我具体抓哪个？就像无头苍蝇一样找不到重点。所以我们从企业层面有不同的导向，可能这一段时间关注持续集成的频率，下一段时间关注做集成问题的修复时间。

下面一堆是指标，我们就把指标做了整合，相当于针对代码质量是一块，代码质量可能包括区块负责度、重复度、单测行覆盖率，所以这是代码质量。还有测试质量，可能更多关注的是自动化测试的情况，还包括持续集成质量、部署质量。相当于我把它一共归了6大类，这里面针对本次最近的一次发布分支，这个叫流水线的成熟度，我们看一下它到底是什么水平，6个方面每一个方面10分，可以看到这里面60分只拿了18.8分，说明情况不理想。情况不理想，你想知道哪方面做的不行？你可以看右边的图，它分为六大方面，可以非常直观看出问题到底在哪里，是代码质量不行，还是说这次部署的质量不行。

上面是从团队到个人的，其实大家的关注点是不一样的，相当于我可以根据大家的实际情况来重点设置我关注的指标，这里面可以自定义的，想关注什么，都可以在首页显示出来，大家可以清晰一目了然地看到最近情况到底怎么样，代码质量也好，自动化测试也好，都可以清晰看到。
这个雷达图一共是6个方面，我针对6个方面，一个是看最近发布分支。如果我说代码质量不太好，我点一下代码质量，其实我可以从右侧看出最近几个发布分支的代码质量情况，能看到它的趋势。
左下角这一块一共有40多个指标，每一个指标都可以看出最近几个版本，就像每一个发布分支的趋势，再一个是还可以看到最近一个发布分支每天的变化趋势，当然有一些指标可能不太适用，但整体是这样的路子。
右下角这一块，从团队层面来讲，其实集成频率很关键，这一次3级标准也会关注这一点，所以我们针对持续集成频率包括程序代码质量中比较重要的指标，我们也单独列了一下。

这张片子主要是从需求的维度来看的。可以看到左上是需求的研发周期，其实这一块可以向下拽取，当然这里是总需求。需求有几大方面，就是需求来了做分析、研发测试，针对每一个阶段还可以向下拽取每一个周期的情况。右边是按月的发布频率，像这个就表示11月份应用做了5次发布。再一个是需求子条目平均工作量，我后面还会提需求拆分，这个很重要。从我们内部来了之后做需求拆分，我先拆分到需求项，需求项下面有需求条目和需求子条目，然后才到这里，相当于后面发布分支的话，一些分支的建立都可能是基于需求条目做的。

我前面提到我们在建流水线平台。其实流水线平台就是从代码提交开始一直到生产、上线部署，其实前面的需求并没有进行很好的串联。当然我们在做开发者平台之前，我们是通过代码提交的时候跟JIRA或者问题做关联，这样就可以关联上，但是从开发人员的视角来说并不直观。其实我们建开发者平台就是给开发人员提供一个统一的视图，经常是需求过来，我直接在这里做设计，我去建特性分支，在这儿上建分支的合并、进行冲突的处理。相当于开发人员只关注这个平台就可以了，下面是各种各样的平台支撑。我们的开发者平台刚投了一期，其实我们也在不断完善，相当于我们后续更多是依托开发者平台，给开发人员提供一个统一的视图，就相当于现在一直强调流水线自助化，相当于不要依赖专业人员，就像傻子上去都能做，基本上是一键式的，下面有各种应用支撑，你可以一键调用。

上面是基础企业基础支撑能力的建设，下面我从团队能力这一块说一下。

我们有一个项目是从3月份开始做，到过认证是8月底了，相当于将近做了5个月。当然这个项目的体量非常大，也是老应用，有各种各样的问题。但从企业层面还是想做点事，不仅仅是拿这个认证，当然我们选了有代表性的应用去做，当然做的非常辛苦。
所以从团队层面，我简单总结了几点：从企业层面，第一点是自动化测试。无论你推敏捷还是推DevOps，最核心的一点是自动化测试。如果团队自动化测试做不到位，你谈敏捷或者谈DevOps都是扯淡。所以我们刚才说了两个项目，做了整个自动化测试，自动化测试的提升非常明显，当然有一个项目的基础本身比较好，另外一个项目做的非常差。其实在整个过程中做了五个多月将近半年，整个团队还是在踏踏实实的做，其实大家反映最痛苦的是单测和结构测试，特别是单测是从0开始，当然接口测试有一些基础，但做的也不理想。当然三级认证标准上也一直强调单元测试变换行覆盖率至少要达到80%，所以对团队来说但云测试行覆盖率的要求非常高，其实这跟架构还有很大的关系。接口测试也是从个别接口覆盖到全覆盖，我们的“工银e生活”现在一共梳理将近三四百个接口，大家做的很辛苦，但现在反过头再问他做后面的项目，大家确实从中受益很多，当然自动化测试脚本根据项目的不断演进要做微调，但这是自动化测试，一开始的投入一定大于产出。一开始写脚本，肯定不如手工测试卡一下就OK了。所以一旦投入了，后面必然会受益。所以说为什么说自动化测试难推？就是一开始投入大于产出，所以大家都不愿意产出。所以我认为DevOps推广实施最重要的一点，就是自动化测试。
第二点，这个不说了，前面已经提该了。
第三点，技术架构。现在3级认证中谈到了一点，就是如果做到编码完成或者做到测试，需求如何能自动回退？标准要求非常高，我们现在很难做到，我觉得很核心的一点跟技术架构有关。如果你技术架构没有解耦，就基本上做不到这一点。
第四个是分层测试。之前在行内也有一些项目在试着有，就是验收趋势测试开发，当然我们也没有做的那么彻底，但我们在努力往一个方向走，相当于编码同步写测试案例，相当于编码完成之后，至少可以做到立即执行，这样的话有问题就可以及时改。还有混沌工程，就是在生产上引入缺陷包括探索性测试，其实我们也是一步步在往前走。

三、后续规划

这个图可能大家都看过，相当于研发闭环和业务反馈闭环，我针对需求澄清、迭代排期说一下。
你看现在业务过来一个需求，一开始我们要跟业务澄清需求，至少要整明白你这个要干什么，然后我才好做迭代排期。所以需求澄清之后，在迭代排期上，人力毕竟有限，需求源源不断，肯定有一个向后顺序，所以你这时候跟业务同学谈，说能不能给我的需求排优先级，我们这个做不来。业务第一反应是什么？这个优先级都高。但实际上你的人力，比如说我只能做三个需求，但他给你抛出五六个，他说这些都急，你怎么办？这时候他不愿意排，你给他排，你就按照你的理解，你抓住三个你发给他，说同学我想做这三个，你看怎么样。业务第一反应是什么？肯定是炸了，你怎么能做这三个，我想做那三个，这是研发同学和业务同学不断协调和沟通的过程。现在的需求的确越来越旺盛，毕竟精力有限，所以需求迭代排期还是很关键的。

其实我觉得DevOps的终极目标就是要实现快速交付，就是快速的高质量的，一个快，一个好，还要高质量，还要是交付业务觉得有用的价值，这是DevOps的终极目标。当然如果想做到这一点，下面的支撑很多，包括我们的流水线，包括我们的一些需求解耦、架构解耦，其实都是为了做这个支撑。
所以我针对分工解耦谈一下。因为从业务部门的角度来说，业务部门也很痛苦，现在工行开发中心一共有7个研发部门，分布在杭州、珠海、广州、北京、上海、成都、西安。其实对于每一个业务部门来说，他的那一条业务线对应我们这边很多研发部门，其实从业务部门角度来说非常痛苦，我今天可能要找珠海的这个，明天可惜要找杭州的那个，他要多头对应。所以我们现在行内也在做分工解耦，就是从业务部门的视角，我们不说把内移到某个研发部门的一个部门，但至少内移到某个研发部门，从业务的视角来说对接起来更方便，这样也是提升业务满意度的一系列措施。

按需求项快速发布，可以看一下我们行的阶段痕迹还是很明显的。我们针对各个阶段都有一些工具支撑，这是项目任务管理工具。我们之前说的流水线平台，我们把测试设计贯通了，当然开发者平台上面又包了一层，希望给开发者提供一个统一的视角，把这些都搞定。当然这里面发现了一个问题，就是我们之前说我们一般都是按照版本的节奏在走，我们一年12个版本，没有办法实现快速交付，所以大家可以看一下灰色的是贯穿始终的按需求项维度来交付，这就是我们努力的目标。所以说现在一直在推，所以现在也是困难重重，推起来阻力非常大，但我们至少向这个方向走。按道理说从DevOps认证来说，按需求项实现快速交付是非常重要的能力。

这张片子，我简单说一下。因为简短的痕迹比较明显，所以这张片子更多的是怎么实现按需求项快速发布。需求这一块，我一直强调需求解耦，我刚才说DevOps的能力的一点是自动化测试，我认为第二重要的就是需求解耦。需求解耦、需求拆分我们已经做了一年多，做的效果不是特别好，我觉得这对产品经理能力要求非常高，不是谁都能做，必须要经过系统训练才能把需求拆分好。接下来说一下编码自测，我们原来是月度版本的模式，我们原来的分支模型非常简单，针对7月建一个、针对8月建一个、针对9月建一个，我就针对7月建一个，我在上面直接改，改完了之后直接做发布。正常的话，我可能有几个并行，可能7月上生产了，生产的话，分支肯定要留着，因为有生产问题要往下解决，8月可能是建了测试中心和实验性测试，9月到1、10月同时开发，四套分支同时活着。相当于7月有生产补丁，7月就同步8月，8月往9月同步，9月往10月同步，当然我们之前引入Git、建立分支模型也是做过很多研究，基本上建立了一套适合工行开发中心自己特色的分支模型。经常有领导总批评我们，为什么？因为你的分支模型没有统一的话语体系，你说了别人听不懂。其实我们之前也研究了阿里的模型，就是特性分支的模型，其实我们也在往这个方向努力，但我们的特性分支模型推起来还是有一些问题，因为我们有一定的特殊性。我们也想建一条Master，Master建了之后，我想Master和生产始终保持一致。但是我现在有一个Master相当于是12月份的内容，我想要1月份的内容，但我们不是开发完了直接上生产，我还要给到测试中心，测试中心可能还要测四五周才能上线及如果这样的话相当于我2月同步做了，我相当于只能从Master拉，其实2月的基准是12月的，我1月的内容怎么体现出来？所以这个问题我们下午可以再交流，这个问题还是很困扰我们的。

最后一张片子，说一下未来展望。其实刚才牛老师展示了DevOps领域几大方面，其实这张片子有点按那几大方面来。可以看一下我们最终的目标是持续按需上线，这是我们的终极目标，当然这里面有一些支撑，包括需求解耦，前面谈到需求解耦很重要；流程也在解耦，包括审批流程，相当于我也在精减；持续交付，这是我们新的分支模型，在这个小图里。
架构解耦，这一块我们在行内做业务架构模型，我们之前的分支怎么分架构模型？我们现在可能就有渠道交易层，用户通过手机银行、网商银行，通过渠道接入之后，我就有一个交互控制层，随着到产品处理层，相当于真正处理核心业务，还有一些决策支持层和技术支撑层，以这种方式来分。我们现在做业务架构转型分成三方面，最下面是技术基础服务，还有业务基础服务，最上面是业务产品服务，我们通过这种方式来推进行内平台化、组件化的开发。
安全风险。现在一提安全，大家就开始没有眉目，抓不到头脑我们行内也有点想研究自然把安全嵌入到DevOps。因为上一次在上海的DevOps峰会专门有一个议题，我觉得挺好，听了感觉没听出什么东西，所以这一块还是要加大投入，我们内部有一个部门在研究这个事，就是看怎么把安全嵌入到DevOps流程中去。
组织架构。我觉得组织架构也是很重要的，传说中早期的康非定律（音）说你有什么样的组织结构就会产生什么样的架构，我们现在也是按照架构的模型在改变组织内部的结构。我这里有三层：有专门的部门做技术基础支撑，有专门做业务技术支撑，还有一些部门做产品服务。还有是资源解救、研发分工解耦，反正各种解耦。谢谢。