Etsy是怎么做到每天50次以上部署的

Etsy是怎么做到每天50次以上部署的，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

Daniel Schauenberg在倫敦QCon大會上描述了Etsy是如何做到每天50次部署的。Etsy以其DevOps和持續交付的實踐而聞名。一個完全自動化的部署管道、全面的應用監控和基于IRC（互聯網中繼聊天）的協作是能達到這個變更頻率的同時又保持最小風險的重要因素。

Etsy的開發策略是反復圍繞著做許多小的、連續的變更。這樣做的一個直接后果就是需要每天做很多次部署。用Daniel Schauenberg的話來說，在任何時刻每個Etsy的開發人員都需要知道下面這個問題的答案：“我現在有足夠的信心來部署這個變更嗎？”。為了能夠每次都可以輕松部署，Etsy采取了一系列的工具和做法：強制基于IRC的溝通、開發者虛擬機、持續集成、一鍵式部署、全面的應用和系統監控、對于開發和運營團隊都采取免責怪的事后檢查（post-mortem）和隨叫隨到的政策。

每個開發人員都擁有自己的通過Chef配置的KVM（基于內核的虛擬機）。在線上運營中使用的cookbooks也同樣地用在了開發人員的虛擬機中，這意味著每個開發者都有自己完整的Etsy棧。任何人都可以通過Virtual Madness(一個可以實現整個過程自動化的Web應用)來提供一個虛擬機。

在持續集成方面，Daniel解釋了Try是如何成為所有過程的核心。Try是一個工具，它允許開發人員在Jenkins(在Etsy中使用的持續集成工具)中測試他的代碼變更，而不需要先提交到trunk中。Try有助于保持trunk干凈從而實現可部署，而同時讓開發人員能夠快速、可靠地測試他們的變更。CI(持續集成)集群必須強大到足以支持150名工程師，以及每天超過14000個測試集的運行。LXC(Linux容器）會平衡工作的負載，它們還提供了隔離機制，確保不同測試的執行之間不會沖突。

部署管道會經過Princess，或者工作臺，這是一種上線前的環境。Princess的所有意圖和目的就是上線環境，但只有Etsy的員工可以訪問它。Deployinator是由Etsy構建并使用的部署工具，提供一鍵式部署。

配置標志，也被稱為功能標志，是部署過程中的一個主要組成部分。通過其功能API，Etsy能夠做A/B測試，即完全啟用或者禁用某一功能或一個給定功能的變體。

監控是Etsy團隊建立信心做持續交付的關鍵。開發人員做自己的功能監控，而且每個人都可以通過儀表盤看到所有的監控圖表。Etsy具有這樣一個策略，在默認情況下所有可以被繪制的信息都會被制成圖表。隨著時間的推移，指標的數量一直穩步增加，所以Etsy建立了Kale來幫助檢測異常模式。所有的日志都可以通過Supergrep展現出來，Supergrep是一個基于Web的日志展示工具，這增加了日志的信噪比。

IRC是貫穿Etsy的主要溝通工具，也是Etsy協作文化的關鍵。里面有很多不同的聊天室，每一個都具有特定目的。例如，在聊天室＃warroom中僅允許中斷事故有關的會談。聊天室是用來協調調查，討論應對措施和解決方案監控的。與其他的聊天室一樣，＃warroom是個鼓勵新工程師們潛水的地方，因為這些聊天室被認為是學習的好地方。

每次中斷發生，或接近中斷的時候，所有人被邀請來做事后檢查。事后檢查是一個重要的文化活動，如果財務和支持人員需要，他們也可以參與。事后檢查是為了成為一個學習的機會，所以它們不應該包含責備。所有事后檢查相關的信息被記錄在Morgue里面：日期、嚴重性、IRC日志、圖表和補救措施。Morgue是Etsy為了保存事后檢查記錄而特別構建的另一種工具。

對于運營、開發、支付和支持部門的員工都采取隨叫隨到的政策。開發人員通常輪流地在每四個星期里的某一周提供隨叫隨到的支持。該政策的目的是讓每個人都意識到上線產品每天所面臨的問題，使他們能夠在開發新功能或改進現有流程時考慮到這些問題。

Etsy擁有約60萬的月訪問量和每月15億頁面瀏覽量。

關于Etsy是怎么做到每天50次以上部署的問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。