從 Etsy 團隊看敏捷架構的設計

© dylan nolte  

孫子說：不用鄉導者，不能得地利。

背景

Etsy是我們最喜歡的一個從事手工藝品或古董線上市場的科技公司。該公司擁有穩定的技術團隊，技術運維由約翰·阿爾斯帕瓦掌舵，其網站偶爾也經歷網站中斷。

2012年7月30日，發生了這樣一件事，員工為支援多位元組字符集的語言進行了資料庫升級。一切都是按照計劃進行的，他們先升級了一個生產資料庫。資料庫升級，尤其是改變靜態資料的編碼，存在著資料破壞或丟失的風險。為此，該小組精心制訂了一個在一段時間內把剩下的伺服器緩慢升級的計劃。他們只升級一臺伺服器，而讓其他伺服器的升級基本上準備就緒。

Etsy往往有許多變更在排隊進入生產環境。網站在夜間備份的時候速度緩慢，更快的備份方案正在排隊等待實施的時機。為了推出解決備份問題的修復程式碼，Etsy的工程師們使用了自動化的工具，以確保伺服器的一致性。經過測試後，他們使用該工具將修復的應用版本釋出到備份中，在不干擾網站效能的基礎上，期待著稍後確認備份的成功。他們當時並不知道部署改進備份的部分也同時升級了資料庫的語言。

當意識到大約60%的Etsy的資料庫伺服器在升級字符集的同時仍然在服務使用者時，他們迅速地關閉了網站，以防止資料損壞。回應這一事故的團隊由多個部門的人員所組成。正如阿爾斯帕瓦說的那樣，“不只是一個團隊在響應事故”。在Etsy，很多人參與了24/7值班小組。沒有問題管理者存在的必要，因為每個團隊擁有自己所研發的服務。在某些情況下，如搜尋團隊，由來自不同領域的員工組成的敏捷開發團隊作為一級響應。搜尋團隊首先接到警報，在必要的時候，把問題升級到的技術運維。

團隊一旦能夠確認資料庫是正確的而且表現正常，就恢復網站的服務。同時，他們與社群透過EtsyStatus網站（）溝通。

這個例子顯示出敏捷團隊（5到12人的跨部門團隊，由經理、工程師、QA人員、團隊和DevOps人員組成）如何從架構設計開始到生產支援一直擁有自己的產品或服務。

本文將透過探討功能和系統設計，來解釋敏捷組織是如何實現系統相關的設計，以及獨立的敏捷團隊如何遵循標準。

敏捷組織中的架構

在功能型組織裡，個人是按照技能、領域或專業組織起來的。然而，幾乎每個專案都需要協調整個團隊，這意味著跨部門協調。對SaaS提供商尤其如此，因為SaaS的責任不僅是軟體開發和測試，還要運維和支援，所以屬於公司的技術團隊。這導致一定程度的情感型衝突。衝突的程度取決於許多因素，但我們希望儘可能減少這些因素。回想一下，情感型衝突是“壞”的，衝突集中在角色和所有權方面，涉及的問題往往是“誰”擁有或任務應該“如何”做？

這種型別的衝突具有破壞性，會導致團隊成員身心疲憊。在身體上，它可以讓交感神經系統（與下丘腦激發的打架或逃跑綜合徵相同的系統）釋放壓力激素皮質醇、腎上腺素和去甲腎上腺素。在組織上，團隊可能會因為爭奪產品和服務的所有權，導致封閉的思路和不良的結果。相反，敏捷組織打破功能型組織的鬥爭，並授權於團隊，消除矩陣組織結構所面臨的組織邊界問題。

敏捷組織是由5至12人組成，擁有設計、開發、交付和支援面向客戶的產品或服務所必需的技能。這些團隊是跨部門和自成一體的。他們有權做出自己的決定，而且不需要外界的認可。他們有能力處理產品或服務的全生命週期。當團隊以服務為主線跨部門組織起來，同時具有自主權，就可以顯著減少情感型衝突。當團隊成員擁有共同的目標，並且不再需要爭論誰負責什麼或誰應該執行某些任務時，團隊就會榮辱與共。每個人都會負責確保所提供的服務符合業務目標。

在SaaS產品服務方面，創新的增加往往是透過度量更快的市場響應時間、更好的產品質量和更高的可用性來確定的。這種創新的驅動力降低了情感型衝突，提高了認知型衝突、多樣性和授權管理的水平。敏捷的組織結構提供了所有這些驅動力，其結果往往是創新的顯著增加。

架構的所有權

