企业为 DevOps 做好准备了吗？

随着 DevOps 运动的受欢迎度不断提升，企业已经纷纷开始采用相关的概念和工具来管理大型基础设施和复杂的交付流程。InfoQ 访问了一些富有经验的 DevOps 采用者，就在组织和技术上依然妨碍企业级领域深入开展 DevOps 的相关问题展开了讨论。

专家成员:

• Gene Kim ——Tripwire 创始人及 IT Revolution 出版社即将出版的新书《 The DevOps Cookbook 》的作者
• Jez Humble —— ThoughtWorks Studios 顾问及持续交付博客作者之一，博客链接在这里
• Patrick Debois ——提出了 DevOps 概念，并在此后定期组织 DevOps Days 活动。从事开发, 管理, 系统管理员及测试等工作
• John Allspaw —— Etsy.com 的高级技术运维副总裁及文化黑客
• Mitchell: Hashimoto—— Vagrant 的创建者， Kiip 的运维工程师以及开源运动的热心参与者

问题:

1. 组织的大小对 DevOps 文化的成功实施的影响有多大？
2. DevOps 在大型传统组织（企业）的主要障碍之一似乎是环境异质性（机器 /OS）。而且，实际上现有的工具似乎只能用于特定的环境，而不是混合环境下，你是否同意这一观点？
3. Opscode Chef 的 CTO Chris Brown 最近提到，将私有 Chef 集成到 DB(MySQL 和 PostgreSQL) 的重要性对企业级用户来说更熟悉。你是否认为避免（技术上）破坏是 DevOps 能在企业级环境里成长的一个要求？或恰恰相反，这种破坏是必要的，它将触发或加强组织在文化上所做出的改变？
4. 现如今，你认为企业在采取 DevOps 作为他们产品生命周期管理的一部分时，主要障碍和前景是什么？
5. 你是否认为大型企业有可能在遭受组织孤岛所带来的折磨后才能意识到 DevOps 方法的好处呢？如何意识到？
6. DevOps 早在一年前就作为一种新兴方法出现在 Gartner 的发展规律周期报告中，虽然当时市场占有率只有 1%，但是 Gartner 认为在未来 5 到 10 年它将迎来高峰期。这与你们自身的经验吻合吗？
7. 太多的曝光是否会最终伤害到 DevOps 的发展呢？因为大家会只关注创建 DevOps 工作时的直观变化，而非真正解决开发和运维间的协作问题。
8. 在座的各位大多都参与了的 DevOps days 大会和该领域其它会议。你们如何看待 DevOps 演进，尤其当它从基于 Web 的敏捷公司到传统的面向流程为主的公司的扩展？
9. 对于这些话题有没有最后的补充？

InfoQ: 组织的大小对 DevOps 文化的成功实施的影响有多大？

Gene:大企业本身并不能成为 IT 组织拒绝采用 DevOps 这类实践的借口。但是如果忽略这类实践在大企业中导致的文化方面以及激励结构上的挑战就很愚蠢了。

大量文章表明，大型企业中会滋生更多的“我们 VS 他们”的部落文化而阻碍了生产力。而且这些部落文化并不仅限于“开发 VS 运维”，同时也存在于“产品 VS 销售”，“市场 VS 开发”以及“开发 VS 质量保证”等。

Eliyahu Goldratt 博士在他的《约束理论（Theory of Constraints）》一文及《The Goal》一书中把这些行为描述为“局部最优”问题，通常情况下，不同组间的斗争会整合到他们各自度量范围内。

就拿制造业来说，销售副总裁通常为了完成对客户的承诺，会尽可能多地准备库存；而生产副总裁为了减少成本，则倾向于减少库存。所以毫不疑问，两者会经常争吵。

经典的 DevOps 例子则是，开发副总裁为了争取市场，总是乐于往新版本里加入尽可能多的新特性；而 IT 运维副总裁出于对运维稳定性的考虑，总是倾向于变化越少越好。

克服开发和 IT 运维间这一核心而长期的冲突是对 DevOps 转型一个重要组成部分，一旦企业能将其攻破，其结果将非常惊人。我就曾亲身体验过一个有着数千名开发人员及数百名运维人员的公司在功能工作流上作出的非凡进步，并同时提高了稳定性和可靠性。

Jez: 我个人对 DevOps 的定义是“一个可以供大家持续讨论如何才能更好地将每一个人参与到提高业务构建和系统维护的方式”。正如 Mike Orzen 曾经跟我说的，我要强调的是 Devops 实现是永远的不能“完成”的。我们不能将该实现作为一个项目或工程来看待，因为它是没有截至日期的。因此，我认为 devops 应该通过持续改进来实现: 即找出最大的问题，并尝试定义期望获得的量化目标，然后设计出如何实现这些目标的方法。让那些有较高成熟度并且愿意尝试新事物的团队做一些实验，并从这些实验中总结出经验教训，然后将其应用到企业的其他部分。

