2.6               設計運營友好的服務的實踐

設計運營友好的服務更具體的最佳實踐包括：

2.6.1             快速服務健康測試。

這是構建驗證測試的服務版本。這是一個嗅探型測試，可以快速在開發者的系統上執行，以保證服務不會以獨立方式出錯。要保證所有的邊界條件都被測試到，是不可能的，但如果快速健康測試通過的話，那麼程式碼就可以檢入了。

2.6.2             在完整的環境中開發。

開發人員不但應當對他們的元件進行單元測試，而且還要對出現元件變更的整個服務進行測試。要高效實現這個目標，必須得有單伺服器的部署，以及前一條最佳實踐——快速的服務健康測試。

2.6.3             對下層元件的零信任。

設想下層元件會出現故障，並且確保元件會有能力恢復並繼續提供服務。恢復的技巧和服務相關，但常見的技巧包括：

l      在只讀模式中依靠快取的資料繼續運轉；

l      在服務訪問故障元件的冗餘拷貝的短暫時間內，繼續向用戶群一小部分的所有人提供服務。

2.6.4             不要把同一個功能構建在多個元件中。

預見未來的互動是一件極其困難的事情，如果不慎引入冗餘的程式碼，那麼將來就不得不在系統的多處做修復。服務的增長和發展是很快的，稍不留神程式碼的質量就會很快惡化。

2.6.5             不同的叢集之間不能互相影響。

大多數服務由小型集合或者系統的子叢集組成，它們之間相互協作，共同提供服務，其中每個小型集合都可以相對獨立地運作。每個小型集合應達到接近100%的獨立程度，且不會有跨群的故障。全域性服務，甚至包括冗餘，是故障的中心點。有時候，這樣的問題是不可避免的，但還是要設法保證每個叢集都擁有各自所需的資源。

2.6.6             允許（少量）在緊急情況的人工干預

見場景是在災難性事件或者其他緊急情況下移動使用者資料。把系統設計成完全無須人工互動，但也要清楚小概率事件可能會發生，其中組合的故障或者未預期的故障都會需要人工互動。這些事件是會發生的，而在這些情況下，操作員的錯誤往往是導致災難性資料丟失的常見來源。一名在半夜2點頂壓工作的運營工程師可能會犯錯誤。將系統設計成一開始在多數情況下無須運營幹預，但請和運營團隊協作制定在他們需要進行干預時的恢復計劃。比起將這些計劃寫進文件，變成多步驟易出錯的過程，更好的辦法是把這些規則寫成指令碼，並在生產環境中進行測試，以確保它們正常工作。沒有經過產品環境試驗的程式碼是不可行的，因此運營團隊應當定時指揮使用這些工具進行“防火演習”。如果演習的服務可用性風險非常高，那麼可以認為之前在工具的設計、開發和測試上的投資不足。

2.6.7             保持一切簡單健壯。

複雜的演算法和元件互動會給除錯和部署帶來成倍困難。簡單到近乎傻瓜式的結構在大規模服務中幾乎總是更勝一籌，因為在複雜的優化工作交付之前，互動中故障模式的數量早就足以磨滅人們的信心。通常我們的慣例是，能夠帶來一個數量級以上改善的優化工作才值得考慮，而只有百分之幾或者甚至於只是低係數級別的提升，就不值得了。

2.6.8             全面推進准入控制。

所有良好的系統會在設計時開門見山地引入許可控制，這樣符合一條長期以來為人們所認可的原則，那就是避免將更多的工作引入一個已經過載的系統，要比持續接受工作然後開始翻來覆去地檢查好一些。在服務入口引入某些形式的節流或者准入控制是很常見的做法，但在所有的主要元件邊界上都應該有準入控制。工作性質的變更最終會導致子元件的過載，即使整體服務仍然執行在可接受的負載級別。總體的慣例就是嘗試採用優雅降級的方式，而不用在統一給所有使用者低質量服務之前進行硬停機並阻斷服務的入口。

2.6.9             給服務分割槽。

分割槽應當可以無限調整，並且高度細粒度化，並且不受任何現實實體（人、集合等）的限制。如果按公司分割槽，那麼對於大的公司，就有可能超過單個分割槽的規模；而如

果按名稱字首進行分割槽，那麼例如所有以P打頭的最終一臺伺服器就可能會裝不下。我們推薦在中間層使用一張查詢表，將細粒度的實體，通常是在設計大規模服務的目標和應用服務提供商或IT外包商的目標之間，要劃一道清楚的界限。應用服務提供商和IT 外包商往往人員更加密集，並且更樂於執行面向客戶的複雜配置。

使用者，對映到其資料相應被管理的系統上。這些細粒度的分割槽隨後就可以自由在伺服器之間移動。

2.6.10         理解網路的設計。

提早進行測試，瞭解機櫃內的伺服器之間、跨櫃的伺服器之間以及跨資料中心之間有哪些負載。應用程式開發人員必須理解網路的設計，且設計應當儘早交給來自運營團隊的網路專員稽核。