6               運營和功能計劃

要高效地運營服務，關鍵在於讓構建的系統有效地消除運營團隊的絕大部分管理互動。這樣做的目標，是讓一個高度可靠的24 x 7 小時執行的服務，由一個8 x 5小時工作的運營團隊就足以維護起來。

不過世事難料，一組或者多組系統救火不成，無法恢復上線的事情是時有發生的。在熟知這些可能性的情況下，實現把損壞的系統標為當機這個過程的自動化。依賴運營團隊手動更新SQL 表或者使用特別的技術移動資料，都會招致災難。與故障交戰正酣時，往往錯誤也容易迭出。先預估運營團隊需要採取的補救措施，然後預先編寫和測試這些過程。一般來說，開發團隊必須將緊急恢復措施自動化，而且他們必須對之進行測試。顯然，百密一疏，並非所有故障都能預估到，但通常一小組恢復措施就可以用來恢復多種型別的故障。從根本上說，要構建並測試可以根據災難的範圍和性質以不同方式使用及結合的“恢復核心”。

恢復指令碼應當在生產環境中進行測試。這裡有一條普適規則，即如果沒經過頻繁測試，什麼程式都無法正常工作，因此不要實現團隊沒勇氣使用的任何東西。如果在生活環境中測試風險過高，那麼指令碼就沒有達到能在緊急情況下使用的標準，或者說在緊急情況下不安全。這裡很關鍵的一點是，災難總是可能發生的，由無法按預期結果執行的恢復步驟所導致的小問題釀成大災難的例子是屢見不鮮的。要預見到這樣的事件，設計出自動化措施，讓服務回覆正常狀態，而不至於丟失更多資料或損耗更多正常執行時間。

6.1              

讓開發團隊承擔責任。Amazon也許是沿著這條道路貫徹得最堅定最矢志不渝的公司了——他們的口號是“你建立就該你管”。這樣的立場也許要比我們會選擇的更堅定一些，但這顯然是一個正確的大方向。如果不得不頻繁在深更半夜給開發團隊打電話，那麼你就得做出一套自動化方案。如果需要頻繁給運營團隊打電話，那麼通常的反應就是要增加運營團隊的人手。

6.2               只進行軟刪除。

只進行軟刪除。絕不要刪除任何東西，只可以把這些東西標記成刪除狀態。在有新資料進入時，即時將請求記錄下來。每兩週（或者更長時間）儲存一份所有操作的歷史記錄，可以有助於從軟體或者管理上的錯誤進行恢復。如果有誰犯了錯誤，忘記在delete 語句加上where 子句（這樣的錯誤以前發生過，以後也可能再犯），那麼資料的所有邏輯拷貝都會被刪除。不管是RAID還是映象都無法防止這樣的錯誤。具備資料恢復的能力，可以讓原來會十分令人窘迫難堪的大問題轉化為一個小到甚至可以忽略不計的小障礙。對於那些已經做過離線備份的系統，只需要從上次備份開始記錄進入服務的附加資料就可以了。不過謹慎起見，不管怎麼說我們還是推薦進行更進一步的備份。

6.3               跟蹤資源分配。

跟蹤資源分配。瞭解效能規劃的額外負載所帶來的開銷。每個服務都需要開發出一些使用的度量標準，例如併發線上使用者數量、每秒使用者訪問數或者其它合適的標準。不管度量標準是什麼，在這個負載度量和所需的硬體資源之間肯定存在一個已知的直接相互關係。估算的負載數字應當由銷售和營銷部門提供，並在效能規劃過程中為運營團隊所使用。不同的服務會擁有不同的變更速率，也要求不同的訂購週期。在我們開發過的服務中，我們每90天更新一次市場預報，每30天更新一次效能規劃和訂購一次裝置。

6.4               每次變更一樣東西。

每次變更一樣東西。在出現麻煩時，應當每次只向環境應用一個變更。這條準則看起來顯而易見，但我們也看見過許多場合裡出現多個變更，導致起因和效果不能吻合。

6.5               使所有資源都可以配置。

使所有資源都可以配置。在生產環境中，任何存在變更需求的資源，都應無需經過任何程式碼改變，就能在生產環境中進行配置和調優。即使你沒什麼好理由說明為什麼某個值會有必要在生產環境中更改，只要實現起來沒什麼難度，還是讓它可變更好些。不應在生產環境中隨意更改這些開關，而應該使用為生產環境所規劃的配置對整個系統進行徹底測試。不過，在出現生產環境問題時，比起編碼、編譯、測試再部署程式碼變更的過程，進行簡單的配置變更永遠是更加簡單、安全和快速的。