Zalando技術發展邁入了成熟期後，技術決策時不再像剛推激進敏捷時的自由，轉而由資深工程社群來主導，發展出技術雷達圖（Tech Radar）協助上百團隊的技術決策。要求各團隊都要參考這一份共用的技術推薦清單，作為新專案挑選出技術的參考，不用每次發起新專案時就得從頭進行技術評估，直接參考清單推薦來選擇。正因為每個團隊都參考了同一份技術雷達圖來挑選，Zalando就能夠確保不同專案所用的技術，都在這份共用技術清單的範圍內，來達到全公司技術面的聚焦。／Zalando

技術發展進入成熟期，靠技術雷達聚焦上百團隊技術決策

從2009到2019年，Zalando組織面歷經了多次變革，技術面也發展出一個超大規模的分散式微服務架構。根據Zalando在2022年柏林DevOpsCon上揭露了數字，2019年當時的微服務數量多達四、五千支。

這時候的Zalando的技術發展邁入了成熟期，技術決策時不再像剛推激進敏捷時的自由，轉而由一個資深工程社群來主導，發展出技術雷達圖（Tech Radar）來協助2百個團隊的技術決策。

這一份技術雷達圖的設計參考了ThoughtWorks顧問公司的作法，但發展成Zalando自己的專屬版本。

這家顧問公司將近百項項涵蓋技術、工具、平臺、框架和語言這四大類的技術名詞，按照推薦採用的程度分為四級，排列在一張圓形又分為四象限的雷達圖上。在這張技術雷達圖，會列出不同類型技術的推薦採用程度，用不同的環來代表不同推薦程度，越靠近核心的環，代表這項技術的推薦程度越高。

Zalando盤點了自己的需求，最後聚焦在軟體開發相關技術，包括了資料儲存，資料管理、基礎架構和開發語言等四大類。推薦採用程度分為四級，形成四個環，每一環代表了不同的推薦等級。這四級包括：Adopt（推薦採用）、Trial（推薦試用）、Assess（評估階段）、Hold（保留不推）。

推薦試用類技術則是是指已經在內部有成功專案的技術，而且至少用於真實問題而非模擬情境的處理，而且重視採用廣泛度，屬於高層有意願長期投資的技術才會列入這個推薦等級。而列入評估階段的技術，這是指一群有明顯潛在價值，且值得投資的技術，還透過自動分析在所有產品中的試驗計畫的資料，找出已經試驗中且值得列入Trial階段的技術。。最後一類保留不推的等級，則是不推薦但會繼續提供維護的技術，而且不只新專案不能用，也不鼓勵用於推廣性服務上，要逐漸縮小這類技術的應用廣度。

每一項技術還會附上一份技術說明文件，列出這項技術的優點，缺點，限制，使用情況和使用後學到的經驗，每一項技術都有一份文件，全部的技術文件集結成了一份技術知識庫。Zalando也整理技術雷達圖的這些推薦技術的採用範本和指南，在指南上會提供使用時常見問題說明，或是已經採用團隊的使用案例，甚至是不同替代技術間的比較等。

每隔一段時間，進行技術推薦等級的調整，首席工程師會搜集了現有技術雷達上每一項技術的真實使用數據，包括了使用量，出事紀錄，採用經驗（例如這項技術在Zalando導入多少年）的數據，再進行評分，由指定維護的首席工程師先建立一份新技術評分的試算表，再開放給首席工程師社群進行投票，決定要「升級」或「降級」

Zalando要求各團隊都要參考這一份共用的技術清單，作為新專案挑選出技術的參考，不用每次發起新專案時就得從頭進行技術評估，工程師直接參考清單推薦來選擇。正因為每個團隊都參考了同一份技術雷達圖來挑選，Zalando就能夠確保不同專案所用的技術，都在這份共用技術清單的範圍內，來達到技術方向的聚焦。

Zalando將原本的數位基礎部門改名為建置部門（Build），繼續負責打造和改善開發者平臺，專門服務開發者這一群人。建置部門開始研究開發者的顧客旅程，也就是開發者日常的工作旅程，發現開發者所用的開發平臺相當分散，每個團隊都以各自的方式，與各自成員溝通，更缺乏全公司共同的溝通語言。

