不要依技術知識或活動來組建團隊，而要依業務領域區塊來組織團隊。

——尤塔・艾克斯坦（Jutta Eckstein），〈Feature Teams—Distributed and Dispersed〉

第一部呈現了康威定律如何以「團隊結構與溝通路徑映照到最終產品設計」的方式，強力拉扯系統架構；也指出有效的軟體交付需要團隊優先取徑，仰賴長壽自主的團隊達成快速流動。第二部聚焦於如何把這兩個想法結合起來，在尊重團隊認知極限的前提下最大化流動。

為什麼要刻意設計團隊#

今日設立或重組團隊的主流方式是「見招拆招」（ad hoc）——聚焦於眼前需要，而非長期的調適能力。

為了盡可能有效，我們必須有意識地設計團隊，而不只是任其偶然或隨意地形成。作者把這些有意識設計出來的團隊結構稱為團隊拓撲（team topologies）——這個詞既承認團隊應當被刻意「安置」進組織，也指涉每個團隊的職責邊界。

本章檢視靜態團隊拓撲的例子，也就是在特定時間點契合某個組織脈絡的團隊結構與互動。內容主要取材自 DevOps 拓撲（DevOps Topologies）目錄，對許多組織而言，這是個良好而平易近人的起點。

團隊反樣式#

依循康威定律，「人如何被組織成建造與營運軟體系統的團隊」，對最終系統的性質有強烈影響。當組織未明確思考團隊結構與互動樣式時，就會在建造與營運軟體系統時遭遇非預期的困難。作者在客戶工作中，於各種規模的組織裡都見過兩種特別的團隊組建反樣式。

反樣式一：見招拆招的團隊設計#

包括：

• 團隊長得太大，等到溝通開銷開始造成損害才拆分
• 為了照顧所有 COTS 軟體或所有中介軟體而成立的團隊
• 因為資料庫處理不當導致正式環境當機，事後才成立的 DBA 團隊

這些狀況當然都該觸發某些行動，但若未考慮團隊相互關係的更大脈絡，那個「看似自然的解法」可能反而拖慢交付，並侵蝕團隊的自主性。

反樣式二：頻繁調動團隊成員#

這會導致極度不穩定的團隊——依專案組建、結束後立刻解散，也許留下一兩位工程師處理應用程式的「加固」與維護階段。

表面上有更高的彈性、更快回應期限的觀感，但組建新團隊與反覆切換情境的成本被忽略了（或不自覺地被算進專案估算中）。

一台電腦放在 A 室或 B 室，效能都一樣；但一位工程師被放進 A 團隊，表現可能與放進 B 團隊截然不同。

組織必須刻意設計團隊，方法是追問這些問題：

• 依據我們的技能、限制、文化與工程成熟度、所欲的軟體架構與業務目標，哪一種團隊拓撲能幫我們更快、更安全地交付成果？
• 我們如何在變更的主流動路徑上減少或避免團隊之間的交接？
• 為了維繫系統的可行性並鼓勵快速流動，軟體系統的邊界該劃在哪裡？
• 我們的團隊如何對齊到那些邊界？

為變更的流動而設計#

建造與營運大規模軟體系統的組織，正轉向那些強調「從概念到可運作軟體之變更流動」的組織設計——我們或可稱之為「低摩擦」的軟體交付。

較舊的組織模型——部門之間的職能穀倉、大量使用外包、團隊之間反覆交接——無法提供「速度下的安全」，也提供不了那些「為了日復一日回應顧客與市場條件而持續演化業務服務」所必需的組織回饋機制。

誠如史丹佛（Naomi Stanford）所指出的：「若一個組織是經過反思而設計的，它成功的機會會更大。」

在檢視團隊互動的設計時，組織必須考慮的絕不只是人的靜態配置。

形塑團隊間的相互溝通，以促成流動與感知#

許多組織在「團隊如何互動以建造與營運軟體系統」上有重大缺陷。具體而言，這些組織似乎假設軟體交付是一個單向流程：從規格到設計，從設計到編碼，從編碼到測試與發布，從發布到日常維運（BAU）。

這種線性、逐步、且各階段通常還分屬獨立職能穀倉的變更序列，與現代軟體系統的變化速度與複雜度完全不相容。

「軟體開發流程幾乎不需要（或完全不需要）從軟體在線上環境的實際運行中學習」——這個假設根本上就是錯的。

