返回 登录
1

阿里巴巴1682亿背后的“企业级”高效持续交付

摘要: 在2017北京云栖大会上,阿里巴巴高级技术专家陈鑫(花名神秀),给大家带来了《1682亿背后的企业级高效持续交付》,引起强烈共鸣。神秀从技术负责人关心的研发流程混乱、质量无法保障、环境管理低效、资源浪费等方面,结合阿里巴巴的DevOps实践,深度解析了企业级持续交付如何做,企业如何高效协作,控制成本的精彩分享。

导读:在2017北京云栖大会上,阿里巴巴高级技术专家陈鑫(花名神秀),给大家带来了《1682亿背后的企业级高效持续交付》。神秀从技术负责人关心的研发流程混乱、质量无法保障、环境管理低效、资源浪费等方面,结合阿里巴巴的DevOps实践,深度解析了企业级持续交付如何做,企业如何高效协作,控制成本的精彩分享。

一、技术管理者的烦恼

开发工程师的日常

图片描述

我们看下开发工程师每天都是如何工作的。老三样总是逃不掉,写代码、测试、发布到线上。具体来看首先要拉分支,每个团队一般都有自己的研发规范,团队成员都需要遵守才能保障基本研发秩序。其次,我们会先在本地进行一些测试,编写一些测试用例,测试通过后需要进行合并请求,最终经过一个流程,逐级发布代码到生产环境。

这老三样说起来简单,但正是我们研发效率需要提升的重要环节,因为它们每天都在不停地被重复。甚至在不断的反复踩坑。比如有重复的工作,有质量问题,有环境问题,还有协作问题。在持续交付原则中有一项,就是如果这件事让你痛苦,那就尽早且尽可能频繁地去做。当然我们不能容忍各种坑,各种效率低下,那么就要想办法去解决这些让我们头疼的问题。

技术管理者的烦恼

开发者日常的苦恼,必然也是技术管理者的烦恼。总结一下,一般会是这么几个方面:

研发流程混乱。团队有大量新人的时候,如何能确保每次代码提交都不会出错?跨团队协作的时候,如何让所有人对于流程理解都是一致的?如何能不用一个scm团队来解决这个问题?其实我们的实践中scm团队也解决不了,如果没有完善的工具支持,很难确保万无一失。
质量无法保障。测试用例覆盖,规约扫描,安全检查是否都能实打实的保障,如何去促进代码质量逐步提高,而不是形成破窗效应后越来越差。
环境管理低效和资源浪费。这个一直是运维工程师的痛,尤其是测试环境。微服务化后,这个问题更加严重,服务之间互相依赖。管理复杂度和工作量成倍提升。还好我们有了容器化的救命稻草,但是仍然无法解决应用稳定性问题。稳定性不好直接导致开发工作互相block,最终拖慢我们整个团队效率。
繁杂的开源工具。用一堆工具攒出来的流程能否一站式解决所有问题,并且有比较好的体验?这要画一个问号。

看到这些问题,我想大家不由自主的会想到云计算,容器化,DevOps等等新的名词,那我们首先看看目前这几个在业界的形势如何。

持续交付与云计算

图片描述

这是我从2016中国软件开发者白皮书中摘录的一些信息。首先看到的是企业上云成为趋势,因为上云可以大大减少我们的it成本,不管是公共云还是私有云。目前来看私有云还是首选,最近3年从7%增长到27%,混合云是目前比较流行的玩法。

DevOps成为业界热词。DevOps给大家带来的直接的想法是将两种角色合二为一,效率肯定有提高,因此可以看到86%的企业不同程度上使用了DevOps相关工具,大部分是Docker和Jenkins。不难理解,这两个工具是目前最容易上手的。

最后是企业对开发工具和流程的认可,绝大部分企业都有严格的研发流程对开发工作进行规范,7成人群在其中受益,并且21%开发者希望公司能加大在这方面投资。这个数字挺有意思,可能表明还有3成的员工还在痛苦挣扎,等待救援。

持续交付与DevOps
图片描述

看了以上我们管理者的痛点,回到正题,持续交付和DevOps,如何能使用这两个理念来解决我们软件生产中的问题?先看看两者要解决的核心问题。

首先是持续交付,核心是需求小批量流转,配合自动化流水线,实现软件短周期的频繁交付。
DevOps的核心是什么?几个关键词:一种方法和文化,自动化、度量和分享,基础设施即代码。

