近些年 DevOps 火遍全国，似乎不说 DevOps 研发效率就是低下的，技能就是落伍的。然而真是这样么？为了让大家更好的了解 DevOps 文化，3 月 27 日《云效说码》分享特别邀请了阿里巴巴资深技术专家陈鑫（花名：神秀）进行视频直播分享，聊聊他对 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 平台，源于阿里巴巴先进的管理理念和工程实践，致力于成为数字企业的研发效能引擎！云效提供从 “需求 ->开发->测试->发布->运维->运营” 端到端的在线协同服务和研发工具，通过人工智能、云原生技术的应用助力开发者提升研发效能，持续交付有效价值。

原文作者：神秀