开发运维一体化(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的问题,并且回答了为什么有时应该忽略传统习惯。

技术手册>更多

  • 企业IT消费化指导手册

    IT消费化是个人和商业使用的设备和应用程序的混合体。学习如何保持在前沿技术的最前端,了解工作场所内部或外部的关于IT消费化的挑战与威胁。虽然企业可以掌控在内部建立的安全机制,但是这是关于个人拥有的设备的事情,所以它需要用新方式去思考。本指南解释了IT消费化,帮助企业在IT消费化中生存,并叙述了IT消费化的影响。

  • 全面应对SOA开发挑战

    面向服务的架构是一种基于可以重用的服务的,新的开发应用的架构体系。 近年来,企业界对于SOA的需求越来越急切。为了满足这样的需求,一系列的SOA基础架构产品被推出。在一个包含各类应用的复杂的IT系统中, 要使用适配器并且在一个符合业务需求的流程中将各类应用串连在一起是一个非常困难的事情,但是现在的SOA平台将困难转变成了容易。

  • 业务流程执行语言BPEL(升级版)

    BPEL即业务流程执行语言,是一种使用XML编写的编程语言。用于自动化业务流程,也曾经被称作WSBPEL和BPEL4WS。广泛使用于Web服务相关的项目开发中,优点为具有可移植性和有效保护了投资。

    BPEL是一门用于自动化业务流程的形式规约语言。用XML文档写入BPEL中的流程能在Web服务之间以标准化的交互方式得到精心组织。这些流程能够在任何一个符合BPEL规范的平台或产品上执行。 所以,通过允许顾客们在各种各样的创作工具和执行平台之间移动这些流程,BPEL使得他们保护了他们在流程自动化上的投资。

  • 业务分析和监控指南

    在SearchSOA.com.cn之前的一些技术手册中,我们已经多次对BPM作出介绍。涉及了BPM的相当多的内容。在这本技术手册中,我们从着重关注业务活动分析和监控部分的内容。虽然BPM有益于企业的流程健康发展,但也并不是所有的企业都适合BPM。在确定了这些内容之后,我们还要考虑如何进行业务活动分析和监控。下面我们就来看看如何一步一步的实现BPM卓越中心。

TechTarget

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