在这里名词解释并不是我的重点,先撇去概念看本质,其实两者都是在说效率与成本这两个词。如何做到效率最高,如何做到成本最低,就是我们研发平台要解决的核心问题。

下面我会重点围绕这两个主题,来介绍阿里巴巴如何做到高效协作和成本控制。

二、高效协作&成本控制

研发模式全自动化

图片描述

说起自动化我们就想到了流水线,但是仅仅是流水线还是不够的,它仅仅解决的是发布过程自动化问题,并无法完全解决开发者的日常协作问题。比如什么时候拉分支,什么时候合并代码,需要达到什么样的标准,发布分支怎么处理,如何和流水线自动的结合起来。这些才是开发日常工作中最繁琐,最容易出错的事情。

如何将研发模式固化下来,并形成全集团的几套规范,落地平台?如何让开发之间的协作都一键化,自动化?这是云效首先要解决的问题。

在我们的实践中,将分支模式、自由模式、gitflow模式抽象到产品层面,穿插在流水线前中后,实现研发模式全自动化。真正的做到了研发过程全上平台,所有数据可追踪,并且彻底杜绝了漏发、错合、管理混乱的情况。甚至开发只需要会checkout和push,其他的都交给平台处理。

总结一下就是规范操作、高效协作、避免错误。分支模式和自由模式已经在云效开放,其他模式和高级配置功能正在陆续开放中。

统一技术栈和运维栈

图片描述

研发过程统一了,那么接下来要面对的就是技术栈和运维栈。我想绝大部分企业都不太喜欢自己的技术栈过于庞杂,这会给员工带来很大的学习成本,比如阿里巴巴主要是Java,我们可以投入很大精力去做框架,去做JVM优化,建设中间件,包括很多测试方案都会基于这个技术栈来做。运维栈更不用说,标准化才能带来成本的节省和效率的提升。

阿里是从以下五个方面来保障技术栈和运维栈统一的。
首先我们有基于不同研发模式和流水线的视图,根据不同的技术栈,在流水线视图上也略有不同。打个比方:C类应用的发布比Java类的就略显复杂,他们在依赖软件包的更新和参数维护上略有差异,我们通过不同的流程组件来解决。
其次是代码推荐,其中包括各种语言技术栈,最新的玩法和框架,让我们平台成为了新技术推广的窗口。
运维模板会包含软件包的模板,Dockerfile,环境规划等等。我们会提供标准化推荐,各个BU技术负责人也可以在平台上针对自己的部门进行定制和维护。所有这些都会在应用创建时确定,普通开发基本不需要介入和了解。
最后两层可以归纳到基础设施层面,统一的应用运维平台,负责机器资源和相关软件资源的分配。系统软件帮我们解决虚拟化和运行环境问题。
这五个层次共同协作才能完整实现技术栈和运维栈的统一,而云效在阿里巴巴正是我们看到的paas和iaas层的对普通研发人员统一出口,并且负责将这些服务粘合起来。比如最新的发布技术、中间件隔离技术、灰度切流技术、测试技术等等。

全云化测试平台

前面从研发、技术、运维角度讲了如何帮助开发高效协作。下面会讲两个成本控制的例子。

首先是全云化测试平台,阿里巴巴虽然技术栈大体统一,但是仍然避免不了各个BU在测试方面的创新,各种工具,各种平台必然会导致一些重复建设和资源浪费。最近几年我们开始建设全云化测试平台,首先他要做的是将各种测试工具通过统一的标准接入进平台,再通过统一的调度引擎为测试工作提供资源保障。当资源由我们来控制的时候,就可以创新出很多资源节省的策略,比如动态伸缩,资源池复用,离在线混布等等。目前我们每日的任务是已经达到了10w+。

图片描述

可以从这个图中看出用户的各种测试工具统一运行在我们的Test engine上,资源来自集团ECS和Docker池,并且在云效我们支持了企业自研自动化测试工具的接入,方便用户将自己的测试方案在企业内部推广和落地。

测试环境隔离

下面我们看下测试环境,大家可别小看了线下测试所带来的资源成本。在阿里目前线下测试物理机规模已经达到数万台。随着微服务化的推进,应用数量和依赖复杂度都被迅速放大,如何管理好测试环境和资源已经变得非常棘手。

