警示已設定卻什麼都沒收到：沒有人測試的傳遞路徑

監控分成兩半：一半是發現某處出錯的檢查，另一半是把這個消息帶到人面前的路徑。幾乎所有注意力都放在前一半，而幾乎所有無聲的故障都藏在後一半。

令人不安的是，從坐在螢幕前的角度看，壞掉的傳遞路徑和健康的系統看起來一模一樣。兩者都只會留下一個空空的收件匣。

為什麼伺服器寄信不再簡單

伺服器直接寄出自己的郵件，長久以來都很正常，如今卻成了例外。原因有三。

收件端的郵件服務商不再信任陌生寄件者。一封寄件者原則記錄不相符、沒有簽章、又來自毫無信譽位址的郵件，會被視為可疑，而可疑的客氣說法就是垃圾郵件匣。

家用與小型企業網路在連接埠層級就被封鎖。許多業者不允許對外連線使用直接投遞郵件的那個連接埠，正是因為它曾被濫用。伺服器嘗試寄送，卻沒有任何訊息告知郵件根本沒有送出去。

信譽跟著位址走，而不是跟著人走。住宅網路或小型雲端業者的位址，帶著它原有的一切歷史。使用這個位址，就一併繼承了這段歷史。

這些都不會讓問題變難，而是讓天真的設定在無聲中失效，這比難還要糟。

兩種可行的做法

透過已經信任的中繼伺服器寄出。伺服器以帳號密碼驗證後，把郵件交給一個獲准寄信的郵件服務商。這是常見的答案，而且行得通，但有一點值得知道：服務商通常要求寄件位址必須是它所代管的位址，所以假裝從別處寄出的郵件會被拒收或改寫。

完全不寄郵件，改用第二條管道。推播通知，或傳一則訊息到原本就會查看的服務。聽起來像是降級，卻往往是更可靠的選擇，正是因為它不依賴電子郵件的送達率。

不論選擇哪一種，重點都在下一節。

真正能證明它可行的測試

幾乎每個人測試通知的方式都錯，而且錯得一模一樣：坐在機器前按下標示為寄送測試的按鈕，沒看到失敗，就當作完成了。

這個測試證明的是系統能把訊息交出去，並不證明訊息會送達。真正的測試要回答四個問題：

它進了收件匣，而不是垃圾郵件匣嗎？送達和被看見是兩種不同的結果，只有其中一種會把人叫醒。

它是從真正的警示會使用的那個位址寄出的嗎？以某個身分寄出的測試，對於以另一個身分寄信的夜間排程工作毫無證明力。

它是在真正的警示會觸發的時段送達的嗎？有些路徑在凌晨三點和下午三點的表現不同，通常是因為中繼伺服器的速率限制或服務商的過濾機制會隨時段變化。這是較少見的故障，卻正是最要緊的那一種。

機器處於高負載時，它還能送達嗎？在真正的事故期間排入佇列的訊息，正在和事故本身爭奪資源。

完全不會產生錯誤的故障模式

佇列。郵件已產生、在本機被接受，然後待在一個永遠重試的佇列裡。什麼都沒有遺失，什麼也沒有送達，而且沒有人去看佇列，因為沒有任何錯誤提醒任何人去看。

被改寫的寄件者。中繼伺服器收下郵件，把寄件者改成一個沒有人查看的位址，然後完美地投遞到一個沒有人打開的信箱。

自己設下的篩選規則。警示看起來都很像，所以某個時候其中一封被某條規則歸檔了，而這條規則在設定的人早已忘記之後仍持續運作。

已經不存在的位址。那個人離職了，別名轉寄到他的帳號，而現在這個轉寄退信，消失在虛空之中。

最有用的單一習慣

讓沒有訊息這件事本身具有意義。

只在出錯時才開口的系統，和已經失去開口能力的系統，無法區分。每天一則說明一切正常的訊息，會把沉默本身變成訊號：如果今天什麼都沒收到，第一個要檢查的就是傳遞路徑，而且是在平靜的早晨發現，而不是在事故當中。

這就是每日摘要比表面上更有價值的原因。它真正的工作不是內容，而是證明這條管道仍然存在。

Atlas 的做法

Atlas Watch 每天寄出一則訊息，而不是一連串的警示，這個選擇正是出於上述理由而刻意為之。摘要承載當天累積的狀態，而它的送達本身，就證明這條路徑完好無缺。

同樣的通知也能送到帳號入口網站，這一點在這裡特別重要：它是不依賴主機自身郵件投遞的第二條管道。如果壞掉的正是電子郵件，那麼不使用電子郵件的管道，就是仍能傳來消息的那一條。

還有誠實的部分，因為這正是本文的主題：當某項檢查無法讀取它的資料時，Watch 會說明它讀不到，而不是保持沉默。從外面看，遺失的備份工作和正常的備份工作看起來完全一樣，唯一能區分兩者的，是一個願意承認自己看不見的守護者。