一天我们能做什么? ——中小金融企业持续交付之路-阿里云开发者社区

开发者社区> 云效DevOps平台> 正文
登录阅读全文

一天我们能做什么? ——中小金融企业持续交付之路

简介: 从最初28天接入一个项目,到现在从需求到上线1天完成,不可不知的国泰产险持续交付之路。
导读:平时工作中,研发、测试、运维同学在持续交付和DevOps上会碰到一些难题:比如持续交付搭一个系统很简单,但是想要管理代码之外的一些资源有点难;公司里的系统多、模块多,开发人员只是做了一小部分,但最终需要集成测试通过才能交付;开发和测试人员之间界限不明确,常常会出现一些互相扯皮的事情。面对这些难题该如何解决?国泰产险首席架构师许磊明首次披露国泰产险持续交付之路,分享解决思路。


前言

对于一家公司或者企业来说,最重要的还是要看结果。持续交付,DevOps只是手段,那怎么衡量这个结果呢?我们需要知道发布的吞吐量是什么,修复时间是多少,质量怎么样?接下来我会跟大家分享国泰产险在持续交付上的一些实践。


保险行业面临的困境

8a772ef92698f5c349f39adfc103cbeaa610148d

保险业是一个强监管的行业。当时我们主要业务是做车险,车险是一个红海市场,中小保险公司操作十分困难,外部面临的是市场竞争惨烈,行业强监管,产品创新乏力。从内部来说,组织机构效率低下,人才不断流失。

国泰产险当时也有一套IT系统,已经运行了8年以上。

dfaaa05540041d595d2a9f11dfa309b1b026aaab

做了一次股权变更后,国泰产险业务从原来的车险转向了互联网保险。当时面临非常强的矛盾就是一方面业务非常创新,另一方面我们需要技改这个基础架构。

88b83afc1ada66038d7ded108b985f9dece59d3c

因为业务团队会找各种手段试错。试错,他就要投入IT资源,而我们只有快速响应才能满足业务需求。而我们原有的基础架构是支撑不了这种业务创新的,这个时候既是挑战也是重构整个IT价值链的驱动力。

转型之路

2fc3055ca7f25d553bf2272c2cf51675cf4425f2

首先我们要有系统思维

开发驱动的组织机体,其能力不是制作软件,而是持续的交付客户价值,我们需要有全局视角和系统思维,深入理解整个价值交付链,从业务需求、研发、测试、集成,到部署运维,这条价值链的效率并不依赖于单个或者几个环节,局部优化的结果往往是全局受损,我们要站在系统高度去优化整个价值交付链,让企业和客户之间形成快速和高效的价值传递。

举例来说,当时我们第一个项目花了28天去接入了一个险种。这个对于业务方来说,是无法接受的。所以我们提出了一个目标,我们要从28天变成一天,从需求到上线一天完成。

这就需要从业务需求、研发、测试、集成,到部署运维全流程的优化。

业务架构决定组织架构, 组织架构决定系统架构。

每位架构师都应该了解康威法则

Mel Conway 在 1967 年提出了所谓康威法则,指出组织架构和系统架构之间有一种隐含的映射关系:

如果你的系统架构不支持,你无法建立一个高效的组织架构。如果你的组织架构不支持,你也无法建立一个高效的系统架构。

其次,强化反馈环

任何过程改进的目标都是加强和缩短反馈环。有两句号这样讲的:
  • no measurement, no improvement没有测量,就没有改进和提升
  • What your measure is what you get你测量什么,就得到什么
我们说从28天到1天,你凭什么说1天,你有度量吗?有标准吗?那我需要有一些数据、流程管理来支撑我这个目标,我们引入了研发管理云效平台。把项目的全生命周期标准化,数字化。

a3d1c0d277da586230ce687d61f8ae59d2f650c3

然后,如何去压缩这个时间呢?需要对技术架构进行微服务化的建设, 来支撑快速的业务创新。

但微服务有额外成本的,需要搭建框架、发布、监控等基础设施。

