“神兵”天降 - 揭秘平安 DevOps 的核心实践 --- 龚明杰

豆沙包

作者简介

龚明杰
平安科技资深敏捷/DevOps教练

今天我给大家分享的是平安的DevOps核心实践，平安是一个非常大的公司，它底下的公司有30多个，业务线也非常多，我不想和大家说所谓的最佳实践，因为很多业务线的做法是存在差异的，给大家分享一下我们认为比较好的或者有效的实践。

一. 平安DevOps的前世今生

我们看平安在DevOps的一些历史，上图是它的一个编年史。平安是从2011年开始做敏捷方面的转型，但大家知道平安是属于金融类的企业，它为什么转型？

11年的时候BAT已经进军互联网金融，所以当时平安的危机意识还是比较强的，我们之前有一个图，那个图是敏捷转型做宣传的一个漫画，一个人后面有三个箭，就是指BAT。所以平安就开始转型，最开始有一个保险直销的平台，淘宝已经开始在网上买了。

12年就是我们的可视化管理，当时平安已经在看板方面有大量的实践了，看板方法的作者也来过平安进行指导和参观。13年看板好像不能解决所有的问题，我们把这些方法进行糅合，关键就是XP这些实践。14年很多项目不需要5—9个人，往往需要很多个人，涉及大型项目的管理怎么做。15年涉及产品与开发的结合。16年包括产品开发和测试运维当时都会涉及，全链打通，这个工具我们内部叫做“神兵”，这个名字跟我今天分享也有关系，之所以这么叫就是和这个工具有关。

平安有一个文化，我们作为敏捷DevOps的教练和工具的实施，和很多公司的做法可能不一样，我们不需要红头文件拿着靶子给大家推广，因为平安内部开发的模式和产品业务的模式是极为复杂的，所以不可能用这个方式，我们更多的是以服务角度进去，所谓服务的角度就是我帮你解决问题，你就会用他，更多的我们是以这个角度切入。

所以“神兵”里面就承载了很多关于精益和敏捷的一些比较好的理念和方法，让它去沉淀在一个产品上面。因为很多时候一些想法我们大家都是写在文字上，没有有效地应用，比如我和你做分享，因为时间有限，你使用的空间比较小，但是我在应用里面做分享，你可能会有更多的启示。

平安敏捷与创新方法

2017年平安创建了平安敏捷方法+，各种方法都会涉及，2018年其实现在还没有进行回顾总结，今年我们很多时候聚焦在业务敏捷方面会偏多一点。

我们简单看一下，上面是我们在平安的一个研发流程，从前面的产品到如何快速启动和敏捷交付到运营，中间怎么构建交付的有效和高效，还有一个上层的框架性的东西，叫做研发体系，这个研发体系和CMA不一样，它更多的是一个框架性的，我们内部有一些说法是制度规范的框架，具体的实践是由团队决定的，既满足了团队的要求，也满足了团队灵活运用的空间。

这就是平安敏捷与创新方法+在平安内部的使用，从上涉及企业敏捷方面的，最下面是技术和工具平台，从左到右涉及产品的启动和交付以及运营，还有一些文化的建设，最后还有一些人员和组织的形式，这些都息息相关。

接下来我们先看一下文化这块，在平安里面也推崇技术卓越的文化，这个是在平安科技内部使用的，就是所谓的管理通道，分技术和产品以及市场，对人才培养的导向和晋升的要求与传统的不一样，你的管理的通道对人员的晋升都有很大的影响，更多的体会技术人员的作用。
之前的管理人员就是走管理，现在其实是两个路，你可以走管理也可以继续走技术，你的荣誉和等级照样可以得到体现。
另外一个方面就是我们说到DevOps大家一定会谈到基础设施这块，我们在这边有一些包括自动化运维方面的一些方案，这边会涉及平安内部有一个平安金融云的服务，这边也会架设整个集团和开发环境的基础，基于刚才说的文化和管理的方法体系以及一些优秀的实践，在这个平台进行结合和有效的管理，大家看到协作空间和测试管理和数据平台以及代码管理和性能测试都是核心的模块，大家对研发感兴趣的话这个里面涉及的层面基本是贯通的。

建设工程师文化，追求技术卓越

接下来我们看一下文化这块，在平安里面也推崇技术卓越的文化，这个是在平安科技内部使用的，就是所谓的管理通道，分技术和产品以及市场，对人才培养的导向和晋升的要求与传统的不一样。

之前的管理人员就是走管理，现在其实是两个路，你可以走管理也可以继续走技术，你的荣誉和等级照样可以得到体现。

智能化运维+云服务化

