团队拓扑差异如何影响了DevOps文化

团队拓扑 团队建设 DevOps SRE

摘要

有许多种团队拓扑都对DevOps有效。每种拓扑都对应一种稍有不同的文化，适合一个组织的拓扑，可能并不适合另外一个组织，即使是类似的部门。本文探讨了不同DevOps团队拓扑之间的文化差异，帮助读者针对自己的组织选择一种合适的DevOps拓扑。

正文

DevOps是一项活动。DevOps是一种理念。DevOps是开发团队和运维团队一起工作。DevOps是一种组织方式。DevOps是持续学习。

DevOps是无形的，领导者很难提出一个清晰的路线图，供组织实施DevOps采用。DevOps的意思同环境有很大的关系，并没有一种为大多数人所认同的方法，规定了可供遵循的做法。

不过，健康的组织都展现出了类似的行为、组织和改善工作模式。在这个系列的文章中，我们将通过参与者的证言和领域顾问（见过若干DevOps实施方案）的分析探讨其中的部分模式。

这篇发表在InfoQ的文章是“DevOps文化模式”系列文章的一部分。读者可以通过RSS订阅，接收文章发布通知。

引言

这些年来，我一直对团队、个体动机和软件交付效果之间的关系感兴趣，这可以追溯到我还是一个大型项目的团队负责人的时候。那是个多供应商的项目，目的是为伦敦的一家大型金融机构重新构建一个关键的软件系统。从那时起，我已经研究过多个软件系统，而且它们是面向具有不同团队配置和团队文化的组织，团队配置（我称之为拓扑）和组织能力之间的关系让我特别感兴趣。

在2015年3月举行的QCon伦敦大会上，我做了有关持续交付的演讲。在同客户一起工作的过程中，我们发现，为了得到对组织而言最好的结果，DevOps工具的选择应该遵循Conway定律。我在演讲中阐述了我们得出这个结论的过程。Conway定律——Rachel Laycock在Build Quality In一书中进行了精彩地描述——源于Mel Conway在1968年难解但可信的观察，就是“设计系统的组织……都受到限制，产生的设计等同于这些组织的沟通结构”。假如IT组织本身就是某种系统，那么它也遵从Conway定律，该系统的拓扑取决于我们允许或推崇的沟通类型。越来越多的证据表明，Conway定律很难绕过。

从2013年开始，我和其他几个人一直在收集和记录组织为了实现DevOps所使用的不同的团队拓扑（点击这里，查看当前的团队拓扑目录）。我们发现，这些模式对于客户处理实现DevOps所需要的团队变革非常有用，因为这些拓扑可以帮助我们推断出，组织需要具有什么样的职责和文化才能让不同结构的团队有效运作。

没有单一的“DevOps文化”

数年来，在与许多不同组织共事的过程中，我越来越清楚地认识到，有关单一、可识别的“DevOps文化”的想法是不合时宜的。在具备有效或新兴的DevOps实践的组织中，我们看到了各种各样的支撑DevOps的文化。当然，在这些不同的文化中，某些方面是必不可少的：对事件进行事后分析时不指摘他人、团队自治、尊重他人、持续改进的愿望和机会，所有这些都是健康DevOps文化的关键组成部分。

不过，在某些组织中，特定团队之间的协作比其他团队多许多，而且沟通的形式和目的可以不同于其他组织。事实上，我们有时候会看到，有些组织为了保持整个“人机系统”逻辑上不同的部分相互隔离，会减少特定团队之间的合作。这是由提前使用Conway定律的需要所决定的（也就是所谓的“反Conway策略”）。

过去几年里，我们大约同20个组织一起开发过DevOps实践，有三种突出的团队模式或拓扑使用最广泛：

• 基础设施即服务（devopstopologies.com上的“类型3”）
• 职责共担（“类型2”）
• SRE团队（“类型7”）

对于某些组织来说，其它团队拓扑也可以有效运作，但这三种模式是我们最常见到的。现在，让我们探讨下这些拓扑之间文化的差异。

基础设施即服务

首先，比如说我们知道虚拟环境配置功能需要“作为一项服务”被应用程序开发团队消费；为了防止Conway定律在开发团队和基础设施团队之间强加过多的耦合，我们建议限制开发团队和基础设施团队之间的沟通。

类型3 适用性：有多种不同的产品和服务并且有一个传统的Ops部门的组织，或者应用程序完全运行在公共云上的组织

在这种情况下，我们希望基础设施团队在某种程度上故意同应用程序开发团队隔离，彼此之间共享的东西少，而各团队内部共享的东西多，至少在代码和工具层面是这样（为了倡导角色轮换以及学习新方法，我们仍然希望在团队之间分享午餐披萨会议）。

“我们构建，我们运行”