这里介绍下阿里的一个比较好的实践经验:测试环境隔离。先看下这个图,我们把日常工作环境分为三部分,第一个是开发机,调用请求的发起方,可能就是我的一个笔记本。第二是隔离环境,里面部署着我们需要联调的应用A1、B1、C1。这三个应用正在实现我们一个要上线的需求。当然我的调用链路会很长,有更多的依赖方,自然我们需要一个基础环境,这个环境里部署着我们所有的应用。

图片描述

类似这种隔离设计,既保障了业务联调又节省了大量机器资源,当然最关键是我们如何实现服务之间的调用隔离。在阿里内部http统一接入、全链路追踪和统一中间件技术,帮助我们实现了无业务侵入性的服务隔离,不需要额外的运维工作,只需要在系统上划出相应的服务范围,对于调入请求会自动进行染色操作,不管这个请求调用到哪里,不管是同步还是异步,最终都可以保证A、B、C服务在两个环境中的互斥关系。

未来类似的环境规划和服务隔离能力也会在云效开放。总结一下就是环境复用、一键申请、快上快下、无代码侵入。

企业级持续交付
图片描述

我们看下一个持续交付平台如何才能做到真正的企业级。

第一个阶段应用创建,元数据维护,代码推荐,技术栈模板,流水线。第二是测试验收,静态扫描、代码规约、安全测试等等。测试完成我们需要部署,就涉及到环境的标准化,企业统一的环境规划,运维模板和云化的动态伸缩能力可以为我们大大节省成本。最终要发布前还需要管理审核、验收卡点、发布窗口等等管控策略。最后上线过程一定需要分批滚动、过程监控和快速回滚能力。

如此五大内容基本可以满足我们开发人员日常的研发活动,不断地在这几个过程中流转,实现最终持续交付目标。

三、阿里DevOps落地

应用为中心的DevOps理念

接下来我们回到DevOps这个热词上,和大家分享下阿里巴巴如何实现DevOps落地,从开发工程师角度怎么看待DevOps这个运动。

图片描述

第一点我要提的是以应用为中心的DevOps理念。应用信息其实可以归纳为cmdb中的一种数据,它对于研发人员天然是亲切的,它可以直接对应一个服务,一个代码库。从代码为起点,又可以串联流水线、环境、测试和资源,最外围工具链监控、db、运维、中间件等等。

用应用串联整个工具链,可以让开发顺理成章的理解和打通DevOps整体过程。不会存在开发说代码,说服务,运维说机器,说机房这种鸡同鸭讲的情况出现。

当工具通过应用打通后,开发就可以顺理成章的在平台上定义它的应用,同时也是在定义运维。比如我可以规划环境,创建资源,设置发布策略等等。

完成定义后,谁定义就要谁负责,因此在阿里,开发需要为应用全生命周期负责,也就是我们看到的这整个大圈。通过类似理念和运维自动化工具化的推进,dev潜移默化的接手了ops的工作,会发现原来这些东西并没有那么复杂。

应用生命周期自助管理

下面我们看一个实际的例子,这是我们一个应用上线过程,信息初始化,代码推荐,配置设置,资源申请,step by step完成。

图片描述

不论是测试环境还是生产环境,不管是技术栈还是运维栈,全部由开发工程师来定义。在全过程中只需要一次审核操作,分钟级即可完成应用注册和发布。

说到全生命周期管理,我们在应用上线后,还会配合度量系统,评估应用健康状况和资源使用情况,对长尾应用进行及时清理和资源调整。

容器化助力DevOps落地

再来看容器化。阿里巴巴从2016年双11前开始大规模推广容器化技术,到今年双11已经完成了几乎所有活跃应用的容器化,这是一个非常惊人的技术革命。为什么我们要这么大力气去推动改变,容器化对DevOps又有何帮助?

图片描述

大家可以看这个图,左侧是在容器化前,我们要做的事情和所需要的角色。软件包管理、基线变更、运维脚本的修改、资源申请、扩缩容等等,哪个工作离不开运维工程师。这些事情门槛高,手工程度大,变更方式复杂,最终导致两个角色协作效率低下。

右侧是我们容器化后的情况,原先软件包管理、基线变更、运维脚本统统交给了dockerfile来解决。在代码库里管理,并通过流水线实现变更,大大简化了变更复杂度。另一部分比如日志清理,巡检类的运维脚本我们通过全网命令通道插件化的承载在ops工具上,负责同学转型为工具开发来维护插件的可靠性。

