阿里巴巴 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 倍研发效能提升案例集》；

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