企业的大小将如何影响这个流程？首先，它会花费更长时间，其次，你要说服领导层接受这个概念，并给你做试验所需的各种资源，同时还要忍受流程导致的节奏放缓以及由此带来的短期到中期阶段的痛苦。最后，你还要找到那些愿意花时间来实验和协作的员工。

因此，在某种意义上“DevOps 文化”意味着它要满足以上条件，即对企业文化的持续改进是可行的。但是有些事情往往很难执行下去，事实上，大型企业中最大的障碍就是领导层，可能他们也是无意识的，不理解创建这种文化的重要性或者不知道怎么去做（参考我下边关于理论 x 和理论 y 的讨论）。

John: 理论上，我并不认为企业的大小是个问题。但实际上，如果前期的成功和企业大小成反比，我并不会感到惊讶。这主要是因为虽然大型企业的一些特征可使他们不断扩张，但却大大阻碍了其文化转变。举例来说，一个公司的开发团队和运维团队在地理上是分割的（不同的建筑，甚至不同的大陆），除非投入资金来拓展两个团队的交流方式，否则两者就很难取得共识，互相合作，并经常沟通。

我认为如果一个公司有着小型的开发和运维团队工作在同一地点，或者大家能自由讨论，并就技术的实施给出广泛的建议，那么它就会运行得很好。这也就是以前介绍过的“skunkworks”方法: 先从一个小组开始，让他们发布一些高品质以及可维护的东西，然后把这类合作 / 协作之类的点子复制到其他地方。我见过并听过该方法的成功案例，但除非它变成一种主导文化现象，否则很难扩展到整个企业中。

****Mitchell:: 我无法回答这个问题，至少作为工程师，我还从未在大于 50 个人的企业里呆过。在小型团队里引入变化总是比大型团队来得容易些。尽管如此，还是有一部分大型企业在设计一些方法，来减轻在引入 DevOps 文化时的痛苦。举例来说，如果一个大型企业被分割成一些小的，具有自发性的，掌握敏捷的团队，那么在一个团队中引入 DevOps 就和在创业型企业中引入一样简单。

当有更多人参与进来时，很重要的一点就是让每一个人都看到 DevOps 给企业带来的价值。对于开发者，意味着更快的发布。对于运维人员，意味着风险得到了更多的分散，并让更多的人都关注到基础架构。对于业务人员，意味着整体灵活性的提高，通常来说这意味着产品将更加便宜。

Patrick:引进任何变化，人数的多少都会直接影响变化的速度和冲击的程度: 在相对较小企业里，一个新想法往往会快速传递到每一个人；并且当人们接触到这个想法时，并不会因为在其间的“翻译 / 转换”而产生过多的失真。不论自上而下还是自下而上的方式都难免避免存在这个问题。

大型企业本身就有更多的组织架构和规则，想改变这些要会花费更多的时间，就像突然要从坦克换成爱斯基摩单人划子一样。即使这样，企业大小并不能保证成功，即使在小企业也会在遇到早期失败或者因理解失误而放弃采用 DevOps。

因此，我认为很重要的一点是: 对于所有变化，尽早和持续地取得成功是至关重要的，而这么做也有其价值和利益。

InfoQ:DevOps 在大型传统组织（企业）的主要障碍之一似乎是环境异质性（机器 /OS）。而且，实际上现有的工具似乎只能用于特定的环境，而不是混合环境下，你是否同意这一观点？

Gene: 异质性的确是事实，但是我不认为它是一个有效的 DevOps 的阻碍力量。总之，任何已经获得成功的 IT 运维组织都必须与不断拓展的平台和应用类型所带来的复杂性做斗争，而这些复杂性也确实拖了日常运维的后腿。当这种情况发生时，企业就需要一个架构和平台策略，来帮助企业决定该向哪些领域投资，以及放弃那些不相关领域。

不论是否采用 DevOps，任何 IT 企业都要遭受不断增长的复杂性所带来的痛苦。事实上，如果做的对，DevOps 能帮助保证计划好的工作的快速开展，也有助于加速偿还技术债。

