新闻发布
管理系统类型一：开发运维顺畅协作
这是 DevOps 的“乐土”：开发团队和运营团队之间顺畅协作，每一个团队都在需要的地方专业化工作，但也在需要的地方共享。
可能有许多独立的开发团队，但每个团队又会在一个单独或半独立的产品组合上工作。我的感觉是，类型一的平滑协作模型需要相当大的组织变革来建立它，并且在管理团队需要有较高的能力。
开发人员和运维人员必须有一个明确有效的共同目标（“高质量交付、快速迭代”或其他）。运维人员必须与开发人员进行舒适的合作，掌握测试驱动的编码和 Git，开发人员必须认真对待运维特性，寻找运维人员以输入日志记录等等，所有这些相比较过去都需要进行相当大的文化变革。
类型一适用性：具有强大技术领导类型的组织
潜在有效性：高
类型二：全嵌入式/共享运维
当运维人员完全融入进产品开发团队中的时候，我们看到了这种类型。Dev 和 Ops 之间的分离很少，以至于所有人都共同高度关注一个目标，这可以说是类型一的一种形式，不过它也具有一定特殊性。像 Netflix 和 Facebook 这样的组织有效地实现了一个基于 Web 的产品，它已经实现了这种类型的结构。
但我认为它可能不太适用于狭窄产品线模式之外，因为预算限制和多个产品线之间通常存在上下文切换，这可能会迫使 Dev 和 Ops 进一步分开（例如回到类型一模型）。这个模式也可以被称为“NoOps”，因为没有明显的或可见的运维团队（尽管 Netflix NoOps 也可能是类型三）。
类型二适用性：基于单一 Web 的产品或服务的组织
潜在有效性：高
类型三：基础设施即服务
对于具有相当传统的 IT 运维部门的组织，他们无法或不能（足够）快速作出改变，和对于在公共云（Amazon EC2、Rackspace、Azure 等）中运行所有应用程序的组织来说，将运维作为一个只需提供应用程序部署和运行功能的弹性基础设施团队或许比较有帮助。这样内部运维团队直接等同于 Amazon EC2 或基础架构即服务。然后 Dev 中的团队（可能是虚拟团队）充当有关操作特性、度量、监控、服务器供应等方面的专业知识来源，并且可能与 Iaas 团队进行大部分沟通。
然而这个团队仍然是一个开发团队，遵循诸如 TDD、CI、迭代开发、指导等标准实践。IaaS 团队结构具有一些潜在的有效性（失去与 Ops 人员直接协作），以便更容易实施，可能比类型一更快地获得价值。
类型三适用性：具有几种不同产品和服务、具有传统运营部门或其应用程序完全在公共云中运行的组织
潜在有效性：中等
类型四：DevOps 即服务
一些组织，特别是较小的组织，可能没有资金、经验或工作人员来领导他们的软件运维。开发团队可能会接触到像 Rackspace 这样的服务提供商，去帮助他们建立测试环境并自动化其基础设施和监控，并就软件开发周期中实现的各种运维功能提供建议。
可以被称之为 DevOps-as-a-Service 的应该是帮助小型团队了解自动化、监控和配置管理的一种有效务实的方法。随着业务的发展和更多的员工加入，可能转向第三类甚至第一类模式。
类型四适应性：运营经验有限的小型团队或组织
有效潜力：中
类型五：临时 DevOps 团队
这个类型看起来和反类型 B 有极大的相似，但是实际上其本质意图和长远性是完全不同的。这个临时团队的任务是使 Dev 和 Ops 更紧密的联合在一起，理想目标是完全转型成类型一或二。临时团队成员将在 Dev-speak 和 Ops-speak 之间进行翻译，并引入一些疯狂的点子，例如为 Ops 团队介绍站立会和看板系统，还有一些吹毛求疵的细节，例如为 Dev 团队介绍负载均衡器，管理 NIC 和卸载 SSL。
如果有足够多的人意识到 Dev 和 Ops 团队结合后将带来的价值，临时团队将有机会真正的实现它的目标。至关重要的一点是，对部署和生产分析的长期责任不应该被分配给临时团队，否则很可能会朝着反类型 B 的不利方向演进。
类型五适应性：想达成类型一的前身，但是要警惕演变成反类型 B 的可能
有效潜力：低至中
总结
究竟哪个 DevOps 团队结构适合一个组织取决于以下几点：
该组织的产品组合：较少的产品会使团队协作更加容易，因为根据 Conway 定律，这种情况下的独立谷仓会比较少。
技术领导的范围力度和有效性；Dev 和 Ops 是否有清晰明确的共同目标。
组织是否具有能力或欲望去该改变它的 IT 运维部门，从“服务器的组建和配置”转变成真的可以实现其价值流，以及软件研发团队认真对待运维团队。
组织是否具有能力和技能去解决运维问题。
