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

日期:2016-5-25作者:Richard Gerdis来源:TechTarget中国

DevOps   敏捷开发   

如今的IT部门存在一个矛盾:敏捷开发者希望可以快速部署常规软件,而运维团队则优先考虑稳定性。开发和运维不同的成功指标使得每个团队都有自己独立的目标。两个团队缺乏沟通使问题更加复杂:开发团队难以觉察到目标环境的变化,而运维团队则不清楚开发团队到底在做什么。

无论具体情景是怎样的,这个问题都说明了如今很多组织都面临技术上的“对峙”。从IT的角度看,运维有责任在复杂的系统基础设施中保持其稳定性,所以规避风险成为他们偏爱的方式也不足为奇。然而从另一个角度考虑,开发团队如今配备了基于云计算的自动化工具,有办法完全绕过运维的障碍。

直面问题

一般而言对流程和规范化实施进行限制有助于运营上的业绩表现——即获得更好的业务成果,那么“稳定性重于处理数量”是一种理性的权衡。但是不要被这种刻板的流程误导,在由CA Technologies委托进行的一项全球调查 “拼装DevOps拼图”中表明,速度和质量并不是相互矛盾的。

调查显示,如今亚太及日本地区的大多数组织(69%)已经实施了DevOps,相比之前的20%有明显提升。而其中15%的DevOps实施者已经达到了 “大师” 级别。

“DevOps大师”更有可能表示他们的数字化举措对竞争力、客户维系和营业额及利润有所贡献。全球范围内,成熟采用DevOps的组织收入增加的可能性是一般组织的2倍,利润增加的可能性是一般组织的2.4倍。

在亚太及日本地区,相比那些未采用DevOps的组织,DevOps大师们:

  • 提高客户维系率的可能性是未采用DevOps者的2.2倍
  • 赢得更多客户的可能性是未采用DevOps者的2倍
  • 提高市场份额的可能性是未采用DevOps者的 3倍
  • 增加客户利润率的可能性是未采用DevOps者的2.3倍
  • 获得新收入来源的可能性是未采用DevOps者的2.2倍

理解DevOps ——寻求平衡

IT运维的理想状态是能够通过快速引进高质量软件而不断推动业务创新。维持平衡则意味着要消除任何可能会破坏这种状态的障碍。

严格和标准化的运维能够实现这些目标,但不止步于此。在项目开发阶段,更快速度和更多支持的需求(配合大部分的资金投入),通常会优化应用实现更快交付,但这是以牺牲其他因素为前提的。这会导致有更多的系统难以得到维护和支持,增加运维成本上的压力。当然,只有当开发人员一味提高生产力却不对整体失衡负责时,情况才会变得更糟。

为了维持平衡,使IT部门恢复正常的运行状态,跨职能部门必须而采用DevOps的方法,将分歧放到一边。这意味着运维团队需要从幕后走到台前,帮助提高应用的质量,尤其是那些正在开发、测试和部署的应用。而对于开发团队,他们则需要将自我意识放到一边并学会接受,因为弹性、可维护性、可扩展性和安全性不一定总是最重要的,他们需要帮助来整合这些要素。这同时也说明每个人都需要站在客户的角度考虑,才会创建出更容易支持客户的应用。

尽管DevOps被视为推动企业敏捷性和紧跟客户需求的关键因素,然而在亚太及日本地区,只有一半多(52%)的受访者实施了 DevOps并具有完善的DevOps战略和目标。另外,该地区44%的DevOps采用者仍旧忙于处理安全与合规性措施工作,从平台支持和风险管理的角度来看,大多数DevOps活动仍未得到良好支持。除此之外,尽管87%的受访者认为企业利益相关者培训很重要,85%的受访者意识到要在IT内部保证足够的业务优先知识,只有31%的DevOps采用者完成了这几步。未能成功促进团队合作仍然是DevOps取得成功的重大障碍。亚太及日本地区的受访者认为,打破开发团队和运维团队之间的文化壁垒是最具挑战的任务,仅有26%的受访者实现了IT文化和谐。

采用DevOps将取得成功

当然,DevOps的成功不仅仅是依靠双方击掌合作就可以实现的。我们仍然需要高层去引导实施,因为他们可以从文化层面上进行深刻变革。企业非常需要这样的高层,他们能够围绕共同的目标将每个人团结起来,无论是对于那些热衷于业务问题的运维工程师还是分析师,使他们能够共同努力去解决问题。这一举措将会确保“生产至上”的文化与“持续的完善”紧紧相连,进而保持DevOps的稳定。

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

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

作者>更多

Richard Gerdis
Richard Gerdis

CA Technologies 亚太及日本地区开发运维副总裁

SOA开发>更多

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

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

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

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

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

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

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

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

相关推荐

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

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

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

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

  • 持续DevOps文档:是必需的

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

  • 避开软件容器:如何探索DevOps

    Bert Jan Schrijver,荷兰JPoint Java软件工匠,也是JavaOne大会的演讲者,他回答了SearchSoftwareQuality的有关DevOps的问题,并且回答了为什么有时应该忽略传统习惯。

技术手册>更多

  • 2011年SOA精彩内容汇总

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

  • SAML技术手册

    安全是所有Web项目在设计时都要考虑的一个重要因素。无论是选择最短口令,决定何时使用SSL加密HTTP会话,还是通过自动登录cookie来识别用户,都经常要付出重大的设计努力,以保护用户的身份信息和他们可能存放于Web站点的其他资料。糟糕的安全性可能带来公关灾难。下面我们就来具体看一下SAML在这里所起到的重要作用。

  • REST开发者RESTful资源指南

    维基百科把表述性状态转移(Representational State Transfer ,REST)定义为“分布式超媒体系统、如万维网的一种软件架构形式”。Web服务的RESTful方案被广泛视为SOAP的一个更简单的替代方案。许多大型的Web服务提供商如亚马逊、Twitter和谷歌都在广泛地使用它。在这本技术手册中,我们将为您提供一些RESTful资源和技巧。

  • 开源PaaS技术手册

    开源业界向来不太平,关于诸多技术的开源未来足以让很多粉丝兴奋躁动起来。商业软件开始揉进开源技术,开源技术也成为IT大佬们得基础架构,这一种趋势蔓延的缓慢有有力。在广告漫天飞得云计算中,开源的分量有多重?是否走向云端就意味着走向开源?开源的PaaS如何选择?如何为开源项目选择PaaS厂商?哪些服务平台值得我们关注,下面我们一一来揭晓。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算