Categories
程式開發

Slack的部署實踐


Slack的部署實踐 1

在Slack,我們重視快速迭代、快速反饋和對客戶的及時響應。同時,我們也擁有數百人的工程師團隊,大家一直在努力提高工作效率。公司在不斷壯大的同時始終堅持這些價值理念,這意味著我們在不斷完善部署系統。我們必須對更高的可視化和可靠性進行投入,以適應正在進行的大量工作。

這篇文章主要闡述我們的流程和一些主要項目,正是這些讓我們取得今天的成就。

我們怎樣開展部署工作?

在Slack,每一次PR都需要經過代碼評審和所有測試。一旦這些條件被滿足,工程師就可以將他們的代碼合併到主分支上。但是,合併後的代碼只能在北美工作時間部署,以確保我們有足夠的人力來處理任何意外問題。

我們每天會進行近12次計劃內的部署活動。每次部署期間,我們會指定一名工程師全權負責,他負責將新的構建發佈到生產環境。這個過程有很多詳細步驟,可以確保構建緩慢部署,以便在錯誤產生更大影響前檢測它們。

如果出現大量錯誤,這些構建也能回滾。如果在發布後檢測到問題,也能輕鬆地發布修補程序。

Slack的部署實踐 2

這是我們管理部署的圖形化界面

1. 創建一個發布分支(branch)

每個版本都從一個新的發布分支開始,這是我們Git歷史中允許我們標記發布的一個點。如果在生產環境發現問題,我們也能在這裡完成修補程序。

2. 部署到臨時生產環境

下一步是將構建部署到臨時生產環境的服務器,並運行自動smoke test。同時,臨時生產環境也是生產環境,但它不接受外部流量。

我們還會在臨時生產環境中做更多的手動測試,因為與只在開發環境中進行測試相比,這樣能讓我們對代碼可以正確工作更有信心。

3. 部署到dogfood和canary環境

發佈到生產環境的第一步是發佈到dogfood環境,它是一組服務器,為我們的一些內部Sl​​ack workspaces提供服務。自己嚐鮮,我們自己就是非常活躍的Slack用戶,dogfooding能幫助我們及早發現問題。

一旦,我們確信核心功能沒有受到不良影響,構建就會部署到canary,其中大約有2%的生產流量會路由到canary。

4. 按百分比發佈到生產環境

如果各種曲線圖保持穩定,沒有異常提醒,我們將繼續以百分比的節奏將構建發佈到生產環境。我們會將發布量劃分為10%、25%、50%、75%和100%等五個階段,以便可以將生產流量緩慢地引入新版本,同時給我們留下時間來調查是否有任何特別的波動或異常。

如果部署過程出現問題如何應對?

代碼變更總會有風險,但我們會讓經驗豐富的部署指揮官掌控每一個新版本的部署過程,觀察圖表了解情況,和發布代碼的工程師協調溝通,來管理風險。

如果在部署過程中出現問題,我們的目標是儘早發現。先對問題調查,找出哪次的代碼提交導致問題,回滾,然後在回滾後的代碼基礎上再完成新構建。不過,有些問題是只有發佈到生產環境後才能發現的。在這種情況下,恢復服務顯得至關重要。所以在開展問題調查前,我們會立即回滾到上一個可以正常工作的構建。

Building blocks

快速部署

在大家看來,上面描述的工作流程似乎並無新意,但是我們的部署系統經歷多次迭代後,才演化到現在樣子。

當公司規模還很小的時​​候,10個Amazon EC2實例就能運行我們所有的應用程序,一次部署意味著對所有服務器做一次快速rsync而已。

因此,以前在生產環境前面只有一層:臨時生產環境。構建將在臨時生產環境終進行驗證,然後直接發佈到所有生產服務器。這個系統簡單易懂,任何工程師都可以隨時部署自己的代碼。

但是,隨著客戶數量的增長,運行應用程序所需的基礎設施數量也在快速增加。很快,我們基於推送的部署模型就無法處理添加的服務器數量了。每增加一台服務器,都會增加部署時間。即使是使用並行rsyncs這樣的辦法也有其局限性。

最後,我們切換到完全並行的基於拉模式的系統上,解決了這個問題。

我們不再使用同步腳本將新的構建推送到服務器上,而是在發出了Consul密鑰更改的信號後,每台服務器都會同時pull構建。即使規模不斷擴大,這也能讓我們保持高速度的部署。

Slack的部署實踐 3

原子部署

另一個為分層部署鋪平道路的項目是原子部署。

在原子部署前,每次部署操作都會導致一系列的錯誤,因為將新文件複製到生產服務器的過程不是atomic。在這個過程中,它會產生一個比較小的時間窗口,在這個窗口中,新函數的調用點已經有了,而實際的實現函數還不可用。當調用這些調用點時,它們會返回內部錯誤,最終表現為失敗的API請求和受損的web頁面。

為解決這個問題而組織起來的團隊最終使用冷熱目錄的方法解決了它。熱目錄用於處理生產流量,而冷目錄則用於準備上線。在部署期間,新代碼將被複製到未被使用的冷目錄中。然後,等服務器上的所有活動進程都完全退出,我們就立即切換目錄。

Slack的部署實踐 4

重新聚焦可靠性

2018年,我們遇到一個問題,即不顧一切地快速部署,這只會對我們產品的穩定性造成損害。我們有一個非常強大的部署系統,公司也對它投入很大成本,但與部署有關的流程也有必要隨之發展。隨著我們的公司規模越來越大,在全球範圍內為越來越多的關鍵任務協作提供支持,可靠性就成為重中之重。

對更安全部署的需求促使我們對部署系統進行徹底檢查,由此引發的行動最終促成前面描述的基於百分比的部署系統。在底層,我們繼續使用快速部署和原子部署,但我們改變了部署方式。這個系統以層的方式發布更新,再加上非常好用的監控系統和工具,讓我們能在有缺陷的情況下,在對用戶產生影響前找到問題,並減輕影響。

但是,我們還沒有做到完美。通過更好的工具和自動化,我們不斷改進這個系統。

特別感謝

本文討論的工作包含以下同事的努力和項目:

  • 原子部署:Saroj Yadav、Chase Jenkins、Jamie Scheinblum
  • 部署系統的圖形化界面:Andrew Morrison、Zack Sultan、Jonathan Chang
  • 快速部署:Paul Hammond、Joe Smith
  • 基於百分比的部署:David Stern、Harrison Page、Travis Crawford、Patrick Bogen
  • Dogfood Tier:Derek Smith、Jamie Scheinblum、Eve Killaby
  • 工作流和流程:Pooja Rana、Karen Xu

英文原文:

Deploys at Slack