阿里巴巴DevOps文化浅谈
DevOps发展的三个阶段
陈鑫,阿里云云效产品技术负责人
专注于为中小企业提供成都网站建设、网站建设服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业凤阳免费做网站提供优质的服务。我们立足成都,凝聚了一批互联网行业人才,有力地推动了上千余家企业的稳健成长,帮助中小企业通过网站建设实现规模扩充和转变。
首先我们简单看一下什么是DevOps,这个词从何而来。我在这里把DevOps发展历史分为三个阶段:诞生期、定义期和落地期。
DevOps的“祖师爷”是比利时一名独立IT咨询师Patrick Debois。2007年,他负责一个大型项目的测试和验证工作,一边和开发对接测试代码,一边和运维对接“发版”。他发现项目组里的开发和运维两个角色的思维方式差异巨大,一边希望“快快快”,一边希望“稳稳稳”,这让他有点崩溃。
在2008 Agile Conference大会上,Patrick遇到了Andrew,两个人一拍即合,开始琢磨如何改变这种Dev和Ops水火不容的现状。
2009 年 10月,Patrick 通过 Twitter 召集开发工程师和运维工程师在比利时根特市举办了首届“DevOpsDays”大会,开始大规模讨论Dev和Ops的协作话题。后来为了便于传播“DevOpsDays”被缩写为“DevOps”。
在2009年以后,DevOps开始火遍全球。2010 年,The Agile Admin博客发表文章《What is DevOps 》 ,详细阐述了DevOps的定义,包括一系列价值观、原则、方法、实践以及对应的工具。
同样是2010 年,《持续交付》的作者Jez Humble出席第二届的 DevOpsDays 大会,并做了 “持续交付”的演讲。这是非常重要的里程碑,可以说《持续交付》这本书就是DevOps的最佳实践,以至于国内搞研发效能的同学人手一本。也正是这本书,加速了业界对DevOps的理解以及落地。
但我认为业界真正开始大规模落地DevOps,还是不能离开容器化技术的功劳。“Docker”起到了决定性作用,通过编写Dockerfile,第一次可以让开发者轻松定义软件运行环境,并且能通过CI/CD标准化流程去交付它。不过这么多容器运维起来仍然麻烦,于是google在2014年开源“k8s”(Kubernetes);2015年CNCF(Cloud Native Computing Foundation 云原生计算基金会)成立,正式将“k8s”作为核心,建立了一个巨大的生态系统。有了“docker”和“k8s”技术上助力,加速了开发和运维角色的融合,于是DevOps不再是空中楼阁。
我距离DevOps有多远
回顾完历史,我们对照下自身,通过三个小问题来看看自己的团队是不是已经是“DevOps”了。
1、我每次写完代码都可以部署生产环境,不需要别人帮助。
2、有很多监控、运维工具可以任我使用,轻松处理线上各种问题和故障。
3、我直接为线上用户的体验负责,不管是代码缺陷还是运维故障,自己搞的自己背锅。
以上我三个问题,其实分别涉及到了DevOps最重要的三个方面,做法、工具、文化,这三者缺一不可。
什么是好的DevOps团队
什么是高效能研发团队呢?我们可以参考《2018 DevOps现状报告》里这张表格:能做到每小时1次或者每天1次部署,1天或1周能够上线1个版本,服务恢复时间小于1天,变更失败率小于15%。不过这个数字其实并不好看,以我们自己举例,阿里巴巴研发平台团队,可以轻松做到1天多次发布生产,可用性99.95%,变更失败率小于5%。
这些要求在阿里巴巴看起来稀疏平常,那阿里是怎么一步一步走过来的,我们其他企业应该如何复制这些经验。让我们进入下一节,阿里巴巴的DevOps文化落地要诀。
阿里巴巴DevOps的发展阶段
DevOps的发展永远离不开技术的变革,在2008年的时候,淘宝启动了服务化改造的历程,创造了Dubbo、Apache Alibaba RocketMQ、TDDL(Taobao Distributed Data Layer)等业界知名的中间件。同时淘宝的巨型应用被拆分,变成了下单、会员、优惠等一系列应用,而围绕各个子业务场景更是诞生了成百上千个前台应用。大家可以想象一下当时的开发是怎样的,每周一个固定发布窗口,几百位工程师在临近发布时提交代码、修改bug、提交测试。在发布日晚上开始按照顺序进行逐个发布,如果发布后出现重大bug,要么当场Hotfix(修补程序),要么回滚,宣告发布失败。所有人都被发布日搞的筋疲力尽。第一代自动化发布工具的出现,将发布能力交还给了开发者,同时也迫使开发者去解耦应用依赖,做到独立发布,业务交付速度得到了质的提升。后来大家给它起了一个名字,就是“微服务”。
没过两年,随着研发人员越来越多,出现了各种复杂研发规范、各种复杂脚本、各种 “挖坑”“踩坑”等情况,让研发工程师苦不堪言。“这一切必须规范起来”,2013年时我们建立了统一构建部署平台,将阿里巴巴集团从代码变更到线上发布环节完全统一起来,进行严管控。
在2016年我们又遇到了新问题,当时线上操作需要运维同学统一来做,而运维同学天然不想去做变更。可以理解,什么都不改的情况下服务是最稳定的。可这在某种程度上限制了开发者的创新,而且明确的职责分工也限制了开发者去关注自己应用的线上状态。这种情况,导致研发过程中出现明显瓶颈,这也是为什么阿里巴巴要做DevOps的根本原因。随着“容器化”的浪潮来临,我们研发平台再一次升级,将线上容器定义、运维监控责任全部交给了开发者,应用运维岗位不复存在。
而今天随着云原生技术的逐步成熟,上云已经变成企业标配,围绕云原生去定义下一代研发平台成为必然。
综上,技术的推动、组织的变化和研发工具的建设,这三者的有机结合才促成了我们阿里巴巴DevOps一步步走向成熟。
阿里巴巴DevOps落地的工具
前面介绍了宏观上技术和平台的发展,具体来看有以下几个工具对阿里巴巴DevOps落地以及研发效能提升发挥了重大作用。
首先是DevOps平台“云效”,大家常见的开源软件Gitlab、Jenkins、Jira这些平台也曾经是阿里巴巴的一个选择,但是后来我们发现,纯工具类型的软件只能解决一些单点自动化问题,比如代码管理、构建打包等等。其实在实际开发过程中还有很多工作无法自动化,比如需求流转的规则,分支管理的规则,开发、测试、运维沟通的模式等。这些工作我们可以统称为“协作”。
要做好“协作能力”需要的是对人和流程以及效率有深刻的理解,并且将这些理解抽象成方法,最终做成产品。阿里巴巴通过数年积累,产出了众多独特的研发管理方法,比如Aone-flow代码管理模式、测试环境管理模式、 AGit-Flow代码管理模式、双十一分层项目管理模式等等。我们把这些研发管理方法都落地在云效平台上,最后作用在人身上,潜移默化的影响着开发者协作的文化,也可以说是DevOps文化。
第二个是流量回放测试技术。这项技术的创新给测试团队带来了很大影响,通过线上流量复制到线下,低成本的解决了测试回归的问题,将传统通过编写用例进行测试,简化为编排数据进行测试。第二层是Mock技术的应用,将一个分布式系统问题,转化为单机问题,可以在几秒钟完成上千个用例运行。有了这两个基础技术后,在上层可以发展测试平台,通过算法的手段去识别有效流量,去自动化处理数据,去识别异常流量背后的缺陷。通过这三层面的变革,可以说让阿里巴巴测试效率有了质的变化。
第三个是全链路压测技术(对应阿里云上的产品叫PTS)。双11大家之所以能放心剁手,一年比一年顺滑,核心就是这项技术在每次大促前帮助开发者发现风险。发现以后就需要快速的响应,通过DevOps工具去解决线上问题。每次压测都是一次练兵,有点类似于军事演习,快速发现问题,快速解决,不断锤炼团队DevOps能力,也可以这样说阿里巴巴的DevOps能力正是一次一次“双11”给练出来的。
阿里巴巴DevOps核心理念:松管控和强卡点
当开发开始定义运维,接手运维的时候。我们管理者会不会有些担忧,比如会不会开发任意操作导致线上故障,随意发布导致稳定性问题等等。
阿里巴巴DevOps有一个核心理念是松管控和强卡点。
先看“松”在哪里?“松”是指我们有多种流水线可以供开发选择,应用Owner可以完整定义这个应用的各种规则,比如如何发布,如何测试,如何进行资源、环境配置等。我们有通用构建和自定义构建,可以给用户最大自由度。最后是“轻发布,重恢复”。在每一个应用维度,开发可以随时使用流水线来交付代码,而并不需要特别的限制,仅仅需要思考的是如果出问题,我们应该如何快速恢复。
在足够的自由度下,我们必须要设置一些“卡点”。比如代码审核和质量红线;代码安全检查、规约检查;发布、封网窗口等。还有所谓“变更三板斧”:可灰度、可监控、可回滚。这些卡点是为了保障阿里巴巴集团所有开发工程师步调统一,交付合格的产品。
总结:DevOps核心是快速交付价值,给与开发最大自由度,负责开发和运维全部过程。在监控、故障防控工具,功能开关的配合下,可以在保障用户体验和快速交付价值之间找到平衡点。
阿里巴巴DevOps核心理念:以应用为中心
阿里巴巴是怎样快速落地DevOps的?这里我要重点提的是:以应用为中心的DevOps理念。应用信息其实可以归纳为CMDB中的一种数据。它对于研发人员天然是亲切的,它可以直接对应一个服务,一个代码库。以代码为起点,我们又可以串联流水线、环境、测试、资源。最外围是工具链:监控、DB、运维、中间件等等。
用应用串联整个工具链,可以让开发人员很好的理解和打通DevOps整体过程。不会存在“开发说代码、服务,运维说机器、机房”,这种鸡同鸭讲的情况出现。
当工具通过应用打通后,开发人员就可以顺理成章的在平台上定义它的应用,同时也在定义运维规则。比如,规划环境、创建资源、设置发布策略等等,这些都可以由开发人员完成。
完成应用和运维定义后,“谁定义就要谁负责”,因此在阿里巴巴,开发人员需要为应用全生命周期负责。通过类似理念和运维工具自动化的推进,“Dev”潜移默化的接手了“Ops”的工作。这时,你会发现原来“DevOps”并没有那么复杂。
享受DevOps红利,成为精英交付团队
通过我们前面提到的阿里巴巴在实践中锤炼的DevOps工具,“松管控、强卡点”和“以应用为中心”的DevOps理念,阿里巴巴的DevOps得以落地,并获取实实在在的效率红利。它消除对个人的依赖,降低团队之间的损耗,降低测试成本提升质量,降低发布软件风险。最终加快企业创新速度,让阿里巴巴在一场一场机会中可以快速响应。
上图是2018年我们发布的一些数据,首次提出了“211” 概念:85%以上的需求可以在两周内交付;85%以上的需求可以在一周内开发完成;提交代码后可以在1小时内完成发布。我也建议大家能够以“211”来作为自己企业的效能目标,通过先进的DevOps工具、实践和文化,三管齐下,带来红利,而不要为了做而做。
云时代带来的新机会
通过前面对阿里巴巴DevOps发展的介绍,我们不难发现这样一个循环:我们在软件研发过程中不断的遇到新的问题,从而催生出新的技术(比如微服务、容器化);然后新的技术又带来了架构的变革(比如服务化、技术中台);最终形成了软件研发的新模式。现在云原生技术来了,这项新技术能给我们带来哪些机会呢?
云原生是什么?业界有各种各样的解读,有观点认为:完全使用云来构建应用系统就是云原生。而从软件研发的角度来看,我认为云原生带来最大的变化是开发者仅需关注业务逻辑,从而带来极大地效能提升。这是怎么做到的呢?我们对比下传统应用和云原生应用。
在传统软件研发过程中,开发者的代码会深度耦合中间件,需要关注服务发现、分库分表、消息处理等多方面。往下也同样需要关注软件部署在哪,需要多少容量,甚至还需要关注操作系统、存储等问题。
在云原生时代会很不一样,中间件核心能力会下沉到云基础设施之中,一些常见的限流、降级、鉴权等能力都不需要关心了,数据库、运行环境等都是动态伸缩的,常见的运维问题也不需要关心。只需要开发好代码,通过软件交付平台自动化的发布到云端。
软件开发的复杂度其实不会消失,而是换一种方式存在。云原生技术下这种复杂度会下沉到云基础设施层,通过云去屏蔽这种复杂性。
那这种复杂性怎么解决,其中一个核心就是用数据去解决。在云原生下我们拥有业界统一的技术标准,比如中间件标准、容器标准等。拥有规范的数据和强大的基础设施,也可以轻松获取到这些数据。有了这些数据,我们就有机会去创造出各种智能工具,去解决我们软件开发的复杂度,或者是通过工具帮助开发者工作,降低这种复杂度。
因此在云原生技术下,我们拥有了前所未有的智能的机会和普惠的机会。
云原生时代影响开发者的三大技术体系
在云原生时代,我认为会有这三个技术会给开发者带全新的体验。分别是开发态的CloudIDE、运行态的Service Mesh、以及运维态的Serverless技术。CloudIDE将开发环境搬到了云上,而且可以和研发平台深度整合,为开发者提供极致的编程体验,再也不用关心我在哪里开发,只要有浏览器,打开就可以编码。
中间件在云时代会逐渐融入到Service Mesh技术下,服务路由、限流降级等开发者将不再关心。
Serverless技术,让自动扩缩,容量评估变为历史,开发者再也不关心机器在哪。
这三项技术将研发全链路云化,并且产生了大量研发数据、服务数据、运行时数据。阿里巴巴在最近几年已经开始投入这些数据的挖掘和研究工作,并且和学界保持着密切的合作关系。
阿里巴巴正在探索的数据应用方向
简单介绍一下我们目前正在探索的数据应用方向:在代码方面,有代码推荐、智能代码评审、代码搜索和优质代码分享。在运维监控方面,我们投入了智能基线,能够根据监控波动情况自动化报警,避免逐个配置规则。还有发布风险控制,通过识别变更前后监控异动来自动阻断发布过程。还有自动化配置的业务全景监控,全链路洞察业务稳定性等。
下面我会通过两个实例,深入细节,谈一下我们在数据应用方面取得的成果。
代码大数据的应用—PRECFIX缺陷监测技术
今年年初,PRECFIX代码缺陷检测技术(Patch Recommendation by Empirically Clustering)已经在阿里巴巴内部生产系统中上线,帮助开发者在代码评审时发现缺陷。
智能化手段在缺陷检测领域应用主要有三个难点:1)在没有缺陷数据沉淀和公开数据集的情况下,如何标注数据?2)代码是重逻辑形式语言,如何去表征代码内容?3)如何通过非人工规则给出修复建议?
我们具体的做法是这样的,首先通过数据挖掘手段标注疑似缺陷的commit,并提取相关统计特征进行学习,通过模型给出风险度评估。然后对缺陷commit的变更diff进行相似性代码聚类,找出工程师常犯的错误,以及工程师常用的修复手段。当再次发生类似错误时,就可以给与开发者相对应的修复补丁。
运行时大数据的应用—无人值守发布
前面一个是“Dev”端的工具,下面介绍一个“Ops”端的工具:无人值守发布。
曾经,我们对所有线上故障做了分析,发现80%的故障都是由“变更”引起的。这也说明如果你不做“变更”,基本上不太会发生故障。因为代码发布是线上变更的一个重要形式,所以要让系统稳定、持续不断地运行,就必须卡住发布这个口子。于是,我们做了 “无人值守发布”这个工具,它可以收集包括系统数据、日志数据、业务数据等,并对各种指标做检查,通过算法对比发布前后的指标异动。一旦发现问题,就可以对发布过程进行阻断,甚至实现自动化回滚。有了这项技术,任何一个开发团队,都可以安全的做好发布工作,运维团队也不必担心因为频繁的线上变更而导致重大故障了。
阿里巴巴软件研发平台的未来:全新云效即将上市
综上所述,“云”和“数据”是我们下一代软件研发平台最大的机会。这些数据智能工具虽好,但不能只给阿里巴巴来使用,更重要的是实现“云”的价值,也就是我们讲的普惠计算的价值。
因此今年我们会在阿里云上推出全新的DevOps工具平台“阿里云·云效”,不但可以继续为大家提供企业级一站式DevOps能力,还会将云原生能力、智能化能力融入其中,最近我们正在积极准备,敬请期待!有兴趣的开发者也可以在云效用户群(钉钉群号:)中联系我们,申请试用,谢谢大家。
【关于云效】
云效,企业级一站式DevOps平台,源于阿里巴巴先进的研发理念和工程实践,致力于成为数字企业的研发效能引擎!云效提供从“需求 ->开发->测试->发布->运维->运营”端到端的在线协同服务和研发工具,通过人工智能、云原生技术的应用助力开发者提升研发效能,持续交付有效价值。
立即体验
分享题目:阿里巴巴DevOps文化浅谈
当前路径:http://myzitong.com/article/dscggge.html