相反地，有的组织是具有产品一致性或KPI一致性的端到端的组织，它们拥有整个软件栈（包括基础设施）。在这样的组织中，我们看到，基础设施的人同应用程序开发人员和测试人员密切合作，而且理当如此：团队中的任何人都可能因为一个现场服务事件在凌晨2点被叫醒。

类型2 适用性：有单个主要的基于Web的产品或服务的组织。

具有不同技能的团队成员密切合作，将彼此的强项用于交付和运维的不同方面。这样一个“我们构建，我们运行”的团队需要独立于致力于不相关的子系统或服务的周边团队，甚至在某种程度上使用不同的应用程序编码、测试、构建或配置（如果需要）工具。再次考虑下Conway定律，我们创建的工作环境最小化了团队间合作和沟通需求。

SRE团队

第三，有的组织使用谷歌模式的“站点可靠性工程（Site Reliability Engineering，即SRE）”团队（有时称为WebOps），文化就又不一样了。SRE团队愿意承担所有生产职责（随时待命、事件响应等），只要开发团队开发的软件能够满足严格的操作性标准。

类型7 适用性：成熟度很高的组织或者对卓越运营有着严格要求的组织。

同产品开发团队合作多限于帮助开发团队满足操作性标准要求，并通过指标、事件报告等提供运行时行为反馈。刻意将开发团队同软件如何在生产环境中运行的某些方面问题隔离开来，使他们可以专注于新特性的开发，不过，这需要产品经理非常成熟，能够保证操作性标准获得适当的优先考虑。

团队拓扑对DevOps文化的影响

在一个成功实施DevOps的组织中，所有团队为了同一个目标齐心协力，到了这种程度，无疑就会有一种支配一切的DevOps文化在发挥作用（上文已经提到过，这包括尊重、自主、不互相职责等等）。然而，在这三种DevOps取得成功的团队模型中——即“基础设施即服务”、“我们构建，我们运行”和“SRE”——，落地的DevOps文化在本质上多少有点不同，我们最好理解并且预先知道其中每一种模型和文化所具有的不同“感觉”。由于技能、激励机制、技术、甚或是人员个性的差异，对一家电子商务公司有用的东西，对于另外一家电子商务公司而言，可能完全没用。

选择一种团队结构来适应文化？

有些组织因为团队内部的敌对、目标冲突、糟糕的领导力和政治（我猜，我们大多数人都在一个或多个这样的地方工作过）而严重受损，这非常可惜。为了解决绩效不佳的问题，其中那些更有远见的公司正设法采用持续交付和DevOps这样的做法，但通常，由于深层的冲突仍然存在，他们主要的困难是团队改革。我们在一个组织中发现，项目经理一个月交付20个故事点会获得金钱奖励，而同时，IT运维团队在固定时间内关闭打开着的事件单会获得金钱奖励：不出所料，这会导致各种怪异的行为和冲突。

对于这样的组织，除非上层有有魄力的领导，否则，为了实现DevOps，使用一种最适合现有的团队激励机制的团队拓扑是有意义的。实际上，我们要让IT负责人自问“考虑到当前的团队内部文化，什么样的团队拓扑最适合我的组织？”

例如，如果开发团队严格由“产品”支出CapEx驱动，而运维团队由“正常运营”预算OpEx驱动，那么SRE模型可能有效：在接管一款软件前，SRE团队会要求提供一份“可操作性协议（contract of operability）”。这份协议可以很好地划分CapEx和OpEx的范畴。

另一方面，如果新上任的技术负责人想要一个“纯嵌入式”的DevOps模型，但认识到，她的开发团队和运维团队在技能上相距甚远，于是立即开始致力于协作，而为了培养一种协作的文化，她也许会引入一个临时团队，用于在短期内（12个月？18个月？）推动“DevOps”。

类型5 适用性：作为拓扑2或拓扑3的前身，但要提防永久DevOps团队妨碍开发团队和运维团队交流的风险。

特别地，我们看到，在有的组织中，系统管理员（Ops）非常不愿意采用一些基本做法，如版本控制和测试优先的基础设施代码开发，而在其他公司中，开发人员认为，监控&指标或部署会“降低他们的身份”，因此对操作问题几乎没有兴趣。在这些情况下，在DevOps文化生效之前，需要有某种催化剂：一个内部或外部团队这时会有所帮助。

选择一种适合当前文化的团队拓扑需要在实现新的、更高效的DevOps文化的希望和团队当前状况的现实之间进行权衡。关键是，应该将团队拓扑——DevOps文化的作料——看作是一种随着技能、技术、能力和业务需求变化而不断发展的东西。

关于作者

Matthew Skelton自1998以来一直构建、部署和运维商业软件系统。作为Skelton Thatcher Consulting的联合创始人兼首席顾问，他专门研究帮助组织采用和维持良好的软件系统构建和运维实践：持续交付、DevOps、ITIL以及软件可操作性。他还与人合著了Build Quality In，这是一本讲述持续交付和DevOps经验的书。