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