三种实现敏捷DevOps的方式

日期:2013-11-8作者:James A. Denman

DevOps   敏捷DevOps   敏捷开发   

【TechTarget中国原创】

DevOps(开发运营)运动在修补残缺的部署流程方面取得很大进步。从表面上看,为开发者提供的解决方案是更多地站在运营者的角度去思考,反之亦然。然而,这种表象级的想法也只能到这里了。需要具体的、可操作的步骤去克服技术方面的欠债,向Amazon(顺便说一下,今年5月该公司的平均部署时间间隔为11.6秒)之类的应用开发组织的效能靠近。

在Agile 2013上,演讲者Gene Kim展示了一个在应用开发和部署流程中做出可操作改变的可行框架。Kim是Tripwire的创始人,也是该公司2010年夏以前的CEO。现在,3年之后,Kim出版了一本小说,名字叫做《凤凰项目》,书中解释了如何给死板的开发组织带来灵活性。这本小说生动描述了Kim对DevOps现象14年的研究当中学到的3个主要概念。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

技术手册>更多

  • 智能BPM与业务流程工具

    Gartner认为iBPM要比运营型智能平台更优秀,表现在以下几个方面:iBPM套件提供更好的工作流,适配性案例管理以及结构化流程协调能力。

  • 云BPM新常态解析

    云端业务流程管理已经不再是什么新鲜事,更不再是什么可怕的方法来管理重要的业务流程。现在,它已经普遍被认为是一种新常态。组织已经从这一技术中获益,使它来更有效地访问和管理企业信息。

  • 企业IT集成指南

    随着云技术的不断采用,现代企业都面临着重大的集成问题。现在已经不再是把企业内部的数据和应用简单地缝合在一起,企业IT现在面临着整合着外部与内部信息的难题。

  • API开发与管理大作战

    2014将会是API管理方法新旧PK的一年,据Delyn Simons说,她领导了Mashery开发者的外展团队。应用编程接口(API)的主流化和私有化在新的一年也将掀起波澜,她在波士顿“Future Insights Ultimate Developer Event 2013”大会上预测说。

【TechTarget中国原创】

DevOps(开发运营)运动在修补残缺的部署流程方面取得很大进步。从表面上看,为开发者提供的解决方案是更多地站在运营者的角度去思考,反之亦然。然而,这种表象级的想法也只能到这里了。需要具体的、可操作的步骤去克服技术方面的欠债,向Amazon(顺便说一下,今年5月该公司的平均部署时间间隔为11.6秒)之类的应用开发组织的效能靠近。

在Agile 2013上,演讲者Gene Kim展示了一个在应用开发和部署流程中做出可操作改变的可行框架。Kim是Tripwire的创始人,也是该公司2010年夏以前的CEO。现在,3年之后,Kim出版了一本小说,名字叫做《凤凰项目》,书中解释了如何给死板的开发组织带来灵活性。这本小说生动描述了Kim对DevOps现象14年的研究当中学到的3个主要概念。

根据Kim的说法,相对于没有开始DevOps计划的组织,那些参与DevOps计划达到或超过12个月的组织展现出了显著的效能提升。Kim说高绩效的DevOps团队会更加敏捷(部署频率高30倍,周期时间快8000倍)且更可靠(成功变更次数最多可增加1倍,响应时间仅是平均响应时间的一小部分)。

组建一支高绩效的DevOps团队需要3个要素,Kim说。在其最新的小说中,Kim将每一个要素阐述为“3种方法”之一,由他的神秘大师展现给领导者。这三种方法可归结为过程流、反馈及持续学习。

方法1:流

在构建过程流中,Kim概括了5项主要规则。首先,理解工作流。如果缺乏理解,任何变更都会有随机效应。第2和第3,永远都要增加流,永远不要把缺陷传给下游。如果你把生命周期管理流程想象为一条河流,就很容易看清为了修正而逆流回溯项目有多困难,尤其是在过程迅速流转的时候。

