技术见解

DevOps:快速可靠的协作式应用交付理念


什么是DevOps?

DevOps 是一种软件交付理念和方法,以协作测试、打包和部署软件为核心,目的是增强软件版本的发布规律和可靠性。越来越多的证据表明,精心设计的稳健 DevOps 实践可提高软件部署的速度和稳定性,同时还可缩短故障恢复时间和软件更新前导时间。DevOps 是软件驱动型企业在云时代取得成功的关键,可提高 IT 响应能力和客户满意度。因此,越来越多的行业领导者开始在工具方面大力投资并提倡协作式理念和团队动态化,以此来推行 DevOps。

DevOps 是以精益思维和敏捷开发为首的各项运动在更广泛范围内的应用和成就,其最终目标是快速交付高质量的软件。敏捷开发通常以软件工程师的角色为核心,侧重于以增量方式快速开发软件。在云时代,随着软件越来越多地作为服务使用,软件直到在生产环境中投入使用之后才被视为已交付。为了秉承敏捷理念,以持续、增量且快速的方式交付软件功能越来越受到重视。因此,“敏捷”的范围必须拓展,以将速度和质量纳为运维中需要考虑的因素,所谓运维,是指一系列能够将软件从“完成代码”状态转变为“在生产环境中受支持”状态的活动,例如,构建、测试、调配、配置、部署和日常管理。可以想像这样快速地交付软件,需要开发人员 (Dev) 和 IT 运维团队 (Ops) 联手合作。

DevOps 运动是对这一需求的确认和回应。因此,DevOps 是动态的,可通过更好地进行协作、沟通和共同承担责任来避免大多数传统的交接障碍以及产品开发(开发人员和 QA)和 IT 运维之间的延迟,从而成功交付软件。




历史背景

DevOps 与传统的企业软件交付理念对比鲜明。大多数企业通常由独立工作的独立软件开发团队和 IT 运维团队组成,开发人员和 IT 运维团队之间相互孤立,在快速交付软件方面的表现差强人意。例如,大多数企业开发人员通常不能轻松地自行调配已配置的基础架构,所以无法启动可重复的标准化环境。因此,他们最终要在专用环境中借助可实现高效开发和测试的独特配置来开发他们的代码部分。然后,他们将代码交给 IT 运维团队,由其处理各种软件工件,并将这些工件运用到具有必要企业特性的运行中应用部署中。

这通常是一个复杂、手动、缓慢且容易出错的流程,需要 IT 运维团队在没有开发团队支持的情况下完成。部署软件过程中遇到的问题通常会造成团队间的摩擦和不信任。这种摩擦在现代持续交付背景下愈演愈烈,因为在这种背景下,一边要激励开发人员快速交付功能特性,一边要激励 IT 运维人员确保稳定性,这样一来,唯一切实可行的方法就是限制变化。


基本要素

对于应如何实际践行 DevOps,并没有具体的标准。然而,效用强大的成功 DevOps 实践往往会具有一些共同的特点,并且会影响企业中的文化、流程和工具。

文化
重视集体成功、协作和共同承担责任的文化渗透在成功 DevOps 实践的方方面面。开发人员和 IT 专业人员共同负责成功完成应用交付。通过企业变革,可以促进成功完成应用交付,例如,为了将共同构建和运行服务的开发人员和运维人员集中在一起,企业应该改变之前混杂的人员编排方式,为各个团队安排所需要的人。
DevOps 还强调共鸣,鼓励开发人员和 IT 运维人员更好地了解对方的角色,这样他们就能够调整自己的工作,轻松适应对方并更高效地进行协作。例如,了解生产部署环境将使开发人员能够更好地了解潜在的运维故障并围绕这些故障进行设计。另外,IT 运维团队可以更好地了解应用设计和目标,这有助于他们优化部署配置。
成功的 DevOps 实践可有效消除由于对不同团队要求不一致而引发的摩擦。例如,一边激励开发人员快速发布功能特性,一边激励 IT 运维团队最大限度地减少生产部署的变更,这就会在企业内部造成摩擦。而这样的摩擦,会通过 DevOps 消除。

流程
在实践中体现 DevOps 文化需要建立联合流程,以便开发人员和 IT 运维团队有一个交流和分享专业知识的论坛,以及一个定义明确的协作框架,从而快速而井然有序地进行软件交付和故障恢复。这样的框架可能会做出一些指定,例如,指定开发人员负责通过 API 自行调配容量,而 IT 运维团队负责实施并提供支持。或者它可能会规定一种协议/合同:不在开发环境、测试环境或生产环境之间区分 API,从而消除环境平等问题,也就是延迟和问题的重要来源。
再例如,联合流程还可能是就集中式存储软件依赖项达成一致意见并加以利用,目前通过共同开发的脚本维护这种集中式存储。随着时间的推移,这种协作可以让相关人员学到知识、实现迭代式改进,并能够将增量和频繁的软件更改部署到生产环境中,部署操作可重复进行,且停机风险很小。

