大規模服務設計部署經驗談(3) | 自動管理和預置
3 自動管理和預置
許多服務編寫的目的是為了在故障時向運營部門發出警報，以得到人工干預完成恢復。這種模式凸顯出在24 x 7 小時運營人員上的開支問題；更重要的是，如果運營工程師被要求在充滿壓力的情況下做出艱難的決定，那麼有20%的可能他們會犯錯誤。這種模式的代價高昂，容易引入錯誤，而且還會降低服務的整體可靠性。然而，注重自動化的設計會引入明顯的服務模型約束。比如說，當前某些大型服務依靠的資料庫系統，會以非同步方式複製到次級備份伺服器，因為複製以非同步方式完成，在主資料庫無法服務請求後，故障轉移到次級資料庫會引起部分客戶資料丟失。然而，不把故障轉移到次級資料庫，則會引起資料被儲存在故障伺服器上的使用者面臨服務停工。在這種情況下，要自動化故障轉移的決策就很困難了，因為這個決策依賴於人為判斷，以及對資料損失量和停機大致時長相比的準確估計。注重自動化設計出的系統會在延遲和同步複製的吞吐量開銷上付出代價。在做到這一步以後，故障轉移變成了一個很簡單的決策：如果主伺服器宕機，將請求轉到次伺服器上。這種方式更適用於自動化，而且被認為更不容易產生錯誤。在設計和部署後將服務的管理過程自動化可能是一件相當具有難度的工作。成功的自動化必須保證簡單性，以及清晰並易於確定的運營決策；這又要依靠對服務的謹慎設計，甚至在必要時以一定的延遲和吞吐量為代價作出犧牲，讓自動化變得簡單。通常這樣的折中方案並不容易確定，但是對於大規模服務來說在管理方面的節約可能不止數量級。事實上，目前根據我們的觀察，在人員成本方面，完全手動管理的服務和完全自動化的服務之間的差別足足有兩個數量級。注重自動化的設計包含以下最佳實踐：
3.1 可以重啟動，並保持冗餘。
可以重啟動，並保持冗餘。所有的操作都必須可以重新啟動，並且所有持久化狀態也必須冗餘儲存。
3.2 支援地理分佈
支援地理分佈。所有大規模服務都應當支援在多個託管資料中心執行。我們所描述的自動化和絕大多數功效在無地理分佈的情況下仍是可行的。但缺乏對多服務中心部署方式的支援，會引起運營成本顯著提升。沒有了地理分佈，很難使用一個數據中心的空閒容量來減緩另外一個數據中心所託管的服務的負載。缺乏地理分佈是一項會導致成本提高的運營約束。
3.3 自動預置與安裝。
自動預置與安裝。手動進行預置和安裝是相當勞民傷財的，故障太多，而且微小的配置差異會慢慢在整個服務中蔓延開來，導致問題的確定越來越困難。
3.4 將配置和程式碼作為整體。
將配置和程式碼作為整體。請確保做到：
l 開發團隊以整體單元的形式交付程式碼和配置；
l 該單元經過測試部門的部署，並嚴格按照運營部門將會部署的方式；
l 運營部門也按照整體單元的方式部署。通常說，將配置和程式碼作為一整個單元處理並且只把它們放在一起修改的服務會更可靠。
3.5 生成環境的變更必須稽核和記錄
如果配置必須在生產環境中變更，那麼請保證所有的變更都要產生稽核日誌記錄，這樣什麼東西被修改，在什麼時候被誰修改，哪些伺服器受到影響，就一目瞭然了。頻繁掃描所有的伺服器，確保它們當前的狀態與預期狀態相符。這樣做對捕獲安裝和配置故障頗有裨益，而且能在早期偵測到伺服器的錯誤配置，還能找到未經稽核的伺服器配置變更。
3.6 管理伺服器的角色或者性質，而不是伺服器本身
管理伺服器的角色或者性質，而不是伺服器本身。每個系統的角色或性質都應當按需要支援儘可能多或少的伺服器。
3.7 多系統故障是常見的。
多系統故障是常見的。請做好多臺主機同時發生故障的準備（電源、網路切換和首次上線）。遺憾的是，帶有狀態的服務必須得注意它們的拓撲分佈。有相互聯絡的故障一直以來都是不可避免的。
3.8 在服務級別上進行恢復。
在服務級別上進行恢復。在服務級別處理故障，相比軟體底層來說，其中的服務執行上下文更加完整。例如，將冗餘納入服務當中，而不是依靠較低的軟體層來恢復。
3.9 對於不可恢復的資訊，絕對不要依賴於本地儲存。
對於不可恢復的資訊，絕對不要依賴於本地儲存。保證總是複製所有的非瞬時服務狀態。
3.10 保持部署的簡單性
保持部署的簡單性。檔案複製是最理想的方式，因為這樣能帶來最大的部署靈活性。最小化外部依賴性；避免複雜的安裝指令碼；避免任何阻止不同元件或者同一個元件不同版本在同一臺機器執行的情況。
3.11 定期使服務停轉
定期使服務停轉。停掉資料中心，關閉櫃式伺服器，斷掉伺服器電源。定期進行受控的關閉操作，能夠主動暴露出伺服器、系統和網路的缺陷。沒有意願在生產環境中測試的人，實際上是還沒有信心保證服務在經歷故障時仍能繼續運轉。此外，若不進行生產測試，在真正出事時，恢復不一定能派上用場。