Jez: 事实上，我认为上一个问题中讨论的组织问题比起本问题中的技术问题要难解的多。主要障碍在我看来是管理层对此产生的顾虑（我们能否让开发者和运维人员一起协作的同时还能符合 SOX 或者 PCI-DSS 标准？），功能分工所引起的管理者上的领域限制，以及不愿意创造空闲时间来提高交付能力。最后一个问题在企业的不同部门会以不同方式呈现。你会发现开发经理只想让开发者关注于新功能的开发和缺陷修复。而在质量控制部门里，测试人员首要工作是完成手工测试。运维人员则整天忙着处理紧急状况。没人有时间去思考如何改善流程。这就好比一个伐木工人要在紧急截止日期前砍伐很多树，以至于他甚至不愿停下来磨下斧头，而这恰恰能加快他的工作。

当然技术问题也是存在的。跟环境异质性相比，我发现企业级架构是一个更大的问题。在大企业中，系统往往是个紧密耦合的大型代码库，同时 COTS 也是深度定制的。因此你除了整体部署之外别无选择，这使得在类生产环境下所做的集成和测试的准备变得不可思议的缓慢和昂贵。优先级最高的就是先让系统模块化以便能自动地单独部署某一模块，并在非集成环境里进行验收测试以找到主要问题。模块化架构也使集成测试更容易。当企业架构师为系统思考需求时，他们应当把可部署能力以及测试和集成的简单化作为首要目标。

John:确实会有人提出这一观点，但是我并不认为这是一个真正的障碍。但是我也不能直接说与之相反的推论就是对的: 单一的环境对开发和运维间的协作来说并不一定就更容易。但可以这么说: 环境越是单一，所需的自动化工具的数量（图像，配置管理，发布，监控等）可能会相对较少，这就使不同部门在分享经验，代码和调整等更加简单。

具有讽刺意味的是，我发现公司内大多数软件产品通常蕴含着类似如下定律的历史依据: 比如，“并不是在这里开发的”，“从事该工作正确的工具”，和“我的经理知道这个技术，因此我们将在团队中使用”。而这些都是区域最优方案（有利于团队），但却是总体的次优选择（对整个公司并非最好）。做出明确的让步是作为成熟的开发和运维关系的一部分（这里就是软件的选择），而总体最优方案就是这么来的。

极端情况下，一个公司内大部分组都使用一套完全统一的软件栈，即使没有组织孤岛，由于这些软件栈可能存在的隐含联结，风险依然存在。比如:“PostgreSQL”组、“MySQL 服务器”组、“Windows”组等。这些边界上所联合存在的隔阂依然需要去克服。

Mitchell:: 可以肯定的是，环境的异质性很大程度上提高了难度。而且，很多人忽视往往忽视了这一点，而简单地呼吁使用相同的机器和操作系统。我想大部分组织其实是推崇使用统一环境的，但是由于很多不可控的因素，最终还是使用了多样的环境。例如: 有的软件就只在某些操作系统上使用，有些组织在移植到新系统后依然保留着旧系统等。

对我和我的工具 Vagrant 而言，我们最高的优先级就是尽可能地支持更多的环境。如果 Vagrant 不能在某个环境下工作，那就是个问题。Vagrant 相对来说是个新的工具，近期才开始进入大公司领域。可以这么说 Vagrant 之所以适合大企业，其重要原因之一就是它对系统的广泛支持。

因此，尽管环境异质性解决起来非常头疼，但是我还是希望新的工具能包容和解决这类问题。

Patrick:如果从 CAMS 模式（文化，自动化，度量和分享）来看 DevOps 的话，我不觉得 DevOps 本身存在任何问题，更多的是技术上的挑战。不论怎样，我们都应该使用最好的工具来完成相应工作。减少工具的数量能加快学习曲线。但需再强调的是企业天生就应在不同时间根据不同技术建立多层次的不同应用。将该多样性作为一企业标准是企业解决技术债务很重要的一方面，尤其当系统逐渐老化后。因此我不认为这是一个采用 DevOps 的瓶颈。

InfoQ:Opscode Chef 的 CTO Chris Brown 最近提到，将私有 Chef 集成到 DB(MySQL 和 PostgreSQL) 的重要性对企业级用户来说更熟悉。你是否认为避免（技术上）破坏是 DevOps 能在企业级环境里成长的一个要求？或恰恰相反，这种破坏是必要的，它将触发 / 加强组织在文化上所做出的改变呢？

Gene:我觉得 Chris Brown 在这里提及的转变并非专指 DevOps，更多是技术供应商如何应对他们客户的技术能力。当我还是 Tripwire 的 CTO 时，我们经历过相同的转变。我们当时要集成到 Oracle 和 MySQL 中去，这样创建一个新的数据库实例将变成一个例行任务（比如: 创建一个工单），这并非每次都需要为客户花费多天时间研究的一次性工作。

