7               稽核、監控和預警

運營團隊不能在部署環境中裝配服務。要在部署過程中付出實質性的努力，以確保系統中的每個元件都可以生成效能資料、健康資料和吞吐量資料等。

在任何有配置變更發生的時候，都必須在稽核日誌中記錄詳細變更內容、變更人和變更時間。在生產環境出現異常時，第一個要回答的問題就是最近到底進行過哪些變更。離開了稽核跟蹤，那麼這個答案就是“什麼都沒被改過”，而且情況往往會是，被人們忘掉的就是引發問題的變更。預警是一門藝術。人們總是傾向於對所有事件都做警報，因為開發人員認為這些事件可能值得關注。正是如此，多數服務的第一版通常都會產生長篇累牘的無用預警，結果再也沒

有人去理睬。要提高效率，每個警報都得說明一個問題，否則運營團隊會慢慢學會對這些警報置之不理。進行互動慢慢跳出需要警報的條件，保證所有關鍵性事件得到預警，以及在無需採取應對措施時沒有警報。除此之外，要實現正確的預警別無靈丹妙藥。要得到正確的預警標準，有兩條度量標準很有用，也值得嘗試：

一、警報和實際故障比（同時要設定一個較為接近的目標）；

二、沒有相應警報的系統健康問題數量（並設定一個近於0的目標）。

7.1               對所有資源進行檢測。

對所有資源進行檢測。測量通過系統的每一次使用者互動或事務，報告異常情況。嘗試“執行器（人為的工作負載，用來模擬生產環境中使用者和服務的互動）”也是可以的，不過這還遠遠不夠。如果只是單獨使用執行器，我們發現需要花費數日才能檢測到一個嚴重錯誤，因為執行器的標準工作負載也會被繼續良好地處理，接下來還要再花幾天才能查出原因。

7.2               資料是最有價值的資產。

資料是最有價值的資產。如果沒有充分理解正常的操作行為，那麼要對非正常行為做出響應就不是件容易的事情。我們需要彙集許多系統內發生的事件資訊，才能知道系統是否真的正常執行。許多服務都經歷過災難性故障，而只有電話鈴響起的時候，人們才意識到故障的發生。

7.3               從客戶的角度看服務。

從客戶的角度看服務。進行端到端的測試。雖然單有執行器不夠，但還是需要它們來保證伺服器的完整執行。保證例如新使用者登入這樣重要的複雜過程經過執行器的測試。避免誤警，如果在某個執行器上的故障沒被當作重要故障，那麼變更測試物件，換到是重要故障的執行器上。重申一下，一旦人們開始對資料視而不見，真正的損失就會讓人們措手不及。

7.4               檢測是生產環境測試所必不可少的。

檢測是生產環境測試所必不可少的。檢測是生產環境測試所必不可少的。要在生產環境中實現安全的測試，就有必要進行全面監控和預警。如果某個元件開始出現故障，就必須快速檢測出來。

7.5               延遲是最棘手的問題。

延遲是最棘手的問題。緩慢的I/O，以及尚未出現故障但處理緩慢的現象，都是很好的例子。這些問題發現起來很困難，所以一定要仔細檢測，保證這樣的現象可以檢測出來。

7.6               要有足夠的生產環境資料。

要有足夠的生產環境資料。為了發現問題，資料是不可或缺的。在早期就要建立細粒度的監控機制，否則放到後面再翻新成本就高得多了。

我們所依賴的資料中最重要的包括：

l      對所有操作使用效能計數器。至少記錄操作的延遲和每秒鐘的操作次數。這些數值突然出現的此消彼長現象，是一個十分危險的訊號。

l      稽核所有操作。每次有人進行操作之後，尤其是那些明顯的操作，一定要記入日誌。這樣做有兩個目的：首先，可以對日誌進行挖掘，找出用採取的操作型別（在我們的例子裡是使用者查詢的種類）；其次，一旦發現問題，這樣做有助於除錯問題。相關視點：如果每個人使用相同的賬號管理系統的話，這麼做帶來不了多少好處。相反這是一個非常糟的辦法，不過這種情況不多。