解決開發者流程破碎化問題，打造開發者入口網站

為了解決開發者工作流程破碎化的問題，建置部門打造了一套開發者入口網站Sunrise（日出平臺），作為開發者每天上班時打開的第一個網站。這個平臺的使用者包括了軟體工程師，資料工程師，技術主管，資料科學家，專案經理，設計師等。

建置部門以Spotify開源的ML管理平臺專案Backstage為基礎，整合了許多Zalando內部技術工具、開發元件、實作範本和技術文件，設計出了這個內部專用的自助式開發者平臺（Internal Developer Platform），介面操作如同商用企業級協作平臺一樣的流暢，講究UX設計細節，就是為了引導開發者自己就能上手操作。甚至開發者可以在日出平臺上直接看到負責AP的常見監控數據。

開發者打開日出平臺看到的第一頁，將他們常用的資訊點都集中到這一夜，讓他們很容易就可以搜尋到所負責的特定應用和常用的API，也能很快地看到每一個應用或API的專責擁有人是誰，若有需要可以直接在這一頁提出需求單（Ticket）來尋求幫助，不用像過去得到另一個系統來申請。日出平臺首頁也整合了所有開發者所負責的AP的所有事件資訊以及可訂閱的參考文件。

工程師或其他使用者，可以檢查產品生命週期的每個階段的進度或狀態，而且是即 時監控，還能與團隊和其他個人協作，對 CI/CD流程上的問題進行故障排除。 Zalando 團隊成員甚至可以使用 Sunrise 引導和部署新應用程序。

為了打造出這個方便好用的內部開發者平臺，Zalando曾公開分享過有幾個關鍵。

例如他們直接動手修改K8s原始碼來解決問題，讓K8s變成他們自己能夠掌控的系統，來發展自己的雲原生平臺。 例如日出平臺就使用了自行開發客製的kubectl 封裝函式

當遇到緊急事件，要快速建立臨時存取的k8s叢集，這個封裝函示就可以派上用場，不 用按照原本標準封裝函式來執行，進一步縮短了不少部署時間。另一個關鍵是，Zalando也將「開發體驗」數據化，也就是得量測開發平臺對開發者體驗和生產力的成效。

Zalando參考了一本書的建議 《Accelerate:The Science of Lean Software and DevOps 》  （臺灣中譯版的名稱「精益軟體&DevOps背後的科學」，來定義了4個開發者效能矩陣的指標。

包括了事前準備時間（Lead Time）、發布頻率（Release Frequency）、平均復原時間（Time to Restore Service）、變更失敗率（Change Fail Rate），這也正是知名DevOps成效指標DORA中四指標所用的概念。

不過Zalando具體量測四個指標的作法略有不同，事前準備時間是從Commit到正式上線環境的時間。而發布頻率:每一個開發者每一周的部署次數。平均復原時間則以事件發生開始計算到服務復原（而非服務當機開始起算）。最後一項變更失敗率則是看在所有部署次數中有多少次失敗來計算。

日出這個開發者平臺最大的好處，就是讓所有開發者保持在相同的軌道上，另外也能滿足不同步部門各自組織分工的需求來提供彈性，最後，這個單一平臺也整合了Zalando他們所設計的技術雷達圖和所有的參考技術實踐經驗，驗證小組的測試文件檔，甚至還有成熟作法和流程的相關範本。可以透過單一平臺來聚焦，推薦開發團隊使用特別想要加碼的技術。

Zalando日出網站的設計目標是「要讓開發者既快樂，又有生產力！」，提供最頂級的開發者體驗，盡可能地降低技術團隊和開發團隊的認知負擔，來提高開發速度和生產力。這是Zalando在去年平臺工程大會上，首度公開日出平臺開發過程時，Zalando高階首席工程師Henning Jacobs格外強調這件事。

為了解決開發者工作流程破碎化的問題，Zalando建置部門打造了一套開發者入口網站Sunrise（日出平臺），作為開發者每天上班時打開的第一個網站。／Zalando

