我们为什么要争夺DevOps?

尽管IT界似乎急于接受DevOps的概念,但并不是每个人都对它的真正含义表示同意。转向仍然有些模糊的事物可能会在您的组织中发出警报,但是您可能无力等待实施这种开发实践。

7个迹象表明您在做Devops错误
Salim Virji通过Flickr

在过去的三年中,DevOps从一个鲜为人知的术语变成了业内每个人的口号。在诸如Etsy和Amazon之类的所谓“网络规模”公司的引领下,DevOps现在已在整个企业市场中广泛普及-似乎每个人都想做。 

只有一个问题:到底是什么 DevOps?有些人将其描述为重新塑造的敏捷开发实践。其他人则将其描述为一种新的支持工具,该工具可以自动完成组装,部署和操作应用程序的过程。还有一些人将其称为文化变革。换句话说,这是一个模棱两可的术语,可以用许多不同的方式来解释。 

在过去的几年中,我一直在DevOps内外工作,有时对有关该主题的无休止的讨论感到失望;人们似乎常常宁愿讨论DevOps,也不愿实际做一些事情来实现它。 

尽管如此,尽管存在歧义,但还是有一些重要的东西。并且了解推动DevOps竞赛的因素以及参与(或确实要赢得)竞赛所需的条件对于未来的成功至关重要-不仅是成为顶级IT组织的成功,而且是成功的关键。公司能够在不断发展的全球经济中竞争的感觉。 

鉴于我在DevOps方面的经验以及它对IT运营的未来的重要性,当我遇到有关该主题的见解时,我会给予很多关注。最近,我遇到了一个 采访达娜·加德纳(Dana Gardner)和库尔特·比特纳(Kurt Bittner),专注于DevOps的Forrester分析师。我发现它是如此发人深省,我想分享它的一些亮点,以及我对它提出的观点的看法。 

敏捷发展还不够 

如上所述,有些人将DevOps作为一种形式 敏捷开发,或者是敏捷实践的扩展。敏捷开发已将软件开发从冗长的瀑布式过程转变为一种团队协作的过程,其中团队协作,专注于代码开发而不是规范编写,并且业务代表直接参与了开发过程。有人认为实现敏捷将导致开发运维,从而解决了更快交付应用程序的问题。 

正如Bittner指出的那样,不幸的是这是不正确的。首先,基础架构可用性差,阻碍了许多组织向敏捷开发转移的努力。尽管各个开发人员都可以在自己的计算机上工作,但不可避免的是,有时必须建立一个类似于生产的环境来评估集成并允许进行更强大的测试。此过程需要配置机器,而获取机器通常可能需要数周或数月的时间。因此,当尝试传统的基础架构运营方法时,即使是敏捷开发也面临着敏捷开发的挑战。 

[有关的: 深入探讨DevOps] 

但是,除此之外,还有一个更大的问题:即使敏捷开发能够顺利进行并可以获得足够的资源,在所有太多的IT组织中,开发代码仍会移交给一个运营组,该运营组将继续通过旧的手动流程执行部署和管理。最后,应用交付的整体速度几乎没有改变。 

跨应用程序生命周期的敏捷 

正如Bittner所言,因此缩短整体交付时间至关重要。这要求在应用程序生命周期的每个部分都具有敏捷性,这意味着应用程序交付链的每个部分都必须提高自己的游戏水平。除非每个小组都能快速执行任务,否则应用程序交付的速度将永远不会足够快。 

顺便提一句,虽然业务团队经常将IT视为提供足够快的应用程序和更新的障碍,但DevOps也可以对业务部门本身进行更改。作为优秀的书 精益企业:高性能组织如何大规模创新 指出,将变更交付到市场需要公司的业务部门在开发所需功能方面敏捷,响应开发团队在使用这些功能时反馈的IT要求,并提供有关先前采用客户的快速反馈交付的功能。毋庸置疑,这需要业务发起人和IT实施者之间紧密的协作。 

DevOps经常伴随的另一个“动作”是应用程序功能和体系结构的新方法,通常称为微服务。其中的关键概念是将应用程序体系结构分解为可以独立更新的多个较小的执行实体。通过实现微服务,开发团队可以避免“大爆炸”发布方法,该方法将许多新功能捆绑在一个更新中。由于每个微服务都有自己的发布时间表,因此较小的更新可以更频繁地推出。微服务仅在最近的12到18个月内出现,但是可以肯定的是,这种架构方法将对IT团队的发展产生强大的影响。 

自动化至关重要 

Bittner指出,缺少与应用程序开发和部署相关的所有IT任务的自动化,DevOps将永远不可能。正如Bittner所说: 