自动化和共享工具
快速可靠的软件交付要求在各流程保持一致性和可重复性,这些流程已经过简化,目的是消除不必要的人工干预。例如,企业经常会因容量调配、开发和生产环境差异以及复杂的手动编译/测试阶段而需要放慢速度。
效果出色的 DevOps 实践利用共享工具帮助明确和简化协作流程,以便对整个软件交付流程有共同的了解。因此,它们能够促进一致性和自动化,帮助 DevOps 从业者提高交付速度,并避免在部署或生产故障恢复期间为临时的救急处理花费时间。许多企业供应商现在都提供用于持续集成或基础架构自动化和配置的工具。然而,集成这些分散的局部解决方案的操作十分复杂,会增加大量的开销,但对企业底线的影响很小。




为什么 DevOps 十分重要

推向市场的时间缩短
在软件驱动的世界中,快速构建和发布软件以了解客户需求并避开竞争对于成功至关重要。鉴于现代企业应用中分布式组件间复杂的相互依赖关系,成熟的 DevOps 实践可以避免通信错误和延迟,并可借助开发人员和 IT 运维团队的联合专业知识来实现简化的软件交付。《2016 年 DevOps 状态报告》指出,实际践行 DevOps 的企业的部署频率能够平均提高 200 倍,并且前导时间,即打算部署代码和代码投入生产之间的时间,能够缩短 2555 倍。其他行业研究也有类似的发现,如以下 Gartner 图表所示,其中列出了改用 DevOps 方法的更多优势。

风险更低,部署更顺畅
编排和管理现代应用的开发、部署、扩展、保护、修补和高可用性是一件复杂的事情,充满潜在的失败诱因。DevOps 实践包括协作式文化以及包装、部署、监控和管理任务的自动化,可实现以一致的方式快速将新代码和更新部署到生产环境中。再加上持续学习,DevOps 团队可以识别和消除大多数问题来源,从而建立更加稳健、简化、可重复且成熟的发布流程,使软件部署始终都能顺利进行。

恢复速度更快
当代码导致生产中断或引起停机时,DevOps 实践已准备好以更快的速度进行诊断并恢复。由于利用可为大多数发布和管理流程提供支持的重要自动化和监控功能,DevOps 团队可以快速协作以跟踪并确定故障的来源、回滚更改或问题修复程序。事实上,《2016 年 DevOps 状态报告》显示,由于这样快速而井然有序地回应意外生产问题,实际践行 DevOps 的企业将平均恢复速度提高了 24 倍,同时将更改失败率降低了 3 倍。

客户满意度更高,产品具有更好的市场适应性
迅速可靠地发布功能或错误修复程序不仅可以提高响应速度和最终的客户满意度,而且可以针对客户最关心的功能快速进行反馈并更快地进行融合。DevOps 实践是这种持续交付和快速周期的核心。如果开发人员和 IT 运维人员之间没有持续进行紧密的协作来管理最终面临的复杂问题,那么将无法始终如一地快速开发、测试和交付现代化的分布式生产就绪型软件功能。




DevOps 与传统方法

DevOps 为软件企业提供了不同的理念和新的流程。实际践行 DevOps 的企业与采用较传统方法的企业相比,存在下面一些主要区别:

DevOps 实践:
传统的方法具有以下特点:
以协作为导向。 DevOps 能否成功取决于软件开发人员和 IT 运维团队能否成功而持续地进行密切协作,以确保快速而可靠地开发和交付软件。
孤立环境驱动。 传统方法所依靠的协作被比喻为“隔墙扔”,也就是说,IT 运维团队负责部署和管理生产环境中的软件,而开发团队基本上不提供帮助或见解。
结构化和全自动化。 DevOps 实践依靠自动化来确保环境调配和配置的速度、一致性和可可重复性,从而保证在开发环境中有效的功能在生产环境中依然有效。结构化方法还可提高故障恢复的速度,因为可重复的自动化能够简化回滚和恢复操作。
手动调整配置。 传统方法依靠脚本编写和手动流程的临时组合来调配和配置基础架构,这导致很难正确操作、可靠地重复或者快速完成。这种方法往往会遇到许多问题,这些问题都起因于无法快速、一致地利用配置对等来调配开发和生产基础架构。
以自助服务为导向。 DevOps 驱动型企业会建立协作和自动化框架,使开发人员和 IT 运维团队能够独立行事,而不会彼此妨碍。例如,开发人员可以通过自动化方式快速调配开发/测试环境,而无需等待 IT 运维团队手动调配。
以“信息技术申请”为导向。 传统的企业方法需要 IT 运维团队来管理 IT 申请的管理开销,并执行可轻松自动完成的重复、手动、复杂的调配和配置。这会给调配、部署、扩展及其他软件交付和管理活动带来严重的复杂性和延迟问题。
注重业务。 DevOps 企业注重联手实现业务上的成功。因此,他们注重共同承担起确保软件交付成功的责任。
注重职能。 传统方法要求开发团队和 IT 运维团队专注于履行其职能,这些团队与整体成功几乎没有任何关系,也几乎不对整体成功承担责任。因此,问题和失败常常会引起很多指责和企业摩擦。
专为实现改变而设计。 所设计的 DevOps 实践具有快速、自动化且可重复的特点,专门用于应对快速变化以及在故障期间快速恢复。反应迅速是它们的设计核心。
不愿意改变。 传统方法因为担心破坏生产部署,无法快速恢复,而尽量避免改变生产部署。他们尽可能地减少变更和更新,并间接鼓励企业放慢速度。凭证频繁更换,以便只能使用很短一段时间。