相反地，讓軟體開發團隊接觸到線上環境中運行之軟體的組織，相較於穀倉化的競爭者，往往能更快處理使用者可見與維運上的問題。

在《Accelerate》中，作者群蒐集了全球數百個組織的軟體開發實踐資料，得出結論：「我們必須……確保交付團隊是跨職能的，讓設計、開發、測試、部署與營運系統所需的所有技能都在同一個團隊裡。」

重視「來自線上（正式）系統之資訊回饋」的組織，不僅能更快改善軟體，也能發展出對顧客與使用者更高的回應力。

這種優越的「感知」能力，來自把第一線員工與團隊視為「關於組織所處市場與環境之訊號」的高價值來源。

當我們把這種感知不只用在組織的邊緣，也用在組織內部——團隊之間——就能獲得一項大幅增強的策略能力：快速發現平台、服務與介面中的缺陷，使我們得以及早處理，從而提升整體 IT 的成效（第三部會進一步探討這種組織感知）。

DevOps 與 DevOps 拓撲#

這種「跨職能團隊建造、測試並營運自己的軟體」的組織感知涅槃，在 2009 年對多數組織而言還是陌生概念。當時，團隊設計與互動上的經典反樣式——把開發與維運團隊（及其他團隊）的職責徹底切開——相當普遍：軟體發布被扔過「圍籬」或「牆」，溝通多半靠工單完成。在 DevOps 圈，這被稱為「混亂之牆」（wall of confusion）。

DevOps 運動在 2009 年前後因這股 Dev 與 Ops 之間日增的摩擦而出現，並被「敏捷日益主流化、維運團隊被要求更頻繁部署的壓力」所凸顯。問題在於，許多導入敏捷的組織並未明確處理「軟體交付速度」與「維運團隊提供資源或部署更新之能力」之間的落差。團隊之間的錯位越發明顯，導致糟糕的行為與對工作流動的失焦。

DevOps 的一項關鍵貢獻，是提高了人們對「團隊在交付鏈上如何互動（或不互動）」所遺留之問題的意識——這些問題造成延遲、返工、失敗，以及對其他團隊缺乏理解與同理。

而且顯然這類問題不只發生在應用開發與維運團隊之間，也發生在與 QA、資安、網路等許多其他參與軟體交付之團隊的互動中。

儘管許多人把 DevOps 看成主要在處理自動化與工具的技術面向，但只有那些同時處理團隊之間根本錯位的組織，才能取得導入 DevOps 的全部潛在效益。

DevOps 拓撲目錄#

DevOps 拓撲目錄最初由史凱爾頓於 2013 年創建、後由派斯擴充，是一份線上蒐集的團隊設計與互動樣式（及反樣式），適合用來啟動關於技術團隊之職責、介面與協作的對話。關鍵在於，成功的樣式強烈依賴於脈絡面向，例如組織與產品規模、工程成熟度，以及共享目標。

這些拓撲成為企業軟體交付在團隊結構上的有效參考；然而它們從來不是靜態結構，而是「受多重因素（交付的產品類型、技術領導、維運經驗）影響之某個時間點的描繪」。其中隱含的想法是：團隊應當隨時間演化與變形。

DevOps 拓撲反映兩個關鍵想法：

1. 為 DevOps 成功而建構團隊，沒有一體適用的取徑。任何拓撲的合適性與成效都取決於組織脈絡。
2. 有幾種拓撲已知對 DevOps 成功有害（反樣式），因為它們忽視或違背了 DevOps 的核心信條。

簡言之：對任一組織而言，沒有唯一「正確」的拓撲，但有好幾種「糟糕」的拓撲。

成功的團隊樣式#

選錯拓撲，不必然代表所欲的成果本身不好。常見的情況是：某個拓撲之所以產不出那些成果，是因為注意力只放在新的團隊結構上，而對周遭的團隊與結構考慮不足。

不同類型團隊的成功，不只取決於成員的技能與經驗，也取決於（也許更重要的）周遭的環境、團隊與互動。

功能團隊需要高工程成熟度與信任#

功能團隊（feature team）指的是跨職能、跨元件的團隊，能把一個面向顧客的功能從構想一路帶到正式環境，交到顧客手上，理想上還會監控其使用狀況與效能。

這是樣式還是反樣式？如你可能已經猜到的：視情況而定。

