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

4
(2589)

要在網購周前幾周,上線全新的功能,如何確保新功能可以撐得住黑色星期五的人潮,維持顧客對網站的信賴感呢?當年Zalando採取了一個大膽的作法,提前在平日的正式環境中,重現網購周的爆量負載來實測新功能
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

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

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

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

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平臺工程沒有停下變革的腳步,仍舊持續進化中。

这篇文章有用吗?

点击星号为它评分!

平均评分 4 / 5. 投票数: 2589

到目前为止还没有投票!成为第一位评论此文章。

显示验证码
没有账号?注册  忘记密码?