这也恰恰验证了那个格言: 执行类似 DevOps 这样的实践需要尽可能地改进现有流程和工具。

Jez:我认为大家需要认清自己所要面临的挑战是什么。对我来说，当组织内有人试图改变他们的工作方式时，他们最需要做的就是尽可能快地展现出可衡量出的改进，而且必须在几个月内完成，并不断保持改进。这样就缩小了需要着手开始修改的范围。需要有最长交付时间的改变是政治层面问题，因此如果你想避免与运维人员有大的争论，那么同意使用 Postgres 或 MySQL 之一是比较聪明的举动。

John:我并不认为避免技术上的破坏是必须的。与此相反，为了性能，功能集和可操作性等因素，组织需要有能力在每个明确的技术选择上做出让步。根据我对上个问题的回答，我能看出 Chris 何时及如何提出这点。

现在很可能需要在文化上有个“爆炸式”的转换，比如: 大的技术抉择，用以加强士气，并为那些准备好迎接这个挑战的程序员提供所需。但对于它是否必须，我不完全确定。

Mitchell:: 我认为它是有关系的。Opscode Chef 是个开源软件，其开源性质就要求其他企业能自己安装和管理。如果一个企业使用它时觉得不舒服，那可以换成付费的 Chef。反过来说，即使技术是不公开的也没关系，因为软件公司保证会为他们的软件提供相应的各种服务。

Patrick:我们应该在两者中间寻找平衡。让部分人采用那些与问题，技术或你推荐方案中必须的新技术。改变往往把人们带离其舒服的区域: 有的人喜欢这样的挑战，但不是所有人。你必须了解你的受众。如果像 Chris 那样希望有更多的人来使用你的产品，就降低采用难度以缩短学习曲线。

InfoQ: 现如今，你认为企业在采取 DevOps 作为他们产品生命周期管理的一部分时，主要障碍和前景是什么？

Gene:通过观察企业级 IT 组织（例如:Unum, Paychex, BNY Mellon, World Bank 等）所展示出来的工作，DevOps 实践通常也是由那些推动企业实行 ALM 和 SOA 的人发起的。而这也恰恰符合逻辑。因为这些团队总是乐于提高服务质量，并不断与企业架构师、开发人员、QA 和运维人员工作在一起。

他们面临的挑战就是如何将所有这些不同团队结合在一起形成一个大部落，然后去试图解决那些较大的企业级问题，而不是让这些团队相互间搞部落战役。

你可以通过下面这个问题来理解 ALM 团队为何特别适合解决组织孤岛问题。

Jez:首先，你要意识到你现在正面临着问题，并决心在现有基础上致力于解决它们，当然这个过程是痛苦的，尤其是想在短期内解决的话。DevOps 的采用范围是很广泛的，根据你的系统架构如何处理条规和审计的不同而不同。从可维护性自动化测试一直到如何让人们在组织内有效地沟通，我们都需要培训，训练和支持。最后，所有人都必须有一个清晰的，共享的视图来告诉大家前进方向和目的，这样才能更好地计划。

John:在我看来，如果一个组织不把技术视为其核心竞争优势的话，那就是最大的障碍。当然这只是我个人偏见，但当我看到公司把所有处理电脑的人员统称为“IT 部门”以对抗“应用开发”或是“技术维护”之类时，这类公司则将电脑视为一个商业上的拘绊，而非助力。

我曾在波士顿的一家广告公司工作过。当时具有完成任务以保证商业的技术组在资源，关注及能力上却与处理灯泡更换的后勤部门处在同一地位。工程师团队作为与商业无关人员往往被排除在未来规划或其他使用技术能帮助公司前进的对话之外？这意味着在文化上，工程师团队就被视为公司里的二等公民，因此没有在应有的发展话题上获得更多的关注。

因此企业级公司最大的困难就是摒弃将 IT 视为只是单纯保证服务器工作的技术人员的旧思想，而开始将他们视为工程师驱动的团队并能为商业带来竞争力优势，从而值得企业为之投入时间和精力。

Mitchell:: 现在最大的阻碍就是教育。在过去几年里，DevOps 运动由于还未完全成型，因此比较不稳定。现在我们终于到达了一个可以让更多的人能舒服地说出 DevOps 是有具体实例证明实际可行的。但是就根据这点，还是很难找到资源来具体说明什么是 DevOps，以及如何将你的组织往 DevOps 文化上转化。

我希望看到更少的对 DevOps 虚无缥缈的谈话，而更多明确的有具体步骤的方案来执行 DevOps。虽然这些方案并不适合每个组织，但是至少它们能提供方向。

