阿里巴巴 DevOps 实践手册 (it-ebooks) (Z-Library)

📄 File Format: PDF

💾 File Size: 3.2 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

(This page has no text content)

📄 Page 2

钉钉扫码或搜索群号35236467 加入阿里DevOps 交流群， 获取2020阿里巴巴研发效能峰会 视频回放及PPT等更多干货 阿里云开发者“藏经阁” 海量免费电子书下载

📄 Page 3

目录 开篇 5 阿里巴巴DevOps文化浅谈 5 1.1　火遍全球的 DevOps 到底是什么？ 5 1.2　如何利用 DevOps 进行高效能研发？ 7 1.3　阿里巴巴是怎样快速落地 DevOps 的？ 8 1.4　如何享受 DevOps 红利，打造自己的精英交付团队？ 12 敏捷研发篇 16 业务驱动的精益敏捷实践 16 2.1　影响研发效能提升的三大问题 17 2.2　实现精益敏捷研发的四大步骤 18 代码管理篇 32 阿里巴巴自研代码管理平台技术解密 32 3.1　阿里巴巴为什么要自研代码管理平台？ 32 3.2　阿里巴巴代码管理平台的整体策略 33 3.3　云效代码管理平台的核心能力 35 3.4　云效代码管理平台的系统架构 36 3.5　人工智能技术助力敏感信息监测 38 3.6　代码质量—饱受好评的 P3C 代码规约检测插件 39 3.7　代码质量—缺陷检测技术 PRECFIX 技术揭秘 40 3.8　代码安全—敏感信息检测 SecretRadar 41 3.9　智能评审助力开发者提升研发效能 43

📄 Page 4

新一代高效Git 协同模型详解 45 4.1　Git 工作流概述及 AGit-Flow 的优势简介 45 4.2　在阿里巴巴，我们如何使用 AGit-Flow 48 4.3　AGit-Flow 实现原理 49 4.4　AGit-Flow 实现的技术细节 50 4.5　阿里巴巴开源的客户端工具 git-repo 简介 54 持续交付篇 56 企业如何规模化落地CICD？ 56 5.1　如何实现持续交付在阿里巴巴的规模化？ 57 5.2　阿里巴巴实现持续交付规模化落地的两大研发实践 57 5.3　如何进行全局风险管控？ 59 5.4　规模化落地 CICD 的重要一步 60 云原生下的开发测试 62 6.1　如何通过 kt-connect 解决本地与集群双向互通问题？ 63 6.2　KT-Connect 背后的原理 65 6.3　共用测试环境相互干扰问题及常见解决方案 67 6.4　如何使用 kt-virtual-environment 打造项目环境？ 71 6.5　阿里巴巴使用项目环境的最佳实践 72 解决方案篇 74 云效架构师手把手教你搭建DevOps平台 74 7.1　背景诉求与推进策略 74 7.2　云效与平台能力 77 7.3　一站式 DevOps 解决方案与详细介绍 79 7.4　三大案例分析 88 7.5　手把手带你完成一个项目 91

📄 Page 5

开篇 阿里巴巴DevOps文化浅谈 本文整理自阿里巴巴资深技术专家陈鑫（花名：神秀）的分享《阿里巴巴 DevOps 文化浅谈》。 1.1　火遍全球的DevOps到底是什么？ 首先我们简单看一下什么是 DevOps，这个词从何而来。我在这里把 DevOps 发展历史分为三个阶段：诞生期、定义期和落地期。 DevOps 的“祖师爷”是比利时一名独立 IT 咨询师 Patrick Debois。2007 年， 他负责一个大型项目的测试和验证工作，一边和开发对接测试代码，一边和运维对接 “发版”。他发现项目组里的开发和运维两个角色的思维方式差异巨大，一边希望“快

📄 Page 6

6　　>　阿里巴巴DevOps文化浅谈 快快”，一边希望“稳稳稳”，这让他有点崩溃。 在 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”了。 1. 我每次写完代码都可以部署生产环境，不需要别人帮助。 2. 有很多监控、运维工具可以任我使用，轻松处理线上各种问题和故障。

📄 Page 7