創新、更大的自主權和更少的情感型衝突聽起來很棒。然而，與更大的權力伴隨而來的是更大的責任。這些敏捷團隊擁有服務或產品的架構。換句話說，他們不依賴獨立的架構團隊，而靠自己完成產品的設計和實施。在實踐中這是如何實現的呢？

敏捷團隊由擁有所需全部技能的人員組成，確保團隊能進行產品的自主研發。典型的團隊成員包括產品經理、幾個軟體開發人員、質量保證工程師和DevOps工程師。如果該公司有軟體架構師，架構師也被放在敏捷團隊裡。這樣的團隊構成應該讓你想到第13章的JAD過程。如果敏捷團隊設計和研發高可用和可擴充套件的產品與服務，其成員需要任何完成同樣任務的其他團隊相同的技能。JAD像一個樂隊助理，在以功能為導向的團隊裡，建立跨領域設計是敏捷團隊的內在特質。

我們知道經驗、技能和關係的多樣性，有助於更好地解決問題—架構功能、場景、解決方案、錯誤修復或提供產品。最好的解決方案來自於包括多個領域代表的團隊，他們利用各自不同的觀點和經驗來解決這個問題。

如果請軟體工程師設計一個門，他或她會馬上開始思考門的工作原理，鉸鏈如何運作，門把手如何轉動，等等。如果請產品經理設計門，他或她可能開始考慮門應達到的效益，其他競爭對手的門都有什麼功能，最後一輪使用者測試的結果。如果請系統管理員設計門，他或她會開始思考如何確保安全，如果插銷或鎖出現常見的故障應該如何恢復。當我們把這些不同的觀點都集中起來，就可以設計出一個更強大、更具可擴充套件性以及更高可用性的產品。

關係的多樣性用來衡量團隊成員的個人或專業關係網路。這對創新很重要，因為幾乎所有的專案都會遇到不同的阻礙。關係廣泛的團隊能夠在專案早期更好地識別潛在的障礙或可能遇到的問題，因為他們可以諮詢各種各樣團隊以外的人。當團隊確實遇到了障礙，這種多樣化的關係使他們的易於發現和取得資源並繞過障礙。

有限的資源

當一個靈活的團隊有多樣化的技能、廣泛的人脈關係以及各種各樣的經驗借鑑後，團隊成員設計、研發、部署和支援高度可靠和可擴充套件的產品的能力會更強。如果公司不能為每個團隊配備一位架構師，或者六個敏捷團隊只有兩個DevOps工程師會怎麼樣？

這個問題的不僅出現在資金有限的初創公司，也同樣存在於現金充沛的高增長型公司。在第一種情況下，公司無法僱用很多架構師、DevOps工程師和其他想要的專業技術人員。在第二種情況下，公司可能無法如願吸引和留住許多架構師或DevOps工程師。團隊的成長常常是非同步的，先招聘軟體開發人員、然後是產品經理、再後是質量保證工程師、DevOps工程師，最後是架構師。填補團隊的週期可能花費一年到18個月的時間。沒有一家公司會讓軟體開發人員閒下來等待架構師的加入。但是在這種情況下，團隊該怎麼做呢？

當面對有限的人員和資源時，團隊通常會試圖以現有的有限資源來對付。這種方法可能會為公司帶來相當大的風險。試想一下沒有足夠的產品經理的情景。結果可能是倉促編寫的使用者場景描述和排程很差的專案優先順序，結果導致嚴重的錯誤。

敏捷團隊的第一步是確保他們有必要的資源來完成專案。

一旦關鍵資源缺失，這個團隊就會處於危險之中。爭取必要資源的辦法是使用看板來直觀地顯示研發過程中的資源瓶頸，說明需要資源的業務理由。另一種方法是跨團隊共享資源。有限的資源，如DevOps工程師，可以在整個團隊共享。這些人應該被分配給多個團隊，但不是所有的團隊。就像有多個房客但不是所有的房客。例如，如果你有兩個DevOps工程師和六個敏捷團隊，把DevOps工程師1分配給敏捷團隊A、B和C，把DevOps工程師2分配給敏捷團隊D、E、F。這樣，團隊會感到與DevOps工程師有某種程度的關聯性。他們開始思考“DevOps工程師1是和我一起配合的人”而不是“我們有兩個DevOps工程師的資源池，要找他們幫忙就要提交請求來排隊”。看到區別了嗎？一方面我們打破了壁壘，另一方面可以確保他們和團隊一起成長。

標準

在多個團隊情況下，如何保持標準，是一個不變的主題。如果我們允許每個敏捷團隊自主決定哪種模式、基礎庫、框架甚至技術，公司如何受益於規模的擴充套件？工程師如何在團隊之間調動的過程中共享知識？在很多情況下，這些問題的答案是“那要看情況”。

