【编者按】本文是 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」那个过程分享的直率令人感动。摘录：
Ross 说：
Target 的发言奠定了本次会议的主题，不仅仅是分享其发展和运营团队的成功，还讲述了不久前的糟糕境况。虽然很多人会说围绕 DevOps 的原则已是旧谈，但成功 DevOps 的举措所带来的收获，让整个过程中的挫折和失败也都变得有意义。
企业 DevOps：由 Metrics、Empathy 和 Empowerment 所驱动的转型过程
Jody Mulkey，Ticketmaster CTO
USAA 和 IBM 的 DevOps 及创新
Michael Bueche， AVP IT Operational Excellence， USAA
Dibbe Edwards， VP Development， DevOps for Hybrid， IBM
当引入一个 DevOps 这样的大型变革到企业时，建议一步步从小处开始，贪多嚼不烂。Michael Bueche 详细地讲述了 USAA 在推向市场前158天的历程，及产品90天后部署敏捷方法的经历，以及当前的每周目标。
Dibbe 说：
在 Michael 分享之前，笔者从来没有听说过「热炉」这个比喻，的确非常适用于 DevOps、敏捷或现代化软件交付。反馈回路必须缩短，才能按时完成和防止生产过程的问题。
赋予开发/测试团队可以按需独立提供扩展性环境的能力，然后再更早更频繁地进行检测，获取 bug 状态的快照，使开发人员可以很容易地重现 bug 并予以消除。就像 Jez Humble 所说的——先在自己的环境下搞好！
DevOps 如何实现精益应用开发
Carmen DeArdo， DevOps Technology Leader， Nationwide Insurance
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。
尽管这个讨论专为嵌入式软件行业设计，但该组的讨论仍适用于大型机到移动端，以及介于两者之间的平台。这些天每个人都在说，交付生命周期晚期发现 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
关于 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
如果迪士尼的 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 官方博客