我们说到DevOps大家一定会谈到基础设施这块，我们这边有一些包括自动化运维方面的方案，平安内部有一个平安金融云的服务，这边也会架设整个集团和开发环境的基础，基于刚才说的文化和管理的方法体系以及一些优秀的实践，在这个平台进行结合和有效的管理，协作空间，测试管理和数据平台以及代码管理和性能测试都是核心的模块，大家对研发感兴趣的话这个里面涉及的层面基本是贯通的。

二. 平安DevOps实践典型案例

我们看看实践部分的情况，首先实践涉及端到端持续交付，这个是平安金融云的一个案例，当时它的一个挑战和痛点，以及解决的一个大概的思路是首先看需求，需求是一个多头需求，偏传统的公司都有类似的问题，产品有很多的需求，想做很多的业务，这个时候面临的市场挑战比较大，第二个是资源有限，很多的时候效率又不高，这个时候必然会形成一些质量问题，大家迫于领导的要求，说必须要在这个点给我上，很多时候就会变相地牺牲质量，这个问题就出来了。

后期的问题爆发也很严重，大家都在天天赶进度，后面一集成有大量的问题要修复，将近40%的时间是投入在改BUG，持续部署的环境也是不全的，华为的那个案例也是类似，很多时候会拖延，团队的整体情况是加班很严重但效率很低。

对一些方案来讲，包括一些需求的看板的应用，开发环境有分支的管理和开发团队的看板，我们所谓的方案没有说一定要用看板，本身敏捷也是一个集大成者，哪个可以用我们就用哪个。

因为我们都是一些金融产品，所以安全方面都会有一些贯穿，最后就是我们的交付和文化上的建设，提高交付的效率，减轻团队加班的严重性。

我们看看实践中是怎么做的。

• 建立统一的端到端持续交付过程

整个的过程涵盖了从需求一直到最后的发布运营，我大概讲一下需求管理涉及三个层级的需求，我们内部原始的需求就是我们的idea，我们分析之后变成特性，这个层级会变低，在需求的粒度就是经常要做版本规划，平安有很多的团队叫做阅读的版本计划。

这样开发以后就会涉及到开发测试和UAT的环节，基本开发的顺序都是按照精益的做法，就是按照特性进行开发和提测，后面就是持续的验证，这样做了之后，就进行生产上的一些部署，当时这个产品还没有涉及灰度发布，当时是一键发布，不是灰度的做法。

我们可以看到另外的一个叫做子空间的，这个涉及我们的团队协作，按照我们敏捷的思想，我们由多个团队构成，怎么解决多个团队的协作，这里会分成不同的团队，每个团队从上面总的空间里面进行分拆，再给到每个团队，每个团队会看到自己负责开发的业务需求。

• 统一需求池、持续滚动规划

刚才说每一个版本和每一个产品都有不同的版本和业务，这个涉及我们之间的依赖，甚至有些项目和产品的需求度比较高，那么通过依赖这种看板来解决，以此避免依赖的风险，同时也可以有效避免一些重复性的需求，一些产品拿到需求没有进行很好的内部沟通就开始做了。

• 开发

开发这边相对比较通俗一点，在这边会涉及上面是版本，下面是迭代，以版本火车的形式来走，每个版本都有两个迭代或者三个迭代，这个根据团队的周期来。后面会涉及团队的看板，它有两块，物理看板和电子看板，电子看板可以很好地统计数据，可以实时知道度量的一些情况，但是物理看板就看不到，你的团队在一起开站会的时候，互动性会更强，感觉会更好，电子看板就没有这么好的体验，我们这里两个看板都会用。最后就是代码扫描和代码评审这块，就是你代码提交之前你自己可以扫描。这个时候技术做评审的时候，直接看代码的差异进行评审，确定之后就进行后面的编译。

• 测试

测试也是两块，一个是测试的管理，一个是测试的执行。管理这边有一个通用测试用例池，会有不同的版本策划，最后会自动生成报告，可以实时看到数据，说明开发的质量有比较高缺陷占比的是什么情况，我们会有这些数据，好处是团队可以预警，可以知道我们的质量，同时你点开这个数据可以看到哪个模块和业务需求出的问题比较多，这个时候团队在迭代的中期就可以做一些解决。

• 持续交付

最后就是部署的流水线，每个团队有各自的部署流水线，后面会再集中部署，同时涉及到度量报表，可以看到它交付的周期，还有一些就是涉及到上面缺陷的质量的情况，还有一些就是涉及我们的吞吐量这块都会有。

复杂系统CI/CD

这个项目它的模式和我前面说的产品有一点类似，也是一个互联网金融的产品，这个项目定制的需求非常多，这就造成重复开发的现象非常多，定制化需求很多的时候，你的系统很难找到产品的创新，或者核心的竞争力比较薄弱，做到后面就没有办法搞清楚代码。

这边当时有100多个总监，设计部署流水线60多条，后面这个版本的配置管理已经混乱了，版本升级的风险很大。所以在这个措施刚刚开始实施的时候，更重要的是首先把持续交付的流程捋清楚，把代码进行分类和回收，然后要在规范分组之后把这些东西进行规范化。

