全球顶级专家为你解读：什么是真正的 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， 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，在移动端、分布式、主机和其余技术中使用精益和敏捷技术。」

效果如何？

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 ——企业意识

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）的定义：

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

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

Day 3

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

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

Rosalind Radcliffe 拉开 DOES 最后一日的序幕，她用 IBM 公司26年的工程师生涯体验和经过虚拟化改变大型机系统的方法，很快打动了在场全部人。

相同的方法也用于 Skytap 和许多合做伙伴规定。在必要时，任何受限于硬件的任何开发和测试团队，都难以得到甚至不可能得到访问。

Rosalind 的主题演讲很是出色，她做为是众多企业演讲者的一份子，向全部人证实 DevOps 实践正在顺利地被引入大型主机层面。

永恒的魅力？：容器与软件供应链发生碰撞

Joshua Corman ，CTO， Sonatype
John Willis ，Director of Ecosystem Development， Docker

「IT运维已经迷失了20年时间；是 DevOps 让咱们成功返航」——John Willis

「我想要拯救生命。咱们对软件的依赖程度愈来愈大，是由于嵌入式的医疗设备、汽车、家——我想要这些东西运做起来。」——Josh Corman

「咱们须要为编码构建代码。若是你并不热血沸腾，不如选择离开」——John Willis

若是迪士尼的 Jason Cox 得到「最佳会议奖」，那应该是实至名归，尤为是做为星球大战迷的笔者，但这实际上这份容易也能够颁给 Joshua 和 John 的「永恒的魅力」主题演讲。

当 Joshua 说，他不仅是热爱软件或 DevOps，这是在挽救生命，你会相信他对于这份事业的热爱。

用2010年在海地和智利的地震来举例，能看到架构质量之间的差别，Joshua 指出，当海地的7.0级地震致使23万人丧生时，智利更强的8.8地震只形成279人死亡。

这二者之间的差距使人难以置信，其中一个缘由就是智利严格的建筑法规，而海地正缺少这样的规范。

「咱们须要创建编程的规范」，Corman 说道。咱们对软件的依赖，能够促进社会交往或帮助移动商务交易，会迅速移动到同时取决于在复杂医疗设备、汽车内置的软件。

那些负责保证这些链接设备正常运行，并防止黑客攻击和故障的代码，更有责任保证工做质量。

关于反馈

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

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

从开发者、测试者、运营、软件的用户/客户、安全性到系统自己，DevOps 须要每一个来源的快速反馈，并结合咱们所听到的采用反馈的组织所创造的优秀事迹。

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

本文系国内 ITOM 行业领军企业 OneAPM 工程师编译整理。咱们致力于帮助企业用户提供全栈式的性能管理以及 IT 运维管理服务，经过一个探针就可以完成日志分析、安全防御、APM 基础组件监控、集成报警以及大数据分析等功能。想阅读更多技术文章，请访问 OneAPM 官方技术博客
本文转自 OneAPM 官方博客