而基础架构部分,因为我们的技术资源是有限的,不可能投入大量的技术资源做基础的工作研发,重复造轮子。所以我们需要拥抱云计算,要让云赋能我们,才能跑得更快。

最后,才是优化价值交付的一个链条,让它从研发、测试、发布各个环节都去把它做到极致,所以我们去做持续交付。

组织架构调整

e49cadae3b73cdd68e73f49bddf80d830bd0228b

首先,我为什么做这个架构调整,这是因为各个部门之间是有部门的墙的存在。持续交付讲究的是端到端的这种负责,能够更加快,而DevOps打通的是开发与运维之间的关系,而持续集成是开发与测试之间的关系,敏捷开发是产品与测试之间的关系,你如果组织架构不调整,这种研发链条是必然很长的。各个职能团队的目标也不一致,最后表现为职能团队间信任不足,合作欠佳摩擦不断。

下面是一个典型的场景:

  • 业务领导:我们的增长太慢了,为啥我们不能比竞争对手更快推出产品?
  • 产品管理:技术团队不给力,大量需求堆积无法推进,技术的问题怪不了我们!
  • 研发团队:没有按时交付项目不能怪我们,我们要求的机器运维一直拖着没有到位,运维的老大该换换了!
  • 运维团队:客户都快气疯了,我们大部分时间在救火保障系统稳定性,不要再扔东西给我们了,我的团队都快跑光了……

那我们需求什么样的组织结构?

总体思路不复杂:

  • 业务和产品研发闭环,围绕核心产品组织跨职能交付团队,各团队可以独立开发,测试、发布和迭代各自的微服务,互不干扰,沟通协调成本小。
  • 平台团队和运维围绕 IaaS/PaaS 基础设施产品开展研发和运维工作,为内部客户提供标准化平台服务。
  • 业务产品团队通过标准 IaaS/PaaS 平台,以自助方式持续交付价值到客户手中。
f335df82ec270b78b907c08873a8662a6104ace0

如图左边是泰勒制的组织,右边是Beta性的组织,是说我们有跨职能的团队的存在。

国泰产险的落地实施

我们组建了互联网事业部和互联网技术部。原来保险公司的职能划分是从前到后,有精算、险部再到财务,然后再到我们的需求、研发、PD、商务,再到开发人员、测试、运维,这么一个串行的流水线的形式。而互联网事业部是在一个事业部里面,把所有的职能都包括进去,比如对应的有技术部,其中测试是支持互联网技术,虽然从组织结构上,它还是一个独立的部门,我们把应用运维和(网络、存储以及硬件等)基础运维分开,也就是说应用运维、中间件、应用的管理这些配置全都归属于开发团队,而运维团队负责的是底层的资源、网络、计算资源等, 以平台化、自助化的形式提供服务。

然后引入一站式研发协同平台云效,从需求到测试到发布全都可以放在云效上实施。

这样做的原因主要是:

dd0d3863aa26a8dc9ee96d06e9cc5fce2afeaa00

首先,我们要有价值导向。做一个项目,老板要看整个链条要投入多少成本,多少时间上线?然后到平台支撑。就是说我需要有一个平台,去支撑整个的东西,最后你还要能够服务的透明,就是说各个环节包括业务部门、PM、PD都能看清楚,知道我在各个环节花了多长时间,瓶颈在哪里。最后做一个数据驱动,做持续的改进。这样我们才能继续往前。

a80e58718398383d4fadfaa8d2b986704dbd1e1e

持续交付的成熟度模型

bca8a5b5712a0e2e9a5759c3d650252ffbec85cf

如果我们是手工做一些部署,那肯定是一种阻碍级的;如果是一些脚本不熟,那我们认为是可重复级的;可定义级的是指我们已经能做到自服务;可定量级是说各个环节都能有一些量化的数据产生,比如我们知道发布失败率是多少?发布时间有多长?最后是优化级,要做持续地改进,有了数据之后,要让各个团队包括业务、PD、开发、测试、运维能坐在一起做持续改进。这是一个持续交付成熟度模型。

