是不是這次更新的鍋？先看方向
昨天還好好的，今天不行了。誠實的答案不是「大概是更新」，而是先看哪件事先發生。
方向很重要
發生在更新之後的故障，是典型的「更新之後出的問題」；發生在更新之前的，就不能怪它——不管這有多誘人。在把責任歸給任何東西之前，先把兩個時間戳並排放在一起。這一步通常就能消掉很大一部分錯誤歸因，兩個方向上都是。
「正常」必須是明確的正面確認
診斷報「正常」這件事本身有個陷阱：如果「正常」的意思是我們沒發現問題，那麼一條從沒執行過的規則，看起來就和一台健康的機器一模一樣。三種狀態應該是：
- 正常——我們查過，明確確認沒問題，而不是「沒有資料」。
- 留意——值得看一眼，但不算缺陷。
- 警告——一個具體的問題。
把「正常」定義為正面確認，才能避免「什麼都沒查」被讀成「一切健康」。
只讀快照，不讀活狀態
結論應當來自一份凍結的快照——裡面是所有規則被允許讀取的東西。如果規則在執行過程中還能去讀活狀態，答案就會取決於分析跑到一半時變了什麼；而同一台機器可以在幾分鐘內給出兩個不同的結論，中間什麼都沒發生。
兩個很細的計數錯誤
- 同一條警告用兩種語言記錄下來，是一個問題，不是兩個。按穩定的類別歸組，否則一份雙語的日誌看起來像麻煩翻倍。
- 解析不出來的名稱算未知，絕不猜。錯誤的歸因比空的歸因更糟，因為它會把你引到錯的地方去找。
實際怎麼辦
- 在動手修之前，先記下問題開始的確切時間——之後的每個動作都會毀掉證據。
- 拿它去和更新記錄比，而不是和你對更新的記憶比。
- 如果問題早於更新，就別再想著回滾了，去看看別的：一根線、一個擴充座、一台顯示器、一次系統小版本更新。
誠實的邊界
- 時間戳只能給事情排序，不能證明因果——更新之後的故障，也可能來自一根恰好在那時候鬆掉的線。
- 快照讓結論可重現，不等於正確。閾值設錯的規則，會把同一個錯誤答案完美地重現出來。