DevOps

DevOps（Development和Operations的混成词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

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

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

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

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

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

1. 使用敏捷或其他软件开发过程与方法
2. 业务负责人要求加快产品交付的速率
3. 虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍
4. 数据中心自动化技术和配置管理工具的普及
5. 有一种观点认为，目前占主导地位的“传统”美国式管理风格（“斯隆模型 vs 丰田模型”）会导致“烟囱式自动化”，从而造成开发与运维之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。

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

对应用程式发布的影响

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

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

减少变更范围

与传统的瀑布式开发模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程式会以平滑的速率逐渐生长。

加强发布协调

靠强有力的发布协调人来弥合开发与运维之间的技能鸿沟和沟通鸿沟；采用电子数据表、电话会议、即时消息、企业门户（wiki、sharepoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。

自动化

强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。

现状

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

• 开发人员经常不考虑自己写的代码会对运维造成什么影响。他们在交付代码之前，并不邀请运维人员参与架构决策或代码评审。
• 开发人员对配置或环境进行修改之后，经常没有及时与运维人员沟通，导致新的代码不能运行。
  • 开发人员在自己的机器上手工修改配置，而没有记录所有需要的步骤。想找到必要的配置参数，通常需要尝试很多不同的参数；在得到一个可工作的状态后，往往很难识别出通过哪些最小步骤就能到达该状态。
  • 开发人员倾向于使用有利于快速开发的工具：对代码修改更快的反馈，更低的内存消耗，等等。这样的工具集与运维人员面对的目标运行时环境非常不同：后者对稳定性和性能的要求远胜于灵活性。
  • 由于开发人员平时使用桌面电脑，他们倾向于使用为桌面用户优化的操作系统。生产环境的运行时系统通常都运行伺服器操作系统上。
  • 在开发过程中，系统在开发者的本地机器上运行。在运维过程中，系统经常分布在多台伺服器上，例如web伺服器、应用伺服器、数据库伺服器等等。
• 开发是由功能性需求（通常与业务需求直接相关）驱动的。
• 运维是由非功能性需求（例如可获得性、可靠性、性能等）驱动的。
  • 运维人员希望尽量避免修改功能，从而降低满足非功能性需求的风险
  • 如果拒绝了小的修改，但给定时间段内需要修改的总量不变，那么每次变更的规模就会变大
  • 变更规模越大，风险也越大，因为其中涉及的区域越多
• 由于运维人员尝试避免变更，新功能流入生产环境的速度因此被延缓，从而延缓了开发人员将特性交付给用户使用的速度。
• 运维人员可能对应用程式内部缺乏了解，从而难以正确地选择运行环境和发布流程。
• 开发人员可能对运行环境缺乏了解，从而难以正确地对代码进行调整。

诉求

• 更小、更频繁的变更──意味着更少的风险
• 让开发人员更多地控制生产环境
• 更多地以应用程式为中心来理解基础设施
• 定义简洁明了的流程
• 尽可能地自动化
• 促成开发与运维的协作

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

发布管理问题

很多企业有发布管理问题。他们需要更好的发布计划方法，而不止是一份共享的电子数据表。他们需要清晰了解发布的风险、依赖、各阶段的入口条件，并确保各个角色遵守既定流程行事。

发布/部署协调问题

有发布/部署协调问题的团队需要关注发布/部署过程中的执行。他们需要更好地跟踪发布状态、更快地将问题上升、严格执行流程控制和细粒度的报表。

发布/部署自动化问题

这些企业通常有一些自动化工具，但他们还需要以更灵活的方式来管理和驱动自动化工作──不必要将所有手工操作都在命令行中加以自动化。理想情况下，自动化工具应该能够在非生产环境下由非运维人员使用。

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

发布协调人

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

1. 需要弥合开发与运维的鸿沟
2. 基础设施日益变得复杂：为了运维web应用，需要多层基础设施和多种平台
3. 发布频率上升（由于敏捷和迭代式开发的引入）
4. 分布式团队：位于全球多个地点的、包含外包人员的、混合开发/测试/基础设施的团队

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

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

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

参见

• BizDevOps
• CI/CD

外部链接

• What Is This Devops Thing, Anyway? (by Patrick Debois, 2010/02/12)（页面存档备份，存于互联网档案馆）
• 捷伴行Agile （页面存档备份，存于互联网档案馆）

产品

• IBM DevOps（页面存档备份，存于互联网档案馆）
• Nolio ASAP
• StreamStep SmartRelease（页面存档备份，存于互联网档案馆）
• The ControlTier Framework（页面存档备份，存于互联网档案馆）
• DevOps（页面存档备份，存于互联网档案馆）