2               整體服務設計

一直以來，人們都相信80%的運營問題源於設計和開發，因此本節關於整體服務設計的內容篇幅最長，也最重要。系統出故障時，人們很自然傾向於首先去審視運營工作，因為這是問題實際產生的地方。不過，絕大多數運營問題都可以歸因於設計和開發，或者最適合在設計和開發中解決。隨後的內容凸顯一個共識，即在服務領域，將開發、測試和運營嚴格分離不是最有效的方式。在環顧眾多服務之後，我們發現了這樣一個趨勢——管理的低成本與開發、測試和運營團隊間協作的緊密程度密切相關。

除了在這裡討論的服務設計最佳實踐以外，隨後一節“以自動化管理和預置為目標進行設計”對服務設計也有實質性的影響。有效的自動化管理和預置通常以一個受限的服務模型來實現。簡單是高效率運營的關鍵，

這是貫穿本文重複出現的主題。在硬體選擇、服務設計和部署模型上的理性約束，是降低管理成本和提高服務可靠性的強心針。

在運營友好的基礎原則中，為整體服務設計帶來最大影響的幾條包括：

2.1               設計時為故障做好準備（Design for failure

在開發包含多個協同運作的元件的大型服務時，這是一條核心概念。這些元件會有故障發生，而且故障的產生很頻繁。它們之間不會總是穩定地協作，也不會單獨出現故障。一旦服務的規模達到10,000臺以上的伺服器和50,000塊以上的磁碟，每天就會有多次故障發生。如果一有硬體故障產生就得采取緊急措施來應對，那麼服務就無法以合理的成本可靠地伸縮。整個服務必須有承受故障而無須人工干預的能力。故障恢復的步驟必須非常簡單，而且這些步驟應當進行頻繁測試。斯坦福大學的Armando Fox 主張說，對故障恢復步驟進行測試的最佳方法，就是絕對不要用正常方式使服務停機，用粗暴的方式讓它停轉就可以了。乍聽起來怎麼做是違背直覺的，但是如果沒有頻繁使用故障步驟，那麼它們在真正臨陣時就可能潰不成軍。

2.2               冗餘和錯誤恢復（Redundancy and fault recovery）。

大型機模型是指購買一臺價高塊頭大的伺服器。大型機擁有冗餘的電源供應，CPU可以熱交換，而且匯流排架構也超乎尋常，使得這樣一個緊密耦合的系統能夠有可觀的I/O吞吐量。這樣的系統，最明顯的問題就是它們的成本；而且即便有了所有這些費用高昂的設計，它們仍然不夠可靠。為了達到99.999%的可靠性，冗餘是必須存在的。實際上，在一臺機器上實現4個9的可靠性都是相當困難的。這個概念在整個業界都耳熟能詳，不過，將服務構建在脆弱而又非冗餘的資料層之上的現象，到目前為止都屢見不鮮。要保證設計的服務其中的任何系統可以隨時崩潰（或者因為服務原因被停止）但又仍然能符合服務水平協定（Service Level Agreement，簡稱SLA），是需要非常仔細的設計的。保證完全遵守這項設計原則的嚴格測試（acid test）步驟如下：首先，運營團隊是否有意願並且有能力隨時讓任意一臺伺服器停機並且不會讓負載被榨乾？如果答案是確定的，那麼肯定存在同步冗餘（無資料丟失）、故障偵測和自動接管。我們推薦一條普遍使用的設計方法，用於查詢和糾正潛在的服務安全問題：安全威脅建模（Security Threat Modeling）。在安全威脅建模中，我們要考慮每一條潛在的安全威脅，並且相應實現恰當的緩和方案。同樣的方法也適用於以錯誤適應和恢復為目標的設計。

將所有可以想象到的元件故障模式及其相應組合用文件記錄下來。要保證服務在每個故障發生後都能繼續執行，且不會在服務質量上出現不可接受的損失；或者判斷這樣的故障風險對於這樣一個特定的服務是否可以接受（例如，在非地理冗餘的服務中損失掉整個資料中心）。我們可能會認定某些非常罕見的故障組合出現的可能性微乎其微，從而得出確保系統在發生這種故障之後還能繼續執行並不經濟的結論。但是，在做這樣的決定時請謹慎從事。在執行數以千計的伺服器的情況下，每天都會有幾百萬種元件故障產生的可能，這時那些事件的“罕見”組合亮相的頻繁程度，足以讓我們瞠目結舌。小概率組合可能變成普遍現象。

2.3               廉價硬體切片（Commodity hardware slice）。

服務的所有元件都應當以廉價硬體切片為目標。例如，儲存量輕的伺服器可以是雙插槽的2至4 核的系統，帶有啟動磁碟，價格在1,000 至2,500 美元之間；儲存量大的伺服器則可以是帶有16至24個磁碟的類似伺服器。主要的觀察結果如下：

l      大型的廉價伺服器叢集要比它們替代的少數大型伺服器便宜得多；

l      伺服器效能的增長速度依然要比I/O效能的增長速度快很多，這樣一來，對於給定容量的磁碟，小型的伺服器就成為了更為穩定的系統；

l      電量損耗根據伺服器的數量呈線性變化，但隨系統時鐘頻率按立方級別變化，這樣一來效能越高的機器運營成本也越高；

l      小型的伺服器在故障轉移（Fail over）時隻影響整體服務工作負荷的一小部分。

2.4               單版本軟體（Single-version software）。

使某些服務比多數打包產品開發費用更低且發展速度更快的兩個因素是：

l      軟體只需針對一次性的內部部署。

l      先前的版本無須得到十年的支援——針對企業的產品正是如此。相對而言，單版本軟體更容易實現，附帶客戶服務，特別是無須費用的客戶服務。但是在向非客戶人員銷售以訂閱為基礎的服務時，單版本軟體也是同樣重要的。企業通常習慣在面對他們的軟體提供商時擁有重要的影響力，並且在部署新版本時（通常是個緩慢的過程），他們會習慣性想去掌握全部的控制權。這樣做會導致他們的運營成本和支援成本急劇上升，因為軟體有許多版本需要得到支援。最經濟型的服務是不會把對客戶執行的版本的控制權交給他們的，並且通常只提供一個版本。要把握好單一版本軟體的產品線，必須：

l      注意在每次釋出之間不要產生重大的使用者體驗變更。

l      願意讓需要相應級別控制能力的客戶可以在內部託管，或者允許他們轉向願意提供這類人員密集型支援服務的應用服務提供商。

2.5               多重租賃（Multi-tenancy）。

多重租賃是指在同一個服務中為該服務的所有公司或終端使用者提供主機服務，且沒有物理上的隔離；而單一租賃（Single-tenancy）則是將不同組別的使用者分離在一個隔離的叢集中。主張多重租賃的理由基本上和主張單版本支援的理由一致，且它的基礎論點在於提供從根本上成本更低、構建在自動化和大規模的基礎之上的服務。

回顧起來，上面我們所展示的基本設計原則和思考如下：

l      設計時為故障做好準備

l      實現冗餘和錯誤恢復

l      依靠廉價硬體切片

l      支援單一版本軟體

l      實現多重租賃

我們約束服務設計和運營的模型，以此最大化自動化的能力，並且減少服務的總體成本。在這些目標和應用服務提供商或IT 外包商的目標之間，我們要劃一道清楚的界限。應用服務提供商和IT外包商往往人員更加密集，並且更樂於執行面向客戶的複雜配置。