阿里巴巴DevOps文化浅谈　<　　7 3. 我直接为线上用户的体验负责，不管是代码缺陷还是运维故障，自己搞的自 己背锅。 以上我三个问题，其实分别涉及到了 DevOps 最重要的三个方面，做法、工具、 文化，这三者缺一不可。 1.2　如何利用DevOps进行高效能研发？ 什么是高效能研发团队呢？我们可以参考《2018 DevOps 现状报告》里这张表 格：能做到每小时 1 次或者每天 1 次部署，1 天或 1 周能够上线 1 个版本，服务恢复 时间小于 1 天，变更失败率小于 15%。不过这个数字其实并不好看，以我们自己举 例，阿里巴巴研发平台团队，可以轻松做到 1 天多次发布生产，可用性 99.95%，变 更失败率小于 5%。 这些要求在阿里巴巴看起来稀疏平常，那阿里是怎么一步一步走过来的，我们其他 企业应该如何复制这些经验。让我们进入下一节，阿里巴巴的 DevOps 文化落地要诀。

📄 Page 8

8　　>　阿里巴巴DevOps文化浅谈 1.3　阿里巴巴是怎样快速落地DevOps的？ 1.3.1　阿里巴巴 DevOps 的发展阶段 DevOps 的发展永远离不开技术的变革，在 2008 年的时候，淘宝启动了服务 化 改 造 的 历 程， 创 造 了 Dubbo、Apache Alibaba RocketMQ、TDDL（Taobao Distributed Data Layer）等业界知名的中间件。同时淘宝的巨型应用被拆分，变成 了下单、会员、优惠等一系列应用，而围绕各个子业务场景更是诞生了成百上千个前 台应用。大家可以想象一下当时的开发是怎样的，每周一个固定发布窗口，几百位工 程师在临近发布时提交代码、修改 bug、提交测试。在发布日晚上开始按照顺序进行 逐个发布，如果发布后出现重大 bug，要么当场 Hotfix（修补程序），要么回滚，宣告 发布失败。所有人都被发布日搞的筋疲力尽。第一代自动化发布工具的出现，将发布 能力交还给了开发者，同时也迫使开发者去解耦应用依赖，做到独立发布，业务交付 速度得到了质的提升。后来大家给它起了一个名字，就是“微服务”。 没过两年，随着研发人员越来越多，出现了各种复杂研发规范、各种复杂脚 本、各种 “挖坑”“踩坑”等情况，让研发工程师苦不堪言。“这一切必须规范起来”， 2013 年时我们建立了统一构建部署平台，将阿里巴巴集团从代码变更到线上发布环 节完全统一起来，进行严管控。

📄 Page 9

阿里巴巴DevOps文化浅谈　<　　9 在 2016 年我们又遇到了新问题，当时线上操作需要运维同学统一来做，而运维 同学天然不想去做变更。可以理解，什么都不改的情况下服务是最稳定的。可这在某 种程度上限制了开发者的创新，而且明确的职责分工也限制了开发者去关注自己应用 的线上状态。这种情况，导致研发过程中出现明显瓶颈，这也是为什么阿里巴巴要做 DevOps 的根本原因。随着“容器化”的浪潮来临，我们研发平台再一次升级，将线 上容器定义、运维监控责任全部交给了开发者，应用运维岗位不复存在。 而今天随着云原生技术的逐步成熟，上云已经变成企业标配，围绕云原生去定义 下一代研发平台成为必然。 综上，技术的推动、组织的变化和研发工具的建设，这三者的有机结合才促成了 我们阿里巴巴 DevOps 一步步走向成熟。 1.3.2　阿里巴巴 DevOps 落地的工具 前面介绍了宏观上技术和平台的发展，具体来看有以下几个工具对阿里巴巴 DevOps 落地以及研发效能提升发挥了重大作用。 首先是 DevOps 平台“云效”，大家常见的开源软件 Gitlab、Jenkins、Jira 这 些平台也曾经是阿里巴巴的一个选择，但是后来我们发现，纯工具类型的软件只能解 决一些单点自动化问题，比如代码管理、构建打包等等。其实在实际开发过程中还有 很多工作无法自动化，比如需求流转的规则，分支管理的规则，开发、测试、运维沟 通的模式等。这些工作我们可以统称为“协作”。 要做好“协作能力”需要的是对人和流程以及效率有深刻的理解，并且将这些 理解抽象成方法，最终做成产品。阿里巴巴通过数年积累，产出了众多独特的研发管 理方法，比如 Aone-flow 代码管理模式、测试环境管理模式、 AGit-Flow 代码管 理模式、双十一分层项目管理模式等等。我们把这些研发管理方法都落地在云效平台 上，最后作用在人身上，潜移默化的影响着开发者协作的文化，也可以说是 DevOps 文化。

📄 Page 10

