關于團隊結構，有很多學問和秘密。小數(shù)在上一篇文章中與大家探討了當 DevOps運用到開發(fā)與運維團隊中的幾種情況。今天我們上升一步，把整個團隊組織看做是一個分布式系統(tǒng)時，它是否適用于CAP理論，又會有哪些新的發(fā)現(xiàn)?
對于團隊來說，CAP理論意味著什么?在分布式數(shù)據(jù)庫系統(tǒng)中，CAP理論是這樣的：只能在一致性、可用性和隔離性中選擇兩個——而隔離性是必選的。
開發(fā)一個軟件系統(tǒng)，除非軟件全部由一個人搭建，否則必須要選擇隔離性。因為眾人的想法不能融合，交流十分緩慢。
在數(shù)據(jù)庫，我們選擇一致性(數(shù)據(jù)相同)和可用性(可以獲取數(shù)據(jù))。隨著團隊成長擴大，我們會選擇一致性(以同樣的方式和理由做事)和執(zhí)行力(把事情真正地完成)。
換句話說，撇開CAP理論，我們平衡了抱團和前進的節(jié)奏。
抱團，齊步走
一組一人的形式不值得提倡：決策雖然具有一致性，所有的工作都不停歇，但是輸出卻很有限，一旦某個人生病，所有的事情都會停下來。
2到7人組成的團隊很理想：溝通伴隨著想法相互碰撞，對話后全新的產(chǎn)出彌補了交談花費的時間成本。它仍然具有可行性，因為團隊里的每個人了解團隊其他人的心智模式(mental model)，清楚每個人各自需要什么。當利益相關者彼此成為朋友，一致性也很容易達成。
一個2到7人的團隊緊密地工作在一起，這個空心向上的箭頭代表了他們的潛在產(chǎn)出是很高的。
這支團隊構建了系統(tǒng)，運營一家便利店，他們?nèi)η斑M，實心代表了真正的產(chǎn)出。
接下來我們添加更多的網(wǎng)站，同時開發(fā)銷售點收款的工具。團隊分裂為兩個。我們?nèi)匀皇褂猛粋€項目數(shù)據(jù)庫，打造著同樣的品牌，所以依然緊密合作著。我們利用彼此的工具。更多的人意味著更多的協(xié)調(diào)成本，但是大家是一個整體，互相喜歡，所以并沒有太多負擔。
一個綠色箭頭，一個紅色箭頭，彼此通過連線來溝通，工作上都是半滿的?，F(xiàn)在商店運營得很好，網(wǎng)站吸引了更多的零售業(yè)務，鄰近的便利店想在我們的網(wǎng)站上宣傳他們的東西，一切都很順利，我們也招聘了更多人進來。一個負責合作伙伴的團隊，意味著我們需要對外做報告，需要一個數(shù)據(jù)管道(data pipeline)。
紫色和藍色的箭頭加入，線交錯糾纏在一起，這些箭頭都只填滿了一點點，因為合作成本增加。紫色箭頭連接的比較少，并且比較滿，但是它向左偏移了30度。
我們不再使用相同級別的一致性和協(xié)調(diào)性。協(xié)調(diào)成本沉重，新人進來后不了解其他人的情況。合作伙伴關系團隊接觸數(shù)據(jù)庫，可能會破壞銷售點或者網(wǎng)站。每個人都要檢查每件事，所以最慢發(fā)布的那個團隊定下了整體的節(jié)奏。紫色團隊在協(xié)調(diào)上花費了更少時間，數(shù)據(jù)管道正在建設，但是和綠色團隊并沒有任何關系，也不會和銷售點有任何合作。
方向正朝著混亂發(fā)展，我們?nèi)绾尾拍茉谝?guī)模擴大的同時穩(wěn)步前進呢?
獨立，大步走
另一個極端是去耦合，劃清邊界。在數(shù)據(jù)管道、銷售點和網(wǎng)站之間有非常明確的API。將數(shù)據(jù)庫分開，必要時復制數(shù)據(jù)。這是一種不同的開銷：更多的技術，更少的人。打破了數(shù)據(jù)庫的后端耦合;打破了前端API耦合及其向后兼容性;團隊彼此運作自己的日程安排，發(fā)布不再需要協(xié)調(diào)。這由更廣闊的箭頭來表示，因為向后兼容和graceful degradation的代價都是昂貴的。
四個箭頭，每個都是短而寬的。彼此有很少的連線。但是工作橫向擴展(厚重)比縱向(項目方向)更多。
這些團隊和上文協(xié)調(diào)負擔沉重的團隊相比，跑得一樣遠。差別在于：它可以橫向擴展。我們可以在溝通成為限制項之前增加更多的團隊。