【千人平臺工程煉成記Part 2】因應開發人力暴增到2千，Zalando以激進敏捷模式展開組織大變革

在2015年時，歐洲大型電商Zalando擁有1萬名員工，超過1千名工程師，200個開發團隊。甚至，開發人力在2015年時只有600人，到了2018年，暴增到2,000人的龐大規模。

再一次的開發人力倍增，也讓Zalando再一次遇到了挑戰更大的開發複雜性協調課題。但這一次，Zalando決定找出一種夠安全，又能讓龐大團隊更敏捷的根本解法。

Zalando找來30名最資深的工程師聚在一起，多次討論後歸納出Zalando所面對的三大問題。

第一個問題是龐大的系統。隨著業務成長和多國據點的擴張，Zalando的程式碼越來越多，程式碼間的關聯也越來越複雜。新手工程師很難快速了解這套系統，得花上好幾個月熟悉後，才能開始有生產力。而且，程式碼數量越多，伴隨的程式臭蟲也越多，為了確保系統運作的安全，衍生了更多檢查，再度拖慢了整體的開發速度。

第二個問題是系統間高度互聯（Interconnected Systems）。過去，Zalando開發團隊的目標是盡可能地優化每一個功能的執行速度，而不是簡化系統。這麼做的結果是，這些系統之間的相依性越來越高，也越來越難以預期和不直覺。任何一個系統的變動，都可能對其他系統產生連帶的影響，增加了整體系統的脆弱性。

最後一項，30位資深工程師們共同提出的大問題是，Zalando用了「無聊技術」。當他們所用的技術越穩定、可靠，也代表了這些技術越老舊，就越讓工程師感覺到無聊。

「這聽起來不像是問題，但從人員招募角度來看，這是一個大問題。」參與Zalando最近4年SRE戰略發展的第一線工程主管、Zalando前工程經理Andrew Howden如此坦言。

剛從大學畢業的年經工程師，興奮地拜讀了所有Google最新的部落格文章，上面介紹了最新的K8s、容器等雲原生新興技術，可是Zalando用的卻是十年前的Java技術架構，很難引起年輕工程師的興趣。

展開組織大變革，決定擁抱激進敏捷模式

「Zalando需要改變，需要徹底改變，我們將這種變革稱為激進敏捷（Radical Agility）。」Andrew Howden表示，這真的是一次組織面的結構性變革。

這項變革策略的核心是，不再由單一大型業務單位主導決策，改由多個平行小單位，可以各自協調來決策。換句話說，等於是從序列式的決策流程，改為由平行的相關團隊自己決定，不用照會其他無關的業務部門。這意味著，可以盡可能減少需要參與的溝通對象，來推出新的業務功能。

為了提高團隊平行運作的能力，Zalando採取了新的所有權制度，定義了一種新的角色，稱為專責所有權人（Dedicated owner），或者可用臺灣社群熟悉的俗稱「爐主」來形容，由這個人來負責一項業務的所有產品、成果、技術的主要決策，也由他負責監督所有狀況的回報。

在供應端、需求端、數位體驗、用戶介面、數位基礎設施的部門中都可以設立爐主這類角色。爐主有很大的自主權能選擇要採取什麼樣的作法，但他得要對這個作法的成敗負起全責。

爐主帶領的團隊採取了跨部門混合編組，找來這項業務上線所需的相關人力，包括開發人員、產品人員、法務、監控人力等。這些人背後都有各自所屬部門的主管。例如開發人員背後還有開發部門的經理。

「以這種方式重組運作方式，就等於是重新組合溝通流程，立即遇到的問題就是，所開發的軟體會受到什麼影響？」Andrew Howden指出。

敏捷領域常參考的康威定律（Conway's Law）提到一個觀點，軟體架構會受制於企業內部的溝通架構。Andrew Howden從另一個角度來看，他指出：「想要重新改變企業的溝通方式，就必須重新改變軟體架構，否則它會自行發生。」

大力擁抱微服務，從100隻到4千隻微服務

所以，Zalando在技術上決定擁抱微服務架構，而在組織面，也將人員分為五、六人規模的小組，由每個小組負責一項微服務。對這個小組說，只需要負責這個微服務，其他的微服務不是你們的問題。

Zalando大力推動各項微服務的開發，從一百個服務，暴增到數千隻，而且持續增加。Zalando曾公開過，在2019年，微服務總數足足超過了4千支。

新的挑戰是，不能再靠人工團隊的測試來確保軟體發布的正常，而是得依賴大量的自動化測試，來驗證相關系統的邊界是否如常運作。

Zalando決定採取全新技術架構和組織架構之後，一開始還建立了一群待命值班團隊，當時有3個待命團隊來確保正式環境的運作。

一開始只有100項服務時，這個作法運作得相當好。但是，隨著微服務的數量，增加到數千隻，還要考量這些微服務間的互動，以及追蹤這些服務隨時間的演變，單靠3個值班團隊，就沒有能力應付了。「當時的管理層，做出了一個影響應用程式開發後的日常維運，非常重要的決定，那就是『自己打造的程式自己管。』（You build it,you run it.）。」Andrew Howden指出。

打造這隻軟體的開發人員需要負責這隻軟體的待命、維護基礎設施、訂定CI/CD流程等，任何將這隻應用程式送到正式環境所需的一切事務，都由打造軟體的團隊來負責。

但這個決定，也讓待命值班作法更加分散，開始影響到待命支援的品質。尤其有些協作經驗不足的團隊，遇到跨團隊的工作時，就會出現責任推來推去，「這是你的問題」或「這不是你的問題」的爭執。

