阿里巴巴DevOps实践指南.pdf

阿里巴巴DevOps实践指南从 DevOps 到 BizDevOps（2021）ALPD系列丛书目录01目录DevOps概述1.1 DevOps 的起源 0101.2 DevOps 的目标是支持业务敏捷 0151.3 阿里巴巴 DevOps 实施的价值主张 02002 业务驱动的协作和产品导向的交付2.1 需求的层次结构 0262.2 业务驱动的协作 0302.3 产品导向的交付 0382.4 规模化实施路径 04403 建设和提升持续交付的工程能力3.1 以特性为核心的持续交付 0513.2 本地开发 055 3.3 云端开发 065 3.4 代码评审 069 3.5 代码检测 073 3.6 测试提效 0823.7 测试环境与路由 0913.8 应用环境能力 0973.9 基于应用和变更的交付模式 103 3.10 提升构建的效率 1093.11 基于制品元数据提升交付效率 11504 基于应用的持续运维05 阿里巴巴 DevOps 工具体系 17306 DevOps 能力提升模型 1804.1 监管控一体化运维 1244.2 业务系统安全工程 129 4.3 全景监控 1374.4 发布策略 146 4.5 编排运维 156 4.6 智能运维 163序数字化是一次产业革命，DevOps 是其中的重要组成部分。每一次产业变革都从革命性的技术开始，围绕它建立新的基础设施，形成新的技术和管理范式，最终彻底变革整个产业。那些及早建立新基础设施，并引领新技术和管理范式迁移的经济体将从一轮产业革命中崛起。第一次工业革命建立了蒸汽动力和机器生产的基础设施，形成了工业化的基本范式，英国从中崛起。第二次工业革命建立了内燃机和电气化的基础实施，形成了科学管理的基本范式，美国和德国实现超越。数字化革命发端于 1970 年代的美国硅谷，它以信息化为肇始，带来互联网在全球蓬勃发展，而这只是开始。今天，数字化变革正深入每一个具体产业，驱动深层次的产业变革，让企业对客户、市场和环境的反应更精准、灵活、即时和高效。数字化和产业将发生化学反应，客户体验和产业效率都必须发生质的提升，这是数字化变革给每个产业的命题和挑战。以云计算、大数据、人工智能、IoT 等为代表，新的数字化基础设施已经就绪，并将继续演进。更重要的是与之配套的技术和管理范式的转变，如：数字化转型路径、面向数字化的组织、数字化的全链路协同、数字化时代的 IT 研发模式。其中 DevOps 已成为数字化时代 IT 研发和管理范式，并成为企业数字化转型重要的组成部分。DevOps 是什么？企业该如何建设 DevOps 能力？我们必须在数字化转型的背景下加以考察，具体来说包含业务交付和系统运行两个方面。第一：持续顺畅高质量地交付有效价值。它的目的是缩短从业务想法的提出到实现和交付的时长，使这一过程更加顺畅和精准。数字化的组织，要围绕这一目标构建技术工程体系和协作模式，消除业务需求交付过程中的一切阻碍和等待，让 IT 交付节奏，跟上业务发展的需要。第二：极致弹性和韧性的系统运行。IT 系统必须满足业务运营的要求，具备极致的弹性和韧性。弹性是指它随业务负载自动、实时的扩缩容，以精准的弹性和合理的成本满足业务；韧性指的是确保系统安全、合规和稳定的运行，实现系统运行的连续可用性和安全稳定。以上两者，都要求打破 IT 开发部门和 IT 运维部门之间的隔阂，包括技术、流程和组织上的隔阂，也就是所谓开发运维一体化（DevOps)。一体化是手段，最终的成果必须体现为顺畅的业务交付和连续稳定的系统运行。而这一切都必须以业务为源头，打通从业务到开发再到运维的整个流程，实现业务、产品和运维的有机融合，形成高效的业务交付、运行和反馈闭环。严格意义上 DevOps 应该是包含业务在内的 BizDevOps，延续业界的习惯，我们还是称其为 DevOps，不过其内涵一定是包含业务，且以业务为根本驱动的。DevOps 是数字化时代的研发新范式，需要协作模式和工程技术两个方面的变革，这两者相辅相成，又相互制约。阿里巴巴 DevOps 实践指南，将分别从协作模式和工程技术两个方面展开。工程技术对应研发敏捷，协作模式对应组织敏捷，帮助组织顺应数字化变革的要求，让技术发挥其核心作用，加速业务发展，引领业务创新。在数字化变革的浪潮中，中国作为产业规模最大和门类最齐全的经济体，迎来百年未有的崛起机会。拥抱数字基础设施，探索符合数字化时代要求的技术和管理范式，将帮助我们切实把握机会，实现伟大的复兴。而把握这一机会的组织，将在数字化变革的浪潮中脱颖而出。DevOps 是其中不可或缺的环节，希望我们的实践总结对你有所启发。推荐语数字化转型是从社会到企业的整体转型，需要顶层设计和统一规划。数字生态最终是一个高度连接的社会而非一座座割裂的竖井。阿里巴巴 DevOps 实践指南说明，一体化的开发和运维要支持的目标正是全链路、全生命周期的业务，这是技术发展的方向，也是数字生态的必然要求。IBM 副合伙人、银行数字化转型作者、极客时间说透数字化转型专栏作者 付晓岩企业的数字化转型必然绕不过 DevOps，核心点还是 IT 如何赋能业务，创造价值。该本指南书体系思路非常清晰，个人理解是从交付态和运行态两个视角去阐述，并完全以应用为视角。交付态也就是今天 DevOps 里面提到的核心工程实践：持续交付。持续交付是对过去割裂的 IT 组织交付模式的一次革命；运行态，是从连续性运维的角度去探讨，其中又引入了多个不同的最新实践，如智能化运维。难得的是，书中的很多实践都来自于阿里实际，实践完善了理论，理论才可以更好地指导实践。的确是一本难得的实践指南书！优维科技创始人&CEO 王津银DevOps 与云化开发平台的结合实现了软件开发工具平台的一次飞跃，不仅实现了软件开发工具的集成化和流水线化，而且使得基于大数据分析的软件开发质量与效能提升成为可能。阿里巴巴 DevOps 实践指南的推出为我们了解业界 DevOps 和云化开发实践、开展软件开发大数据分析研究工作提供了重要指导。围绕相关话题，学术界和工业界有望开展更多的交流与合作，共同推进软件工程研究与实践的发展。复旦大学计算机科学技术学院副院长、软件学院副院长、教授 彭鑫过去 10 多年，阿里云在 IT 基础设施方面做了非常多的探索和努力，得到了客户和社会的认可。云、大数据、AI、IoT 等，已成为新一代数字化基础设施。如何让这些基础设施发挥更大作用，推动产业数字化变革，这也是我们持续努力的方向，DevOps 能力是其中的核心环节之一，希望阿里巴巴 DevOps 实践指南对你有所启发，成为你在数字化转型道路上的伙伴。蒋江伟 阿里巴巴合伙人技术创造新商业，技术已成为数字化时代业务创新和发展的核心环节。提升技术的业务响应和交付能力，并保障系统运行的连续性和稳定性，已成为数字化组织的共同挑战。阿里巴巴 DevOps 实践指南源自阿里巴巴多年的一线实践，并做了系统性的沉淀。不管是工程、协作、运维还是工具，希望你能有所收获，并用以指导实际工作。刘国华 阿里巴巴研究员、混合云平台负责人从 B2B 到淘宝、从跨境电商到本地生活，面对如此丰富、如此大规模的业务交付需求，阿里巴巴在软件交付效率上一直走在行业的前列。为此，公司从技术文化、技术架构、软件基础设施及平台、以及流程上做了全面和深入的设计和优化。阿里巴巴 DevOps 实践指南总结了其中精华的部分，并详细解释了实践背后的思考，指南的内容主要是由工作在一线的资深工程师撰写，读来体感强烈，推荐给大家。许晓斌 阿里巴巴高级技术专家概述DevOps概述1.1 DevOps 的起源谈到 DevOps，就必须从敏捷和精益开发说起。DevOps 在它们基础上发展而来，借鉴了其中的方法、理念，并发展和完善了它们的实践体系。敏捷软件开发的兴起敏捷软件开发的实践最早出现在上世纪 90 年代。当时，一批轻量的软件工程方法和框架相继诞生，它们共同的特点是，相对传统软件工程，都遵循演进和迭代的模型，过程更加轻量灵活。其中 Scrum 和极限编程（ExtremeProgramming）在实践上最为成功，影响最大。它们都是迭代和增量的软件开发框架，区别是Scrum 只包含管理实践，而极限编程则同时涵盖工程和管理实践。上世纪 90 年代，PC 软件流行和第四代编程语言的出现，面向对象和设计模式运动的兴起，让小型项目的开发蓬勃发展。同时，互联网应用和开源社区兴起，有别于传统的开发模式不断涌现，优秀个人在程序开发中的作用得到凸显。这些因素都让非传统开发方法有了实验的土壤。其结果是，一方面质量问题层出不穷，这部分促使了源自全面质量管理体系的 CMM/CMMI 在这一时间的繁荣和推广；另一方面也产生了许多不同于传统方法的有效实践，让业界看到了新的可能。敏捷运动这时已经呼之欲出，它既是对传统的反叛，也是对野蛮生长的规范。2001 年 2 月，17 位轻量级软件工程方法的代表人物，齐聚美国犹他州的雪鸟滑雪胜地，其中也包括 Scrum和 极 限 编 程 的 几 位 发 明 人。在 两 天 的 会 议 之 后，发 布 了 后 来 产 生 巨 大 影 响 的 敏 捷 宣 言（参 见http:/agilemanifesto.org/），敏捷宣言陈述了他们共同认可的关于软件的开发方法的理念，同样重要的是他们找到了敏捷这个词来总领这些理念。010敏捷概念在 2001 年出现，可以说适逢其时。当时，一方面传统方法变得越来越臃肿笨重，却没有解决软件危机；另一方面，人类正在进入互联网时代，软件业对响应变化和创新的要求迅速升级，这是更根本的原因，毕竟需求才是行业发展的最好助推剂。敏捷宣言发布后，敏捷成为了一场运动，被迅速地推广和应用。但是，早期的敏捷专注的还是研发交付阶段，站在业务的角度，它的目标是帮助产品和研发团队提升敏捷响应能力，也就是：“更早地交付价值，更灵活地应对变化”。然而，在企业数字化转型的背景之下，IT 不仅要保证产品的开发和交付，系统部署和运行同样重要。DevOps 继承了敏捷开发的理念，又补上了运维的部分，但 DevOps 绝不是开发和运维的简单叠加，这个我们后面还会说到。精益产品开发的出现精益思想最早源自生产制造领域，根源于丰田在产品制造中管理和工程实践。1988 年斯隆管理评论的一篇论文精益生产系统的胜利比较了西方的生产方式和丰田生产方式在效率和质量上巨大差距，挑战了规模生产带来效益的神话。从此，精益开始进入西方的视野，逐渐成为现代管理学的重要组成部分。精益思想一书将精益定义为：有效组织人类活动的一个新的思维方法，目标是消除浪费，以更多地交付有用的价值。书中进一步总结了精益的 5 个原则，同时也是精益的 5 个实施步骤：1.定义价值：站在用户的视角定义什么是价值，并把它描述为具体产品或服务；2.识别价值流：识别和映射创造价值的流程步骤，消除不增加用户价值的步骤和活动；3.让价值持续流动：让用户价值在流程步骤中流动起来，使它们持续、顺畅地流向最终用户；4.用户价值拉动：由用户价值拉动流动，避免不带来用户价值的浪费；5.精益求精：不断重复 1 到 4 步。追求完美的价值和价值流动，消除过程中所有浪费。在这个抽象层次上，精益思想超越了其诞生的制造业，深刻影响了各个行业，如精益政务、精益医院、精益领导力、精益服务业、精益供应链、精益教育等，这其中也包含产品开发。事实上，主流的敏捷开发方法都直接受到了精益思想的影响，遵循精益的基本原则。与此同时，精益产品开发作为独立的实践体系也快速发展，它聚焦两个方面的目标价值交付过程和价值本身。阿里巴巴 DevOps 实践指南011第一，关注价值交付过程。其中比较有代表性的是“精益看板方法”，它由 David Anderson 在 2006 年左右基于自己的实践发展而来，并在 2010 年出版的看板方法一书中加以系统总结。“看板方法”是精益思想在软件开发中具体应用。它从可视化需求交付端到端的价值流开始，通过系统的实践提升需求的流动效率，并确保流动的过程质量，从而实现端到端的系统改进。“看板方法”为代表的这一类精益实践的本质改变是：从关注资源的使用效率，转变为关注价值的流动效率。这也带动使用者从过去的局部优化转向端到端的全局优化。第二，关注价值本身。其中比较有代表性的是“精益创业”。精益创业的实践最初由 Steve Blank 基于自己和其他硅谷的创业实践发展而来，Eric Ries 在精益创业一书中对精益创业的理念和实践，做了系统的总结，并让精益创业的理念迅速普及。精益创业认为创业是一个巨大不确定的过程，其最大的浪费是交付没用的（不能解决用户问题，或带来业务成功）的东西。为此它把价值的探索和发现融入产品交付过程，提出了著名的“开发-测量-学习”循环。循环从关于市场和产品的待检验概念开始。接下来，循环的第一步是开发用以验证这一概念的最小可行产品（MVP，Minimal Viable Product）；第二步：基于最小可行产品收集市场、用户的反馈，并获得测量数据；第三步：用数据验证假设，证实或证伪它们，并加以调整，产生经实证的认知。然后，进入下一循环，持续探索商业模式和产品功能设计。精益创业的影响远超初创公司，事实上“精益创业”一书中把“创业”定义为在不确定的环境下，开创新的业务和产品。而“不确定性”似乎已成为今天 IT 领域身处环境的共性，也因此，MVP、“开发-测量-学习”循环等理念已成为 IT 创新领域公认的实践，并且围绕精益创业发展出一套完整的创新实践体系，如精益数据分析、精益客户开发、精益交付设计等。探索和发现有效的价值，并让价值顺畅流动。围绕这两个目标，并遵循精益思想，精益产品开发已经发展成为系统的实践。精益思想对 DevOps 的影响也非常根本，DevOps 三原则就完全遵循了精益思想。DevOps 的诞生最初，敏捷和精益社区都还只是关注开发侧的实践和行为，运维并没有成为他们关注的重点。但是，光有系统开发是不够的，开发完的系统必须即时顺利部署，并连续稳定运行才能够实现价值。而传统上，这部分是由运维负责的。从价值的角度，开发加运维才构成相对完整的 IT 价值链。当然更完整的还应该包含业务，这是后话了，这012还不是早期 DevOps 社区关注的重点。DevOps 诞生之初，解决的问题还是开发和运维之间的问题，这是影响 IT 价值链的最突出问题。在传统的 IT 组织下，开发团队（Dev）和运维团队（Ops）之间诉求不同开发团队（尤其是敏捷团队）追求变化，运维团队追求稳定。双方往往存在利益的冲突，比如，精益和敏捷的团队把持续交付作为目标，而运维团队则为了线上的稳定而强调变更控制。部门墙由此建立起来，这当然不利于 IT 价值的最大化。2009 年，在美国举行的第二届 Velocity 大会上，来自 Flickr 公司的 John Allspaw 和 Pauk Hammond发表了一个演讲10+Deploys Per Day:Dev and Ops Cooperation at Flickr。在这个演讲中，Allspaw和 Hammond 以角色扮演的方式，生动地表现了开发与运维之间的各种冲突。演讲中出现很多金句，如“Its notmy code,its your machines!”，这深刻反映了 Dev 和 Ops 关系的现状。接着，他们又展示了如何通过消除开发团队（Dev）和运维团队（Ops）的壁垒，双方通力合作，借助工具和文化的改变让软件的发布和运维变得持续和高效。这次演讲是 DevOps 发展历程中的标志性事件。它提出了正确的问题为了更快交付和实现价值，必须弥合开发和运维之间的鸿沟，并给出了解决方案为了弥合开发和运维之间的鸿沟，需要在文化、工具和实践方面的系列变革。同一年，比利时独立 IT 咨询师 Patrick Debois 看到这个演讲，受到启发，组织了第一届 DevOpsDays，DevOps 正式登上舞台，DevOps 的理念开始流行，其相关的工具和实践也快速发展。期间以容器化和自动编排调度为代表的云原生技术的出现也极大加速了这一进程。今天，DevOps 已成为企业数字化的核心能力之一，是对 IT 交付和运行的基本要求。其后，在 凤凰项目和DevOps 实践指南两本书中，Gene Kim 等人总结了 DevOps 实施的三步工作法，它们分别是:流动原则：聚焦 IT 系统的整体价值流，全局优化，保证价值从左（上游）到右（下游）的快速流动。反馈原则：创建从左到右的反馈循环，并缩短反馈周期和放大反馈效果。这样，就可以更快的响应和理解内外部客户，并即时获取改进所需要的知识。持续的实验和学习原则：创建承担风险、持续实验并从错误中学习的文化，在不断的尝试中精进能力，并提高系统的韧性。Kim 等人认为，这三步工作法是其他一切 DevOps 流程、实践的价值和哲学根基，所有 DevOps 模式都可以从这三个原则派生而来。阿里巴巴 DevOps 实践指南013稍作探究，就能够觉察，DevOps 三步工作法是精益原则的翻版。更确切的讲，是精益原则在 IT 开发和运行上下文中的具体实例。事实上，DevOps 的基础部分，体现了精益原则的影响和应用。总结回顾敏捷、精益和 DevOps 的发展，我们可以得出如下两个结论。第一，DevOps 是敏捷开发实践的自然发展。敏捷开发的目标是“更早地交付价值，更灵活地应对变化”。敏捷运动始于开发侧，但运维侧如果不做改变，就一定会成为瓶颈，最终敏捷的目标还是无法达成。为了让敏捷实践发挥真正的价值，开发运维的联动就势在必行了。第二，DevOps 是精益思想应用在 IT 领域的必然结果。精益产品开发的目标是：“顺畅的交付有效价值”，精益思想则要求端到端的系统优化和持续的改进。而开发和运维是系统的两个重要组成部分，缺一不可。DevOps 三原则，正是精益思想在 IT 开发运维领域的具体实例。最后，从精益思想出发，我们可以看到 DevOps 的必然发展方向，那就是向业务侧延伸。业务是产品开发和运维的源头，完整的价值流必须从源头开始。这不是预测，而是正在发生的事实，大部分 DevOps 的实施都已经将业务侧包含在内，成为 BizDevOps，只不过 DevOps 的称谓已经深入人心，我们也将延续 DevOps的说法，但缺省情况下，它包含了业务在内。DevOps 发展的同时，数字化转型也成为了企业界的共识，大部分企业数字化框架都把 DevOps 作为最核心的能力之一，DevOps 的影响范围也不断扩大，成为力求提升数字化能力的企业必然选择。下一节我们将在数字化转型这一背景下，分析 DevOps 要解决的根本问题。0141.2 DevOps 的目标是支持业务敏捷数字化时代，技术已成为产业发展的核心，技术的交付速度和质量，直接关系业务的发展和创新。大部分企业在规划数字化转型战略时，都会把 DevOps 作为重要一环。DevOps 的实施必须服务于数字化转型的目标。在实施 DevOps 时，我们首先要理解数字化转型对它的期望和要求。数字化转型：从信息化到数字化数字化正在深入改变各个产业。就影响的广度和深度，毫无疑问数字化是一次技术革命。工业革命以来的 5 次技术革命015技术革命与金融资本一书回顾了工业革命以来的 5 次技术革命的历程，总结了其中的共性。每一次技术革命大致都可以分为三个时期：导入期、转折期和展开期。数字化革命也是如此：01导入期（1971-2000）：信息化阶段，互联网从无到有数字化革命的导入期开始于 1971 年。第一台个人计算机和第一个微处理器都诞生在 1971 年。而此前，1969 年 ARPANET 诞生，成为后来互联网的原型；1968 年 NATO 第一次软件工程会议，标志着软件工程诞生。微处理器、PC、互联网、软件工程，数字化的基础技术元素就绪。其后 30 年是数字化革命的导入期，互联网从无到有，让全球范围内信息获取、传播和处理都有了若干数量级的提高。02转折期（2000-2016）：基础设施就绪，技术和管理范式准备技术变革不可能一蹴而就，它需要基础设施的全面升级，以及行业认知的深层次转变。而这往往会让技术变革遭遇低潮，2000 年的互联网泡沫，标志着数字化革命进入了转折期。转折期影响的是业务发展，但技术发展本身并没停滞。这期间包括云、大数据、AI 和 IoT 等大力发展，奠定了数字化的基础设施。数字化理念也不断深化，并开始在各个行业播种。今天业界公认转折期已经结束。对中国 2016 是一个标志性的年份，那一年中国的互联网网民超过 7 亿，互联网人口首次过半，再也不可能翻番了。信息产业不可能再单纯依靠互联网人口红利来维持增长。数字革命必须向纵深发展，与各个产业结合。03展开期（2016-至今）：数字化阶段，互联网从有到“无”今天，数字化革命正处于其展开期，它的关键标志是：数字化转型成为各个产业共识。人们关心的不是要不要数字化，而是数字化如何与具体的产业结合。2016 年是中国产业数字化转型的元年，正如马云在 2016 乌镇的互联网大会上所说，过去 30 年互联网从无到有，未来 30 年互联网从有到“无”，这里的无指的是无处不在，互联网产业和传统产业的界限正在消失。总结数字化革命已经走过的历程，我们正在从信息化向数字化转变。信息化和数字化有什么不同？信息化面向的是信息及互联网产业，包括企业内的信息部门。它关注的对象是信息，解决信息互联互通的阿里巴巴 DevOps 实践指南016问题。它最终目标是提升信息获取、存储、处理和传递的效率。就这一目标而言，信息化做得非常出色。数字化面向的是全社会的所有产业，关注的对象是具体的业务，深入具体的业务流程；解决的问题是如何精准、实时地响应用户需求。而最终目标是，同时实现最佳的客户体验，和最高的运营效率。信息化 vs.数字化如上图所示，相对信息化，数字化的要求要高许多广度更广、深度更深、问题更复杂、而目标也更高。这对 IT 技术当然也提出了更高的要求。从信息化到数字化，DevOps 必须以支持业务敏捷为目标数字化变革的结果也必须体现在业务上。数字化要做的是赋能业务，带来用户体验和运作效率的同步提升。在规模化生产时代，体验（尤其是个性化的体验）与运营效率本来就是一对矛盾。我们以牺牲个性化需求体验为代价，带来规模化和标准化的效率。数字化将有机会为彻底化解体验和效率的矛盾，精准和实时的响应多样化的用户需求，同时还要提高组织的运作效率，实现最佳体验和最高效率的统一。我们把这样的能力称为业务敏捷。业务敏捷的目标017业务敏捷要求组织全方位的转变，比如构建产业的全量、多维度和实时的数据采集和处理体系；建立符合数字化时代快速反应的组织结构等；实现线上和线下业务的的融合；IT 交付、运行能力的升级等。数字化转型，是一个系统的变革，DevOps 是数字化转型的一个重要组成部分。数字化时代，更多的业务创新和发展，通过数字化技术才能落地。IT 技术交付和运行的效率，成为决定数字化转型成败的关键，而DevOps 要解决的问题正在于此。与聚焦信息本身的消费互联网不同，面向产业的数字化转型，提出了更高的挑战。数字化时代的业务敏捷挑战第一：交付内容上，从以信息为中心到关注完整的业务链路。在信息化时代，我们更多关注的还是信息的获取，分享和处理，在商业系统中更多关注的是交易。面对具体的产业，我们必须关注从客户获取、供应链、生产制造、财务支持、市场运营、内部协同到服务交付等完整的链路。第二：交付过程上,从聚焦技术交付，到优化端到端的过程。我们讲敏捷时，再也不能仅仅是敏捷软件开发，而是要关注从业务、开发、运维在内的全链路的流程，实现端到端的快速响应、交付和稳定的运行。上面所说的两个变化，是对 IT 技术部门的巨大挑战，需要能力的全面升级，包括组织和协同能力，以及技术和工程能力。下一节介绍阿里巴巴 DevOps 的价值主张时，我们会具体介绍这两个能力。总结数字化转型的核心是产业变革。中国有全球最齐全的产业门类，最大的产业规模，是全世界唯一拥有联合国产业分类中所列全部工业门类的国家。同时，我们建立了强大数字化基础设施，有强有力的政策支持和技术人才红利。改革开放 40 年，我们迅速工业化，实现了规模化制造能力。而，数字化将引领我们进入规模化定制时代，实现体验和效率的同步提升，我们称之为业务敏捷。它比较带动中国产业能力的跃升，从产业大国走向产业强国。阿里巴巴 DevOps 实践指南018数字化转型是信息技术与产业的结合。需要转型的不仅仅是各个传统的产业，也包含信息产业本身，如互联网公司。DevOps 是数字化转型的重要组成部分，DevOps 的体系和实践也必须服务于数字化转型的需求，这是互联网和传统产业公司的共同挑战和使命。0191.3 阿里巴巴 DevOps 实施的价值主张数字化转型是对互联网公司和产业内公司的共同挑战。产业公司要应用数字化能力，提升用户体验和运作效率；互联网公司要将数字化能力与具体的产业结合，带来更广更深的创新。共同点是，它们都需要升级 IT 的交付和运行模式，都离不开 DevOps 的能力。DevOps 实施的定位和目标下图展示阿里巴巴对 DevOps 实施的理解。对 DevOps 的理解和价值主张020DevOps 的实施构建在云原生的基础设施之上，并以一站式的 DevOps 工具平台为支撑。通过 DevOps实施，构建以下两个能力：第一，持续地顺畅高质量交付有效价值。持续优化协作模式和工程体系，消除业务需求交付过程中的一切阻碍和等待，让交付节奏跟上业务发展的需要，同时保障交付的质量和交付效能的可持续性。第二，极致弹性和韧性的系统运行。IT 系统必须满足业务运营的要求，具备极致的弹性和韧性。弹性是指它随业务负载自动、实时的扩缩容，以精准的弹性和合理地成本满足业务；韧性指的是确保系统安全、合规和稳定的运行，实现系统运行的连续可用性和安全稳定。为了建设这两个能力，我们明确提出了 DevOps 实施的价值主张。它们分别是：1）业务驱动的协作模式；2）产品导向的交付模式；3）特性为核心的持续交付；4）应用为核心的运维。接下来将分别作一概述。阿里巴巴 DevOps 实施的价值主张01业务驱动的协作模式IT 系统的交付是一个协作过程，涉及交付链路上的不同职能，如：业务、产品、开发、测试和运维等；涉及不同功能团队，如前端、后端、中台的不同产品、基础技术组件等。如何让协作更高效，从而更快地响应和交付业务需求？我们实施 DevOps 的第一个价值主张就是，业务驱动的协作模式。它要求：1）通过业务需求拉通端到端的交付过程，包括：业务、产品、开发、测试、运维等职能的工作；2）通过业务需求对齐各个功能开发的工作，如：前端，后端，中台的交付节奏等。业务驱动的协作模式寻求系统优化，确保各个局部的工作转化为业务可见的交付效能。我们将在第二部分介绍业务驱动的协作模式相关的实践。02产品导向的交付模式业务需求的满足最终必须落地到产品上才能够交付。产品的交付有两种模式，分别是产品导向的和项目导向的。项目关注短期的交付，而产品关注的是长期的价值。我们主张产品导向的交付模式，是为了长期的效率和业务的价值。阿里巴巴 DevOps 实践指南021产品导向的交付模式把技术交付团队看成利润中心（而非成本中心），面向产品和业务建设跨功能和相对稳定的产品交付团队，以业务价值和业务响应来衡量和激励产品交付团队。团队面向业务价值，持续地迭代和学习，并积累软件资产、工程和技术资产，提升自己的响应和交付能力。产品导向的交付模式实践也会在第二部分介绍。03特性为核心的持续交付“业务驱动的协作模式”以及“产品导向的交付模式”，这两者都离不开工程能力的支持，尤其是持续交付工程能力。我们将持续交付分解为持续部署和持续发布这两个能力。其中，部署（deployment）是技术概念，指的是将软件安装到一个特定的环境；发布（release）是业务概念，指让一个或一组需求对用户可用。建设持续交付能力，首先要做到两个解耦。1）需求之间的解耦，让各个需求的开发和发布能够独立进行；2）部署和发布之间的解耦，让部署的动作更加灵活，发布能够随需进行。单应用部署、单需求发布是持续交付的最理想状态这两个解耦要达成的是：单应用持续变更和单需求持续发布的能力。这是响应业务最敏捷的方式，也是我们对持续交付能力的追求。上图反映了这一状态，一个业务需求经过拆解，对应多个应用的变更，每个应用独立开发、测试和部署，当该需求涉及的所有变更部署完成，这个需求就可以自动发布，或通过特性开关按业务需要发布。为了做到单应用的持续部署和单需求的按需发布，需要一系列机制、能力和工具体系的支持，如：环境的管理，持续交付流水线的构建、开发联调的手段、质量的保障体系。我们将在第三部分介绍持续交付的实践。02204应用为核心的运维体系运维的目标是在快速响应业务的同时，保障业务系统运行的弹性和韧性。弹性指的是随业务的规模自动和精准伸缩的能力，韧性指的是系统运行的稳定、安全，并保障业务的连续性。应用视角是连接系统和业务的必然选择，也是连接开发和运维的必然选择。以电商系统为例，购物车、商品详情，下单系统都是独立应用。众多应用构成了淘宝、天猫、支付宝等业务系统。阿里巴巴 DevOps 的开发、交付、运维工作都是围绕应用展开的。每个应用有独立的负责人，对应独立的代码库，有自己独立的资源集、预算，故障定责都是以应用为维度展开的。阿里巴巴运维体系是构建在应用这个基础单元之上的。基于应用，我们可以进行各种精细化管理，推动完成技术升级，资源成本优化，以及各种稳定性治理工作，实现监、管、控一体化的运维。我们将在第四部分介绍应用运维的实践。一站式的 DevOps 工具体系和 DevOps 能力提升模型DevOps 的实施离不开工具的支持。好的工具能够沉淀原则和方法，贯彻正确的价值主张，让 DevOps的实施事半功倍。在研发协作和交付过程，以及 DevOps 的实施过程中，我们面临诸多挑战，如：1）工作流程自动化、标准化问题，如何让业务、产品、技术三种角色高效和有效地协同；2）资产管理问题。如何有效的管理代码、文档、应用、资源等关键资产；3）透明化与数字化问题。如何通过全局的信息透明促进协同，并通过数据洞察为团队改进指明方向。为了应对这些挑战，阿里逐渐形成了自己特色的 DevOps 实践，并将这些实践落地到一套完整的 DevOps工具体系中，以适应业务研发的诉求。它有如下特点：1.一站搞定需求、开发、测试、部署、运维的所有诉求。2.松管控、强卡点，在工具设计上弱化人为管控，把操作权限下放到一线研发，同时，又提供了全局和特定范围内的卡点能力（如安全检测），保证发布的质量符合要求。3.可定制、可复用，可扩展，允许开发者根据应用特征和开发习惯定制自己的使用方式以及扩展组件，同时又能方便地复用他人的优秀成果。阿里巴巴 DevOps 实践指南023024我们将在第五部分介绍阿里巴巴的 DevOps 工具体系。为了给组织 DevOps 实施指明方向，并协助规划清晰的路径，我们设计了 DevOps 能力提升模型，它分为 4 个方面 10 个能力。基于它组织可以评估当前的状态和不足，并规划 DevOps 实施和提升路径。我们将在最后部分提供 DevOps 的能力提升模型。业务驱动的协作和产品导向的交付业务驱动的协作和产品导向的交付业务驱动的协作和产品导向的交付2.1 需求的层次结构解决交付问题的第一步，是搞清交付的是什么。否则，交付对象是模糊的，明确的过程就无从谈起，更无法保证过程效率。搞清楚交付的对象，具体包括它来源于哪里，为什么服务，有怎样的层次结构以及各个层次承载的价值。接下来，我们将基于最典型的需求层次结构，介绍这部分内容。典型的需求层次典型的需求来源及需求层次关系上图展示了典型的需求层次结构，它包含三个层次：业务需求、产品需求和技术任务。026阿里巴巴 DevOps 实践指南02701业务需求需求协作和交付过程，最终必须为业务服务交付业务价值，并保障业务成功。业务需求来源或转化自原始的用户诉求或业务和产品的初始想法。这些原始的需求经过过滤、归类和分析转化为正式业务需求。不同特征的组织，业务需求的习惯名称不同。比如：强调用户驱动的可能称之为“用户需求”，对外以产品形式售卖的可能称之为“解决方案”或“产品特性”。不管名称是什么，它们的共同特点是都服务于业务的目标，且最终都要落地为产品功能。在本篇中，我们统称其为“业务需求”，强调这个层次的业务属性。业务需求承载业务价值，它是系统验收的基本单元，也是运营和发布（Release）的基本单元，需要时可以被独立地发布和运营。它一般由业务人员（如业务运营或业务分析师）负责收集、创建和维护。02产品需求产品需求可以分为两类。第一类拆分自业务需求，直接服务于今天的业务，它一般由业务负责人或产品经理基于业务需求拆分而来；第二类源自产品的规划，它们不直接服务当前业务，而是为未来的业务做基础和提前的准备，典型的包括：产品的基础功能、提前的技术布局、技术重构等。它们通常由产品经理和技术团队创建和维护。产品需求承载产品的具体功能，是产品集成和测试的基本单元，通常也是系统部署（Deploy）的基本单元。一个业务需求涉及多个产品的功能时，它会被拆分到多个产品，对应多个产品需求。例如，业务需求是“在供应链中支持预先锁定库存”。为了实现它，需要供应链计划、库存管理、履约服务、财务结算等多个产品的功能改动，就对应多个产品需求。03技术任务技术任务承载具体的实现工作，它是工作分配（Assign）的基本单元，也是实现的基本单元。技术任务分解自产品需求，它包括不同职能的任务，如前端、后端、算法等。技术任务的拆分通常由技术团队完成。不同上下文中的层次结构变体现实中，业务和产品复杂度不同，其层次结构也不同。下图是三个不同变体。从左到右分别适用于简单、典型和复杂的业务和产品。基于不同的业务和产品复杂度的需求层次结构调整图中的第一种模式适用于简单的业务。这时，业务与产品一一对应，业务需求与产品需求也合并为一层。这一模式下，原始需求直接转化为产品需求，产品需求分解为技术任务。这一模式适用于简单的互联网业务、企业应用或工具产品，业务在初创时都适合这一模式。对于复杂的产品和业务，如果产品需求只有一个层次，可能会让产品需求过大。这时，可以将产品需求分解为两个层次产品特性和产品需求两层，也就是图中的第三种模式，它适用于电信产品、基础技术产品、复杂的企业应用等复杂的业务领域。不过，对于大部分场景，第二种典型中的三个层次就已经足够。赋予每个层次明确的意义和目的不同方法体系，其需求层次结构的定义的依据不同，结果也不同，如：Scrum 中常用 Epic、Story 和 Task来描述需求的层次关系。这一层次结构的划分依据是规模。其中，Story（用户故事）是从用户角度对需求的描述，它要求能够在一个迭代完成；Epic（史诗）是巨型故事或故事集，需要被进一步分解为 Story；Task（任务）是对 Story 的进一步拆分，要求能跟踪和更新日常进展，通常可以由单个人完成，工作量不超过 20 工作人时（Person Hours）。028需求类型的不同命名方式作为通用方法，Scrum 追求普适性，其推荐的需求层次刻意回避了业务属性。但是，它在提高普适性的同时，让协作过程的业务意义模糊，导致无法定义精准和有效的协作流程。我们认为，只有明确需求层次以及每个层次承载的价值，我们才能够定义有意义的协作过程，过程相关的人员的职责和活动，并判断这一过程是否与所承载的价值匹配。因此，我们在设计需求的层次结构时，要求明确每个层次的意义和价值。总结以上，我们分析了需求的来源、需求的层次结构、以及每个层次所承载的价值。它是一个标准参考模型，本身具备较好的普适性。基于业务的特征不同，也可以加以定制。比如：因业务的复杂性不同，而增减层次；或者业务交付方式不同，而将业务需求改成其他名称。清晰定义需求的层次结构，明确各个层次的价值。基于它们，我们就可以定义协作过程，实现并交付这些价值，保障协作和交付的效率和效果。下一节我们会介绍业务驱动的协作。阿里巴巴 DevOps 实践指南0292.2 业务驱动的协作明确需求层次以及每个层次承载的价值之后，接下来