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

以下为译文：

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

Day 1

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

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

关键人物：

Ross Clanton， Director
Heather 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， USAA
Dibbe 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，在移动端、分布式、主机和其他技术中使用精益和敏捷技术。」

效果如何/strong>

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 的成本远远超过早期，在进入客户的手中之前。

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

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

也许，正是因为 Jez 根据结果来定义 CD 才使得其如此受欢迎，而并非采用单一指令性的全有或全无方法。

笔者不清楚你们中有多少人是 Jez Humble 的粉丝（我们当中倒是有很多）。然而，正是这种感觉，每次他演讲或写一本新书，整个世界都为之疯狂。

Day 3

大型机应用程序的测试自动化

Rosalind Radcliffe，Distinguished Engineer，Chief Architect for DevOps and CLM，IBM

关于反馈

Elisabeth Hendrickson，VP of Engineering， Pivotal’s Big Data Suite

「更多的测试者不等于质量更好」，避免：反馈流污染、误 警/故障、失真、丢失信息

原文链接：http://www.tuicool.com/articles/YV7vqmV

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8793 人正在系统学习中 相关资源：Scrum敏捷软件开发_敏捷开发-专业指导文档类资源-CSDN文库