开发与运维的关系一直很“微妙”。你说什么……开发和运维之间的恩怨由来已久，而由此而生的DevOps正是解决他们之间关系的一剂良药。DevOps的主要目的是改善用户和业务需求，提高产品交付能力和效率。不同行业和企业需要规划不同的DevOps团队架构，以适应开发运维协同。树人云今天要跟大家探讨的就是这些形形色色的团队架构。首先请“反面教材”上台??……反例A：什么是DevOps？这是典型的开发运维。就是说虽然可以很早的宣告项目的完成（这里的完成只是指功能的完成，而不是交付到生产环境），但是不能保证软件的可操作性，因为开发没有考虑很多用于操作和维护。维护人员也没有足够的时间或精力来推动开发人员修复这些问题。每个人都知道这种团队结构很糟糕，但显然还有更糟糕的——至少我们都知道的结构是有问题的。反例B：孤立的DevOps这种形式通常来自于领导者或执行者的决定——他们觉得自己需要一点DevOps，然后组成一个“DevOps团队”。这支队伍很快形成了新的壁垒。在他们眼里，开发是愚蠢的，运维是落伍的。他们捍卫自己小团体的知识、技能和工具，使开发和运维之间的距离越来越远。这种结构只有一种情况是有意义的，那就是DevOps团队只是临时的，存在时间不超过12或18个月，并且有明确的目的是将开发和运维拉近距离。该团队不再有用，这在下面的示例5中有所提及。反例C：我们不玩运维。这种团队组织的幼稚和傲慢来自开发人员和开发部门领导，尤其是在开始一个新项目或系统时。开发人员认为O&M已成为过去（“我们现在有云，不是吗”），淡化O&M的复杂性和重要性，认为他们可以在没有它的情况下完成，或者只花很少的时间去做。当他们的软件变得越来越复杂，运维活动开始陷入泥潭（哦，开始编程吧），这个结构就会结束，取而代之的是下面的正例3（IaaS）或者4（DevOps-as-a-服务）。团队会意识??到运维在软件开发过程中的重要性，可以避免很多不必要的痛苦和低级运维错误。看完反面教材，我们再来看看DevOps中一些常见且可用的团队组织结构。正例一：彼此相爱，彼此享受。这就是DevOps的“乐土”：开发团队和运维团队的和谐合作，在一个隔离或半隔离的产品栈上工作，需要专一的地方有专人负责，需要分担的地方也是特别的分享场所。但这种融洽协作的模式需要大量变革，还需要更高水平的技术领导团队。开发和运维必须有清晰的沟通表达（交付可靠的、频繁的变更）和明确有效的共同目标。运维人员必须与开发人员很好地合作，认真对待测试驱动代码和Git，而开发必须认真对待各种操作特性，这需要相当大的文化变革。适用于：技术领导力强的团队潜在效率：高正例2：我在你里面，你在我里面。运维人员已全面嵌入产品开发团队。开发和运维几乎密不可分，高度专注于一个共同的目标；这是正例1中比较有争议的一种特殊形式，它有一些独特的特点。Netflix和Facebook等组织有效地使用了这种结构，因为它们拥有独立的基于Web的产品。但这种结构在狭窄的产品范围之外效果不佳，在这种情况下，有限的预算和多个产品线会导致DevOps分离。这种全嵌入式的模式也可以称为“NoOps”（无运维），因为没有明显的或具体的运维团队（Netflix的情况也可能归因于下面的正例3，IaaS）。适用于：单一主导、基于Web的产品或服务的组织潜在效率：高正例3：翻身难，IaaS来帮忙相当传统的IT运营部门可能不愿意或不能快速做出改变，或者为了对于所有应用程序都运行在公有云上的组织，这种结构可以帮助组织的运维部分只需要一个弹性的基础设施来进行应用程序的部署和运行，而内部的运维团队就变成了，比如Amazon的EC2，或者IaaS。这样的团队（可能只是虚拟的）包含在开发中，是运营方面的专家——知道运营特性、指标、监控和服务器配置等，并且与IaaS团队有很多沟通。但是，团队仍然是一个开发团队，遵循TDD、CI、迭代开发和培训等标准开发实践。IaaS的出现，以失去与运维人员的直接合作换取更简单的实施和更高的效率，其实施速度可能比正例1更快。适用于：拥有多种不同产品和服务的组织，或者有传统的运维部门，或者把应用完全部署在公有云上。他们需要更多专业的技术服务公司来帮助搭建测试环境，自动化基础设施和监控，并在软件开发过程中为他们提供一些运营建议。DevOpsasaservice可能会成为小型组织或团队非常有用的自动化、监控和配置管理形式，然后随着团队的壮大，他们可以接纳更多面向运营的员工，??并逐渐走向常规3甚至积极例1进化。适用于：经验有限的小型团队或组织潜在效率：中正示例5：DevOps团队作为一个额外的DevOps团队临时的DevOps团队看起来像一个大反例B，但它有不同的目的和存在时间。这种临时团队负责将开发和运维更紧密地联系起来，向正例1和2进化，最后在完成任务后消失。临时团队将充当“开发语言”和“运维语言”之间的“翻译者”，将开发者疯狂的想法传达给运维团队，传递负载均衡、管理网卡和SSL卸载运维开发。如果有足够多的人开始注意到让开发人员和运维人员一起工作的价值，那么临时团队就达到了它的目的。至关重要的是，部署和生产诊断等长期工作不应分配给这个临时团队，否则可能会变成反例B。适用性：正例1的领先模型，但存在转向的风险转化为反例B潜在效率：从低到高敲黑板总结以上反例和正例均有详细统计。总而言之，DevOps结构的适用性取决于以下几点第一个要素：组织的产品集：正如康威定理所说，更少的产品使协作更容易，孤岛也更少。技术领导的能力和效率，开发和运维的目标是否一致。是否有能力或意愿更换运营部门，是否重视产品运营特性。是否具备牵头运维关键点的能力。当然，这里所说的拓扑结构只是作为参考或启发。现实中，多种模式的组合，或者一种模式转化为另一种模式都是可以的，毕竟适合的才是最好的。