Patrick:如果要考虑 DevOps“运动”的挑战，就会带出相比于创业型 web2.0 公司成功更多的企业级成功的例子。人们总是尝试各种不同的成功，却害怕公开那些‘没有’成功的，因为他们把这些看成了失败。但是分享失败是学习一个重要方面，值得提倡。

对于企业内部人员，我觉得引入任何改变时都一样（比如，多年前的敏捷）。这取决于你的谈话对象，对于 CEO、CIO、项目经理或技术人员来说，它必须具有说服力和价值。阻碍对改变的采用往往是公司内部的惯性，以及对新趋势的消极看待。所有的东西都必须经过批准。人们和他们的习惯确实是最大的挑战。我发现这几乎是个信仰问题了: 是合作和共同目标提高了价值，还是更严格明确的分工具有更好的影响？这取决于团队和个人观点，人们总是倾向于其中一个。我甚至认为如果这就是你的主要信仰，那么其中一些人可能就无法适应 DevOps 思想。

InfoQ: 你是否认为大型企业有可能在遭受组织孤岛所带来的折磨后才能意识到 DevOps 方法的好处呢？如何意识到？

Gene:a. 对共同问题的共识

通过长达 5 年多的研究我发现组织内的孤岛问题导致了开发和 IT 运维间的敌对关系，造成了前所未有的不断增加的技术债，从而延缓了发布功能到市场的速度和时间，以及不断加重的 IT 产品环境的不稳定和混乱。

我们的挑战一直是如何向开发和 IT 运维管理者显示他们的目标其实一直未被满足，问题还没解决，而且将会持续恶化。

b．管理层和参与者面对问题的意愿

我发现当我们向领导层演示整个组织是如何被这个内部斗争所危害和威胁时，他们都会表现出要结束该情况的决心，并要在一起工作解决这些难题，这在几个月前是几乎无法想象的。

结果得到了更短的发布时间，更好的自动化测试，更少的代码打包时间，更多成功的发布，以及更快的发布节奏。除此之外，IT 运维和开发团队间更好的反馈循环，开发者可以更快地获得所需信息（通常通过自选服务），并通过交叉培训 IT 运维人员减少风险数目，以及系统级循环中更多程度地偿还技术债务。

最终结果是在不断提高产品环境的稳定性、可靠性、弹性和安全的同时，实现了更快的工作流。

这时，开发和 IT 运维才真正帮助商业获得成功。

Jez:是的。对我来说，DevOps 最重要的信息是任何人都有能力: 每天都可以做些小的事情来改进情况。开发人员可以去和 DBA 人员共进午餐，找出他们为什么不喜欢开发人员，以及可以做些什么来改进。运维人员可以抽出 30 分钟时间建立版本控制，嵌入他们的脚本来改善他们的配置管理，赋予开发人员读权限以便他们理解产品环境是如何创建和维护的。组织跨岛午餐和学习座谈会来分享知识和建立团队间关系。创建内部博客。任何人都不应该等到上级强制下令才开始实施 DevOps 之类的实践。

John:我同意，但是应只投资在组织内原始孤岛背后所真正存在的问题上。如果你无法快速而简单地展示团队合作所带来的好处，那你就没有理由去做。还有，如果上层领导不同意，尤其那些相信他们正在从组织孤岛上获利的管理人员（相对的，一种简单方便的“盖住屁股”和边界互指），那么其阻力是非常大的。

我认为说服的技巧在于直接表明在开发和运维间，对合作、协助和沟通投资是值得的，比各自拥有安全毯而互相指责的文化更值得。但这个说服只有在双方团队都意识到这存在于他们专业领域所允许的范围，即他们相互推脱的边界。

Mitchell:: 我认为这是有可能的。负责管理这些孤岛的人需要看到 DevOps 在商业和文化上所带来的利益。为了改变而改变是毫无意义的，但是一旦获得了真正价值，那改变就会随之发生。

Patrick:它们当然会发生，甚至有很大的可能经常最需要它们。因为，在通常情况下，人们总是趋向将相同的事物组合在一起，而公司的大小往往促进了团队的建立。从单纯项目组到从始至终都负有全责的产品组的转换在企业内是可以良好运行的。这会促进合作和更好的结果。但它们也往往取决于公司文化:IT 并非完全独立存在于真空中，而是一个平衡艺术。如果减少对所谓的商业范畴的影响，有些产品团队往往看起来会有翻倍的精力和费用。但是他们没想到的是在敏捷和自我管理上的所带来的利益往往超越了这些。

InfoQ:DevOps 早在一年前就作为 一种新兴方法出现在 Gartner 的发展规律周期报告中，虽然当时市场占有率只有 1%，但是 Gartner 认为在未来 5 到 10 年它将会迎来高峰期。这与你们自身的经验吻合吗？

