阿里巴巴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年带领过大数据测试团队、测试工具研发团队、持续交付平台团队。对研发协同、测试、交付、运维领域都有很深的见解。

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

【云周刊】第147期：解密天猫双11 1682亿背后的“霸下-七层流量清洗”系统
摘要: 解密天猫双11 1682亿背后的"霸下-七层流量清洗"系统,语音合成技术,从日志到双11大屏只要一步:LOG/SLS+DataV 打通,"业务为王"时代 ...
阿里1682亿背后的协同研发云——云效正式商业化
2017年4月阿里云宣布阿里巴巴内部的一站式企业协同研发云产品--云效正式开放对外,近日云效公共云版本正式进入商业化服务阶段,将为更多企业提供研发效能服务. 云效是一站式企业协同研发云,支持公共云.专 ...
阿里1682亿背后的协同研发云——云效公共云正式商业化
摘要: 2017年12月20日云栖大会北京峰会,阿里云宣布其一站式企业协同研发云产品--云效公共云版本正式进入商业化服务阶段,同时云效还发布了三大新功能模块:跨团队联合作战的项目集.多维度测试服务.便 ...
阿里1682亿背后的协同研发云——云效公共云正式商业化 1
摘要: 2017年12月20日云栖大会北京峰会,阿里云宣布其一站式企业协同研发云产品--云效公共云版本正式进入商业化服务阶段,同时云效还发布了三大新功能模块:跨团队联合作战的项目集.多维度测试服务.便 ...
2017天猫双11，1682亿背后的阿里绝密50+技术（长图下载）
2017天猫双11的交易额定格在1682亿.但对技术的追求,却从未定格. 11秒交易额破亿,28秒破10亿,3分01秒破百亿,40分12秒破500亿,9小时破1000亿--2017年11月11日的数据 ...
双十一1682亿背后的真相曝光
今年"双11"天猫平台第11秒钟,成交额便超过1亿元.9点00分04秒,天猫交易额冲破1000亿元,打破2017年全国社会消费品日均零售额. 双11成交额最终定格在1682亿元,相 ...
解密：天猫双十一1682亿背后的“霸下-七层流量清洗”系统
上古神话中,龙生九子,其六为赑屃(bi xi),又名霸下,力大无穷,喜负重.在阿里安全也有这么一套技术框架以此命名. 上古神兽--霸下名如其意,霸下的责任是支撑阿里安全产品的底层技术框架,它面向的用 ...
初创企业如何做高效持续交付
摘要: 6月29日,由阿里云研发协同RDC.阿里云云效和云栖社区联合举办的"首届阿里巴巴研发效能嘉年华"上,阿里巴巴产品专家.研发协同RDC产品经理胥引带来"初创企业的持 ...
高效持续交付的7大原则
原文链接:https://devops.com/7-highly-effective-continuous-delivery-principles/ 如果你身处IT领域,并且你不是昨天才出生的,那么你 ...

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

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

最新文章

热门文章