滕州住房和城乡建设局网站,沧州做公司网页的公司有哪些,个人简历模板在线编辑免费,思博企业管理咨询有限公司前言 组织中任何DevOps工作的主要目标都是改进客户和业务的价值交付#xff0c;而不是降低成本、提升自动化或者通过配置管理驱动一切#xff1b;这意味着#xff0c;为了实现有效的Dev和Ops协同#xff0c;不同的组织可能需要不同的团队结构。 概述 具体哪种DevOps团队结构…前言 组织中任何DevOps工作的主要目标都是改进客户和业务的价值交付而不是降低成本、提升自动化或者通过配置管理驱动一切这意味着为了实现有效的Dev和Ops协同不同的组织可能需要不同的团队结构。 概述 具体哪种DevOps团队结构或拓扑适合组织取决于以下几个方面 组织的产品集产品越少协同越简单就像康威定律预言的那样自然形成的筒仓就越少技术领导者的职责范围、实力和有效性Dev和Ops是否有共同的目标组织是否有能力或意愿变革其IT运维部门使其不再只是“上架硬件”和“配置服务器”而是成为真正与价值流一致的部门使运维特性为软件团队所重视组织是否有能力或技能主导运维。 当然这里列出的主题有些差异这些拓扑和类型可作为参考指南用于评估某个模式是否恰当。实际上组合多个模式或将一个模式转换为另一个模式通常是最好的方法。 那么什么样的团队结构适合采用DevOps呢显然不存在适合每个组织的神奇结构或团队拓扑。然而介绍几种不同的团队结构模型是有用处的其中一些模型比其他模型更适合某些组织。通过探索这些团队结构或“拓扑”的优缺点我们可以确定自己的组织中最适合DevOps实践的团队结构并考虑康威定律。 下面为你一一介绍DevOps实践的各种团队结构。 DevOps的反类型 了解一些糟糕的做法是有用处的我们可以叫它们“反类型anti-types”这个叫法源于我们常见的“反模式”。 反类型ADev和Ops筒仓 这是典型的Dev和Ops“各管一摊”。这意味着可以尽早声明故事点“完工”意味着“特性完成”但还没应用到生产中而软件可操作性受损因为Dev没有足够的有关运维特性的上下文信息而Ops人员没有时间或无意为了软件上线前解决问题而参与开发。 我们可能都知道这种拓扑不好但我认为还有实际上更糟糕的拓扑对于反类型ADev和Ops筒仓我们至少知道这其中寻在问题。反类型BDevOps团队筒仓 DevOps团队筒仓反类型B的形成通常是因为经理或主管认定他们“需要一点DevOps的东西”并创建了一个“DevOps团队”可能其中全是被称为“DevOp”的人。DevOps团队的成员迅速形成另一个筒仓Dev和Ops远比以往任何时候都注意保持距离因为他们要捍卫自己的老窝、技能和工具集不被那些“一无所知的Dev”和“守旧落伍的Ops”所破坏。 一个单独的DevOps筒仓只在一种情况下是真正有意义的就是该团队为临时团队存在时间不超过12或18个月其目的是为了让Dev和Ops团结起来而且很明确过了这段时间该DevOps团队就是多余的了这是我下文所说的5型DevOps拓扑。反类型CDev不需要Ops 这种拓扑诞生于开发人员和开发经理的天真和傲慢特别是当开始新项目或系统时。假设Ops现在已经成为过去“我们现在有云对吧?”开发人员严重低估了运维技能和活动的复杂性和重要性并相信可以没有他们或者只在空闲时间涉及他们。 这种反类型C的DevOps拓扑可能最终需要下文说到的3型Ops即IaaS或4型 DevOps即服务的拓扑因为他们的软件变得更加复杂并且运维活动开始占用“开发”即编码时间。要是这样的团队认识到运维作为一门学科的重要性与软件开发同等重要和有价值他们就能够避免许多痛苦和不必要的非常基本的运维错误。反类型DDevOps作为工具团队 为了“成为DevOps”而又不影响当前Dev团队的速度或者说功能点交付创建一个DevOps团队致力于部署管道、配置管理、环境管理等所需的工具。同时运维人员继续孤立工作而Dev团队继续把应用程序从“墙上”扔给他们。 尽管这个专门小组的成果就改进工具链而言可能是有好处的但其影响很有限。在应用程序开发生命周期中Ops人员未能早期参与和协作的基本问题仍然没有改变。反类型E换个名的SysAdmin 这种反类型在工程成熟度较低的组织中很典型。他们想要提高实践并降低成本然而他们并没有将IT视为业务的核心推动力。因为DevOps在行业内取得的成功现在已经显而易见所以他们想“做DevOps”。不幸的是他们没有反思当前的结构和关系存在什么差距就去为Ops团队招聘“DevOps工程师”这很难达到目的。 DevOps只是对以前的SysAdmin角色改了个名没有真正的文化/组织变革发生。这种反类型正变得越来越普遍因为为了招揽人才而无所不为的招聘人员会赶时髦寻找具有自动化和工具技能的求职者。遗憾的是人类的沟通技巧可以让DevOps在组织中茁壮成长。反类型FOps嵌入到Dev团队 组织不希望保留一个单独的运维团队因此开发团队会负责基础设施、管理环境、监控等。然而在项目或产品导向的方式中这样做意味着这些工作会受到资源限制和优先级重排的影响导致低于标准的方法和不成熟的解决方案。 这种反类型表明组织对有效IT运维的重要性和所需的技能缺乏认识。特别地开发人员将其视为一种烦恼Ops的价值因此被贬低Ops是由开发团队的管理者管理的而开发团队往往有其他的优先级事项。反类型GDev和DBA筒仓 这是反类型A Dev和Ops筒仓的一种形式在中大型公司中非常突出在这些公司中多个遗留系统依赖于相同的核心数据集。因为这些数据库对于业务而言非常重要在Ops保护伞下会有一个专门的DBA团队负责它们的维护、性能调优和灾难恢复。这是可以理解的。问题是当这个团队成为任何数据库变更的守门人时它实际上就成为频繁的小规模部署DevOps和持续交付的核心原则的障碍。 此外就像反类型A中的OpsDBA团队并不参与应用程序的早期开发因此在交付周期中会发现数据问题迁移、性能等。再加上需要负责多个应用程序的数据库最终的结果是不断地灭火和越来越大的交付压力。DevOps团队拓扑 与反类型相反让我们看一些有效的DevOps拓扑。 1型Dev与Ops协作 这是DevOps的“应许之地”Dev团队和Ops团队之间顺畅协作各自专注于自己的工作并在必要的时候互相分担。可能有许多单独的Dev团队每个团队致力于一个独立或半独立的产品栈。 我的感觉是这种1型模型的建立需要相当大量的组织变革并且要求技术管理团队的高层具有一定的能力。Dev和Ops必须有一个清晰描述且明显有效的共同目标提供可靠而频繁的变更诸如此类。Ops人员必须适应与Dev人员搭配掌握测试驱动编码和Git而Dev人员必须认真对待运维特性从Ops人员那里获得日志实现的输入等等所有这些都需要相当大的文化变革。1型适用于具有强力技术领导者的组织。潜在有效性高 2型完全共担Ops职责 运维人员已经被整合到产品开发团队我们看到了一个2型拓扑。Dev和Ops之间几乎密不可分所有人都高度关注同一个目标这是一种有争议的1型Dev和Ops协作形式但它有一些自己的特点。 像Netflix和Facebook这种实际上只有一种Web产品的组织已经实现了这种2型拓扑但我认为如果不是只关注少量核心产品这种模式可能不是非常适用因为在拥有多个产品流的组织中预算限制和上下文切换很可能会迫使Dev和Ops进一步分开比如说回到1型模型。由于没有明显的或可见的运维团队所以这种拓扑可能也被称为“NoOps”(尽管Netflix NoOps也可以是下文的3型Ops即IaaS)。2型适用于具有单一主要Web产品或服务的组织。潜在有效性高 3型Ops即IaaS平台 对于具有传统IT运维部门不能或不愿做出足够迅速的变更的组织以及将所有应用程序运行在公有云Amazon EC2、Rackspace、Azure等等上的组织这可能有助于将运维视为一个团队他们只是提供了弹性基础设施供应用程序在上面部署和运行为此内部Ops团队直接就相当于Amazon EC2或“基础设施即服务IaaS”。 然后Dev中的一个团队也许是一个虚拟团队可以作为运维特性、指标、监控、服务器配置等方面的专家组可能负责大部分与IaaS团队的沟通。然而这个团队仍然是一个Dev团队遵循TDD、CI、迭代开发等标准实践。 IaaS拓扑的潜在效益是实现更容易不必和Ops人员直接协作完成可能比尝试1型Dev和Ops协作拓扑更快地获得价值至于1型可以后续再试。3型适用于有多个不同的产品和服务以及传统Ops部门的组织或者应用程序全部在公有云上运行的组织。潜在有效性中 4型DevOps作为外部服务 有些组织特别是较小的组织可能没有财力、经验或人力可以运维其开发的软件。Dev团队可能会联系服务提供者如Rackspace帮助他们构建测试环境及自动化基础设施和监控并就他们在软件开发周期中实现何种运维特性提供建议。 对于小型组织或团队如果他们想要学习自动化、监控和配置管理然后随着他们的发展会有更多的人专注于运维他们可能发展成3型Ops即IaaS甚至1型Dev和Ops协作模型那么DevOps即服务可能是一个有效而务实的方式。4型适用于运维问题相关经验比较有限的小型团队或组织。潜在有效性中 5型具有截止日期的DevOps团队 具有截止日期的DevOps团队5型看上去非常像反类型BDevOps团队筒仓但它的意图和期限有很大的不同。这个临时团队的使命是让Dev和Ops更紧密地联系在一起在理想的情况下向1型Dev和Ops协作或2型完全共担Ops职责模型转化并最终会淘汰掉。 临时团队的成员将“翻译”Dev语言和Ops语言引入大胆的想法像站立会议和运维团队看板考虑讨人厌的细节如负载均衡、管理NIC以及为Dev团队进行SSL减负offloading 。如果有足够多的人开始看到Dev和Ops一起协作带来的价值那么临时团队就真正获得了一个达成目标的机会至关重要的是部署和生产诊断的长期职责不应该给临时团队否则它就可能会成为一个DevOps团队筒仓反类型B。5型是1型拓扑的前身但要注意反类型B的危险。潜在有效性低到高 6型DevOps布道团队 在Dev和Ops之间存在巨大鸿沟或者差距有变得很大的趋势的组织里它可以有效地“促进”DevOps团队保证Dev和Ops之间的对话。这是5型具有截止日期的DevOps团队的一个版本但这里的DevOps团队是一直存在的其具体职责是促进Dev团队和Ops团队之间的协作。这个团队的成员有时也被称作“DevOps布道者”因为他们帮助宣传DevOps实践。 “DevOps团队”的目标应该是通过赋能组织的其他部分来让自己脱离业务。——EricMinick6型适用于Dev和Ops之间有疏远趋势的组织。注意反类型B的危险。潜在有效性中到高 7型SRE团队谷歌模型 DevOps经常建议Dev团队加入值班轮换但这不是必要的。事实上有些组织包括谷歌运行一个不同的模型软件由开发团队显式“交接给”运行软件的团队即网站可靠性工程团队SRE。在这个模型中Dev团队需要向SRE团队提供测试证据日志、指标等证明他们的软件已经达到一个SRE团队认为足够好的标准。 至关重要的是SRE团队可以拒绝不符合运维标准的软件要求开发人员在投入生产之前改进代码。Dev和SRE之间的协作围绕着运维标准展开但是一旦SRE团队对代码满意他们而不是Dev团队就会在生产环境中提供支持。7型只适用于工程和组织成熟度较高的组织。如果SRE/Ops团队被告知进行“JFDI”部署则要注意不要回到反类型A。潜在有效性低到高 8型容器驱动协作 容器将应用程序的部署和运行要求封装到了容器中消除了Dev和Ops之间的某些协作需求。在这种情况下容器充当了Dev和Ops的责任边界。在良好的工程文化中容器驱动协作模型运转良好但是如果Dev开始忽视运维注意事项那么这个模型就会向敌对的“我们和他们”回归。8型适用性容器可以很好地发挥作用但要注意反类型A不要期望Ops团队运行Dev扔给他们的任何东西。潜在有效性中到高 9型Dev和DBA协作 为了消除Dev和DBA之间的鸿沟有些组织已经尝试使用类似9型的模型DBA团队的数据库能力与Dev团队的数据库能力或专长可以很好地互补。这似乎有助于将以Dev为中心的数据库视图基本上就是作为应用程序笨拙的持久性存储和以DBA为中心的数据库视图智能丰富的业务价值源之间的转换。9型只适用于有一个或多个大型中心数据库连接多个应用程序的组织。潜在有效性中 你所在的团队开始采用DevOps了吗是怎样的模式呢欢迎大家在评论区一起谈谈。 查看英文原文https://web.devopstopologies.com/