跨職能的功能團隊可以為組織帶來高價值——交付跨元件、以顧客為中心的功能，比「多個元件團隊各自變更再同步進一個發布」快得多。但這只有在功能團隊自給自足時才會發生，也就是他們能把功能交付到正式環境而不必等待其他團隊。

功能團隊通常需要碰多個程式碼庫，而這些可能歸不同的元件團隊所有。

若團隊的工程成熟度不高，他們可能會抄捷徑——例如不為新的使用者工作流自動化測試，或不遵守「童子軍規則」（讓程式碼比你發現時更好）。長期下來，隨著技術債增加、交付速度變慢，團隊之間的信任會崩解。

除非跨團隊紀律很高，否則多個團隊在同一程式碼庫上工作的累積效應，會導致共享程式碼失去擁有權。

產品團隊需要一套支援系統#

產品團隊（product team）在目的與特性上與功能團隊相同，但擁有一個或多個產品的整組功能。他們的工作要能觸及終端使用者，仍依賴基礎設施、平台、測試環境、建置系統、交付管線等。其中有些依賴他們可能完全掌控，但受限於團隊天然的認知與專業極限（見第 3 章），其他部分他們很可能需要協助。

團隊要保持自主，關鍵在於外部依賴必須是非阻塞的——也就是新功能不會閒置在那裡，等待某件超出團隊掌控的事發生。

舉例來說，要確保一個獨立的 QA 團隊「剛好在產品團隊完成新功能的那一刻有空來評估它」極其困難。團隊各有不同的工作量、優先序與問題；而且一般來說，建造與營運軟體系統的不確定性太高，光靠預先排定的時程來協調多個團隊在同一工作流上的行動，是無法成功的。堅持這種做法必然導致等待與延遲。

非阻塞依賴通常以自助服務能力的形式出現（例如佈建測試環境、建立部署管線、監控等），由其他團隊開發與維護，讓產品團隊在需要時能獨立取用。

在沒有相容支援系統的情況下建立產品團隊，只會製造更多瓶頸。所謂支援系統，是指易於消費的服務（最好透過平台導向的取徑），加上團隊不熟悉之任務所需的隨手可得專業。

缺了它，產品團隊最終會頻繁地卡在對職能團隊（基礎設施、網路、QA）的「硬依賴」上。摩擦隨之升高：產品團隊被逼著交付更快，卻身處一個不支持必要自主程度的系統之中。

雲端團隊不該替應用建基礎設施#

如果雲端團隊大體上只是傳統基礎設施團隊的改名，就無法善用雲端所提供的速度與擴展性。若雲端團隊只是複製既有行為與基礎設施流程，組織的軟體交付就會遭遇和以前一樣的延遲與瓶頸。

產品團隊需要自主權，得以在雲端佈建自己的環境與資源，必要時建立新的映像檔與模板。雲端團隊仍可擁有佈建流程——確保必要的控制、政策與稽核到位（在高度受監管的產業尤其如此）——但其焦點應放在提供高品質的自助服務，同時滿足產品團隊的需要與適當的風險與法遵管理需求。

換句話說，必須把兩件事拆開：

• 設計雲端基礎設施流程的職責——由雲端團隊負責
• 實際佈建與更新應用資源——由產品團隊執行

SRE 在規模夠大時才合理#

網站可靠性工程（Site Reliability Engineering, SRE）是 Google 為應對其全球數百萬使用者系統而首創的軟體應用營運與改善取徑。若完整採用，SRE 與過去的 IT 維運有顯著差異，因為它聚焦於「錯誤預算」（error budget，即界定何謂可接受的停機量），以及 SRE 團隊「有權退回品質不佳之軟體」的能力。

SRE 團隊的人需要優秀的編碼技能，並且——關鍵地——具備用程式碼自動化重複性維運任務、從而持續減少苦工（toil）的強烈動力（與餘裕）。Google 工程副總崔納（Ben Treynor）說，SRE 就是「當你叫一個軟體工程師去設計維運職能時，會發生的事」。

SRE 模型透過服務水準目標（SLO）與錯誤預算，在「新功能的速度」與「讓軟體變可靠所需的任何工作」之間取得平衡，從而在開發團隊與 SRE 團隊之間建立健康且有生產力的互動。