10　　>　阿里巴巴DevOps文化浅谈 第二个是流量回放测试技术。这项技术的创新给测试团队带来了很大影响，通过 线上流量复制到线下，低成本的解决了测试回归的问题，将传统通过编写用例进行测 试，简化为编排数据进行测试。第二层是 Mock 技术的应用，将一个分布式系统问 题，转化为单机问题，可以在几秒钟完成上千个用例运行。有了这两个基础技术后， 在上层可以发展测试平台，通过算法的手段去识别有效流量，去自动化处理数据，去 识别异常流量背后的缺陷。通过这三层面的变革，可以说让阿里巴巴测试效率有了质 的变化。 第三个是全链路压测技术（对应阿里云上的产品叫 PTS）。双 11 大家之所以能 放心剁手，一年比一年顺滑，核心就是这项技术在每次大促前帮助开发者发现风险。 发现以后就需要快速的响应，通过 DevOps 工具去解决线上问题。每次压测都是一 次练兵，有点类似于军事演习，快速发现问题，快速解决，不断锤炼团队 DevOps 能力，也可以这样说阿里巴巴的 DevOps 能力正是一次一次“双 11”给练出来的。 1.3.3　阿里巴巴 DevOps 两大核心理念 当开发开始定义运维，接手运维的时候。我们管理者会不会有些担忧，比如会不 会开发任意操作导致线上故障，随意发布导致稳定性问题等等。

📄 Page 11

阿里巴巴DevOps文化浅谈　<　　11 阿里巴巴DevOps有一个核心理念是松管控和强卡点。 先看“松”在哪里？“松”是指我们有多种流水线可以供开发选择，应用 Owner 可以完整定义这个应用的各种规则，比如如何发布，如何测试，如何进行资源、环境 配置等。我们有通用构建和自定义构建，可以给用户最大自由度。最后是“轻发布， 重恢复”。在每一个应用维度，开发可以随时使用流水线来交付代码，而并不需要特 别的限制，仅仅需要思考的是如果出问题，我们应该如何快速恢复。 在足够的自由度下，我们必须要设置一些“卡点”。比如代码审核和质量红线； 代码安全检查、规约检查；发布、封网窗口等。还有所谓“变更三板斧”：可灰度、 可监控、可回滚。这些卡点是为了保障阿里巴巴集团所有开发工程师步调统一，交付 合格的产品。 总结：DevOps 核心是快速交付价值，给与开发最大自由度，负责开发和运维全 部过程。在监控、故障防控工具，功能开关的配合下，可以在保障用户体验和快速交 付价值之间找到平衡点。 另外一个核心理念就是：以应用为中心的DevOps 理念。应用信息其实可以归 纳为 CMDB 中的一种数据。它对于研发人员天然是亲切的，它可以直接对应一个服

📄 Page 12

12　　>　阿里巴巴DevOps文化浅谈 务，一个代码库。以代码为起点，我们又可以串联流水线、环境、测试、资源。最外 围是工具链：监控、DB、运维、中间件等等。 用应用串联整个工具链，可以让开发人员很好的理解和打通 DevOps 整体过程。 不会存在“开发说代码、服务，运维说机器、机房”，这种鸡同鸭讲的情况出现。 当工具通过应用打通后，开发人员就可以顺理成章的在平台上定义它的应用，同 时也在定义运维规则。比如，规划环境、创建资源、设置发布策略等等，这些都可以 由开发人员完成。 完成应用和运维定义后，“谁定义就要谁负责”，因此在阿里巴巴，开发人员需要 为应用全生命周期负责。通过类似理念和运维工具自动化的推进，“Dev”潜移默化 的接手了“Ops”的工作。这时，你会发现原来“DevOps”并没有那么复杂。 1.4　如何享受DevOps红利，打造自己的精英交付团队？ 通过我们前面提到的阿里巴巴在实践中锤炼的 DevOps 工具，“松管控、强卡 点”和“以应用为中心”的 DevOps 理念，阿里巴巴的 DevOps 得以落地，并获取 实实在在的效率红利。它消除对个人的依赖，降低团队之间的损耗，降低测试成本提

📄 Page 13