Gene:我认为我们对 DevOps 采用还处在最初级阶段，它会为 IT 企业带来在生产力上大幅度的提升。我曾经问过那些采用 DevOps 的企业，如何回应那些说 DevOps 不适合大企业的人，他们往往感到困惑。对他们而言这只是个优先级问题。

我相信 DevOps 模式是在 IT 价值流中采用 Lean 原则不可避免的结果。如同 Dr.Deming 曾说过的:“生存并非必然的。”

Jez:如果我们能在 5 至 10 年内把握任何一个广泛变化，我将非常吃惊和高兴。最让我郁闷的是我目前在写的关于执行持续交付的新书，在某种程度上，关于持续交付的想法大家已经讨论了好几十年。Peter Drucker 早在 50 年代后期就曾讨论过知识工作者和制造业间的不同，但我们从中依然什么都没学到。比如，他说到“知识工作者的生产力不是——至少不主要是——在数量上的产出。”但是依然还是有公司依据程序员每天写出的代码行数来判断其生产力。代码行数是个变量，而非优势！Douglas McGregor 在 1960 年提出的理论 X 和理论 Y，他明显指出知识工作者只有在其管理者拥有理论 Y 态度的企业才能有效地工作，但显然许多公司（很可能甚至是大部分）都不将它视为常规。

John:老实说，我并没有花太多注意力在 Gartner 的报告上，我本人对商业上的行业预测并不大感兴趣。不论一个分析员的预测是否正确，都不能推动一个行业的发展。我真正感兴趣的是那些具体细节，它们能给企业能力带来成熟度，然后提供针对当前问题的工业方案。

Mitchell:: 我赞同。目前我所在的公司还比较年轻，环境相对比较新潮和宽松，因此 DevOps 执行起来比较容易。但是它依然有其不到位的地方。我想在未来 5 到 10 年，它应该会到达一个稳定点。

Patrick:我意识到很多 DevOps 讨论是由其早期采用者发起的，同时也将需要时间扩散。早些年，人们质疑敏捷，到现在大约 10 年了，其市场占有率又有多少呢？我没有水晶球，但我希望我们还是会有很大的发展可能。类似代码即基础框架的技术因素发展起来相对比较快，因为它们已经有了现有的实践。在将来，对新文化的采用会增加，但也需要更长时间。

InfoQ: 太多的曝光是否会最终伤害到 DevOps 的发展呢？因为大家会只关注创建 DevOps 工作时的直观变化，而非真正解决开发和运维间的协作问题。

Gene:根据 DevOps 创建工作职责说明了商业领导者看到了 DevOps 的价值。就算他们无法说出具体角色，责任或日常工作，也不能否认对它的需求。在我看来，这只是表示我们走这条路的时间早晚而已。

目前来看，DevOps 更像一场哲学运动，对实践还没有一套自己的具体方法，还不具体或精确（比如:CMM-I，ITIL 等）。“DevOps Cookbook”项目背后的意图在于将以下内容归类: 具有高 DevOps 执行力的组织共同点是什么，能使他们获得出色的执行结果。我们的目的是创建规范的指导来创建文化、价值、流程、具体步骤和日常工作，这样我们就可以反复重现成功的结果。

你可以从这里学习更多关于该项目内容。

Jez:如果企业当初通过寻找“DevOps 人员”来使组织改变的话，我就不可能被选上。但是很多公司试图通过创建一个新的“DevOps 团队”来解决 Dev/Ops 分离问题，该新团队负责在不改变团队工作的同时，连接现有功能团队间的边界。这真是令人啼笑皆非。组织关注点所关心的恰恰是 DevOps 所能完成的: 通过持续交付有价值的软件来满足客户，比如，帮助现有人员改变工作方式，学习 DevOps 技巧，其中包括如何看待代码即基础框架。试图聘请“DevOps”人员的另外一个问题是对拥有所需经验的优秀人员的需要往往供不应求。而且很多人往往陷入企业中被用来试图缓解症状，而非解决根本问题的困境中，这不能真正提高供给。

John:我觉得过多的曝光事实上对任何事物都会有伤害。坦白地说，我现在所见的就是这样。很多人将 DevOps 等同于持续交付。频繁发布，如何发布，以及如何自动化其实和 DevOps 没有任何关系，除了确实在使用自动化和持续发布的公司通常拥有 DevOps 文化。

我还认为在通常情况下，技术公司往往低估了“软技术”的价值。我见过在有的项目中，有的工程师花费了多个月的时间去自动化一个流程，这样他们就不用跟另外团队经常沟通交流。这是很荒唐的，一个成熟技术公司不应以此为基础。