沒錯：不是 Google 的每個開發團隊都用 SRE。Google 的 SRE 多根（Jaana B. Dogan）說：「如果你的專案規模在縮小，就縮減 SRE 支援；如果規模根本不需要 SRE 支援，最終就讓你的開發團隊自己擁有 SRE 工作。」

SRE 團隊與應用團隊關係的四個階段

SRE 是一套高度動態的大規模軟體系統建造與營運取徑。SRE 團隊在不同時期與應用開發團隊有數種不同互動，取決於：軟體有多少使用者、軟體有多可靠、從產品觀點軟體需要多高的可用性等。

1. 初期：應用開發團隊獨自建造並在正式環境營運軟體，直到規模值得 SRE 介入。
2. 第二階段：隨著應用使用量增加，SRE 向應用開發團隊提供指導，說明如何讓應用在全球規模下運作得更好。
3. 第三階段：當規模足以支撐時，SRE 全面介入，負責營運與支援該應用（但仍與應用團隊協作）。此時該應用的產品負責人必須決定合適的服務水準目標與對應的錯誤預算。
4. 回退：若某個時點該應用因可運作性不足而變得太難支援，或應用使用量下滑，應用團隊便重新承擔維運職責。若應用的可運作性改善到足以滿足錯誤預算、且使用量再度上升，關係可以回到第三階段。

SRE 團隊與一個或多個應用開發團隊之間有強烈關係，是一種親和性。就這點而言，SRE 模型可視為一種特殊的流動對齊團隊。

SRE 與應用開發團隊之間的動態互動，是 SRE 取徑之所以在 Google 與類似組織運作良好的原因之一：它承認建造與營運軟體系統是一項社會技術活動，而非工廠裡的裝配線。

然而 SRE 模型不是輕鬆選項。Google Cloud 客戶可靠性工程總監倫辛（Dave Rensin）說：「要達到 Google 等級的維運嚴謹度，需要你這一方持續的投入。」

SRE 是「應用開發團隊對可運作性的承諾」與「SRE 團隊的專業」之間的動態平衡。若缺乏高度的工程紀律與管理層的投入，這個微妙平衡很容易退化成傳統的「我們 vs. 他們」穀倉，導致服務反覆中斷與團隊間的不信任。

選擇拓撲時的考量#

從上述諸多團隊結構例子可以看出，組織的脈絡會影響特定類型團隊能否成功設立。以下是選擇拓撲時應納入考量的因素。

技術與文化成熟度#

處於不同技術與文化成熟度階段的組織，會發現不同的團隊結構才有效。

• 例如到 2013 年，Amazon 與 Netflix 都已建立成熟策略，以跨職能團隊對其提供給組織其他部分的服務負起端到端責任。
• 與此同時，導入敏捷、轉向小批量交付的傳統組織，往往缺乏「長期維持可持續步調」所需的成熟工程實踐（如自動化測試、部署或監控）。他們可以從一個臨時的 DevOps 團隊中獲益——由身經百戰的工程師帶入專業，更重要的是透過在共享實踐與工具上的協作把團隊拉在一起。

但若這樣的 DevOps 團隊沒有清楚的任務與到期日，就很容易跨過那條細線——從這個樣式落入對應的反樣式：組織裡又多了一個知識被隔間化（設定管理、監控、部署策略等）的穀倉（DevOps 團隊）。

另一方面，對於「全面成功導入 DevOps 需要由上而下與由下而上同時對齊」的大型企業，投資一個 DevOps 布道者團隊是合理的——他們提高意識，並在組織其他部分積極宣傳初期成果。

組織規模、軟體規模與工程成熟度#

選擇好的團隊拓撲高度依賴組織及其團隊的處境脈絡。至少，組織規模（或軟體規模）與工程成熟度應當影響 DevOps 脈絡下的拓撲選擇。

• 低成熟度組織需要時間才能取得「自主端到端團隊」所需的工程與產品開發能力。在此期間，較專業分化的團隊（開發、維運、資安等）是可接受的取捨——只要他們緊密協作以最小化等待時間並快速處理問題。
• 中等規模的組織或軟體：強調團隊之間快速緊密協作的樣式運作良好。
• 規模持續增大時：把底層基礎設施或平台「即服務」提供出來，能在「面向使用者的服務可靠度」與「滿足顧客期待的能力」上帶來重要好處。
• 若組織具有高度工程成熟度與紀律，前述 SRE 模型在規模化時也可能有效。

拆分職責以打破穀倉#

