转载

全球顶级专家为你解读：什么是真正的 DevOps？

【编者按】本文是 Skytap 内容主编 Noel Wurst 对 DevOps Enterprise Summit （DOES）的不完全综述，内容包括了 Noel 和一些与会嘉宾的思考，旨在勾画 DevOps 当下的局势，以及未来的趋势。以及 DevOps 的真正价值——DevOps 正帮助越来越多的企业迈向非凡成功之路。本文系OneAPM 工程师编译整理。

以下为译文：

正如 Elisabeth Hendrickson 的闭幕演讲的标题「It’s all about feedback」，因此笔者也撰写了自己的参会感，注以下斜体字是笔者参加演讲时现场所记。

Day 1

Gene Kim 在主题演开幕词中指出，对比2014年的600张售票，本次会议售票激增到1200张，而之所以形成这个局面，主要是因为 DevOps 当下已经切实预备运用于许多大型项目，全世界都在期盼从中获取价值。

（重新）构建一个工程文化——Target 的 DevOps 实践

关键人物：

Ross Clanton， DirectorHeather Mickman，Senior Group Manager

Target 的 Ross Clanton 和 Heather Mickman 对「pre-DevOps」那个过程分享的直率令人感动。摘录：

「Target 多年前就曾困惑于工程师的重要性。我们知道必须改变现状......我们在 silos 中嵌套 silos ......单服务器支撑需要十个团队才能完成，而 IT 部门处于一片混乱，以至于大部分的开发流程都耗在等待队列中。」

Ross 说：

「我们得到了很多称赞，但这还只是刚刚开始——我们正从事着非常有意思的工作，但还有很长的路要走」。

Target 的发言奠定了本次会议的主题，不仅仅是分享其发展和运营团队的成功，还讲述了不久前的糟糕境况。虽然很多人会说围绕 DevOps 的原则已是旧谈，但成功 DevOps 的举措所带来的收获，让整个过程中的挫折和失败也都变得有意义。

企业 DevOps：由 Metrics、Empathy 和 Empowerment 所驱动的转型过程

Jody Mulkey，Ticketmaster CTO

Jody 用足球来比喻：长久以来，开发和运维都被认为是功能相反的团队。在足球场上，运维被视为防守，试图阻止开发者（进攻）的射门。但运维其实也应该归为进攻，尽一切努力给开发者争取充足的时间来得分。

从2011年到2014年，Ticketmaster 的开发者人数增加230％，而运维人数只增加了12％。 Mulkey 却说「这可不是好事」。

修复 bug 的平均时间以前是47分钟，但现在是3.8分钟。时下存在更多的挑战，永远需要修复错误，部门自视为是其他部门的对手，长时间等待。之所以老生常谈，因为大多数企业都经历着这些斗争。

Jody 的故事也非常有意思，他谈到 Ticketmaster 如何成就「背负着遗产前行」，以及 DevOps 是如何适用于传统的大型机系统。Ticketmaster 的售票引擎产生了25亿的收入，尽管它首次提交代码是在1976年。正是这个系统和团队的不懈努力支持着 Ticketmaster，使得修复 bug 的平均时间从47分钟提升到如今的3.8分钟。

USAA 和 IBM 的 DevOps 及创新

Michael Bueche， AVP IT Operational Excellence， USAADibbe Edwards， VP Development， DevOps for Hybrid， IBM

当引入一个 DevOps 这样的大型变革到企业时，建议一步步从小处开始，贪多嚼不烂。Michael Bueche 详细地讲述了 USAA 在推向市场前158天的历程，及产品90天后部署敏捷方法的经历，以及当前的每周目标。

「我们人类在确定行动或决定之前，会常常经历一个非常糟糕的时期，以及在获得结果前。把这种状态比作‘热炉’再恰当不过。试想，当你把手放在滚热的炉子，要多久才能意识到疼痛？并不需要一个星期。正如一个开发者在生产中出现 bug，而你直到6周后才发现这个问题，那么找到责任人有多难？甚至即使你找到了，让开发者回忆当时的问题和原因也很难。缩短反馈回路非常有必要，也帮助行动对应其结果」——Michael Bueche

Dibbe 说：

「我们必须确保企业中有适用于 DevOps 计划的可伸缩环境，同时还一直致力于寻求提高的方法。」

在 Michael 分享之前，笔者从来没有听说过「热炉」这个比喻，的确非常适用于 DevOps、敏捷或现代化软件交付。反馈回路必须缩短，才能按时完成和防止生产过程的问题。

赋予开发/测试团队可以按需独立提供扩展性环境的能力，然后再更早更频繁地进行检测，获取 bug 状态的快照，使开发人员可以很容易地重现 bug 并予以消除。就像 Jez Humble 所说的——先在自己的环境下搞好！

DevOps 如何实现精益应用开发

Carmen DeArdo， DevOps Technology Leader， Nationwide Insurance

Carmen 说，Nationwide 也曾考虑过外包软件交付，顶住了种种压力，他们证明这是完全没必要。从减少依赖、等待时间和未计划的工作中，可以降低大量预算。

Carmen DeArdode 的幻灯片展示了妨碍 Nationwide Lean 交付的因素，以及与此同时，国外的企业在如何应对。

另一个恰当的运动和软件类比，笔者认为这个观点非常恰当：「如果你的团队缺乏一体化的工具，就像你在完全不了解篮球队的比赛情况下，却要指导篮球队的实战训练，所以根本无法针对实际问题进行操作。」