Sunrise（日出平臺）採用Spotify開源的ML管理平臺專案Backstage為基礎，整合了許多Zalando內部技術工具、開發元件、實作範本和技術文件，設計出了這個內部專用的自助式開發者平臺（Internal Developer Platform）。Zalando的開發人員可以在日出平臺上，取得全公司不同部門、產品團隊所打造的各種工具、服務的資訊，還能一站式取得所有支援服務。／Zalando

Zalando的開發人員可以在日出平臺上，快速檢視和管理所負責產品專案的進展。／Zalando

再次積極擁抱SRE，甚至成立專責SRE部門

另一方面，前面談到網購周時就提到，Zalando再度設立了SRE輔助團隊，2019年更直接成立了專責SRE部門，這個部門包括了Log紀錄團隊、追蹤矩陣團隊、事件應變團隊和啟動輔導團隊組合，透過同一套KPI讓這群人聚焦在相同的願景和目標。

Andrew Howden指出：「SRE部門的目標是要建立一套關鍵業務維運的模式，聚焦在顧客體驗，解決跨部門對齊的課題。」他一路參與了Zalando過去4年來的SRE發展歷程。

關鍵業務維運就是一項聚焦顧客體驗的服務水準目標（SLO），透過測量顧客與網站的互動，可以將開發者、管理者和顧客的觀點，整合到同一組數據中，並且用這些數據來改善可靠度。

成立嵌入SRE團隊，專門解決特定維運難題

有了專責的SRE部門還不夠，Zalando更設立了一個新的SRE團隊，稱為嵌入SRE團隊（Embedded SRE），專門要解決結帳過程的特殊挑戰。例如有些瘋狂買家會突然鎖定特定商品進行大掃貨，帶來一些系統問題。這類結帳流程的難題，涉及了十幾隻應用程式、4、5個部門、上百位工程師之間的溝通和協作。Andrew Howden就是這個團隊的負責人，帶領了2名工程師。

Andrew Howden先分析不同結帳異常背後相關產品系統的影響，一一找出解決作法。他處理過的問題，像是因為大量請求造成系統過載而無法回應後，促發叢集管理軟體自動重啟，卻造成了整套系統停擺。

因為結帳系統是一個大規模的分散式微服務架構，原本採取了斷路器模式的設計，來避免不斷呼叫到同樣出錯的服務，但因為斷路器的設計太敏感，一個系統失效後，開始影響到其他系統斷路器的錯誤率判斷，帶來連鎖性的影響。

或者另一次的問題是，為了確保可靠度，結帳系統設計了許多自動擴充機制，一發現有顧客結帳請求的回應速度變僈，就會自動擴充，但這導致雲端費用暴增，後來發現，少部分顧客因為掃貨行為產生大量請求，造成這一小群人的回應速度變慢，而不是所有顧客都有同樣的問題，只要以能涵蓋99.9%的一般顧客的標準，來定義出每一名顧客的請求數量上限，就能減少特定顧客瘋狂行為對自動擴充機制的影響。

將維運難題解決經驗融入日常維運

因為解決一個問常常只需要3周，但是得花上3個月，把這個異常問題的處理經驗，交接給平臺團隊，以及涉及的不同產品負責團隊。嵌入SRE團隊最後一個挑戰是，如何將這些維運問題的解決經驗，變成日常維運的一環。

Zalando每周都會舉辦一個維運回顧周會（Weekly operational review meetings，簡稱WORMs），首席工程師社群透過這個會議來查看事後分析報告，檢視各種維運問題。但是這些分析報告的品質落差很大，工程師為了準備這些文件也花了很多力氣。

嵌入SRE團隊協助將這樣的分析報告產出過程自動化，甚至增加了相關SRE作法的調整建議，可以自動發送報告給這個團隊，也將報告自動發送給工程管理團隊每周檢視之用。

2023年中，嵌入SRE團隊完成了最初設立時所要解決的課題，結束了這個團隊的任務，Andrew Howden也在8月結束了他在Zalando的旅程，轉而成為提供SRE培訓的顧問。

但是，Zalando平臺工程沒有停下變革的腳步，仍舊持續進化中。