导读：平时工作中，研发、测试、运维同学在持续交付和DevOps上会碰到一些难题：比如持续交付搭一个系统很简单，但是想要管理代码之外的一些资源有点难；公司里的系统多、模块多，开发人员只是做了一小部分，但最终需要集成测试通过才能交付；开发和测试人员之间界限不明确，常常会出现一些互相扯皮的事情。面对这些难题该如何解决？国泰产险首席架构师许磊明首次披露国泰产险持续交付之路，分享解决思路。
前言
对于一家公司或者企业来说，最重要的还是要看结果。持续交付，DevOps只是手段，那怎么衡量这个结果呢？我们需要知道发布的吞吐量是什么，修复时间是多少，质量怎么样？接下来我会跟大家分享国泰产险在持续交付上的一些实践。
保险行业面临的困境
保险业是一个强监管的行业。当时我们主要业务是做车险，车险是一个红海市场，中小保险公司操作十分困难，外部面临的是市场竞争惨烈，行业强监管，产品创新乏力。从内部来说，组织机构效率低下，人才不断流失。
国泰产险当时也有一套IT系统，已经运行了8年以上。
做了一次股权变更后，国泰产险业务从原来的车险转向了互联网保险。当时面临非常强的矛盾就是一方面业务非常创新，另一方面我们需要技改这个基础架构。
因为业务团队会找各种手段试错。试错，他就要投入IT资源，而我们只有快速响应才能满足业务需求。而我们原有的基础架构是支撑不了这种业务创新的，这个时候既是挑战也是重构整个IT价值链的驱动力。
转型之路
首先我们要有系统思维
开发驱动的组织机体，其能力不是制作软件，而是持续的交付客户价值，我们需要有全局视角和系统思维，深入理解整个价值交付链，从业务需求、研发、测试、集成，到部署运维，这条价值链的效率并不依赖于单个或者几个环节，局部优化的结果往往是全局受损，我们要站在系统高度去优化整个价值交付链，让企业和客户之间形成快速和高效的价值传递。
举例来说，当时我们第一个项目花了28天去接入了一个险种。这个对于业务方来说，是无法接受的。所以我们提出了一个目标，我们要从28天变成一天，从需求到上线一天完成。
这就需要从业务需求、研发、测试、集成，到部署运维全流程的优化。
业务架构决定组织架构, 组织架构决定系统架构。
每位架构师都应该了解
康威法则
Mel Conway 在 1967 年提出了所谓康威法则，指出组织架构和系统架构之间有一种隐含的映射关系：
如果你的系统架构不支持，你无法建立一个高效的组织架构。如果你的组织架构不支持，你也无法建立一个高效的系统架构。
其次，强化反馈环
任何过程改进的目标都是加强和缩短反馈环。有两句号这样讲的：
- no measurement, no improvement没有测量，就没有改进和提升
- What your measure is what you get你测量什么，就得到什么
我们说从28天到1天，你凭什么说1天，你有度量吗？有标准吗？那我需要有一些数据、流程管理来支撑我这个目标，我们引入了研发管理云效平台。把项目的全生命周期标准化，数字化。
然后，如何去压缩这个时间呢？需要对技术架构进行微服务化的建设, 来支撑快速的业务创新。
但微服务有额外成本的，需要搭建框架、发布、监控等基础设施。
而基础架构部分，因为我们的技术资源是有限的，不可能投入大量的技术资源做基础的工作研发，重复造轮子。所以我们需要拥抱云计算，要让云赋能我们，才能跑得更快。
最后，才是优化价值交付的一个链条，让它从研发、测试、发布各个环节都去把它做到极致，所以我们去做持续交付。
组织架构调整
首先，我为什么做这个架构调整，这是因为各个部门之间是有部门的墙的存在。持续交付讲究的是端到端的这种负责，能够更加快，而DevOps打通的是开发与运维之间的关系，而持续集成是开发与测试之间的关系，敏捷开发是产品与测试之间的关系，你如果组织架构不调整，这种研发链条是必然很长的。各个职能团队的目标也不一致，最后表现为职能团队间信任不足，合作欠佳摩擦不断。
下面是一个典型的场景：
- 业务领导：我们的增长太慢了，为啥我们不能比竞争对手更快推出产品？
- 产品管理：技术团队不给力，大量需求堆积无法推进，技术的问题怪不了我们！
- 研发团队：没有按时交付项目不能怪我们，我们要求的机器运维一直拖着没有到位，运维的老大该换换了！
- 运维团队：客户都快气疯了，我们大部分时间在救火保障系统稳定性，不要再扔东西给我们了，我的团队都快跑光了……
那我们需求什么样的组织结构？
总体思路不复杂：
- 业务和产品研发闭环，围绕核心产品组织跨职能交付团队，各团队可以独立开发，测试、发布和迭代各自的微服务，互不干扰，沟通协调成本小。
- 平台团队和运维围绕 IaaS/PaaS 基础设施产品开展研发和运维工作，为内部客户提供标准化平台服务。
- 业务产品团队通过标准 IaaS/PaaS 平台，以自助方式持续交付价值到客户手中。
如图左边是泰勒制的组织，右边是Beta性的组织，是说我们有跨职能的团队的存在。
国泰产险的落地实施
我们组建了互联网事业部和互联网技术部。原来保险公司的职能划分是从前到后，有精算、险部再到财务，然后再到我们的需求、研发、PD、商务，再到开发人员、测试、运维，这么一个串行的流水线的形式。而互联网事业部是在一个事业部里面，把所有的职能都包括进去，比如对应的有技术部，其中测试是支持互联网技术，虽然从组织结构上，它还是一个独立的部门，我们把应用运维和(网络、存储以及硬件等)基础运维分开，也就是说应用运维、中间件、应用的管理这些配置全都归属于开发团队，而运维团队负责的是底层的资源、网络、计算资源等， 以平台化、自助化的形式提供服务。
然后引入一站式研发协同平台云效，从需求到测试到发布全都可以放在云效上实施。
这样做的原因主要是：
首先，我们要有价值导向。做一个项目，老板要看整个链条要投入多少成本，多少时间上线？然后到平台支撑。就是说我需要有一个平台，去支撑整个的东西，最后你还要能够服务的透明，就是说各个环节包括业务部门、PM、PD都能看清楚，知道我在各个环节花了多长时间，瓶颈在哪里。最后做一个数据驱动，做持续的改进。这样我们才能继续往前。
持续交付的成熟度模型
如果我们是手工做一些部署，那肯定是一种阻碍级的；如果是一些脚本不熟，那我们认为是可重复级的；可定义级的是指我们已经能做到自服务；可定量级是说各个环节都能有一些量化的数据产生，比如我们知道发布失败率是多少？发布时间有多长？最后是优化级，要做持续地改进，有了数据之后，要让各个团队包括业务、PD、开发、测试、运维能坐在一起做持续改进。这是一个持续交付成熟度模型。
把一切纳入版本控制
代码 -> 配置 -> 数据 -> 运行环境
这里重点说运行环境和数据。
- 运行环境
环境是个老大难问题，发布的时候发布失败，很大可能是环境问题。这些环境你要做到开发环境、测试环境、以及生产环境能够一致，是非常困难的。但是又不得不做，所以我们用Docker来解决这个问题。
- 数据
我们最早的时候是把数据结构以及数据初始化的工作，做成一个.sql文件，把它放在SVN里面。但是这样也是有问题的，因为我不知道你这个变更的历史，以及你为什么做这个东西？所以我们引入了那个flyaway去做这个版本化。然后用flyaway做了一个maven 插件，以后就可以把maven插件放到云效里面，让jenkins调用插件，这样每发布一次，甚至说到测试环境部署一下，云效就能自动把我的数据环境给初始化的完成了。
配置管理也是个老大难问题，线上经常会出现配置项不对，造成发布失败。所以我们想了一些方案。
这个环境管理也是云效提供的一些功能。
测试管理也是一个非常大的难点。比如做一个分层的测试，单元测试是开发同学做，接口和UI是测试同学做，集成测试是所有测试同学以及开发人员去做，以及业务人员也会参与。这里从开发负责人的角度来说，我认为单元测试是非常难推的，因为开发同学没有看到它的价值。单元测试的确是有好处，但是付出的成本也是很高的。如果说付出了成本，但是看不到价值，就很难推下去。
我们首先从KPI的激励机制上做了一个调整，要确保单元测试能通过，流程上也进行监督，不管你的覆盖率有多高，起码你现有的单元测试一定要通过，才能提到集成环境上去。另外，我们还采用其他一些机制，比如有些单元测试我们用框架化，如果是DB测试就把它拿掉了，我们只要求在业务代码上做单元测试，框架上保证。
小结
最后， 建立通过透明、 反馈、 自动化的流程改进再收集数据的闭环，鼓励从全局视角出发， 创新试错，持续提升的文化。
这点是最难的，一般和企业人才密度有关。工具，技术，流程只是一个公司的冰山浮出水面的部分，而真正对企业效能影响大的则是冰山水下的部分，即企业的人和文化，架构师作为技术和架构的布道者，有责任义务鼓励和推动试错文化。
我们要关注整个价值交付链的效率，关注每个环节的闭环反馈，鼓励和推动公司的试错文化，打造全系统的闭环架构（Architecting for closed loop feedback），提升整个系统效能。
而在国泰的实践中， 通过前面组织架构的调整， 对开发环节做微服务化，测试环节引入自动化测试，发布环节做DevOps，目前我们已经成功地实现了从需求到发布在一天之内完成， 为公司提供了价值。
当然这个过程中云效的数据反馈，体系化，自动化起到了基础性的作用。
点击链接
https://www.aliyun.com/product/yunxiao
马上体验云效一站式企业协同研发平台。
作者介绍
许磊明：国泰财产保险有限责任公司首席架构师。曾任职于易保、惠普、 eBay、阿里巴巴国际站、蚂蚁金服。专注于金融企业的持续交付、DevOps技术发展。
本文来源，云效（ali_yunxiao）微信号。