笔者确实非常喜欢 Carmen 的演讲。超过200个敏捷团队正在质量和生产方面做出显著提升，但 Nationwide 仍然处于等待状态，在各种规模的企业内都普遍感到这种状态。

那么，Carmen 和 Nationwide 到底做了什么呢？他们从未停止推进，「在持续交付中采用 DevOps，在移动端、分布式、主机和其他技术中使用精益和敏捷技术。」

效果如何？

Carmen DeArdo 的幻灯片显示，在引进精益应用开发后 Nationwide 的收获。

以上是第1天的内容，根据一起参会的 Skytap 同事所说，某些错过的其他回忆也同样令人深省！可以在网上找找我们现场所录的博客，视频中会包含其他会议！

Day 2

在轮渡大厦的 Boulettes Larder 享用了平静安宁的早餐后，第二天也像第一天那样，在匆忙的会议中进行。

银行业务的 Innovation 和 DevOps

Tapabrata Pal， Product Manager， Capital One

Tababrata 说：

「为什么要开源我们的工具？因为这是正确的做法，它们有助于一个持续实验和学习的文化，开源令它变得更好。」

这是笔者在 Tapabrata 主题演讲中唯一记录的东西，但不是说其他的内容都不好。

老实说，事实恰恰相反。但他对开源工具的观点确实令人影响深刻，以及简单有力的答案，「这是应该做的......因为开源令它变得更好」，引起全场轰动的掌声，以至于几乎全场都起立为之喝彩。

Tapabrata 接着指出，Capital One 非常擅于获得快速反馈，因为他们需要保证员工和客户都高兴。

有资源的团队被称为「办公时间」，无论什么项目都可以在那里获得帮助，以及「客户之声」项目可以让客户指出瓶颈位置——传统思想这种情况只会出现在企业内部中。我很喜欢这个主意。

「我不是在构建网络软件，为什么要关心持续交付？」讨论由 Jez Humble 主持

嘉宾从左到右依次是：Jez Humble、 Gary Gruver、Kathy Herring Hayashi、Hugo Gayosso 和 Anders Wallgren。

「如果你在打造精品，它会很快地融入市场。」因此，发现的错误越晚，付出的代价就越昂贵。在嵌入式软件中，这会变得严重得多。汽车、医疗器械对高品质的需求，安全软件是绝对必要的。”

观众提问：「这些变化需要什么文化？」「产品是容易投入的，并且IT部门不能只被当作成本中心......它们同样应该被视作完成业务的根本。」

尽管这个讨论专为嵌入式软件行业设计，但该组的讨论仍适用于大型机到移动端，以及介于两者之间的平台。这些天每个人都在说，交付生命周期晚期发现 bug 的成本远远超过早期，在进入客户的手中之前。

「构建质量」可能需要严重破坏的现状，无论团队在这方面有多么熟悉，「他们一直都做的方式」，多长时间才能负担得起继续沿着这条道路的成本?

正如这个小组所说，「IT不能只被看作是成本中心」。对于软件交付同样适用，软件交付也经常被当作成本中心，或者是获取功能及发布的障碍。

对虚拟环境、DevOps、连续检测以及整个交付过程的其他改变的需求，改变着世人对该团队的看法，并让他们对软件的速度和质量产生实质性的影响力。全球顶级专家为你解读：什么是真正的 DevOps？

迪斯尼的 DevOps ——企业意识

Jason Cox，Systems Engineering Disney Internet Group，Web Operations

这并不容易，但运维就有机会扭转局面。那么，如何为你的「DevOps Jedi」寻找成功的契机？

引用自迪斯尼，显然所指的是开发/测试/运维团队。

在该会议上，笔者没有做任何记录，因为不愿意错过 Jason 的每一句话。显而易见，他不可思议的星球大战理论，和前两个月上映的《星球大战7》遥相呼应，但即使没有这部电影，他的演讲仍然会让人耳目一新。

笔者不清楚这周是否有人更明确地揭示组织中的繁文缛节、官僚机构、silos 和内战的普遍现状。

但这显示出 Jason 的诚实和热情，他说：「一切都尚待改变」。这让在座的所有人都摩拳擦掌，想要带着这份触动和灵感回归自己的团队。

就像许多人已经多次指出：没有哪种方式是容易的。DevOps、敏捷方法、持续集成/测试/部署/交付都很艰难。有时说，「随时都可以开始」，但这远远不够。这些变化带来的价值并非一蹴而就。

正如 Jason 所说，你需要被启发。如果缺乏灵感，我强烈建议大家来听听 Jason 的演讲，或许能激发你的相关思考。

持续交付的架构设计

Jez Humble，Author，Continuous Delivery

「在座的有做持续集成的吗？」，几乎所有人，1000名观众，都在举手。「谁可以在发现 bug 的10分钟内解决故障？」大家笑了笑，放下了手。「你应该可以通过按钮就能从发布转到生产状态。每一个构建中的更新，而每一个版本都是候选版本……软件应该永远处于可检验状态，并且始终可部署。开发者必须从一开始就关心这些内容。DevOps 可能无法保证其安全性、可靠性和部署性。你必须尽早地构建这些内容。我们必须追溯到1970年代以来，我们所了解软件开发的一些非常实用的内容。大多数独角兽也只是性能达标的马而已。」

关于 DevOps 定义的模糊性问题对笔者而言问题不大，但笔者同样了解对于缺乏具体的、普遍能接受的定义会让一些人抓狂。所以不足为奇，笔者也很欣赏 Jez Humble 对持续交付（CD）的定义：

全球顶级专家为你解读：什么是真正的 DevOps？