在大年夜多半的团队中，开辟、运维之间有着一系列冲突和博弈。

有人说，DevOps 的出现闪开辟和运维不再相爱相杀，大年夜此一路手牵手，高兴得 coding 和捉 bug。

但也有人说，DevOps 就是开辟吃掉落运维。

是如许的吗，不合的团队构造会对 DevOps 的成长有何影响?

请看下文，你会有本身的谜底。

引言

组织中提议任何DevOps相干晃荡的重要目标是改良对客户和营业的价值交付，而不是降低成本，晋升主动化程度，或者大年夜设备治理中驱动任何工作;这意味着不合的组织可能须要不合的团队构造才能开展有效的开辟和运维协作。

提纲

哪些DevOps团队构造或拓扑合适组织取决于几件工作：

• 该组织的产品组合：较少的产品使得协作加倍轻易，因为根据康威定律，这种情况下各自自力的小团队较少。
• 技巧引导力典范围，力度和有效性;Dev和Ops是否有合营的目标。
• 一个组织是否具有将IT运维部分大年夜“硬件机架”和“设备办事器”改变为与价值流实际一致的需求或才能，以及软件研发团队是否定真对待来自运维方面的请求。
• 该组织是否具备带头解决当前运维问题的才能或技能。

当然，这琅绫氰述的主题有所不合;拓扑和类型是作为参考指南或启发，协助您来评估哪些模式可能是合适的。实际上，将多种模式或一种模式转化为另一种模式的组合往往是最好的办法。

那么DevOps的团队构造若何成长呢? 显然，没有任何合适每个组织的幻想构造或团队拓扑。然而，对于团队构造来说，参考少数不合的模型是有效的，个一一些模型与某些组织的合适度更高。经由过程摸索这些团队构造(或“拓扑”)的优缺点，推敲到康威定律，我们可以肯定可能对我们本身组织中DevOps做法最有效的团队构造。

这些DevOps拓扑中的大年夜多半已经在其他处所描述过;特别是CollabNet的Lawrence Sweeney在对Ben Kepes博客的评论中谈到了有关我在这里所描述的反类型B(自力的DevOps团队)，

类型3(运维作为基本举措措施办事)以及类型1(开辟和运维协作)。DevOpsGuys列出了十二个DevOps反模式，Jez Humble，Gene Kim，Damon Edwards(以及很多其他人)也曾经说过类似的工作。我在这里添加了三个额外的“拓扑”，我没有看到或听到于此相干的一些评论辩论(共享运维，DevOps-as-a-Service和临时DevOps团队)。

DevOps 反类型

A: Dev和Ops分别 B: 零丁的DevOps团队 C: 开辟不须要运维 D: 对象团队 E: 体系治理员 F: 开辟包含运维 G: 开辟和DBA分别

反类型 A：Dev和Ops分别

这是经典的“扔过墙去”式的Dev和Ops分别。这意味着需求点可以在前期被提掏出来(DONE意味着“功能完全”，但不克不及在临盆中应用)，并且软件的可运维性受到伤害，因为开辟者没有运维相干的高低文信息，运维人员没有时光或者动力介入到开辟者中，在软件上线之前解决问题。

我们都知道这种拓剖攀类型不好，但我认为有很多类似的拓扑构造很差;至少我们清跋扈反类型A(开辟和运维分别)是一个问题。

反类型B：零丁的DevOps团队

零丁的DevOps团队(反类型B)平日来自经理或履行官，决定他们“须要一点这个DevOps的工作”，并启动一个“DevOps团队”(可能是被称为“DevOp”的人)。DevOps团队的成员敏捷形成另一个集团，使Dev和Ops比以往任何时刻都加倍分开，因为他们须要保卫本身的角色，技能和对象集，防止本身被“蒙昧的Devs”和“恐龙般的Ops”所祛除。

零丁的DevOps团队真的有意义的独一的情况是，当团队是临时的，例如持续时光少于12或18个月，其明白目标是使Dev和Ops更慎密地结合在一路，并被明白地授权的时刻，当这段时光以前，这个团队是多余的。这就是我所说的类型5 DevOps拓扑。

类型8适应性：容器可以工作得很好，但要留意反类型A，Ops团队估计会运行Dev发出的任何内容。

反类型C：开辟不须要运维

这种拓扑构造由开辟人员和开辟经理之间的无邪和傲慢相结合，特别是在新项目或体系开端时。假设Ops如今是过时的工作(“我们如今有了Cloud，对吗?”)，开辟人员大年夜大年夜低估了运维技能和晃荡的复杂性和重要性，并认为他们可以不须要运维，或者在闲暇时光就可以搞定运维做的工作。

这种反类型C DevOps拓扑可能最终须要Type 3(Ops as IaaS)或Type 4(DevOps-as-a-Service)拓扑，当他们的软件变得加倍深刻和复杂，运维开端须要开辟工作“(又称编码)”的时刻。如不雅如许的团队熟悉到运维作为一个重要和有价值的学科，并且承认其对于软件开辟的重要性，他们将可以或许避免很多苦楚和不须要的(和相当根本的)运维缺点。

反类型D：DevOps作为对象团队

在不影响当前开辟团队的速度(实现用户故事)的情况下，成立一个DevOps团队，负责安排管道，设备治理，情况治理等所需的对象。同时，Ops的人们持续孤立工作，Dev团队持续将他们的应用法度榜样“放在墙上”。

固然这个专门团队的结不雅在改进的对象链方面可能是有益的，但其影响是有限的。在应用法度榜样开产生命周期中缺乏早期运维的介入和协作，根本问题依然存在。

　　推荐阅读

　　如何根据数据冷热程度分层存储，让HDFS更高效？

主题简介：SSM体系架构设计HDFS优化存储功能讲解SSM体系应用处景分析一、背景跟着大年夜数据技巧相干技巧的成>>>详细阅读

本文标题：DevOps，就是开发吃掉运维？

地址：http://www.17bianji.com/lsqh/38395.html

 1/2    1