第4,永远都不要让本地优化导致到全局的退化。在内部开发组织各自为政的大型组织当中这是很棘手的。每一个团队都希望自己的部分成为演出的明星。然而,让一切保持平衡对于整个系统来说好处要大得多。最后第5点,对整个系统要有深刻的理解。这一点跟第1点相呼应。你必须理解每一部分的细微差别,知道它们是如何相互适应的,这样才能维持一切平衡有序。

从这些规则当中,Kim发现了一个改进开发时间的重大方法。其诀窍是找出流程瓶颈然后打破它。Kim引用了Eliyahu Goldratt《目标(The Goal)》里面自己喜欢的台词,说的是“任何地方的变化都能带来改进,但是在瓶颈之处那只是一种幻觉。”也就是说,整个部署流程链的速度取决于最慢的环节。

Kim说大型软件组织有6个领域是最有可能成为瓶颈的:环境创建、代码部署、设置以及运行测试、过度紧密的架构、开发及产品经理。Kim说,根据2012年Puppet Labs的一项调查,组织当中两个最常见的展现出一致速度和品质的链环是基础设施版本控制(89%采用版本控制)及自动部署流程(82%对部署进行自动化)。

方法2:持续反馈

第2种办法是反馈,也有4条重要规则。首先,理解并响应所有客户的需求,包括内部和外部的。其次,缩短并放大所有的反馈环。Kim说这条规则效仿流量丰田精益生产线,后者让任何一名员工在看到有缺陷的情况下均可停止生产线。第3,从源头建立品质。意思是说积极地将品质注入到一切东西上。最后是第4点,在需要的地方创建并嵌入知识。

Kim建议把脆弱的服务返还给开发者,让他们对服务的稳定性负责。为了说明为什么这么做有效,Kim引用了BrowserMob CEO Patrick Lightbody的话,他发现“凌晨2点叫醒开发者时缺陷被修复的时间就会前所未有的快,”当然,他们并不是为了激怒开发者而在半夜叫醒他们。除非代码出错开发者才要凌晨2点起床。这当然会激发开发者写出高质量的代码。“这可以归结为有难同当。”Kim解释说。

Kim还建议为各种指标设立简单的自动化监视器。比方说,开发者也许可以建立简单的增量计数器来跟踪成功及失败登录尝试。这一监控可为团队提供验证服务运作情况的反馈。甚至还可以找出恶意活动。

方法3:持续学习

Kim的第3种方法是培育一种鼓励实验(哪怕要冒风险)、奖励成功、从失败中学习以及认识到重复是精通的先决条件的文化。Kim说成功组织形成了一种靠着能令自己在危险中生存的习惯不断向危险区推进的文化。

Kim援引了Netflix云架构师Adrian Cockcroft的说法。“痛苦的事情做得越多你就能让它带来的痛苦感觉越少,”Cockcroft建议说。他说自己的开发者不会回避痛苦的任务,因为他们知道这可以让大家的部署流程流畅的多。Cockcroft的方法在2011年4月得到验证,当时EC2中断导致Reddit和Quora服务停止,但是并未严重影响到Netflix—即便Netflix也一样跟EC2捆绑在一起。

Cockcroft的团队开发了一种名为Chaos Monkey的测试工具。Chaos Monkey的目的是随机禁用一些服务以便测试其他所有服务的独立性。当然这是个多少有点极端的例子,但是的确说明了尽早失败及经常失败的价值。这么做让开发组织成长,一旦应用进入生产阶段,可处置任何有可能出问题的情况。

为了坚持这3种方法,Kim提出了3点建议。首先,处处都要强制要求一致性—代码本身如此,环境和配置也一样。其次,在代码中使用Assert(断言)语句找出配置错误并执行最佳实践。最后,采用自动化持续集成测试的同时也要利用静态代码分析。