devops

DevOps是一组过程、方法与系统的统称，用于促进 开发（应用程序/ 软件工程）、技术 运营和质量保障（QA）部门之间的 沟通、 协作与整合。 它的出现是由于 软件行业日益清晰地认识到：为了按时交付 软件产品和服务， 开发和 运营工作必须紧密合作。

  

可以把DevOps看作 开发（ 软件工程）、技术运营和质量保障（QA）三者的交集

传统的 软件组织将 开发、IT运营和质量保障设为各自分离的部门。在这种环境下如何采用新的 开发方法（例如 敏捷软件开发），这是一个重要的课题：按照从前的工作方式，开发和 部署不需要IT支持或者QA深入的、跨部门的支持，而现在却需要极其紧密的多部门 协作。然而DevOps考虑的还不止是 软件 部署。它是一套针对这几个部门间 沟通与 协作问题的流程和方法。[6]

需要频繁交付的企业可能更需要对DevOps有一个大致的了解。 Flickr发展了自己的DevOps能力，使之能够支撑业务部门“每天 部署10次”的要求[7]──如果一个组织要生产面向多种用户、具备多样功能的应用程序，其部署周期必然会很短。这种能力也被称为持续部署[8]，并且经常与 精益创业方法联系起来。[9] 从2009年起，相关的 工作组、专业组织和 博客快速涌现。[10][11][12][13]

DevOps的引入能对产品交付、 测试、功能 开发和 维护（包括──曾经罕见但如今已屡见不鲜的──“ 热补丁”）起到意义深远的影响。在缺乏DevOps能力的组织中， 开发与 运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望 基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。

以下几方面因素可能促使一个组织引入DevOps：

使用敏捷或其他软件开发过程与方法

业务 负责人要求加快产品交付的速率

虚拟化[14]和 云计算 基础设施（可能来自内部或外部供应商）日益普遍

数据中心 自动化技术[15]和 配置管理工具的普及

有一种观点认为，目前占主导地位的“传统”美国式管理风格（“ 斯隆模型 vs 丰田模型”）[16]会导致“烟囱式 自动化”，从而造成 开发与 运营之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。

DevOps经常被描述为“ 开发团队与 运营团队之间更具 协作性、更高效的关系”。由于团队间 协作关系的改善，整个组织的 效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低。

DevOps对应用程序发布的影响

在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低，原因如下：

  

与传统 开发方法那种大规模的、不频繁的发布（通常以“季度”或“年”为单位）相比，敏捷方法大大提升了发布频率（通常以“天”或“周”为单位）

减少变更范围与传统的 瀑布式开发模型相比，采用敏捷或 迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于 部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。加强发布协调靠强有力的发布协调人来弥合 开发与 运营之间的技能鸿沟和 沟通鸿沟；采用电子数据表、 电话会议、 即时消息、企业门户（wiki、sharepoint）等 协作工具来确保所有相关人员理解变更的内容并全力合作。 自动化强大的 部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。

现状

很多组织将 开发和和系统管理划分成不同的部门。 开发部门的驱动力通常是“频繁交付新特性”，而 运营部门则更关注IT服务的可靠性和IT成本投入的 效率。两者目标的不匹配，就在 开发与 运营部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度。

开发人员经常不考虑自己写的代码会对 运营造成什么影响。他们在交付代码之前，并不邀请 运营人员参与架构决策或 代码评审。

开发人员对配置或环境进行修改之后，经常没有及时与 运营人员 沟通，导致新的代码不能运行。

开发人员在自己的机器上手工修改配置，而没有记录所有需要的步骤。想找到必要的配置参数，通常需要尝试很多不同的参数；在得到一个可工作的状态后，往往很难识别出通过哪些最小步骤就能到达该状态。

开发人员倾向于使用有利于快速开发的工具：对代码修改更快的反馈，更低的内存消耗，等等。这样的工具集与 运营人员面对的目标运行时环境非常不同：后者对稳定性和性能的要求远胜于灵活性。

由于 开发人员平时使用 桌面电脑，他们倾向于使用为桌面用户优化的操作系统。生产环境的运行时系统通常都运行 服务器操作系统上。

在 开发过程中，系统在开发者的 本地机器上运行。在 运营过程中，系统经常分布在多台服务器上，例如web服务器、 应用服务器、 数据库服务器等等。

开发是由功能性需求（通常与业务需求直接相关）驱动的。

运营是由非功能性需求（例如可获得性、可靠性、性能等）驱动的。

运营人员希望尽量避免修改功能，从而降低满足非功能性需求的风险

如果拒绝了小的修改，但给定时间段内需要修改的总量不变，那么每次变更的规模就会变大

变更规模越大，风险也越大，因为其中涉及的区域越多

由于 运营人员尝试避免变更，新功能流入生产环境的速度因此被延缓，从而延缓了 开发人员将特性交付给用户使用的速度。

运营人员可能对应用程序内部缺乏了解，从而难以正确地选择运行时环境和发布流程。

开发人员可能对运行时环境缺乏了解，从而难以正确地对代码进行调整。

诉求

更小、更频繁的变更──意味着更少的风险

让 开发人员更多地控制生产环境

更多地以应用程序为中心来理解 基础设施

定义简洁明了的流程

尽可能地 自动化

促成 开发与 运营的 协作

一般而言，当企业希望将原本笨重的 开发与 运营之间的工作移交过程变得流畅无碍，他们通常会遇到以下三类问题：

发布管理问题很多企业有发布管理问题。他们需要更好的发布计划方法，而不止是一份共享的电子数据表。他们需要清晰了解发布的风险、依赖、各阶段的入口条件，并确保各个角色遵守既定流程行事。发布/ 部署协调问题有发布/部署协调问题的团队需要关注发布/部署过程中的执行。他们需要更好地跟踪发布状态、更快地将问题上升、严格执行流程控制和细粒度的报表。发布/ 部署 自动化问题这些企业通常有一些自动化工具，但他们还需要以更灵活的方式来管理和驱动自动化工作──不必要将所有手工操作都在命令行中加以自动化。理想情况下， 自动化工具应该能够在非生产环境下由非 运营人员使用。

要开始优化发布流程，可以从问题识别开始：看看上面提到的哪种问题在你的团队中具有最高的优先级。

发布协调人

这是企业级IT组织中一个新出现的角色，其主要任务就是协调安排将企业级 软件 部署到预生产环境。对发布协调人的需求来自于以下几方面原因：

需要弥合 开发与 运营的鸿沟

基础设施日益变得复杂：为了 运营web应用，需要多层 基础设施和多种平台

发布频率上升（由于敏捷和 迭代式开发的引入）

分布式团队：位于全球多个地点的、包含外包人员的、混合 开发/ 测试/基础设施的团队

发布协调人的角色（也被称为 部署协调人或集成协调人）源自发布管理或发布工程团队。这个角色与航空交通管制有些类似──实时协调不同团队的行动，有效使用共享的资源（空域、航道、跑道、航站门），达到组织的总体目标（安全起降）。

传统意义上的发布管理往往只关注 软件变更的计划与管理，发布协调则需要控制“将特定软件变更发布至生产环境”的整个过程。这项工作需要系统地管理所有与“将代码构建并 部署到生产环境”相关的技术任务，也被称为“发布工程”。

变更管理是跟踪企业IT环境中各种变化──不管是应用程序还是 基础设施的变化──的基本原则。 变更管理是 ITIL v3的核心之一。

对DevOps的批评

有IT 博客对“DevOps”这个标签进行了批评，认为它不过是系统管理员的精英至上论俱乐部在老调重谈一些现有的问题（参见“对此运动的批评”）。