把一切纳入版本控制
代码 -> 配置 -> 数据 -> 运行环境

6608e86e1a96c02ee435c8752a9b029640312765

这里重点说运行环境和数据。

  • 运行环境
环境是个老大难问题,发布的时候发布失败,很大可能是环境问题。这些环境你要做到开发环境、测试环境、以及生产环境能够一致,是非常困难的。但是又不得不做,所以我们用Docker来解决这个问题。

  • 数据
我们最早的时候是把数据结构以及数据初始化的工作,做成一个.sql文件,把它放在SVN里面。但是这样也是有问题的,因为我不知道你这个变更的历史,以及你为什么做这个东西?所以我们引入了那个flyaway去做这个版本化。然后用flyaway做了一个maven 插件,以后就可以把maven插件放到云效里面,让jenkins调用插件,这样每发布一次,甚至说到测试环境部署一下,云效就能自动把我的数据环境给初始化的完成了。

c08e69ca3e585e561539a5f5044873a1d4b37f86

配置管理也是个老大难问题,线上经常会出现配置项不对,造成发布失败。所以我们想了一些方案。

b211870f62cc6e7782f913c6f5cc1c4f2073ca59

这个环境管理也是云效提供的一些功能。

1f48298c7b9562ec678947a675194d8a10a6491a
 
测试管理也是一个非常大的难点。比如做一个分层的测试,单元测试是开发同学做,接口和UI是测试同学做,集成测试是所有测试同学以及开发人员去做,以及业务人员也会参与。这里从开发负责人的角度来说,我认为单元测试是非常难推的,因为开发同学没有看到它的价值。单元测试的确是有好处,但是付出的成本也是很高的。如果说付出了成本,但是看不到价值,就很难推下去。

6aa6c75059cda5b061e0f627cbe8ca01882bdceb

我们首先从KPI的激励机制上做了一个调整,要确保单元测试能通过,流程上也进行监督,不管你的覆盖率有多高,起码你现有的单元测试一定要通过,才能提到集成环境上去。另外,我们还采用其他一些机制,比如有些单元测试我们用框架化,如果是DB测试就把它拿掉了,我们只要求在业务代码上做单元测试,框架上保证。

f3c3c082b3b4de2f4391c54a0f4800703749005c

小结

最后, 建立通过透明、 反馈、 自动化的流程改进再收集数据的闭环,鼓励从全局视角出发, 创新试错,持续提升的文化。

a8e734806fbca73cb5c26e5954373078e4af7670

这点是最难的,一般和企业人才密度有关。工具,技术,流程只是一个公司的冰山浮出水面的部分,而真正对企业效能影响大的则是冰山水下的部分,即企业的人和文化,架构师作为技术和架构的布道者,有责任义务鼓励和推动试错文化。

我们要关注整个价值交付链的效率,关注每个环节的闭环反馈,鼓励和推动公司的试错文化,打造全系统的闭环架构(Architecting for closed loop feedback),提升整个系统效能。

而在国泰的实践中, 通过前面组织架构的调整, 对开发环节做微服务化,测试环节引入自动化测试,发布环节做DevOps,目前我们已经成功地实现了从需求到发布在一天之内完成, 为公司提供了价值。

当然这个过程中云效的数据反馈,体系化,自动化起到了基础性的作用。

点击链接https://www.aliyun.com/product/yunxiao马上体验云效一站式企业协同研发平台。

作者介绍

许磊明:国泰财产保险有限责任公司首席架构师。曾任职于易保、惠普、 eBay、阿里巴巴国际站、蚂蚁金服。专注于金融企业的持续交付、DevOps技术发展。

本文来源,云效(ali_yunxiao)微信号。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

云效,云原生时代新DevOps平台,支持公共云、专有云和混合云多种部署形态,通过云原生新技术和研发新范式,助力创新创业和数字化转型企业快速实现组织敏捷和研发敏捷,打造“双敏”企业,实现10倍研发效能提升。

官方博客
【产品与服务】
【友情链接】