【编者按】本文是 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? 技术分享 第1张

迪斯尼的 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? 技术分享 第2张

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

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

Day 3

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

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

全球顶级专家为你解读:什么是真正的 DevOps? 技术分享 第3张

全球顶级专家为你解读:什么是真正的 DevOps? 技术分享 第4张

全球顶级专家为你解读:什么是真正的 DevOps? 技术分享 第5张

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 说道。我们对软件的依赖,可以促进社会交往或帮助移动商务交易,会迅速移动到同时取决于在复杂医疗设备、汽车内置的软件。

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

全球顶级专家为你解读:什么是真正的 DevOps? 技术分享 第6张

关于反馈

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

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

全球顶级专家为你解读:什么是真正的 DevOps? 技术分享 第7张 全球顶级专家为你解读:什么是真正的 DevOps? 技术分享 第8张

全球顶级专家为你解读:什么是真正的 DevOps? 技术分享 第9张

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

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

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