因此我觉得过多的曝光确实能伤害到这一概念，它会将注意力从文化层面上转移开，而变为“DevOps 锦盒”，一个包装了的仅仅关于技术的概念。

Mitchell:: 我们已经看到这类事情的发生，有的人称他们自己是“DevOps 工程师”或“我们正在做 DevOps”。同样，我发现造成这类事情最根本的问题在于教育。因此如果围绕 DevOps 的曝光给出消息是错误的话，这个循环将是永久的。

Patrick:要帮助那些情愿相信推销者所兜售的童话故事的人们是非常难的。在这里我并不是要说所有的销售人员都是坏的。我所见到的报道加快了那些有经济能力去实践的人们。但是陪审团总是在判决下定后就散场了。风险在于这些所谓的“DevOps”标签会因此贴上坏名声。一个坏的经验所带来的影响远远胜过多个正面的。还有如果你就是要往坏的方向想的话，那所有的争论都是有可能的。持续保持好的内容和用例能让我们一直看到事物乐观的一面。Agile 和 Lean 也发生了同样的事，不同的地方在于 DevOps 做为一种思想在全球范围传播的速度。但是速度同样也是新思想和用例获得传播，变化获得注意的优势。从反对者那里学习是非常重要的，这可以明确地避免将 DevOps 人员往“原教旨主义”方向转变，比如:“代码即基础架构”就是比“Shell 脚本”好等。

InfoQ: 在座的各位大多都参与了的 DevOps days 大会和其他该领域的会议。你们如何看待 DevOps 的演进，尤其是它从基于 Web 的敏捷公司到传统面向流程为主的公司的扩展？

Gene:我相信我们第一次看见 DevOps 模式是在基于 web 的敏捷公司里，因为那里的竞争最激烈，停机时间和用户响应时间直接等同于利润。

由于 IT 对几乎任何一个商业都是至关重要的，接下来我们将看到更传统的 IT 企业对 DevOps 的采用。我和 Mike Orzen 曾写过一篇文章讲述了采用 DevOps 所带来的价值。我们相信每年将会创造出 4 万亿美元的价值，这比德国整个经济体一年所创造的价值还要高。

它将会在以下几点上带来极大的正面影响: 生产力，生活标准和减少由于在 IT 行业工作对人体所引起的伤害。正因为以上这些我认为 DevOps 真的是一个非常重要的运动。

Jez:现如今有很多基于 web 的敏捷公司没有 DevOps 文化，可能你会对他们的“敏捷”有所怀疑，因为理论上如果你做敏捷的话就应该有 DevOps 文化。根据我的经验，这些公司和那些没有将他们自己定义为敏捷的企业面临着同样的问题。企业主要的风险是试图在还未明确自己需要达到什么目的的情况下就采用 DevOps，尤其在还未定义他们所要跟踪的可度量的结果前。

人们总是倾向于购买一系列工具来开始这类实践，而这往往是个“坏主意”: 工具是很重要，但不应该是起始点。一个好的开始方法是查看你现有的用于创建和运行软件的系统的能力的成熟度，然后根据你想要到达的可度量结果确定它们将来的样子，最后才制定计划如何在几个月内从 A 点到达 B 点（如果你觉得需要多个月时间，那你就需要选择一个更近的目标）。

但在我的经验里，执行你设计的计划将会遇到以下几方面主要问题: 制度、文化、架构、错误的工具和技能的缺失。

John我认为依然有很多“异花传粉”可以发生的，web 公司和大型企业间的沟通和共识需要进一步发展以便真正达到目的。因为双方间依然存在着很多傲慢和偏见。

曾经有个银行技术管理者跟我说，Etsy（或任何 web 公司）不是一个“认真的”力图者，而银行需要处理“严肃的金钱”，这意味着他们不可以像 web 公司那样“乱搞”。当然我也见过 web 公司讽刺这些企业，认为他们被他们那一小群用户给“惯坏了”，而且还不 24 小时提供服务。

如果这些组织间没有一个共识，那将会使得想法和概念健康而成熟地发展缓慢进行。

Mitchell:: 我对这个领域了解还比较新，只参与了 1 年多，我偏向将这个问题留给对这方面比较有经验的人。

Patrick:在 DevOps 的过去这几年里，我们看到人们开始采用自动化实践。这就慢慢往更可行层面的度量和标准挺进了。我倾向于将其看作是自动化要求所返回的信息: 差的自动化实践并不能提高任何事情除非我们从中学到了教训。现在安全领域已经意识到 DevOps 的价值了，我非常兴奋地看到公司不同部门开始改变他们的看法。基于传统面向流程的公司不管是否部分受到因为缺少‘敏捷’工具而带来的影响，但很大程度上都会受到前面提到的人们在心态上的固执和惯性的影响。