有時我們可以拆解某個團隊的職責集合、並賦權其他團隊承接其中一部分，藉此移除或減輕對該團隊的依賴。

例如近年許多組織日益採用的一種樣式：把資料庫開發（DB Dev）與資料庫管理（DBA）的活動分開。

DB Dev 與 DBA 的活動過去常被合併在資料庫團隊這個職能穀倉裡；但「更快速變更流動的需要」加上「共享資料庫使用的減少」，使得拆開這兩種角色更為有效。實務上，DBA 角色通常會成為平台的一部分——無論是內部自行運行，或作為雲端供應商「資料庫即服務」產品的一部分（平台詳見第 5 章）。

以上所有例子都凸顯了一件事的重要性：思考團隊的能力（或能力的欠缺），以及那如何在團隊之間造成依賴。

當工作量增加時，不要只是複製團隊或加人，而要思考：哪些團隊間依賴我們應該移除，哪些應該明確接受（因為好處大於壞處）。

團隊之間的依賴與等待時間#

要讓團隊職責定義良好、能獨立工作、並為流動而最佳化，偵測並追蹤團隊之間的依賴與等待時間至關重要。

• 迪格蘭迪斯（Dominica DeGrandis）在《Making Work Visible》中建議使用實體依賴矩陣，或在看板卡片上使用「依賴標籤」，以辨識並追蹤依賴，並據以推斷讓這些依賴順利運作所需的溝通：「把重要的跨團隊資訊可視化，有助於跨團隊溝通。」
• 史特羅德（Diane Strode）與哈夫（Sid Huff）2012 年論文〈A Taxonomy of Dependencies in Agile Software Development〉提出三類依賴：知識依賴、任務依賴、資源依賴。這樣的分類法有助於提前指認團隊之間的依賴與工作流動的潛在限制。

無論使用何種工具，重要的是追蹤每個區域的依賴數量，並建立對特定情境有意義的門檻與告警。

依賴數量不應被允許無節制地增長；相反地，這種增長應當觸發團隊設計與依賴關係的調整。

Spotify 靠一份簡單的試算表偵測與追蹤小隊、部落之間的相互依賴。它會標示某個依賴是落在同一部落內的小隊（可接受），還是不同部落（可能是團隊設計或工作分派有誤的警訊）。這個工具也追蹤該依賴多快會衝擊到被依賴方團隊的流動。

用 DevOps 拓撲演化組織#

以上處理的是「在某個時間點影響特定拓撲成效」的種種面向。但組織、團隊與策略會隨時間改變——可能出於刻意的行動方針（例如以 DevOps dojo 提升團隊的文化與工程成熟度），也可能因市場與技術的變化。

許多組織把 DevOps 拓撲目錄當作有效團隊結構的「快照式」建議；但有些組織更進一步，思考出一條演化路徑：從今日脈絡下最合理的拓撲，走向一個能匹配組織能力與限制之預期變化的終局目標。

本章總結：採用並演化符合當前脈絡的團隊拓撲#

被動地設立新團隊結構與職責——因為要擴展產品、採用新技術或回應新市場需求才臨時觸發——在當下或許有幫助，但往往達不到深思熟慮之拓撲所能有的速度與效率。

因為這類決策常是以單一團隊為單位做出的，它們缺乏對重要的組織層級因素之考量：技術與文化成熟度、組織規模、軟體規模、工程紀律，或跨團隊依賴。

結果就是：團隊結構只為暫時或範圍有限的問題最佳化，而無法隨時間適應新問題。

「DevOps 團隊」反樣式是最典型的例子。紙面上，把自動化與工具專家找進來加速軟體交付與維運很合理。然而，如果這個 DevOps 團隊被要求去執行每個應用交付路徑上的步驟，而不是幫忙設計並建造應用團隊能自主倚賴的自助服務能力，那它很快就會變成應用團隊的硬依賴。

關鍵在於：明確考量各種正在作用的面向，採用在組織脈絡（它傾向緩慢演化）下行得通的拓撲，而不是去套用那些「解決某個當下特定問題或需要」的拓撲。

具體到 DevOps 脈絡，DevOps 拓撲能幫忙釐清哪些拓撲在哪些脈絡下行得通。具前瞻性的組織會對團隊設計採取多階段取徑，理解今天最有效的做法，未必在幾年後、甚至幾個月後仍然如此。