您正在考虑采用DevOps? 请牢记以下内容。

DevOps 倡导一种新方法,通过将文化、流程和工具结合起来缩短软件交付周期。一开始可能会很难,所以这里提供了一些最佳实践,可能有助于您思考和规划 DevOps 实践。

确保根据您的需求进行定制。DevOps 实践的实施应结构化以应该满足企业的独特需求,同时还要考虑到企业结构、团队激励、当前的软件生命周期、延迟来源和自动化机会。


及时了解重要主题

时事通讯订阅

在自动化和新流程方面投资。Forrester调查公司在16年6月的报告《有效的 DevOps 需要协作、自动化和文化变革》中称:“不间断的自动化对于现代服务交付至关重要。”通过可实现自动化的工具,DevOps 的效用大幅增强。在许多情况下,成功进行 DevOps 需要全新形式的自动化功能。我们有必要加大团队合作培训方面的投入、建立新流程和使用新工具,这些都是值得的。

根据上文 Forrester 的报告,82% 的受访 I&O 专业人员至少在以下一个领域部署自动化解决方案:发布管理、配置管理和变更管理。

认识到团队建设和文化的重要性。要建立信任和合作精神,调整对开发人员和 IT 运维团队成员的激励措施以及他们的目标至关重要。例如,几个协调一致并积极合作的团队共同负责同一个项目,并根据项目取得的成功的方方面面共同接受评估,这样的多个团队协作,要比单个开发人员同时负担多个团队的不同职责有更好的协作效果。虽然工具可轻松买到,但单靠工具,却不能带来 DevOps 实践的好处,必须在根植于协作和共同责任的文化理念背景下使用工具。

了解企业动态可能会成为障碍。随着新的流程和工具准备就绪,当前流程出现中断以及现有企业规定面临威胁都是不可避免的,特别是合规性、安全性和审核职能部门。重要的是,这些部门要参与到更大的愿景中,并自愿成为利益相关方。否则,本是出于一番好意而简化的 DevOps 实践可能会因人为延迟而难以实现。自上而下的行政支持以及多个团队的贡献有助于在面临这些复杂的企业动态时正常开展工作。事实上,2015 年 Gartner 研究调查的一半受访者将人员问题列为执行 DevOps 的最大挑战。

认识到集成开销和复杂性问题。考虑到提供解决方案的供应商数量,购买针对性解决方案来处理所设计的 DevOps 整体实践的各个方面是十分简单的。然而,这可能会导致巨大的开销和高度的复杂性,因为企业要尝试集成不同的工具来打造无缝体验。有一种统一方法可提供根植于最佳实践的有力观点,它与应用运行时平台相集成,并可提供重要的灵活性,以便根据企业的独特需求定制自动化功能。这种方法可以帮助我们避开上述陷阱,为开始实践打下坚实的基础。

从小事着手。要打造 DevOps 实践,可能需要反复试验并不断完善。从小事着手很重要。为了获得有意义的成果,要从一个实际应用着手,但这个应用不能规模太大,也不能是任务关键型应用,不然业务成果会受到影响。

考虑传统的工作负载。DevOps 不仅仅对新的工作负载有意义。团队考虑革新和迁移现有云端工作负载,因此,请考虑如何将 DevOps 原则和自动化功能运用到它们的生命周期中。在发布规律和部署可靠性/稳定性方面,传统工作负载也可以从 DevOps 中获益良多。

了解 DevOps 是一个旅程。DevOps 是一种实践理念。一旦定义了团队和实践,请记住它不能保持不变。随着工作负载、需求和运维背景的转变,实践需要发展和演变,以继续满足其存在的理由:快速可靠地交付软件。