DevOps架构的演进.docx
《DevOps架构的演进.docx》由会员分享，可在线阅读，更多相关《DevOps架构的演进.docx（18页珍藏版）》请在冰豆网上搜索。
DevOps架构的演进
DevOps架构的演进
在大多数的团队中，开发、运维之间有着一系列冲突和博弈。
有人说，DevOps的出现让开发和运维不再相爱相杀，从此一起手牵手，开心得Coding和捉Bug；但也有人说，DevOps就是开发吃掉运维。
是这样的吗，不同的团队结构会对DevOps的发展有何影响？
请看下文，你会有自己的答案。
组织中发起任何DevOps相关活动的首要目的是改善对客户和业务的价值交付，而不是降低成本，提升自动化程度，或者从配置管理中驱动任何事情。
这意味着不同的组织可能需要不同的团队结构才能开展有效的开发和运维协作。
哪些DevOps团队结构或拓扑适合组织，取决于几件事情：
∙该组织的产品组合：
较少的产品使得协作更加容易。
因为根据康威定律，这种情况下各自独立的小团队较少。
∙技术领导力的范围，力度和有效性；Dev和Ops是否有共同的目标。
∙一个组织是否具有将IT运维部门从“硬件机架”和“配置服务器”改变为与价值流实际一致的需求或能力，以及软件研发团队是否认真对待来自运维方面的要求。
∙该组织是否具备带头解决当前运维问题的能力或技能。
当然，这里描述的主题有所不同；拓扑和类型是作为参考指南或启发，协助您来评估哪些模式可能是适合的。
实际上，将多种模式或一种模式转化为另一种模式的组合往往是最好的方法。
那么DevOps的团队结构如何发展呢？
显然，没有任何适合每个组织的理想结构或团队拓扑。
然而，对于团队结构来说，参考少数不同的模型是有用的，其中一些模型与某些组织的适合度更高。
通过探索这些团队结构（或“拓扑”）的优缺点，考虑到康威定律，我们可以确定可能对我们自己组织中DevOps做法最有效的团队结构。
这些DevOps拓扑中的大多数已经在其他地方描述过；特别是CollabNet的LawrenceSweeney在对BenKepes博客的评论中谈到了有关我在这里所描述的反类型B（独立的DevOps团队），类型3（运维作为基础设施服务）以及类型1（开发和运维协作）。
DevOpsGuys列出了十二个DevOps反模式，JezHumble，GeneKim，DamonEdwards（以及许多其他人）也曾经说过类似的事情。
我在这里添加了三个额外的“拓扑”，我没有看到或听到与此相关的一些讨论（共享运维，DevOps-as-a-Service和临时DevOps团队）。
DevOps反类型
看看一些不好的做法，我们可以称之为“反类型”（在无处不在的“反模式”普及之后的说法）是有用的。
∙Dev和Ops分离
∙单独的DevOps团队
∙开发不需要运维
∙DevOps作为工具团队
∙系统管理员
∙开发包含运维
∙开发和DBA分离
反类型A：
Dev和Ops分离
这是经典的“扔过墙去”式的Dev和Ops分离。
这意味着需求点可以在前期被提取出来（DONE意味着“功能完整”，但不能在生产中使用），并且软件的可运维性受到损害。
因为开发者没有运维相关的上下文信息，运维人员没有时间或者动力参与到开发者中，在软件上线之前解决问题。
我们都知道这种拓扑类型不好，但我认为有很多相似的拓扑结构很差；至少我们清楚反类型A（开发和运维分离）是一个问题。
反类型B：
单独的DevOps团队
单独的DevOps团队通常来自经理或执行官，他们决定“需要一点这个DevOps的事情”，并启动一个“DevOps团队”（可能是被称为“DevOp”的人）。
DevOps团队的成员迅速形成另一个团体，使Dev和Ops比以往任何时候都更加分开，因为他们需要捍卫自己的角色，技能和工具集，防止自己被“无知的Devs”和“恐龙般的Ops”所消灭。
单独的DevOps团队真的有意义的唯一的情况是，当团队是暂时的，例如持续时间少于12或18个月，其明确目的是使Dev和Ops更紧密地结合在一起，并被明确地授权的时候，当这段时间过去，这个团队是多余的。
这就是我所说的类型5DevOps拓扑。
反类型C：
开发不需要运维
这种拓扑结构由开发人员和开发经理之间的天真和傲慢相结合，特别是在新项目或系统开始时。
假设Ops现在是过时的事情（“我们现在有了Cloud，对吗？
”），开发人员大大低估了运维技能和活动的复杂性和重要性，并认为他们可以不需要运维，或者在闲暇时间就可以搞定运维做的事情。
这种反类型CDevOps拓扑可能最终需要Type3（OpsasIaaS）或Type4（DevOps-as-a-Service）拓扑，当他们的软件变得更加深入和复杂，运维开始需要开发工作（又称编码）的时候。
如果这样的团队认识到运维作为一个重要和有价值的学科，并且认可其对于软件开发的重要性，他们将能够避免许多痛苦和不必要的（和相当基本的）运维错误。
反类型D：
DevOps作为工具团队
在不影响当前开发团队的速度（实现用户故事）的情况下，成立一个DevOps团队，负责部署管道，配置管理，环境管理等所需的工具。
同时，Ops的人们继续孤立工作，Dev团队继续将他们的应用程序“放在墙上”。
虽然这个专门团队的成果在改进工具链方面可能是有益的，但其影响是有限的。
在应用程序开发生命周期中缺乏早期运维的参与和协作，根本问题依然存在。
反类型E：
变相的SysAdmin
这种反类型在工程成熟度低的组织中是典型的。
他们希望改善他们的做法并降低成本，但是他们不能将IT视为业务的核心驱动力。
因为DevOps的行业成功现在显而易见，他们也想“做DevOps”。
不幸的是，他们并没有反思目前的结构和关系的差距，而是为其Ops团队聘请了“DevOps工程师”。
DevOps只是一个名为SysAdmin的角色的重塑，没有真正的文化/组织变化发生。
这种反型越来越广泛，因为庸碌的招聘人员只是寻找具有自动化和工具技能的候选人。
不幸的是，人际沟通技巧才能真正使DevOps在组织中茁壮成长。
反类型F：
运维嵌入开发团队
该组织不希望独立的运维团队，所以开发团队负责基础设施，管理环境，监控等。
但是，这样以项目或产品驱动的方式，意味着这些项目受到资源限制，优先次序导致了较差的运作方式和半成品的解决方案。
在这种反类型方面，该组织对于有效的IT运维所需的重要性和技能缺乏认识。
反类型G：
Dev和DBA隔离
这是一种在中型到大型公司中突出的反类型A（开发和运维分离）的形式，其中多个遗留系统依赖于相同的核心数据集。
由于这些数据库对于业务至关重要，因此经常在业务范围内的专门的DBA团队负责维护，性能调整和灾难恢复。
这是可以理解的，但问题是当这个团队成为任何数据库变更的门户时，有效成为小型和频繁部署（DevOps和持续交付的核心宗旨）的障碍。
此外，就像在反类型A中的运维一样，DBA团队在应用开发早期也没有涉及，因此数据问题（迁移，性能等）在交付周期的后期被发现。
加上支持多个应用数据库的过载，最终的结果是面临持续的“救火”和部署压力。
DevOps团队拓扑
站在反类型的对面，我们看一些适合DevOps的拓扑：
∙开发和运维协作
∙完全共享运维责任
∙运维作为基础设施服务
∙DevOps-as-a-Service
∙临时DevOps团队
∙DevOps布道者团队
∙SRE团队
∙容器驱动的协作
∙数据库能力
类型1：
开发和与运维协作
这是DevOps的“乐土”：
开发团队和运营团队之间的顺利协作，每个专业都在需要的地方，但也需要分享。
可能有许多独立的开发团队，每个工作在一个单独的或半独立的产品堆栈。
我的意思是，这种1型模型需要相当大的组织变革才能建立起来，在技术管理团队中具有较高的竞争力。
开发者和运维部门必须有明确的表达和鲜明合理的共同目标（“高质量交付，拥抱变化”或其他）。
运维人员必须与Devs配对，掌握测试驱动的编码技能和Git工具，并且开发必须认真对待运维特性方面的要求，并寻找运维人员加入日志实现。
从目前状况到这个状态，所有这些都需要相当的文化变革。
类型1适应性：
一个技术驱动型的组织。
有效潜力：
高
类型2：
完全共享运维责任
在运维人员已经集成到产品开发团队中的情况下，我们看到了类型2拓扑。
Dev和Ops之间的分离很少，所有人都高度重视共同的目标；这是一种形式的类型1（开发和运维协作），但它有一些特殊的功能。
Netflix和Facebook等组织有效实现了一种基于Web的产品，已经实现了这种2型拓扑结构。
但是我认为在单纯的产品角度之外来看，它可能不是非常适用的，因为预算限制和多个产品线之间通常存在上下文切换，这可能会迫使Dev和Ops进一步分开（例如，回到类型1模型）。
这个拓扑也可能被称为“NoOps”，因为没有明显的或可见的运维团队（尽管NetflixNoOps也可能是类型3（作为IaaS的Ops））。
类型2适应性：
组织只有一个简单的基于Web的产品或服务。
有效潜力：
高
类型3：
运维作为基础设施服务
对于IT运维部门非常传统的组织，不会或者不能（足够）快速地拥抱变化，适合在公共云（AmazonEC2，Rackspace，Azure等）中运行所有应用程序的组织。
它可能将运维作为一个只需提供应用程序部署和运行功能的弹性基础设施团队。
因此，内部运维团队直接等同于AmazonEC2或基础架构即服务。
Dev内部的一个团队（或许是一个虚拟团队）将作为运维特性、指标、监控、服务器配置等方面的专业知识来源，并且可能与IaaS团队进行大部分的沟通。
然而，这个团队仍然是一个开发团队，遵循TDD、CI、迭代开发、人员指导等标准实践。
IaaS拓扑结构具有一些潜在的有效性（与Ops人员直接协作），以便更容易实施，可能比稍后尝试的类型1（开发和运营协作）更快地获得价值。
类型3适应性：
具有多种不同产品和服务，传统的运维部门，或其应用程序完全在公有云中运行的组织。
有效潜力：
中
类型4：
DevOps作为外部服务
一些组织，特别是较小的组织可能没有资金，经验或工作人员来主导他们的软件运维。
开发团队可能会接触到像Rackspace这样的服务提供商，以帮助他们建立测试环境并自动化其基础设施和监控，并就软件开发周期中实现的各种运维功能提供建议。
可以称之为DevOps-as-a-Serviced的可能是小型组织或团队，他们了解自动化，监控和配置管理的用途和实现方式。
随着业务的发展和更多的员工加入，可能转向第3类（作为IaaS的操作）或甚至第一类（开发和运维协作）模式。
类型4适应性：
运营经验较少的小型团队或组织。
有效潜力：
中
类型5：
具有到期日的DevOps团队
具有到期日的DevOps团队（类型5）看起来像反类型B（DevOpsTeamSilo），但其意图和寿命是完全不同的。
这个临时团队的任务是使Dev和Ops更紧密地结合在一起，理想目标是面向类型1（开发和运营协作）或类型2（完全共享的OpsReponsibility）模型，并最终使其自身过时。
临时小组的成员将在Dev-speak和Ops-talk之间进行“翻译”，引入疯狂的想法，如为Ops团队引入站立会和看板，并考虑“肮脏”的细节，如负载均衡器，管理NIC和为Dev团队卸载SSL。
如果足够多的人开始看到将Dev和Ops组合在一起的价值，那么临时团队就有实现其目标的真正机会。
至关重要的是，部署和生产环境的长期分析诊断责任不应该提供给临时团队，否则可能会造成 DevOps团队隔离（反类型B）。
类型5适应性：
运营经验较少的小型团队或组织。
有效潜力：
低至中
类型6：
DevOps“布道者”团队
在Dev与Ops之间存在巨大差距（或者大的差距趋势）的组织中，拥有一个“促进”DevOps团队来保持Dev和Ops方面的交流是有效的。
这是一个类型5（DevOpsTeamwithExpireyDate）的版本，但DevOps团队在持续的基础上存在着具体的促进Dev与Ops团队之间的协作与合作的职责。
这个团队的成员有时被称为“DevOps布道者”，因为它们有助于传播DevOps实践的意识。
“DevOps团队”的目标应该是通过启用组织的其余部分来实现自己的业务。
—Twitter:
EricMinick
类型6适应性：
Dev和Ops趋势分散的组织，小心类型B的危险。
有效潜力：
中至高
类型7：
SRE团队（Google模型）
DevOps经常建议Dev团队定期参加值班会议，但这不是必须的。
事实上，一些组织（包括Google）运行不同的模式，从开发到运行该软件的团队（站点可靠性工程（SRE））可以实现明确“切换”。
在这个模型中，开发团队需要向SRE团队提供测试证据（日志，指标等），表明他们的软件具有足够的标准，得到SRE团队的支持。
最重要的是，SRE团队可以拒绝在运维上不合标准的软件，要求开发人员在将代码投入生产之前对其进行改进。
Dev和SRE之间的协作发生在运维标准上，但是一旦SRE团队对代码感到满意，他们（而不是开发团队）就在生产中支持它。
类型7适应性：
类型7仅适用于具有高度工程和组织成熟度的组织。
如果SRE/Ops团队被告知“JFDI”部署，请小心返回反类型A。
有效潜力：
低至高
类型8：
容器驱动的协作
通过将应用程序的部署和运行时需求封装到容器中，容器不再需要Dev和Ops之间的某些协作。
这样，容器就成为开发和运维的责任界限。
凭借良好的工程文化，容器驱动的协作模式运作良好，但如果开发者开始忽视运维需要考虑的一些事情，这种模式可以转变为对抗的“我们与他们”。
类型8适应性：
容器可以工作得很好，但要注意反类型A，Ops团队预计会运行Dev发出的任何内容。
有效潜力：
中至高
类型9：
开发和DBA协作
为了弥合Dev-DBA的鸿沟，一些组织已经尝试过类似于类型9的数据库功能，DBA团队的数据库功能与Dev团队的数据库功能（或专业）相称。
这似乎有助于在以开发为中心的数据库（本质上是应用程序的虚拟持久存储）视图和DBA为中心的数据库（智能，丰富的业务价值来源）视图之间进行转换。
类型9适应性：
适用于具有多个应用程序连接一个或多个大型中央数据库的组织。
有效潜力：
中
升级会员 