开发和运维的关系一直很“微妙”他听我的 他不听我的哦他开口了哦好吧我听不懂他说了啥……开发和运维的恩怨情仇由来已久由此诞生的DevOps却是解决他们之间关系的一剂良药。
DevOps最主要目的在于提高用户和业务需求提高产品的交付能力与效率。不同的行业和企业需要规划各种DevOps团队结构来适应开发和运维的协作。数人云今天和大家讨论的就是这些五花八门的团队结构首先我们先请“反面教材”登场……
反例ADevOps是啥?
这是典型的开发和运维“各管一摊”。它意味着虽然能很早地声明项目完成(这里的完成意思仅仅是功能上的完成而不是交付到生产环境)但是软件的操作性却无法保证因为开发没有为运维考虑很多运维人员也没有足够的时间或者精力去敦促开发去修正这些问题。
大家都知道这个团队结构很糟糕但是显然还有更坏的情况——至少这个结构我们都知道它是有问题的。
反例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的情况可能也归结为下面的正例3IaaS)。
适用于单一为主、基于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结构的适用性取决于如下几个要素
组织的产品集如康威定理所说更少的产品会让合作更加容易隔阂也更加少。
技术领导的能力和效率开发和运维是否目标一致。
是否有能力或者意愿改变运营部门是否认真地对待产品运营特性。
在运维关键点上是否有能力起到带头作用。
当然这里提到的拓扑结构都是作为一种参考或者启发。在现实中多个模式的组合或者一个模式转换成另一个模式都是可以的毕竟适合才是最好的。
作者数人云
来源51CTO