InfoQ: 对于这些话题有没有最后的补充？

John:我想说的是目前该领域是由参与者的报告控制的。DevOps 作为一个概念或集成的想法能否成活取决于它能否完成商业上需它完成的工作。这就是为什么在会议或文章上分享实例如此重要。对于相信 Dev 和 Ops 间协作，沟通和合作是个好主意的人，请分享你的故事，但不要保留那些不好的点，应该全部陈述。

对于另外一些还未被 DevOps 折服的人: 如果你认为你的商业会在以下这些方式，比如: 保留信息、在资源链上独立他们各自的功能、或让团队间互相矛盾下往前发展的话，大可以继续下去。但希望你能与自己领域其他的人分享你的故事。

文化改变的发生不是因为人们创建了新的单词，而是因为人们采取了行动，并将故事宣传开来。

Mitchell:: 使用 Vagrant ！我这是明显的个人偏见，但是我从多个资源了解到，该工具真的让组织内对 DevOps 改变变得更加顺利，但前提是你可以自由地试验和尝试所需工具以合理地融入到 DevOps 文化中。

Patrick:同事间，组织间，行业间分享是一个发展和丰富 DevOps 想法的至关重要的因素。与分享代码相同，我希望获取新思维方式，并持续激励人们做同样的事。DevOps 显示了基础想法所带来的影响，就如同你在 youtube 上表达自己而不是在电视上购买时间。我们自己来决定我们的行业将会如何发展的。

关于专家们

Patrick Debois习惯于不断通过改变从事的顾问职位及所在行业来理解当前的 IT 行业：他当过开发者、经理、系统管理员、测试员，甚至是客户。在长达 15 年的咨询生涯里，最让他烦恼的就是团队间彼此的隔离分割。但是时代在改变：作为市场中一员就要求你控制住这些孤岛间“斗争”。

他第一次做关于敏捷架构演讲是在 2008 多伦多敏捷大会上，在 2009 年他组织了第一个 DevOps Days 。从此他就致力于宣传‘DevOps’概念以促进团队间交换思想，以及给他们展示如何互相帮助在商业上达到更好的结果。目前他正在全世界范围内组织DevOps Days 活动。

Gene Kim在多个角色上获过奖：CTO、研究者和作家。他曾是 Tripwire 的创始人并担任了 13 年的 CTO。他写过两本书，其中包括《可见的运维指南》（The Visible Ops Handbook），目前他正在编写《当 IT 失败时：一个商业传说》和《开发运维手册》（ When IT Fails: A Business Novel 和 The DevOps Cookbook ）。Gene 是 IT 运维的超级粉丝，钟爱于它如何让开发人员最大限度地从“代码完成”到“产品”地产出功能模块而不导致混乱或破环 IT 环境。他和多个顶级互联网公司合作过，致力于提高他们的发布流程，提高围绕在 IT 运维流程上的严密性。在 2007 年，ComputerWorld 将 Gene 列入了“40 岁以下的 40 个创新 IT 人士”的名单中，普度大学还给他颁发了杰出校友奖以表彰他在专业领域的成就和领导力。

Jez Humble是 ThoughtWorks Studios 的主管，也是 Jolt Award 获奖作品《持续交付》（Continuous Delivery）的联合作者，该书发表于 Martin Fowler 的签名系列（Addison Wesley，2010）。Jez 从事于多种平台和技术，为非营利性组织提供咨询，还就职于电信，财务服务，以及在线零售公司。Jez 关注于帮助组织通过执行有效的工程实践来频繁和稳定地交付有价值及高质量的软件。

Mitchell Hashimoto是 Vagrant 创始人及 Kiip 的运维工程师。他热衷于任何关于运维和开源的事物，并喜欢将他每天业余时间中的几个小时奉献给社区。除了对开源社区的贡献，Mitchell 还喜欢在各会议上或 Vagrant 用户组里做演讲。可以通过 @mitchellh 账户在 Github 或 Twitter 上找到 Mitchell。

John Allspaw已经在生物技术，政府系统和线上媒体上有着超过 14 年的系统运维经验。他曾为 Salon, InfoWorld, Friendster 和 Flickr 建立过备用基础架构。现在他是 Etsy 的技术运维副总裁，同时也是 O’Reilly 计划出版的《能力计划的艺术》（The Art of Capacity Planning）一书的作者。

查看英文原文: Is the Enterprise Ready for DevOps?

感谢马国耀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。