阿里巴巴DevOps文化浅谈　<　　13 升质量，降低发布软件风险。最终加快企业创新速度，让阿里巴巴在一场一场机会中 可以快速响应。 上图是 2018 年我们发布的一些数据，首次提出了“211” 概念：85% 以上的需 求可以在两周内交付；85% 以上的需求可以在一周内开发完成；提交代码后可以在 1 小时内完成发布。我也建议大家能够以“211”来作为自己企业的效能目标，通过先 进的 DevOps 工具、实践和文化，三管齐下，带来红利，而不要为了做而做。 1.4.1　云时代带来的新机会 通过前面对阿里巴巴 DevOps 发展的介绍，我们不难发现这样一个循环：我们 在软件研发过程中不断的遇到新的问题，从而催生出新的技术（比如微服务、容器 化）；然后新的技术又带来了架构的变革（比如服务化、技术中台）；最终形成了软件研 发的新模式。现在云原生技术来了，这项新技术能给我们带来哪些机会呢？ 云原生是什么？业界有各种各样的解读，有观点认为：完全使用云来构建应用系 统就是云原生。而从软件研发的角度来看，我认为云原生带来最大的变化是开发者仅 需关注业务逻辑，从而带来极大地效能提升。这是怎么做到的呢？我们对比下传统应 用和云原生应用。

📄 Page 14

14　　>　阿里巴巴DevOps文化浅谈 在传统软件研发过程中，开发者的代码会深度耦合中间件，需要关注服务发现、 分库分表、消息处理等多方面。往下也同样需要关注软件部署在哪，需要多少容量， 甚至还需要关注操作系统、存储等问题。 在云原生时代会很不一样，中间件核心能力会下沉到云基础设施之中，一些常见 的限流、降级、鉴权等能力都不需要关心了，数据库、运行环境等都是动态伸缩的， 常见的运维问题也不需要关心。只需要开发好代码，通过软件交付平台自动化的发布 到云端。 软件开发的复杂度其实不会消失，而是换一种方式存在。云原生技术下这种复杂 度会下沉到云基础设施层，通过云去屏蔽这种复杂性。 那这种复杂性怎么解决，其中一个核心就是用数据去解决。在云原生下我们拥有 业界统一的技术标准，比如中间件标准、容器标准等。拥有规范的数据和强大的基础 设施，也可以轻松获取到这些数据。有了这些数据，我们就有机会去创造出各种智能 工具，去解决我们软件开发的复杂度，或者是通过工具帮助开发者工作，降低这种复 杂度。 因此在云原生技术下，我们拥有了前所未有的智能的机会和普惠的机会。

📄 Page 15

阿里巴巴DevOps文化浅谈　<　　15 1.4.2　云原生时代影响开发者的三大技术体系 在云原生时代，我认为会有这三个技术会给开发者带全新的体验。分别是开 发 态 的 CloudIDE、 运 行 态 的 Service Mesh、 以 及 运 维 态 的 Serverless 技 术。 CloudIDE 将开发环境搬到了云上，而且可以和研发平台深度整合，为开发者提供极 致的编程体验，再也不用关心我在哪里开发，只要有浏览器，打开就可以编码。 中间件在云时代会逐渐融入到 Service Mesh 技术下，服务路由、限流降级等开 发者将不再关心。 Serverless 技术，让自动扩缩，容量评估变为历史，开发者再也不关心机器在哪。 这三项技术将研发全链路云化，并且产生了大量研发数据、服务数据、运行时数 据。阿里巴巴在最近几年已经开始投入这些数据的挖掘和研究工作，并且和学界保持 着密切的合作关系。

📄 Page 16

敏捷研发篇 业务驱动的精益敏捷实践 本文整理自洪永潮 ( 舍卫 ) 的直播分享《业务驱动的精益敏捷实施》。 随着 5G、人工智能、IOT 等新技术的迅猛发展，企业的业务都将构架在软件和 互联网之上。软件交付能力成为企业的核心竞争力，随着市场竞争的加剧，企业对研 发效能的期望越来越高。 然而新技术、新业态的不断涌现，又使企业的业务变得越来越复杂，各个团队之 间的协作也越来越困难，企业的研发效能呈现降低趋势。“期望”与“现实”之间产 生了巨大的“Gap”，正是我们要努力的方向。这就是为什么我们要提升研发效能的 根本原因。

📄 Page 17

