三种实现敏捷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中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

SOA开发>更多

  • 故障注入注定要成为软件专业人士的必备技能

    尽管云改善了企业迅速发布高质量、高能力应用的能力,但专家警告说要小心这些应用会变得太复杂,难以进行人工测试。

  • 容器与微服务要“联姻” 你对它们够了解吗?

    在虚拟化和云计算领域,容器大概是发展最快、最广为令人兴奋的技术了,微服务则紧随其后。如果把这两大技术结合起来会碰撞出怎样的火花呢?

  • 事件驱动框架和SOA在空军的应用

    空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。

  • HTML5促进企业移动化服务走向极致

    在企业困扰于传统移动化方式过于复杂时, HTML5凭借其天然的跨平台特性,乘势而起并逐渐得到企业的关注。可是,由于HMTL5标准建立时间不长,展示性能及稳定性更是需要和浏览器有一个良好的兼容,除此之外企业更是缺乏实际应用经验,所以基于HTML5技术的企业级服务市场还处于一片初创状态。

相关推荐

  • 对于orchestration而言 ALM和DevOps至关重要

    为了确保开发和运营能够持续同步演进,开发者需要理解DevOps与orchestration之间的差异,对自己的开发和运营策略进行重新思考,并且对重要的新兴趋势保持警觉。

  • 开发运维一体化(DevOps):协作是成功的保障

    如今的IT部门存在一个矛盾:敏捷开发者希望可以快速部署常规软件,而运维团队则优先考虑稳定性。开发和运维不同的成功指标使得每个团队都有自己独立的目标

  • 中国市场DevOps应用趋势分析

    为了解决开发人员与运维之间的协作问题,从而提升工作效率,DevOps方法论应运而生。几年的发展,DevOps现在国内市场的应用情况如何?如何才能取得DevOps实施的成功?

  • 持续DevOps文档:是必需的

    文档和管控的流程仍旧是防止企业陷入困境,保证员工不丢掉工作的有效方式,让文档和管控成为进展缓慢的同义词是因为一些历史原因。软件版本引入的相同的自动化也适用于文档领域。

技术手册>更多

  • SOA管理

    SOA管理是经常谈论的一个话题,不管你的组织开始SOA多长时间,SOA管理都是需要多加注意的。首先我们需要弄清SOA管理与SOA治理的区别。

  • 2011年SOA精彩内容汇总

    时光飞逝,转瞬已经步入2012年,在十二月份,SesrchSOA.com.cn对于相关的一些领域做出了总结和展望,希望对于读者具有一定的指导意义。同时,编者也在这段时间内,对于过去一年中网站上的原创内容进行了一次全面的回顾,为大家总结了一些较为实用的技巧和分析,内容涉及SOA现状以及发展、SOA实操技巧、热门话题云计算以及Web服务。下面我们就来看看这些内容。

  • REST结构全面解析手册

    REST (Representational State Transfer)是代表状态传输的缩写。它代表了分布式超媒体系统的体系结构风格,该风格是Roy Field在他的论文中定义的。它是一种针对网络应用的设计和开发方式,可以降低开发的复杂性,提高系统的可伸缩性。REST提出了一些设计概念和准则。本手册将为您作出详细讲解。

  • 评估成功:衡量BPM的利益

    我们已经在典型的商业预告中听到了一种变奏曲,即不可以改变或者改进无法衡量的东西。没有什么比BPM更能体现这句话了。在这本技术手册中,我们将提供可靠的最佳实践,精确衡量BPM的发展。专家将就如何削减BPM复杂性以及将BPM和重要的客户关系管理流程整合。同样,我们也会提供一些BPM趋势、愿景和技巧。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算
【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(断言)语句找出配置错误并执行最佳实践。最后,采用自动化持续集成测试的同时也要利用静态代码分析。