关于团队结构，有很多学问和秘密。小数在上一篇文章中与大家探讨了当 DevOps运用到开发与运维团队中的几种情况。今天我们上升一步，把整个团队组织看做是一个分布式系统时，它是否适用于CAP理论，又会有哪些新的发现?
对于团队来说，CAP理论意味着什么?在分布式数据库系统中，CAP理论是这样的：只能在一致性、可用性和隔离性中选择两个——而隔离性是必选的。
开发一个软件系统，除非软件全部由一个人搭建，否则必须要选择隔离性。因为众人的想法不能融合，交流十分缓慢。
在数据库，我们选择一致性(数据相同)和可用性(可以获取数据)。随着团队成长扩大，我们会选择一致性(以同样的方式和理由做事)和执行力(把事情真正地完成)。
换句话说，撇开CAP理论，我们平衡了抱团和前进的节奏。
抱团，齐步走
一组一人的形式不值得提倡：决策虽然具有一致性，所有的工作都不停歇，但是输出却很有限，一旦某个人生病，所有的事情都会停下来。
2到7人组成的团队很理想：沟通伴随着想法相互碰撞，对话后全新的产出弥补了交谈花费的时间成本。它仍然具有可行性，因为团队里的每个人了解团队其他人的心智模式(mental model)，清楚每个人各自需要什么。当利益相关者彼此成为朋友，一致性也很容易达成。
一个2到7人的团队紧密地工作在一起，这个空心向上的箭头代表了他们的潜在产出是很高的。
这支团队构建了系统，运营一家便利店，他们全力前进，实心代表了真正的产出。
接下来我们添加更多的网站，同时开发销售点收款的工具。团队分裂为两个。我们仍然使用同一个项目数据库，打造着同样的品牌，所以依然紧密合作着。我们利用彼此的工具。更多的人意味着更多的协调成本，但是大家是一个整体，互相喜欢，所以并没有太多负担。
一个绿色箭头，一个红色箭头，彼此通过连线来沟通，工作上都是半满的。现在商店运营得很好，网站吸引了更多的零售业务，邻近的便利店想在我们的网站上宣传他们的东西，一切都很顺利，我们也招聘了更多人进来。一个负责合作伙伴的团队，意味着我们需要对外做报告，需要一个数据管道(data pipeline)。
紫色和蓝色的箭头加入，线交错纠缠在一起，这些箭头都只填满了一点点，因为合作成本增加。紫色箭头连接的比较少，并且比较满，但是它向左偏移了30度。
我们不再使用相同级别的一致性和协调性。协调成本沉重，新人进来后不了解其他人的情况。合作伙伴关系团队接触数据库，可能会破坏销售点或者网站。每个人都要检查每件事，所以最慢发布的那个团队定下了整体的节奏。紫色团队在协调上花费了更少时间，数据管道正在建设，但是和绿色团队并没有任何关系，也不会和销售点有任何合作。
方向正朝着混乱发展，我们如何才能在规模扩大的同时稳步前进呢?
独立，大步走
另一个极端是去耦合，划清边界。在数据管道、销售点和网站之间有非常明确的API。将数据库分开，必要时复制数据。这是一种不同的开销：更多的技术，更少的人。打破了数据库的后端耦合;打破了前端API耦合及其向后兼容性;团队彼此运作自己的日程安排，发布不再需要协调。这由更广阔的箭头来表示，因为向后兼容和graceful degradation的代价都是昂贵的。
四个箭头，每个都是短而宽的。彼此有很少的连线。但是工作横向扩展(厚重)比纵向(项目方向)更多。
这些团队和上文协调负担沉重的团队相比，跑得一样远。差别在于：它可以横向扩展。我们可以在沟通成为限制项之前增加更多的团队。