另外，在基礎架構管理上，也遇到新的挑戰，為了讓爐主負起全責，Zalando的作法是讓每一個爐主有一個專屬的AWS帳號，這就像是對他們說，「這個帳號就是你的信用卡，你可以做你認為對的事。」這種放權，有助於讓開發人員打造了傑出、複雜又有趣的架構，但是，基礎架構管理是一種專業，不能讓擅長軟體開發的工程師自己亂嘗試。

打造集中式平臺，讓技術知識民主化，人人都能取得維運經驗

尤其，Zalando的挑戰是2千名工程師，超過1千套系統的規模，因此，「Zalando需要發展出一種做法，可以大規模地將知識民主化（Democratization of knowledge ），讓人人可以取得正式系統運作的經驗。」Andrew Howden表示，唯一的方法就是建立一個集中式的平臺來分享知識，這正是平臺團隊可以發揮之處。

Zalando有一個「數位基礎（Digital Foundation）部門」，為其他各單位提供一套通用的能力。

在2014年到2018年之間，這個數位基礎團隊發布了一些重要的內部產品，包括了像是應用程式註冊表（Application Registry）、容器化平臺服務（Docker-base platform as a service）、CI/CD機制、API探索及驗證工具、開發者控制臺等。

這個AP註冊表服務的名稱是Kio，開發團隊在將自己打造的程式部署到正式環境之前，要先到這個集中式的AP註冊表上登記，沒有登記到Kio上的AP就不能部署。Kio服務也會提供一套指南，涵蓋了各單位部署AP的相關指引。這個註冊表提供了工程師詳細查看各種業務和功能的索引，也有助於處理資安問題。

而容器化平臺服務則用來執行容器、提供服務、保管映像檔、支援部署、授權、憑證派發、產品存取控管、稽核和Log管理等。另外也用Jenkins伺服器建立了一系列CI/CD機制，後來更在Docker平臺上，發展出了一套持續部署平臺（Continuous Deliver Platform，簡稱CDP），負責處理在正式上線前的發布階段的任務，像是映像檔和二進位檔驗證、合規檢查等。

另外還有一款API探索和驗證工具，因為Zalando採取API優先（API First）的策略，開發工程師得採取Swagger工具來建立符合標準的API，在RESTful API和事件指南提供了相關API定義和驗證。

最後一項的開發者控制臺（Developer Console），這是一個內部網站，可以讓開發人員查看自己的CI/CD工作流。

積極發展這些工具和平臺，反映出，「這是Zalando第一次意識到開發者平臺的重要性。」Andrew Howden指出。

2016年開始擁抱SRE

Zalando在2016年時，決定開始擁抱SRE（網站可靠性工程），成立了SRE團隊。這一年也是Google發表《Site Reliability Engineering: How Google Runs Production Systems》 這本書的那一年。

Zalando先進行內部問卷調查，了解各團隊對於SRE角色的期待，來凝聚所有人對SRE定位的共識，歸納出5項SRE的能力：SRE具有軟體工程能力、維運思維、系統工程能力、軟體架構技能和問題解決能力。這五大能力也成了Zalando建立內部人才庫的重要方向，不只SRE，更用來要求各種技術角色的工程師，都要具備這五大能力。

接著，Zalando成立了第一個SRE團隊後，第一件事就是設計SLI（服務水準指標） ，並且訂出想達成的SLO（服務水準目標），還開發出一款SLO報表工具。同步也舉辦工作坊，對內部上百團隊的產品PM和工程師介紹SRE，還在一年一度的網路購物周準備計畫中，舉辦SRE工作坊，來討論購物潮的各項網站可靠性設計。不過，第一次擁抱SRE，最後沒有發揮原本預期的作用。

第一次導入SRE失利的原因

Zalando曾在工程部落格上公開了第一次SRE導入失敗的主因，雖然蒐集到大量的SLI指標維運數據，但是空有SRE數據， SRE團隊沒有善用這些維運數據來改善開發，也無法解決原本待命支援不足的問題。SRE導入一段時間後不如預期，Zalando高層決定暫時喊停。

原本Zalando按照產品叢集來建立SRE團隊，一個團隊負責一個叢集，一個SRE團隊負責同一個產品網域下的所有維運責任。

後來，Zalando高層取消了原本在各產品下所設置的SRE團隊，改將SRE工作交給各產品團隊中的交付小組（Delivery Team）接手，讓他們接手自己產品中關鍵服務的維運，要求產品交付團隊必須具備SRE能力，來負責各自所負責的關鍵產品的待命工作。

雖然裁撤了SRE團隊，但是Zalando沒有停止採用SRE的實踐，Zalando開始改良SRE工具和SRE做法，例如從產品管理層級來管理SLO的達成情況，而非監控微服務工程層級的龐大SLI指標數據，也不再用當機事件的指標數據，改用事件徵兆來設計警示機制，還設計了新的事件處理流程，進一步區分不同的改善做法對顧客或是業務能帶來的效益，優先採取更有利的做法。

Zalando也開始認真累積SRE維運指標的成效數據，來衡量這些指標是否符合指標設計的目標。

「當年，整體組織還沒有準備好要以SRE方式來思考可靠性。」Andrew Howden事後回顧當年的考驗。但他認為，更重要的一點是，「數位基礎部門的設立，代表了Zalando真正開始重視開發者體驗，成為企業優先考量的事。」

未完，繼續閱讀

【千人平臺工程煉成記Part 3】業務決策和工程創新讓網購周業績暴增後，聚焦開發者體驗優化也再次擁抱SRE