关于devops:阿里巴巴DevOps实践指南-以特性为核心的持续交付

36次阅读

共计 2463 个字符,预计需要花费 7 分钟才能阅读完成。

开发者工具
打造围绕开发者全生命周期的工具产品 https://developer.aliyun.com/…
随着微服务架构和云原生技术的成熟,继续交付的理念也深入人心。继续交付要求开发团队继续、高频地向生产零碎交付软件。然而,一直增多的服务数量,给企业交付流程治理带来了微小挑战。同时,在 DevOps 落地的过程中,逐渐凋谢生产环境的公布权限给到开发人员,这种松管控与企业平安生产存在抵触,多利用版本之间的协同问题也逐步凸显。如何解决企业在新技术转型和 DevOps 落地中的痛点,拿到技术改革带来的效力红利,是每个企业包含阿里巴巴都必须面对和解决的难题。

软件交付挑战

阿里巴巴 2008 年对淘宝巨型服务进行拆分当前,逐步形成了一套实用于服务化、分布式架构的中间件体系,解决了简单零碎性能和稳定性在业务高速扩张中的瓶颈问题。随之而来的是利用变多、架构依赖简单、人员数量高速收缩、技能参差不齐等等问题。总结下来有以下几个方面:

利用数量多

微服务架构被广泛应用当前,首先面临的就是利用数量的疾速收缩。原有研发流程也必须从批量公布模式向继续交付模式转型,否则会导致公布软件的危险和回滚的复杂度不可控。另一方面,测试和运维的工作量因为利用的收缩而倍增,变成整个研发团队的效率瓶颈。突破这种瓶颈的办法就是 DevOps 的全面落地,把整个软件交付过程交给开发来主导,从而解除瓶颈晋升效率。

架构依赖简单

微服务架构让利用内依赖变为了利用间依赖,变更过程无奈做到原子化,因而须要很好的模块拆分和接口设计。一方面缩小单个性笼罩的利用数量,变更程序可控、回滚危险可控;另一方面单元测试能笼罩的场景须要集成测试来笼罩,导致开发过程对测试环境的应用频度和依赖度变高,须要稳固、牢靠的环境来保障所有开发人员都能够并行工作。

测试资源老本大

测试环境受到资源老本和运维老本双重制约。在业务倒退初期,能够采纳全链路残缺部署加上多套环境的形式来满足研发团队的要求。然而随着业务的疾速倒退和研发团队的疾速扩张,一直地减少环境在老本上曾经无奈累赘。因而须要一套运维高度自动化,高度弹性随用随取,并且能够实现部分隔离的测试环境计划来满足多版本部署需要。

研发协同难

研发环节的协同分为开发间协同和测试,开发、运维多角色间协同两种。前者次要解决并行开发、按需上线的问题。后者解决的是在一个交付流程中各司其职、相互束缚,确保软件能高质量、平安交付的问题。在 DevOps 场景下软件交付过程由开发人员主导,而测试和运维角色则须要承当流程守护、门禁卡点、提供自动化工具的责任。为了晋升协同的效率,须要一个可能满足以上要求的工具平台来将团队的约定固化下来,确保团队各个角色能够高效率的实现工作。

线上危险大

线上的危险来自于两方面,一方面越来越高频的线上迭代意味着出错的概率也在变大,另一方面随着零碎规模变大,传统人防人治的伎俩已不可能满足风控要求。因而必须从出错可能性和出错影响面两个方面系统性地去解决问题,前者关注是否在出错之前对危险进行拦挡,而后者关注零碎变更影响的用户数量和频度。这两种被动和被动进攻措施的相结合,能够无效的解决危险管制的投入产出比问题,从而达到一个比拟优的状态。

解决思路

为了解决以上在企业规模增长和新技术利用中的种种交付痛点,阿里巴巴一直摸索和尝试,逐渐摸索出一种适宜这种业务倒退快、软件迭代快、架构依赖简单场景的交付办法和实际,咱们称之为“以个性为外围的继续交付”。它有三个特点:

以个性为外围

个性是一个用户能体验到的产品能力的最小单元,其代码可能波及到多个利用,因而个性也是协同多个开发团队实现一个能力的最小单元。以个性为外围的交付过程治理能够无效地将开发、测试等角色连接起来并对立推动,比方组织隔离测试环境、运行自动化测试、编写测试用例、做好测试验收等等。

以利用为载体

利用能够间接对应一个服务,是提供一种业务能力的最小单元,也是软件交付和运维的最小单元。能够通过利用串联代码、流水线、环境、测试和资源,以及外围工具链比方监控、数据库、运维、中间件等。开发人员能够在工具平台上定义他的利用,及利用的交付运维过程,比方配置流水线、布局环境、创立资源、设置部署策略等。以独立利用为载体的交付流程能够实现软件交付的原子化,并强制开发升高利用间的耦合性,同时防止零碎级集中式交付模式的惯性。

松管控与强卡点

在软件高速迭代下须要兼顾品质和效率,DevOps 模式须要给开发人员足够的自由度来实现软件的线上变更,阿里巴巴联合本身业务特点,在实践上采纳了松管控和强卡点联合的形式。“松管控”体现在有多种流水线能够供开发抉择,利用负责人能够残缺定义这个利用的各种规定,比方如何部署、如何测试、资源环境如何配置。在技术可控的前提下,还能够凋谢线上测试,比方全链路压测和全链路灰度。轻公布,重复原,在每一个利用维度,开发能够随时应用流水线来交付代码,不主张过多的人为限度,重点须要思考的是如果出问题,如何管制影响面,如何疾速复原。“强卡点”是一种软件品质底线思维的体现,比方代码审核和品质红线,规约查看,公布窗口,安全检查,线上灰度卡点等。这些卡点是为了保障团体所有开发工程师步调对立,交付合格的产品。

继续交付的外围是疾速高质量地交付价值,给与开发人员最大自由度,负责开发和运维全副过程。在监控、故障防控工具、性能开关的配合下,能够在保障用户体验和疾速交付价值之间找到平衡点。

总结
明天,基于云的开发已成为支流,这是效力晋升的微小机会,同时又对工程实际提出了前所未有的要求。比方,云原生基础设施、云原生中间件和新一代的云软件编程办法等等,都要求有与之适配的实际和工具。在适配新的技术发展趋势过程中,阿里造成了以个性为外围的继续交付工程实际,并且将其内建到 DevOps 工具体系中,以保障实际精确、无效地落地。
编者按:本文源自阿里云云效团队出品的《阿里巴巴 DevOps 实际指南》,可返回:https://developer.aliyun.com/…,下载完整版电子书,理解阿里十年 DevOps 实践经验。

正文完
 0