公司 ricardo.ch 地點 瑞士蘇黎世 行業 電子商務

挑戰

瑞士線上市場 ricardo.ch 正面臨速度問題,以及開發和運營之間“經典鴻溝”,雙方無法很好地協同工作。“他們想合作,但沒有共同點,”平臺工程主管 Cedric Meury 說。“這是導致我們放慢速度的根本原因之一。” 公司開始將傳統的單體應用拆分為微服務,需要在自己的資料中心部署編排工具以支援新的架構,並實現開發和運營的協同。

解決方案

公司採用 Kubernetes 進行叢集管理,Prometheus 進行監控,Fluentd 進行日誌記錄。第一個叢集於 2016 年 12 月在本地部署,三個月後第一個服務投入生產。遷移已完成約一半,公司計劃在 2018 年底前完全遷移到 Google Cloud Platform

影響

Meury 表示,將單體應用拆分為微服務“提高了速度,Kubernetes 在支援這一點方面至關重要”。生產部署數量已從每週不到 10 次增加到每天 30-60 次。以前,“當生產中出現問題時,工單或投訴會被拋給運營團隊,這是典型的問題。現在,人們有機會先檢視運營情況並自行排除故障,因為所有部署都以標準化方式進行,”Meury 說。他看到了日常互動中的影響:“幾周前,我看到一位產品經理對一個包含一些變數的 JSON 檔案進行了拉取請求,另一個人接受了它。然後幾分鐘甚至幾秒鐘後就部署了,這在以前是不可想象的。以前需要一系列事情才能發生,整個單體應用很難理解,即使對於工程師來說也是如此。因此,以前的請求會進入龐大而低效的看板,希望幾周或幾個月後有人會完成更改。” 以前,基礎設施和平臺相關的專案需要數月或數年才能完成;現在開發人員和運營人員可以合作,透過 Kubernetes 在幾周甚至幾天內部署基礎設施部件。從長遠來看,公司還預計從定製資料中心和虛擬機器轉向容器化基礎設施和雲服務將節省 50% 的成本。

當 Cedric Meury 於 2016 年加入 ricardo.ch 時,他看到了運營和開發之間明顯的分歧。事實上,它們之間存在物理距離:工程團隊在法國工作,而組織的其餘部分在瑞士。

“這是這些部門之間的經典鴻溝,甚至到處都有一些憤怒和沮喪,”Meury 說。“他們想合作,但沒有共同點。這是導致我們放慢速度的根本原因之一。”

這一差距正在損害瑞士線上市場 ricardo.ch 的速度。該網站在高峰期每天處理多達 260 萬次來自網路和移動應用程式的搜尋,為其 320 萬會員提供即時拍賣服務。技術團隊的主要挑戰是確保“物品的競價按正確的順序到達,並在拍賣結束之前,並且這種方式公平有效,”Meury 說。“我們有即時要求。我們還提供了一個自動競價系統,它需要準確無誤。對於分散式系統,你面臨著確保排序正確的挑戰。這是我們目前正在處理的事情之一。”

為了解決速度問題,ricardo.ch 首席技術官 Jeremy Seitz 建立了一個新的軟體工廠,名為 EPD,由 65 名工程師、7 名產品經理和 2 名設計師組成。“我們把這三個部門聚集在一起,這樣他們就可以簡化流程,更密切地相互交流,”Meury 說。

公司還開始將遺留的單體應用拆分為 100 多個微服務,並需要編排工具來支援其資料中心中的新架構。“拆分單體應用提高了速度,Kubernetes 在支援這一點方面至關重要,”Meury 說。“Kubernetes 的容器化和編排幫助我們大幅減少了開發和運營之間的衝突,也使我們雙方能夠用相同的語言交流。”

Meury 組建了一個平臺工程團隊來選擇工具——包括用於日誌記錄的 Fluentd 和用於監控的 Prometheus,以及 Grafana 視覺化——併為第一個 Kubernetes 叢集奠定基礎,該叢集於 2016 年 12 月在本地安裝。幾周內,新平臺就可供團隊使用,並提供了培訓課程和文件。平臺工程團隊隨後與工程師們一起,幫助他們在新平臺上部署應用程式。第一個投入生產的服務是 ricardo.ch 的工作頁面。“這是前端開發的一個練習,所以開發人員可以嘗試使用新的技術棧,”Meury 說。

Meury 估計一半的應用程式已遷移到 Kubernetes。計劃是到 2018 年底將所有內容遷移到 Google Cloud Platform。“我們仍然在自己的資料中心執行一些伺服器,但所有容器化工作和將我們的服務描述為 Kubernetes 清單將使我們能夠非常輕鬆地完成這一轉變,”Meury 說。

影響是巨大的。從定製資料中心和虛擬機器轉向容器化基礎設施和雲服務,預計將為公司節省 50% 的成本。生產部署的數量已從每週不到 10 次增加到每天 30-60 次。以前,“當生產中出現問題時,工單或投訴會被拋給運營團隊,這是典型的問題,”Meury 說。“現在,人們有機會先檢視運營情況並自行排除故障,因為所有部署都以標準化方式進行。這減少了時間和不確定性。”

Meury 還在日常互動中看到了影響:“幾周前,我看到一位產品經理對一個包含一些變數的 JSON 檔案進行了拉取請求,另一個人接受了它。然後幾分鐘甚至幾秒鐘後就部署了,這在以前是不可想象的。以前需要一系列事情才能發生,整個單體應用很難理解,即使對於工程師來說也是如此。因此,以前的請求會進入龐大而低效的看板,希望幾周或幾個月後有人會完成更改。”

開發和運營之間的分歧也減少了。“幾個月後,我收到人們的請求,他們說,‘嘿,你能幫我安裝 Kubernetes 客戶端嗎?我想看看發生了什麼,’”Meury 說。“人們直接檢視系統狀態,使他們與運營部門之間的距離大大拉近。” 以前,基礎設施和平臺相關的專案需要數月或數年才能完成;現在開發人員和運營人員可以合作,透過 Kubernetes 在幾周甚至幾天內部署基礎設施部件。

對系統的洞察力也擴充套件到公司的其他部門。“我發現我們的一位客戶支援代表透過檢視 Grafana 指標來判斷系統是否執行良好,這太棒了,”Meury 說。“Prometheus 直接連線到客戶服務。”

ricardo.ch 的雲原生之旅可能對運營團隊的影響最大。“我們有一個運營團隊,他們來自硬體背景,現在他們正在重新學習如何在更虛擬化和雲原生的世界中運營,到目前為止取得了巨大成功,”Meury 說。“因此,除了仍然操作現場資料中心防火牆之外,他們還學習用 Go 編寫程式碼或進行一些 Python 指令碼編寫。以前的網路管理員現在正在編寫 Go 程式碼。這真的很酷。”

對 Meury 來說,這段旅程歸結為這一點。“我的一位同事在 KubeCon 上聽了所有的演講,他被我們平臺目前所缺乏的所有工具、技術、框架所震撼,”Meury 說。“但與此同時,他也很高興知道,未來還有很多我們可以探索、改進和努力的事情。我們正在從到處看到問題——比如,‘這個壞了’或‘這個停機了,我們必須修復它’——更多地轉向,‘我們如何才能真正改進和更多地自動化,並讓開發人員和終端使用者體驗更好?’”