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