在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
熱門新聞
2024-12-03
2024-11-29
2024-12-02
2024-12-02
2024-12-03