其他资源类的事情统一由容器调度解决,其中包括统一调度开发,规模化运维相关算法开发等等,通过人工智能,通用性的解决资源利用率问题,比如2017年双11落地的离在线混布技术。

通过容器化,我们实现了环境标准化,运维服务的下沉,智能化的解决了效率和成本问题。因此可以说通过容器化改造,DevOps理念真正在阿里落地。

松管控和强卡点

图片描述

最后还有一个比较关键的点,当开发开始定义运维,接手运维的时候,我们管理者会不会有些担忧,比如会不会开发任意操作导致线上故障,随意发布导致稳定性问题等等。

在阿里我们建设平台的核心理念是松管控和强卡点。先看松在哪里?松在我们有多种流水线可以供开发选择,应用owner可以完整定义这个应用的各种规则,比如如何发布,如何测试,资源、环境配置如何。我们有通用构建和自定义构建给用户最大自由度,最后我们是轻发布,重恢复。在每一个应用维度,开发可以随时使用流水线来交付代码,而并不需要特别的限制,仅仅需要思考的是如果出问题,我们应该如何快速恢复。

在足够的自由度下我们还有一些卡点可供选择,比如代码审核和质量红线,规约检查,发布窗口,和前后端联动。这些卡点是为了保障集团所有开发工程师步调统一,交付合格的产品。

持续交付核心是快速交付价值,给与开发最大自由度,负责开发和运维全部过程。在监控、故障防控工具,功能开关的配合下,可以在保障用户体验和快速交付价值之间找到平衡点。

四、云效实践

上手云效最佳路径

图片描述

最后我们看看如何通过云效提高研发效能。首先可以通过首页的快速开始完成创建产品空间,创建代码库,选择我们的研发模式,创建应用,也就是刚我们所说的非常重要的基础元数据。然后配置构建、机器、部署规则,并通过流水线完成交付。

云效会提供一些模板和测试机器,帮助我们快速上手。

使用持续交付流水线

图片描述

大家现在看到的是我们系统一个流水线的视图,根据不同的研发模式,视图会略有不同。云效根据现代企业软件研发特点,自主研发了全新的流水线。不同的团队,比如研发、测试、运维都可以在不同的stage上工作,并且互不干扰。而且有多种触发机制可供选择,阿里优秀的组件还在陆续开放中。

无侵入的构建加速

图片描述

再来看下构建,云效完全自研的全云化构建调度系统,拥有经过阿里云安全团队认可的安全加固机制。并且根据不同技术栈提供了自适应的构建缓存策略,避免依赖的重复下载,大大节约构建时间,提高开发过程效率。开发在使用云效只需要选择他的技术栈和构建命令,其他都可以交给平台自动化完成。

全网部署能力

再看下部署能力,不管是公共云,还是专有云,还是其他云主机,云效都可以接入并执行部署。他是基于阿里内部的agent的技术,安全高效,此技术已经在阿里巴巴全网部署并且经过多年改进。

如下图所示,不管是采购云效公共云还是专有云,我们的主机都无需暴露公网就可直接接入,可选择通过internet或者专线对不同的云进行互联,对开发人员屏蔽底层机器资源细节,提高自动化程度和工作效率。

图片描述

Docker、EDAS、ECS任意切换

图片描述

云效目前支持Docker、Edas、Ecs三种部署方式,对每个应用的每个环境都可单独定义它的部署方式,并且实现任意切换,方便快捷。比如我们生产环境使用edas保障稳定,测试环境使用ecs混合部署节省资源都是可以实现的,非常方便。

在我们做运维栈转型升级的时候,可以通过修改部署配置进行平滑升级,如果有问题,我们还可以实现一键回滚。云效保存着历史所有软件发布升级的基线数据随时可查,随时可rollback,这些都是阿里巴巴内部多年积累的实践经验。

作者介绍

陈鑫(花名神秀),阿里巴巴高级技术专家,负责阿里集团持续交付平台和研发工具建设,致力于企业研发效率、产品质量、DevOps方向研究和探索。在阿里6年带领过大数据测试团队、测试工具研发团队、持续交付平台团队。对研发协同、测试、交付、运维领域都有很深的见解。

评论