守護者倒下時：為什麼沉默不是好消息

警示都設定好了。幾個星期過去，卻連一封郵件都沒有收到。

可能的解釋有兩種。不是真的什麼事都沒發生，就是警示系統已經停止運作，而管理者毫不知情。從外面看，兩者一模一樣。

而人的直覺總是傾向把沉默當成好消息。正因如此，這類故障可以存在好幾個月而無人察覺。

這和檢查項目變得沉默是不同的問題

本 wiki 在別處寫過：檢查項目讀不到資料時不能保持沉默，必須明確說出讀不到。

這裡要談的是更上一層的問題。在那篇文章裡，是運作中的守護者內部有一項檢查變得沉默。這裡則是守護者本身已經不在了。沒有誰能發出聲音，自然也沒有誰能回報讀不到。

守護者如何無聲地倒下

服務停止。一次更新、一次當機、記憶體耗盡。原本該發出通知的，正是停下來的那個東西。

郵件路徑中斷。密碼變更、服務商封鎖、收件地址退信。守護者照常運作，訊息照常寫出，卻沒有一封送到管理者手上。這是最具欺騙性的一種，因為在伺服器端一切看起來都正常。

有人關掉之後忘了打開。調查某個問題時暫時關閉了通知。問題解決了，通知卻一直關著。

機器關機。最極端的情況：沒有任何東西故障，只是一切都安靜了。

這四種情況的共同點是：都不會產生任何訊息。如果察覺故障的方式是收到訊息，那麼不產生訊息的故障就完全看不見。

解法的形狀不同：不是警報，而是心跳

方向必須反過來。

警報的邏輯是：出問題時才發聲。心跳的邏輯是：即使沒有任何問題，也定期回報自己還活著。然後由另一方負責察覺回報何時停止。

這個差異很重要。警報是關於問題的訊息；心跳則是關於傳訊者本身的訊息。兩者回答不同的問題，誰也無法取代誰。

有了心跳之後，沉默的意義就變了。沉默本身開始帶有資訊：某個應該發聲的東西沒有發聲。

負責察覺的一方必須位於被監看的機器之外

這一點值得多談。一台機器無法回報自己的死亡。

判斷心跳的地方必須位於被監看伺服器的外部：另一台機器、一支手機、一個外部端點。在伺服器內部執行的檢查會隨伺服器一起關機，什麼也不會告訴任何人。

即使是最簡單的自製做法也足夠：讓伺服器每小時在某處留下一個標記，再檢查這個標記有多舊。不需要複雜的架構，唯一需要的是判斷發生在別的地方。

心跳本身也有陷阱

這裡有一個不易察覺的設計錯誤，多數架構都會掉進去：把心跳綁在使用者可以關閉的某項功能的排程上。

假設心跳與每日摘要郵件共用同一個時間表。使用者覺得摘要太多而把它關掉，心跳也跟著停止。外部一方看到訊號中斷，便發出伺服器失聯的警報，而實際上什麼問題都沒有。

結果不難想見：使用者第一次白白受到驚嚇，第二次就直接把警報關掉。由安全機制自己製造的假警報，摧毀對該機制信任的速度，比完全沒有機制還要快。

規則是：心跳必須有自己的排程，不依附於任何可以被關閉的東西。

同樣的形狀，出現在別處

本 wiki 談備份工作的文章寫過：不要看工作的狀態，要看最新一份備份有多舊。

這裡出現的是同樣的形狀：不要問警示系統是否正常運作，要看最後一次訊號距今多久。狀態是一種宣稱，時間長度才是一項量測。

最後，設定當天唯一該做的一件事：刻意製造一次故障，親眼確認郵件送達。沒有測試過的警報不是機制，只是一種期望。

Atlas 的做法

Atlas Watch 會寄送每日摘要，遇到嚴重狀況時不等摘要即刻回報，除此之外還會發出每小時一次的存活訊號。

值得說明的，是這個訊號沒有綁在哪裡。

這個訊號既不依附每日摘要的排程，也不依附警報的排程。兩者各有自己的設定，使用者可以關閉其中任何一個。如果訊號依賴它們，使用者一關掉摘要，訊號也會跟著停止，遠端就會在一切正常時回報這台伺服器失聯。正因如此，訊號有自己的排程。

第二個細節出自同樣的思路：通知設定關閉時，訊號的排程檔案根本不會寫入。因此不存在已啟用卻沒有運作的中間狀態；訊號只有存在與不存在兩種情況。

通知路徑本身完全由使用者掌握：郵件伺服器由使用者自行設定，郵件也從使用者自己的伺服器寄出。將訊號送到外部端點是選用的附加功能，產品本身的運作並不依賴它。

通用的教訓是：安全機制不能依附在它所保護對象中可被關閉的部分。否則它會跟著一起無聲地倒下。