它的 绝对必要 没有自动化,并且没有数据驱动的可视性来了解应用程序中发生的事情,几乎没有办法快速交付这些应用程序。我们发现许多组织现在每个季度发布一次,不一定每个季度发布相同的应用程序,但是它们有一个季度发布周期。以每季度的速度,通过裤子的座椅和某种蛮力,您可以设法释放它。这很痛苦,但您可以生存。 

如果您提高时钟频率的速度快于尝试降低到每月一次的速度,那么那些手动过程将完全崩溃。今天,我们有一些组织希望每周和每天定期交付,尤其是在 SaaS的环境或基于云的环境。对于任何种类的手动过程来说,那种传送速度都是无法想象的。随着组织从季度发布过渡到更快的发布,他们必须采用这些技术。 

我目睹了IT组织在试图通过“蛮力”更快地行动时所经历的挣扎。随着对应用程序更新的需求越来越大,压力和压力越来越大。不幸的是,所有太多的IT组织都发现自己“太忙了”,无法投资自动化。对他们而言,只有在每个人都不可避免地意识到现有流程无法达到预期的情况下,才会向DevOps迁移。可惜的是,太多的员工逃离了环境,因不切实际的需求而精疲力尽。然后,该组织面临双重挑战:实施自动化的需求,但发现自己缺乏熟悉现有流程并因此最适合将其自动化的经验丰富的人才。 

以后,我将有更多关于此问题的发言,但是Bittner强调的一点是,自动化并不是“好事”,它是DevOps的基础。 

低层执行,高层赞助 

Bittner讨论的向DevOps迁移的一方面是需要高级赞助。我在这里解释他的说法,但概念是端到端的自动化要求工作在不同的IT团队之间畅通无阻;换句话说,DevOps突破了组织边界。自然,大多数组织(包括IT部门)都会对此予以抵制。每个小组都有其既定的做事方式,并且不愿改变。 

因此,DevOps计划始于低层人员的基层努力,仅凭孤立的实验就不可能取得成功。 DevOps原型发布后,各个小组将确定妨碍全面实施跨组织自动化的原因,并将其作为进一步发展的不可逾越的障碍。  

这样做的主要目的是,如果没有足够高级的人员可以使所有小组向他或她汇报,DevOps就无法成功,并且该人显然会在时间和金钱上赞助DevOps投资。 

另一方面,如果没有低水平的人员准备并渴望使其工作,DevOps就不会成功。试图将中级管理视为DevOps成功的主要障碍,但是我看到很多IT人员不愿意进行任何更改;他们已经将当前的系统淘汰了,为什么还要麻烦一些新的东西呢? 

然而,这种态度并不普遍。在每个组织中,都有其他人不耐烦地改变事物,并对参加的机会感到兴奋。这些人应该参与早期的DevOps实施工作,并应率先将其推广到整个大型组织中。一旦达到临界质量,即使是坚持不懈的泥潭也将发现动量是不可抗拒的,他们将需要参加该计划-或离开。  

一个警告 

很明显,我喜欢Bittner的采访,发现他的观点令人信服。不过,我想指出我在采访中要注意的一个问题。在讨论企业IT团队如何转移到DevOps时,他指出这通常是逐步采用的过程–首先是自动化基础架构配置,然后是持续集成和自动化测试,最后是组织重组到包含每个IT成员的面向产品的团队纪律以及与谁合作以加快整体应用程序交付。这是有道理的-随着他将一个阶段的结果内部化,组织可以转移到应用程序交付的下一个瓶颈,并逐步实施完整的DevOps解决方案。 

根据Bittner的说法,从第一阶段过渡到第三阶段通常需要数年时间。我要在这里警告。从我的角度来看,企业IT组织没有很多年。这 第三平台的压力过大,并且在每个行业中,初创企业和一些老牌企业都在充分利用“第三平台”的道路上。进行长达数年的DevOps之旅会使IT组织(及其所属的公司)面临危险并容易受到破坏。这并不是要批评Bittner,而只是要指出,当今的商业环境并不足以或无法接受多年的努力。 

无论您是属于DevOps之路的IT组织的一员,还是正在考虑如何应对这一新流行语的组织的一员,我预计您都会发现DevOps背后的推动力是不可避免的。简而言之,对应用速度的需求是当今“软件正在吞噬世界”经济的一个因素,每个IT组织都需要做出回应。 Bittner的访谈是有关趋势和入门方法的出色入门,您应该自己阅读整篇文章。

版权© 2015 IDG通讯,Inc.