业务驱动的精益敏捷实践　<　　17 2.1　影响研发效能提升的三大问题 为了提升研发效能，我们首先要知道是什么影响了研发效能——我们究竟面临怎 样的挑战？这里有三个“不等于”： 局部效率 ≠ 高效交付 如何提升“研发效率”，很自然想到是让大家都忙起来，也就是提升运营、产品 和技术人员（包括开发、测试和运维）的效率或延长工作时间。大家都忙起来，局部 的效率可能是提高了，但这就意味着高效交付吗？ 很多时候，运营、产品、技术各自为战，虽然都很忙碌，但是却“不出活”。这 个“活”不是由我们定义的，而是由用户来定义的。用户不会因为你的繁忙买单，只 会因为你的交付买单。 高效交付 ≠ 持续高效 我们如果做到了“高效交付”，就可以做到“持续高效”吗？其实也不一定。有 可能是你的团队突击加班了，暂时提升了交付效率，但是无法做到持续高效。也有可 能你暂时产出了软件，却留下了一系列的技术债。软件的质量很差，也没有相应的测 试去维护，也没有去建立工程能力，还是不会持续高效的。 高效交付 ≠ 业务成功 即使我们做到了“高效交付”，甚至“持续高效”，那么业务就一定会成功吗？其 实也不一定。你可能交付了很多需求，但这些不是用户真正要的，用户绝不会长久为 此买单。你能不能吸引用户、并留住用户，产生利润，这才是业务成功的关键。真正 的业务成功，是要能解决用户真正的问题，所以高效交付也不等于业务成功。

📄 Page 18

18　　>　业务驱动的精益敏捷实践 精益和敏捷的方案是需要解决上面的三个问题： ● 从局部效率到高效交付，我们需要做到：顺畅高质量交付。 ● 从高效交付到持续高效，我们需要做到：持续地顺畅高质量地交付。对于代码设 计和质量的长期维护和提高，持续工程能力的积累，持续交付实践的实施等。 ● 从高效交付到业务成功，我们需要做到：持续地顺畅高质量交付有效价值。 至此，我们定义了问题，也分解了问题，并明确了方向：持续地顺畅高质量地交 付有效价值。 2.2　实现精益敏捷研发的四大步骤 精益敏捷研发实践框架

📄 Page 19

业务驱动的精益敏捷实践　<　　19 精益敏捷研发实践框架分为三层，第一层是战略和目标，主要包含用户诉求、愿 景目标和战略规划。第二层是产品规划层，这里需要业务、产品、技术之间的敏捷协 作，将战略和目标层的业务诉求形成业务诉求条目后录入业务需求池，然后通过业务 设计、产品设计、产品交付等环节，交付有效价值，并根据业务验证结果，建立业务 反馈进行调整，最终达成业务结果。第三层是团队交付层，在这一层需要产品和技术 团队高效协作，持续澄清，开发和验证需求，并通过自动化交付流水线和持续交付机 制实现快速交付需求。 如何实现精益敏捷研发呢？我们需要做到以下四步： 第一步，我们需要打通端到端的业务价值流。什么叫“端到端”呢？就是要关注 从用户的需求到用户问题的解决这一全过程，而不是中间的某一个阶段。这就需要我 们的业务、产品、技术进行协作。 第二步，快速高质量交付，即更快更好地交付需求。 第三步，度量反馈和持续改进。我们期望产品交付过程是可被度量的，同时可驱 动交付团队持续改进。 第四步，规模化实施。有了以上三步，其实还不够，我们需要赋能整个企业或组 织，进行规模化实施。 后面，我会详细介绍这四步如何实施。 精益敏捷研发第一步：打通端到端的业务价值流

📄 Page 20

20　　>　业务驱动的精益敏捷实践 可见，是协作的基础。我们可以通过云效的“看板”实现端到端需求流动过程的 可视化，如上图所示在“看板”的最左端是需求池，最右端是“已发布”，其中包含 了业务、产品、开发、测试和运维在内的端到端交付过程。打通端到端的业务价值流 必须做到：用户价值驱动，即每一个流动单元体现的都是具有用户价值的业务需求； 前后职能拉通，即拉通业务、产品、开发、测试等各个职能一起来看整个链路，始于 用户问题的提出，终于用户问题的解决。 建立端到端的需求流动过程，并利用云效看板实现可视化，这是提升效能的基 础。下一步需要明确各阶段的准入准出标准。 明确各阶段的准入准出标准，即明确流转规则，是内建质量的重要手段。团队要 达成对规则的一致理解并共同守护和持续改进。 如上图所示，从阶段“业务讨论”开始到“已发布”都需要有明确的准入规则。 举两个具体的例子，一个是从“产品”流入“开发”的规则： ● 开发、测试和产品达成一致，定义明确的验收标准。 ● 大需求，需拆分为工作量在两周以内的故事。 ● 与关联方（如有）确认相关计划；- 识别大的技术风险并定义应对方案。 ● 涉及三位及以上开发人员的需求，指定需求负责人，负责协调进度。