这个里面最痛苦的是配置，很多配置是有差异化的，最后不知道谁是谁的。所以配置结构的标准化也是很重要的，包括自动化的测试，最后的效果也是从那个组建的标准的核心部署的效率达到秒级，新site上线从一周到半天。

上面是组件版本的规划，就是100个组件会分开进行规划，每个组件会有一个流水线的配置，通过后面的自动化持续集成到交付，交付的流水线可以100多条同时跑，来实现最后的交付。

这是我们当时做的代码分支，一方面我们理清楚了代码，还涉及合并，合并当时是用了代码自动归并的功能，后面所有的开发是不需要人工做归并的。自动就可以进行归并，后面的代码不会再出现这种情况，这边就涉及标准组件的规范和银行实施配置规范以及数据库规范，我们看到整个CI/CD的做法都会有差异，前面是从代码VT持续部署这边的平台进行测试之后，这些组件统一放到了制品库，我们的开发工作到制品库才算结束，它有一个统一的版本。

后面我们对实施的site把文件放到这个库里面，配置文件拉出来之后，定制化会有专门的组件，拉出来以后统一进行打包，放到灰度的环境进行验证和发布。

运维这边也是，涉及很多包的发布，产品涉及到银行，所以工具里面其实不是自动部署，自动部署也有人做，但是从安全上考虑，很多时候需要运维点一个按纽来进行一键部署，它可以多条线一起部署。

在这个部署方案里面会有一点复杂，但是这是一个CI/CD的体现，它通过左边进行一些编译和打包，然后在右边通过部署向用户提供服务，所以它中间会有一个处理，包括部署制品库的结构，负载均衡，这些东西实际上都是非常复杂的。

自动化精准测试

我们谈到DevOps里面还有一个非常重要的环节，一旦解决就会很大程度提升效率的就是手工测试比较麻烦。我们回到另外一个问题，我有一部分测试可以自动化，但是不代表所有都可以自动化，所以哪些东西要自动化？第二个是人工的部分我们有没有可能做得更轻松？手工测试遗漏的问题非常明显，UI测试维护代价比较大。

所以我们要把这两个结合起来，最小化测试用例，我们把这个叫做精准测试的实践。

首先是自动化用例的编写，这个没有什么好说的，接下来是测试的执行，我们把测试用例录入之后，它就可以自动进行测试和运行，这个过程会有相应的测试报告立马显示出来，这个是非常方便的。

还有一个非常重要的就是我们执行的过程当中，接口的测试代价相对比较低。测试里面有两个代价，第一个是测试用例的编写和维护代价，所有的测试要是经常变的话，比如单元测试为什么很多团队做不起来，就是因为改变了测试的业务，测试的脚本很多都需要重新更新。写一次还好，按照敏捷的方法两周做一次代价很大，第二个是解决执行的代价，一个一个去点就比较麻烦。

我们有一个叫做Inner自动化测试的工具，这是平安针对内部的一些东西研发的，这个工具可以降低我们执行层面的代价，同时接口里面微服务化之后稳定性相对是比较高的，你不可能明天就随便改接口，特别涉及外部关联的接口你一改就麻烦了。

当然我们所有的东西都跑了之后还有一些东西涉及代码更新，这里面也会有一个覆盖率和变更覆盖率的问题，就是我改的这个东西到底哪些是变化的，如果我能准确地知道哪些点是变了的，测试的代价就变低了。这里还有一个静态链路的分析，从入口到结束所有的函数的调用链是什么样的，这个可以分析出来。

其实还有一个上面这个图片没有给出来，就是会有一个代码，它会给你标记出你新加的代码哪些被测试用例覆盖了哪些没有，它可以通过这些精准的分析把需求，缺陷代码这些形成一个有效地关联，以减少大量用例的情况，同时也可以很准确地测到我们要测的情况，规避质量上的一些漏点。

三. 平安DevOps实践情况及效果

最后我们看一下平安应用“神兵”在DevOps的一些情况，我们现在是有17家专业公司，有38000的活跃用户，团队的空间是7600，至少应该有大几千的团队使用，我们上线的系统是3600，每周的部署是28200次，APP的项目是100多个，需求平均实现周期是14.5天，可以加快，这些东西打通可以提高效率，还有交付周期以及部署效率和生产缺陷这些部分提升的情况也是比较明显的。

其实我们很多时候有一些好的方法和理念在实践的时候会面临一个问题，一些好的方法和度量的东西如果没有工具支撑的话，会觉得很难操作和应用，比如你要做一个故事的梳理管理，你怎么和你的缺陷你的质量进行关联，你很难进行有效的管理，团队的吞吐量这些你也很难找到一个有效的方式，这些东西都找到了之后它的效率会事半功倍。