這取決於組織、領導和團隊成員。讓我們看一些不同的方法。

“規模經濟”一詞是指企業因其經營的規模而實現的成本優勢。基本的概念是，因為固定成本分散在更多的輸出單位，每單位的輸出成本隨規模的增加而減少。這種思想可以追溯到亞當·斯密（1723～1790）和透過分工獲取更大的生產效益的概念。

對於工程團隊，規模經濟來自於諸如有關技術或經營方式的知識共享。如果從專案的角度把軟體研發服務的成本分解成固定成本的和可變成本兩個部分，我們可以得到如下的結果。固定成本包括軟體開發人員的知識和技能。我們在每個迭代為此付出，無論是為一個場景寫程式碼還是為50個場景寫程式碼，成本都一樣。每個迭代的程式碼完成量越多，固定成本的分攤就越小。如果只完成一個場景的程式碼，這個場景就消耗固定成本的100%，如果我們的寫20個場景的程式碼，每個場景就只負擔5%的固定成本。如果每個軟體開發團隊（敏捷團隊）必須是不同的語言、技術或過程的專家，這個知識的固定成本只由負責那些場景的單一程式碼團隊負擔。如果所有的團隊都可以利用彼此的知識，那麼成本就可以由所有的團隊來分擔。

一些組織認為應該允許團隊對所有的事情獨立做決定，最好的想法就會滲透到整個團隊。其他組織採取不同的方法，把團隊成員集中在一起制訂出大家要共同遵守的標準。我們先來看看Spotify的數字音樂服務是如何解決敏捷團隊的架構設計問題的。然後我們將以此方法與Wooga作對比，Wooga是一個社交遊戲公司，其採用的方法稍有不同。

Spotify把每個團隊稱為小組，類似於一個Scrum團隊（敏捷團隊）。小組類似一個微型的初創公司，包含設計、研發、測試和配置管理服務全部所需的技能和工具。2012年10月，科內博和愛瓦森發表了論文，《擴充套件性敏捷@ Spotify，部落、小組、章節和公會》（Scaling Agile@ Spotify with Tribes, Squads, Chapters and Guilds）。“不論什麼事都有不好的一面，完全自主不好的一面是虧損的規模經濟。A小組負責測試的工程師正在想辦法解決B小組的測試人員上週剛解決了的問題。如果所有的測試人員可以跨越小組和部落的邊界聚集在一起，那麼他們可以互相分享知識和研發對所有人都有益的工具。”他們繼續探討這個問題，“如果每個團隊都是完全獨立的，不與其他隊員溝通，那麼為什麼要成立公司？”

正是這些原因，Spotify開始用章節和公會的辦法。

一個章節就是一小部分人，他們有相似的技能。每個章節都會定期開會討論其專業知識和遇到的挑戰。章節的領導作為一個業務線經理以及一個小組的成員，參與到日常工作中。一個公會是一個更加有機的和更加廣泛的興趣社群，一組想要分享知識、工具、程式碼和實踐的人。章節存在於當地的部落中（小組在部落中工作），而公會通常跨越整個組織。利用章節和公會，Spotify可以保證在整個機構共享架構標準、開發標準、圖書館、甚至是技術。章節和公會負責任協調和促進討論、實驗、並最終做出決策，所制定的標準被所有的團隊所遵守。章節和公會成員參與這些過程，負責把知識和決定返回自己的團隊，確保團隊的同事遵守決定。這種方法在專制的自上而下的方法和民主的自下而上的方法之間取得了很好的平衡。即使如此，對大型組織中的小型和獨立的敏捷團隊而言，在設計服務和產品的過程中，這也並不是唯一的方式。

在李希特的文章，《用獨立的團隊來擴充套件小的公司：遊戲公司Wooga是如何運作的》，2013年9月8日發表在在“下一代網路”（）上，作者概述了他培養獨立團隊的方法，以及向Spotify挑戰的想法。李希特是成立於2009年的社交遊戲公司Wooga的工程負責人。Wooga已經從第一年的大約20名員工，成長到2013年超過250名員工。李希特說道，“在公司的早期，大家緊密地結合在一起，不必因為等待審批而放緩。通常隨著公司的增長，管理層增加，工作就變得不那麼有效率了。我們是怎麼堅持這種文化的？我的答案是：一切圍繞著獨立的遊戲團隊。”

類似於Spotify和我們的模型敏捷團隊，李希特組織了小型的自治、跨部門團隊負責獨立的遊戲。這些團隊自己編寫和運維遊戲本身，不依賴於集中的技術運維團隊或框架。“工程師不是被迫共享或複用程式碼”是李希特對每個團隊運作的獨立水平的描述。關於社團以外個人的影響，包括公司的創始人，“這完全取決於團隊是否想聽或無視外界的意見。

