【编者按】本文是 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 官方博客
