部署需要在速度和可靠性之間達到謹慎平衡。在Slack，我們重視快速迭代、快速反饋循環，以及對客戶反饋的響應速度。我們擁有數百名工程師，他們都在努力提高工作效率。在公司成長的同時也保持這些價值觀，就意味著我們的部署系統需要不斷完善。為了適應工作量，我們必須加大可視性和可靠性的投入。本文將概述我們的部署流程以及一些使我們達到目標的主要項目。
部署過程
Slack的每一個PR都需要代碼review和所有的測試通過。一旦滿足這些條件，工程師就可以將他們的代碼合併到master中。但是，合併後的代碼只在北美工作時間內部署，以確保我們有足夠的人員來應對任何意外問題。
我們每天會進行大約12次計劃內部署。在每次部署過程中，我們會指定一名工程師作為部署指揮官，負責將新的build推出到生產環境中。這是個多步驟的過程，確保構建緩慢推到線上，這樣我們可以在錯誤影響到所有人之前發現錯誤。如果錯誤激增，這些構建可以回滾，如果我們在發佈後發現問題，可以很容易地進行熱修復。
創建一個發佈分支
每個版本開始時都會有一個新的發佈分支，這是我們的Git歷史記錄中的一個點，我們可以在這個點上標記發佈，同時我們也可以在這裡對在發佈過程中發現的問題進行修復。
部署到staging版
下一步是將構建部署到Staging服務器上，並運行自動冒煙測試。staging是一個不接受公共流量的生產環境。我們在staging環境中進行額外的手動測試，因為與只在開發環境中進行測試相比，它能更大程度保證代碼更改能正常工作。
部署到狗糧環境和金絲雀環境
向生產領域的推廣首先從狗糧環境開始，這是一套服務於我們內部Slack工作區的主機。由於我們自己也是非常活躍的Slack用戶，所以狗糧環境部署能幫我們發現很多問題。一旦我們確信核心功能沒有變化，就會將構建部署到金絲雀環境上，大約有2%的生產流量路由到該環境。
基於百分比的推廣到生產中
如果各種指標保持穩定，並且沒有警報，我們將繼續以百分比為基礎的方式向生產環境推廣。我們以10%、25%、25%、50%、75%和100%的增量來分解部署，以便慢慢地將生產流量暴露在新的構建中，同時給我們時間來調查是否有任何尖峰或異常。
如果在部署過程中出了問題怎麼辦？
修改代碼總是會帶來風險，但我們通過讓訓練有素的部署指揮員，觀察各種指標並與推送代碼的工程師進行協作。
萬一有問題，我們的目標是儘早發現問題。我們會調查問題，找出導致問題的PR，還原它，在還原的過程中需要精挑細選，然後進行新的構建。然而有時我們無法找到問題。在這種情況下，恢復服務至關重要，這時我們會立即回滾到之前的版本中，然後再開始調查問題的原因。
基石
快速部署
上面描述的工作流程在事後看來可能很明顯，但我們的部署系統經歷了多次迭代，才能達到這個目標。
當公司規模很小的時候，我們的整個應用程序可以在10個Amazon EC2實例上運行，而部署只是快速rsync到所有服務器。在推到生產環境之前，只有一個過程：staging環境。構建完成後，在staging系統上進行驗證，然後直接rsync到所有的生產服務器。這個系統很容易理解，任何工程師都可以隨時部署自己的代碼。
但隨著客戶數量的增加，運行應用程序所需的基礎設施數量也在增加。很快，基於推送的部署模式就無法應對。每增加一臺服務器，就會增加部署時間。即使像並行rsyncs這樣的策略也有其侷限性。
最終，我們通過切換到完全並行的拉模式系統解決了這個問題。當Consul key更改的信號發出後，每臺服務器都會併發地拉當前構建，而不是使用同步腳本將新的構建推送到服務器上。這使我們能夠在繼續擴大規模的同時保持高速的部署速度。
原子部署
另一個為分層部署鋪平道路的項目是原子部署。
在原子化部署之前，每次部署都會引起一系列的錯誤，因為將新文件複製到生產服務器上的過程並不是原子化的。這就導致了一個小時間窗口，在該窗口中，新函數的調用點會出現。當這些調用站點被調用時，它們會返回內部錯誤，表現為API請求失敗和網頁無法展示。
圍繞這個問題的團隊通過使用熱目錄和冷目錄解決了這個問題。熱目錄將為生產流量提供服務，而冷目錄正在準備中。在部署期間，新的代碼會被複制到未使用的冷目錄。然後，一旦服務器的活動進程被耗盡，我們就會瞬間切換目錄。
重視可靠性
在2018年，我們遇到了一個問題，就是儘可能快的部署速度傷害了我們產品的穩定性。我們有一個非常強的部署系統，然而圍繞著部署的流程必須要進化。隨著我們成為一家更大的公司，在全球範圍內為越來越多的關鍵任務協作提供動力，可靠性成為了我們的核心。
對可靠性的需求促使我們對部署系統進行了全面的改造，從而形成了前面描述的基於百分比的部署系統。在幕後，我們繼續使用快速部署和原子部署，但我們改變了部署方式。整個系統按層級更改，再加上更好的監控和工具，讓我們有能力在BUG影響到所有用戶之前就發現並減輕BUG。
然而這也不是最終形態，我們還在通過更好的工具和自動化來不斷改進這個系統。敬請關注未來更多關於這些方面的文章。
原文
https://slack.engineering/deploys-at-slack-cd0d28c61701
本文由高可用架構翻譯。技術原創及架構實踐文章，歡迎通過公眾號菜單「聯繫我們」進行投稿。
高可用架構
改變互聯網的構建方式