l      跟蹤所有容錯機制。容錯機制會把故障隱藏起來。每次出現重試、某個資料被一處複製到另一處，以及機器或者服務重啟這類現象時，都要進行跟蹤。要了解容錯機制在何時隱藏了小故障，這樣就可以對這些小故障進行追溯，以防其變成大面積故障。我們曾經碰到過這樣一個問題：一個跨2000臺機器的服務在幾天內慢慢地癱瘓，最後只剩400 臺機器可用，而一開始這個問題卻沒有發現。

l      跟蹤對重要實體的操作。為某個特殊實體的所有重要操作記錄一份“稽核日誌”，不管這個實體是一個文件，或者一組文件。在執行資料分析時，常常能在資料中發現異常現象。要了解資料的來源及其經歷的處理過程。到了後期才往專案加入這樣的功能是非常困難的。

l      斷言（asserts）。不要吝惜斷言的使用，而且要貫徹在整個產品中。收集因此產生的日誌或者崩潰轉儲（crashdump），並進行調查研究。對於在同一個程序邊界內執行不同服務並且無法使用斷言的系統，要寫下跟蹤記錄。不管哪種實現，都要能夠對錯誤進行標記，頻繁挖掘不同問題的頻率。

l      保留歷史記錄。歷史性能和日誌資料對於趨勢的總結和問題的診斷都是非常必要的。

7.7               可配置的日誌功能。

可配置的日誌功能。對可配置的日誌功能提供支援，這些日誌記錄可以有選擇性開啟或關閉，以便進行錯誤除錯。在故障過程中，如果不得不部署帶額外監控功能的新構建版本是非常危險的。

7.8               外部化健康資訊，用於監控。

外部化健康資訊，用於監控。考慮能實現外部監控服務健康程度的方式，並使對生產環境進行監控容易實現。

7.9               保證所有報告的錯誤可以應對。

保證所有報告的錯誤可以應對。問題總會發生，系統也總會出錯。如果在程式碼中檢測到無法恢復的錯誤，並且在日誌或者報告中歸為錯誤，那麼錯誤資訊應當指出錯誤可能發生的原因，並提供修復的建議。無法採取應對措施的錯誤報告毫無用處，而且時間一久這些錯誤報告會像“狼來了”一樣被人們忽略，那時候真正的錯誤就可能被錯過。

7.10           啟用生產環境問題的快速診斷。

啟用生產環境問題的快速診斷。

為診斷提供足夠資訊。當問題被標出時，要提供足夠的資訊，人們才可以對其進行診斷；否則門檻會非常高，標註也會被忽略。例如，不要只說“10個查詢都沒返回結果”，還得補上“列表在這裡，還有問題出現的次數”。

證據鏈。保證存在一條貫穿始終的路徑，可供開發人員診斷之用。通常這都是由日誌實現的。

在生產環境中的除錯。我們偏愛這樣的一種模式：系統沒有被包括運營團隊在內的任何人觸碰過，並且除錯是通過映象快照、記憶體轉儲並將所得資料傳送到生產環境之外來實現的。當生產環境成為唯一選擇是，開發人員就是最好的選擇。要確保開發人員得到良好的培訓，知曉生產環境的操作限制。我們的經驗是，系統在生產環境中動的次數越少，客戶通常也越開心。因此我們推薦，一定要多努一把力，儘量避免接觸生產環境中的系統。

◇記錄所有重要的操作。每次系統執行了重要的操作，特別是對網路請求和資料修改上，要進行記錄。這既包括使用者傳送命令的事件，也包括系統內部的行為。有了這樣的記錄，除錯問題的時候就會獲益無窮。更重要的是，還可以開發出相應的挖掘工具，用來找出有用的集合，比如使用者的查詢都是什麼樣的（也就是說，用了哪些關鍵字，有多少關鍵字等等）。