Open WangShuXian6 opened 2 years ago
发布于 2019-05-04 [荷]Bart de Best 著
DevOps Master 和 DevOps Professional 认证 DevOps Days
把开发团队和运维团队合并,形成一个新的管理团队——开发/运维综合团队,我们把它简称为 DevOps 方法,从而让开发管理者和运维管理者都能够共享知识和技能。
以 30 篇最佳实践案例的形式,提供了如何使 DevOps 团队协同工作的知识,并在这些案例中分别提供了关于 DevOps 各环节过程的最佳实践。这些案例涵盖了规划、编码、构建、测试、发布、部署、运维和监控等各个环节(或阶段)。
2.1 DevOps 的起源 近年来,许多组织都体验到了使用敏捷方法(如 Scrum 和看板)的好处。软件交付的速度更快、质量更高的同时成本却更低。然而一个主要的缺点是在信息管理、应用管理和基础设施管理方面,敏捷开发与传统的服务管理相冲突。这主要是因为服务组织无法满足敏捷开发人员的灵活性要求。但一个更重要的原因是,开发和服务管理之间的差距也因此变得越来越大。敏捷所倡导的速度、沟通和协作文化与传统控制型服务管理的组织文化不一致。其结果是,开发团队能够快速交付软件,但软件无法快速发布到生产环境。这一问题需要在合作方式上发生根本性的变化。
2.2 DevOps 是什么 这个问题已经可以通过 DevOps(开发运维)来解决。通过把开发和运维二者合并成一个团队,使知识和技能得以分享,工作方法得以匹配。这对服务管理过程应该如何组织有重大影响。然而,其优势在于既可以频繁地发布,又有高度的控制能力。DevOps 并不像 ITIL 那样有一个明确的统一定义或概念。比如,Gartner 识别了 6 种不同的 DevOps 流程,每种流程对于 DevOps 都有着不同的解释。
2.4 DevOps 框架 这不是一个放之四海而皆准的 DevOps 框架,而只是其中的一个 DevOps 框架。
DevOps 持续测试
持续测试是在整个开发过程中协助测试管理的一个测试方法,包括单元测试、集成测试、系统测试和验收测试。测试用例最好在软件开发之前编写,而且除了执行常规测试类型外,测试管理也是高度自动化的。要达到这一点,就需要把需求管理、软件配置管理和测试管理高度集成起来。
DevOps 敏捷开发
敏捷开发指的是在 DevOps 中采用敏捷思想进行软件开发,敏捷宣言无疑是很重要的一项。有多种敏捷方法可以采用,比如 Scrum、看板和极限编程。
DevOps 持续集成
持续集成提供了让多个程序员可以同时运行应用程序的最佳实践,可以频繁合并源代码、验证代码(静态测试用例)、编译和测试代码(动态测试用例)。
DevOps 持续交付
持续交付关注从开发、测试、验收到生产环境的高频生产能力。基于高度的自动化,极端的发布上线时间可以达到分钟级。
DevOps 持续监控
持续监控是 DevOps 的重要组成部分,它不仅监控软件(资源),还监控开发人员(人员)和开发过程(方法)。资源在所有环境中被持续地监控,以便尽早发现问题。人员的衡量标准是能力发展(知识、技能和态度),方法层面的衡量则包括速率(处理能力)和效率。
DevOps 敏捷流程
敏捷流程重点关注在标准管理过程中,需要进行哪些调整改进,才能符合敏捷开发方法的要求。
DevOps 不是一套最佳实践,不是一个模型,也不是一个新的噱头。DevOps 更多的是基于一些基本原则的行动,以便更好地满足客户对上市时间和附加价值方面的需求。其原则包括文化方面、合作方面、通过工具实现自动化和合作的可扩展性。
深色部分表示开发流程,浅色部分表示运维流程。这两个流程构成了 DevOps 方法的核心 这两部分流程的每一部分又可以进一步细分为一系列阶段、过程,或被称作另一系列流程,它们都是由反复出现的步骤组成的。这些步骤都是为了达到同一个结果,实现相同的目的。
结构化的 DevOps 将更加容易被定义,从而也更容易被解释。当然,我们需要意识到这些流程虽然是按照顺序画出来的,其实它还包含着一些反馈循环。例如,在测试流程中,为了解决缺陷,有可能触发编码流程。当然,在 DevOps 中,从测试流程触发编码流程是一种浪费,应该尽可能避免。事实上,流程比图上标识的范围更宽泛一些。比如,监控流程也包括了监控整个 DevOps 流程。
每个流程的交付物只包括了最重要的那部分,而不是所有的。接下来的文章会讨论 DevOps 最佳实践。这些文章并不是为了定义 DevOps,而只是一系列的故事,用来阐述这些流程是如何在实践中被应用和实施的。
3.2.1 规划流程
目的
这个流程的目的是为了和相关方一起确定好以下内容:支持客户所需新服务的商业论证(Business Case)、交付的路线图和实现交付的最佳方案。
输出物
○ 被任命的相关方
○ 确定的业务需求
○ 制定的交付路线图
○ 选定的交付方案
解释
相关方就是定义功能性和非功能性需求并为之付款的第三方。商业论证说明了为顾客产生的价值及为此所需要的时间、预算和需要控制的风险。交付路线图是一个包含构建模块发布进程的季度时间表。每个构建模块都在史诗(Epic)上定义。方案指的是采用何种开发流程,是敏捷还是瀑布式。在实践中,大多数(80%)采用 DevOps 的组织的商业论证都使用敏捷开发。在这个流程的结束部分,产品待办事项列表已经填好,DevOps 团队已经组建,预算也已经确定。
循着这个最初计划,接下来就会是一个瀑布式项目或 DevOps 方法。在 DevOps 方法中,服务将会采用循环方式增量交付。对每个增量来说,都需要一个详细的计划,史诗被细化为特性,特性被细化为故事。这个方法经常在敏捷 Scrum 开发和看板中使用,但是在实践中任何组合都可能被接受。
3.2.2 编码流程
目的
本流程的目的是产生源代码文件,以便在后续构建流程中,生成需要的应用程序和基础架构组件。
输出物
○ 特性被细化为故事
○ 确定的功能性或非功能性需求,并且伴随着度量规则
○ 定义好的验收测试条件
○ 确定好的技术需求
○ 定义好的测试用例
○ 源文件被保存在一个版本管理系统中
解释
源文件包含了开发人员编写的用来生成应用程序组件的源代码。同时,源文件还包括运维人员创建的用来配置基础架构组件的脚本。为了便于实现,我们使用「特性」来进行描述。特性是使用业务语言描述的需要交付的功能性或非功能性需求。特性分解后的故事就是需要完成的源代码(应用程序)和脚本(基础架构)的技术描述。
由于经常是多名开发人员在一起编写代码,而代码也会随着时间而改变,因此保持源代码文件和脚本的版本控制非常重要。
3.2.3 构建流程
目的
构建流程的目的是将可应用的源代码转换成目标代码,并执行一系列的单元测试。终极目标是在 5 分钟内验证源代码是否合格,并且将其签入基线版本中。
输出物
○ 创建目标代码,并且错误日志中没有错误记录。
○ 目标代码被存放在制品库中。
○ 源代码已完成质量检查。
○ 单元测试执行完成,测试结果无任何错误。
○ 源代码被签入基线中。
解释
源代码就是一种适用于某问题域的编程语言,例如,PHP 适用于网站 Web 开发,Java 代码适用于业务功能开发。有些源代码可以直接在生产环境中运行,如 PHP、Basic 和 SQL 编程语言。但是,大多数语言需要把源代码转换成操作系统可读指令(目标代码)。这一过程产物被称为制品。如果源代码扫描和单元测试都是成功的,就把源代码签入基线中。
单元测试不同于其他类型的测试,因为这些测试用例保留了目标代码的代码环境。鉴于 5 分钟构建的要求,因此不需要再对目标代码中需与其他应用组件或基础架构的协作进行测试检查。在 DevOps 团队中共享的源代码一起形成一个新的服务。
3.2.4 测试流程
目的
测试流程的目的是在当前冲刺中生成的所有源代码和基础架构脚本上,执行集成测试和系统测试。
输出物
○ 系统和集成测试被成功执行。
○ 服务符合技术要求和度量要求。
○ 技术验收测试执行完成,测试结果无任何错误。
解释
集成测试被定义为测试应用程序组件间的协作。系统测试被定义为测试端到端的服务实现,包括对基础架构的测试。
3.2.5 发布流程
目的
发布流程的目的是判定服务的新版本是否满足其功能性及非功能性需求。
输出物
○ 服务符合规定的功能性及非功能性需求和度量要求。
○ 验收测试执行完成,测试结果无任何错误。
解释
在 DevOps 中,发布流程和部署流程有所区别。发布流程是关于新版本服务的正确性的验证,部署流程是为分发服务的新版本而服务的。新版本服务的发布则是基于相关需求的测试结果。
3.2.6 部署流程
目的
部署流程的目的是通过部署流水线尽可能实现以自动化的方式在生产环境中推出新服务。
输出物
基础架构脚本化的生产环境。
解释
自动化创建服务新版本是 DevOps 的一个重要方面,其实现机制就是部署流水线。实际上部署流水线并不只局限于部署过程。部署流水线从设定需求就已开始,其格式可度量并可以自动化(编码过程),最终自动化发布新服务和自动化安装补丁(运维过程),以保持服务永远满足需求。另外,旧版本服务的重置回滚也是部署流水线的功能的一部分。
3.2.7 运维流程
目的
运维流程的目的是保持服务的稳定可靠,并且运行符合约定的功能和质量要求,保证业务的连续性。
输出物
○ 安全的环境和数据。
○ 执行管理任务。
○ 预防事件发生。
○ 观察并记录发生的事件。
解释
保持服务正常运行实际上包含多个流程,包括最底层的基础架构(基础架构管理)、应用程序(应用程序管理)和数据(信息管理)。为了使服务正常工作,在编码流程需要采取多种测量。请注意,应对程序 Bug 的解决方案并不是本流程的一部分,而属于编码流程。
3.2.8 监控流程
目的
监控流程的目的是监控约定的服务标准。其范围不仅仅包括生产环境,还涉及整个 DevOps 流程。
输出物
○ 已建立的监控指南。
○ 已定义的事件目录。
○ 已装配的监控设施。
○ 确定(潜在)的生产标准偏差。
○ 已登记的事件。
○ 服务报告。
解释
监控合适的运维操作实际上包含多个流程,包括底层的基础架构、应用程序和数据。为了使服务正常工作,我们需要在编码流程中采取多种测量。请注意,列入事件(inclusion of incidents)并不是监控过程的一部分,而是编码流程的一部分。
DevOps 流程与 DevOps 框架间的关系概览
图中没有画出清晰的线条,但它向我们展示了其连贯性。以下是对图 3-2 的简要解释,需要说明的是这种关系不是纯粹的一对一的关系。
规划
规划包含所有 DevOps 活动,既包含最初的整个路线图,又包含服务最后的增量交付。
编码
敏捷开发主要涉及编码流程中提及的各个方面。
构建
持续集成主要包括构建流程,也包含单元测试。
测试
持续测试在本文中比测试流程范围更大,因为它包括全生命周期中所有测试类型,如构建流程中的单元测试用例。
发布
持续交付不仅是一次发布的推出,还包括部署流水线,这已经在敏捷开发可执行的测试用例中被定义了。
运维
敏捷流程实际包括所有 DevOps 流程,而不仅仅是运维流程。整个 DevOps 流程就是敏捷流程。
监控
持续监控不仅包括产品阶段,还包括整个 DevOps 流程。
服务台
服务台是客户和服务供应商之间的单一接触点(SPOC)。二者之间主要的沟通内容包括问题、服务请求、事件、产品特性需求和投诉。服务台对于 DevOps 团队尤为重要,因为它使得 DevOps 团队可以专注于其流程。
变更控制
在每个 DevOps 团队内都会通过一种关卡的形式来接受一个产品特性并推进它。这种控制被归纳为一个术语「变更控制」。它可以有多种组织形式,如产品负责人、把关人、变更顾问委员会(CAB)。根据产品特性的风险和影响,同一个 DevOps 团队可以选择不同的变更控制。
垂直特性分割
在理想的情况下,一个 DevOps 团队能够独立自主地实现一个产品特性。这意味着他们的工作不需要依赖其他 DevOps 团队或其他组织单位,如基础架构部门。这种方式的优点是使得团队之间的沟通和协作最小化,缺点是这个团队必须有丰富的知识和专业技术。
水平特性分割
在一些服务组织中,需要一个专门的 DevOps 团队,他们只负责实现某个产品特性需求的一部分。在这种情况下,一个产品特性需求需要更多的 DevOps 团队一起协作才能最终发布这一产品特性。其优点是这些团队对其负责的产品模块有深度的知识并能够交付高质量产品,缺点是几乎每个产品特性都需要两个以上团队协作才能完成系统上线。
模式
模式是针对某个通用问题或反复出现的问题的通用解决方案。一个 DevOps 团队可以通过分析其遇到的问题及解决问题的方法,总结出模式,并通过叙事分享给其他 DevOps 团队。本文给出了一些关于如何组建 DevOps 团队的模式。
特性分割
在 DevOps 团队中有两种方法来细分产品特性,即垂直特性分割和水平特性分割。垂直特性分割意味着一个 DevOps 团队要处理整个产品特性。水平特性分割意味着需要多个 DevOps 团队共同来实现一个产品特性。
一般来说,我们首选垂直分割,因为这只需要较少的团队间交互。然而,这并不是总能奏效的,比如当应用程序与/或基础架构过于复杂时。
4.4 模式 在组建 DevOps 团队时已经识别出了多种模式,每种模式都有其优点和缺点。本文主要讨论以下 3 种模式:
○ 业务线模式。在这种模式下 DevOps 团队只为一条业务线工作。
○ 组合模式。这种模式基于应用程序组合中的各个应用来划分 DevOps 团队。
○ 信息价值链模式。这个模式特别适用于信息提供商把信息池(information lake)转化为报告。
这 3 种模式都应用了服务台和变更控制的各种职能,但每种模式对垂直分割和水平分割的使用方法是不同的。采用的模式不同,对 DevOps 团队的绩效及其工作质量会产生很大影响。
4.4.1 业务线模式
业务线模式是按照应用程序来划分 DevOps 团队的,所有的应用程序根据不同的业务线来分割,在各个 DevOps 团队中的交互为零(见图 4-1)。因此这是一种垂直特性分割。
在这种模式下,服务台是客户和服务供应商之间的单一接触点。运维团队负责监控服务。变更控制是一个控制单元,在不同的 DevOps 团队间规划业务特性请求及系统上线。这个变更控制是轻量级的,因为不同 DevOps 团队之间负责的产品特性很少被共享。
这些业务线是:
○ 目标为业务的商业市场。
○ 目标为自然人的个人市场。
○ 在器材、停车场、餐馆及其他服务领域中提供服务的设备公司。
4.4.2 组合模式
在这种组织形式中,团队是按照应用程序的功能而聚集的。同样,这种模式也是基于垂直特性分割的。
这些通用的 DevOps 团队(服务台、运维、变更控制)与业务线模式相同。应用程序集群的例子是运维、财务应用、资源管理应用、人力资源管理应用及人事和组织应用(见图 4-2)。
4.4.3 信息价值链模式
信息价值链模式试图通过一组相互协作的团队来提供客户信息服务(见图 4-3)。这就意味着 DevOps 报告团队想要设计一个新的报告,需要 1~5 个 DevOps 团队参与。因此,这是水平特性分割(参见文章#12)。
在这种模式中,服务台是客户和服务供应商之间的单一接触点。运维团队负责监控信息服务。数据基础团队负责收集信息文件。核算团队负责管理信息文件的处理流程及质量审计。运算团队负责执行报告中需要的数据计算。报告团队负责将计算好的数据提供给客户,报告形式包括数据市场、报告模板及应急报告。变更控制是一个控制单元,在不同的 DevOps 团队间规划业务特性请求及系统上线。
选择这种模式的原因是,如创建报告这种情况下,所需要用到的知识和专门技术太广泛。也可以改变这种模式,根据报告内容来为 DevOps 团队分组。然而,这就需要 DevOps 团队必须能够完成数据收集、数据核算、数据计算和数据报告的全部任务。因此,当各个团队工作于相同的应用程序和信息对象时,团队之间就会相互影响。
组织模式的常见问题
一种体系结构模型(architecture model),用它在以 DevOps 为基础的服务组织中实现服务管理流程的平衡设计。
体系结构模型
体系结构模型是对现实情况的简化呈现。
流程蓝图
流程蓝图是体系结构模型的一个例子。蓝图用一张图显示了在服务组织中使用哪些服务管理流程,以及在没有详细显示所有沟通路径的情况下,如何组织纵向和横向治理。
表 5-1 展示了一个 16 区域的服务管理模型。这个模型是通过 DevOps 流程完成的,对于每个组织来说都是非常有启发性的。如果流程没有被明确识别,那么也可以用可交付成果来完善这个 16 区域模型。为了简单明了起见,本文只阐明可交付成果。另外,DevOps 团队当然也可以在单元格中加入更多内容。
表 5-1 16 区域服务管理模型
这种管理模型的优势在于,它可以帮助您思考 DevOps 领域内有什么和没有什么。一旦有些内容被排除在 DevOps 领域之外,那么,可交付成果在哪里被覆盖就成了问题。
DevOps