然而在Wooga，要利用知識並取得一定的規模經濟，團隊要積極地分享知識。他們透過每週的工作狀態更新、閃電會談、便餐會和其他的互動來完成這個任務。這種知識共享的優勢幫助團隊避免重複同樣的教訓。正如李希特所描述的，“這樣我們可以在遊戲中嘗試新東西，當新東西奏效時，再把知識傳播到其他的團隊，這個機制很有效。”應當指出的是，團隊有共享的結果，如關鍵績效指標（KPI），但這些不構成團隊間的競爭。

Wooga的方法與Spotify的方法有很大的不同，章節和公會領導人的任務是確保整個團隊共享知識和標準。那麼哪一個是最好的？這兩種方法都是必要的，公司需要評估整個團隊需要建立哪些標準，各團隊可以自行建立哪些標準。這取決於組織的文化、成熟度和過程。作為一個領導，你覺得哪個方法更好？你是否有一種企業文化的組合，包括有經驗的個人為了公司的最佳利益可以獨立行事，或者需要更大的監督？對這些問題的回答將引導你在一個特定的時間，為組織找到最佳答案。隨著組織的成熟和發展，這種方法也可能需要改變。

敏捷組織中的ARB

如前所述，敏捷團隊提供JAD試圖實現的跨團隊設計。因此，當員工被組織成真正的自治、跨部門團隊時，JAD就顯得沒有必要。下一個問題是，“敏捷組織是否需要ARB？”答案還是“不一定”。許多我們曾經提供過諮詢服務的公司儘管有跨部門的團隊，但仍然還有ARB。ARB的主要好處是它為團隊提供了第三方的觀點，因此不會被容易傳染的自治團體思維左右。然而，如果我們把ARB放在產品的生命週期中，那麼就會影響自主性和敏捷團隊產生的市場效益。在迭代後進行ARB審查是一個增加優點和減少缺點的潛在方法。另一個選擇是召開ARB每日例會（也許在午餐），討論需要審查的任何專案。這樣，團隊就不必花相當長的時間來等待ARB的召開。

在敏捷組織裡使用ARB時，主要的目標是確保制訂的架構原則得到尊重。這有助於確保團隊在技術標準和架構原則上保持一致。ARB的第二個目標就是透過互動來教導工程師和架構師。隨著團隊規模的快速增長，或收購具有不同標準的新公司的時候，ARB變得越來越重要。最後，ARB有助於評估每個團隊成員如何理解和執行標準。評估團隊如何實現共同設計，並幫助糾正缺陷。

結論

敏捷團隊作為一種小型和自治的組織，可以獨立負責服務和產品的架構和設計。在設計方面，如果團隊要儘可能靈活，這種自主權就至關重要。JAD可以有效地確保完成跨部門的設計，跨部門的敏捷團隊依靠其本身的組成確保這個結果發生。

有時組織面臨有限的資源，比如DevOps工程師的人數比其他團隊要少。我們建議將每個DevOps工程師分給幾個團隊共用。理想情況下，團隊應該知道和他們配合的人的名字，而不是必須提交請求到佇列上。這有助於打破組織架構的壁壘。

當我們與客戶討論敏捷團隊的時候，經常有人會提出的問題是，如果團隊是完全自主的，如何確保標準可以跨團隊共享。一種方法（Spotify採用）涉及跨越敏捷團隊的章節和公會來確定並實施這些標準。另一種不同的方法（Wooga採用）是團隊很獨立而且積極透過各種論壇分享知識。最後，你可以考慮使用ARB來驗證架構原則的採用和合規情況，透過定期召開會議來回顧最近釋出的設計。

關鍵點

▲敏捷團隊應該自主行動，這意味著他們應該擁有自己的服務和產品設計。

▲ARB和JAD確保跨團隊的服務設計。敏捷團隊透過自身的構成確保這個結果。

▲當運維資源如DevOps工程師或架構師有限的時候，把他們分配給多個團隊。不要恢復取票排隊等候DevOps資源池。

▲跨團隊共享標準和知識，以實現規模經濟仍然可以透過敏捷團隊來完成。在這種情況下，可以使用各種方法。為組織選擇正確的方法取決於多種因素，包括團隊的成熟度、產品的複雜性以及對分散式命令和控制的舒適度。

本文選自架構即未來：現代企業可擴充套件的Web架構、流程和組織(原書第2版)一書，由馬丁·阿伯特、邁克爾·費舍爾著，陳斌翻譯。