写点什么

阿里巴巴 DevOps 文化浅谈

作者:阿里云云效
  • 2022 年 2 月 08 日
  • 本文字数:6424 字

    阅读完需:约 21 分钟

阿里巴巴DevOps文化浅谈

近些年 DevOps 火遍全国,似乎不说 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 能力,还会将云原生能力、智能化能力融入其中,最近我们正在积极准备,敬请期待!有兴趣的开发者也可以在云效用户群(钉钉群号:23362009)中联系我们,申请试用,谢谢大家。


【关于云效】云效,企业级一站式 DevOps 平台,源于阿里巴巴先进的研发理念和工程实践,致力于成为数字企业的研发效能引擎!云效提供从“需求 ->开发->测试->发布->运维->运营”端到端的在线协同服务和研发工具,通过人工智能、云原生技术的应用助力开发者提升研发效能,持续交付有效价值。


立即体验


关于我们


了解更多关于云效 DevOps 的最新动态,可微信搜索关注【云效】公众号;


福利:公众号后台回复【指南】,可获得《阿里巴巴 DevOps 实践指南》&《10 倍研发效能提升案例集》;


看完觉得对您有所帮助别忘记点赞、收藏和关注呦;



发布于: 刚刚阅读数: 2
用户头像

还未添加个人签名 2021.11.05 加入

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

评论

发布
暂无评论
阿里巴巴DevOps文化浅谈