週三箴言：當警報顯示故障時，先檢查警報器本身（一天兩次誤報——都是我的）

昨晚 20:05，我的視訊代理開始渲染。渲染到第 3 步（共 10 步）時失敗，並出現供應商錯誤代碼。代理執行了相應的操作，向 API 發送探測請求，以確認服務本身是否正常運作。探測結果顯示服務已恢復。 HTTP 503.

這是一個清晰明了的故事。供應商宕機了。正確、謹慎且省錢的做法是停止支付渲染費用，改為發送靜態影像。我的經紀人只差一行程式碼就能做到這一點。.

服務很好。最終交付的渲染圖是一個真正的43秒影片。以下是其中的精髓，以及證明其價值的兩張收據——這兩張收據都來自同一時期，而且都是我自己創作的樂器演奏。.

智慧之言：紅燈是一種主張，而非結果。

所有使用代理進行開發的人最終都會學會對綠色退出代碼保持警惕。乾淨的退出代碼僅僅意味著腳本已完成，並不代表工作已經完成。這個教訓很容易吸取，因為你第一次遇到代理商對空文件報告成功時就會明白。.

幾乎沒有人會對紅色抱持同樣的懷疑。當儀器顯示… 破碎的, 我們立即採取行動——而且不經審計——因為根據故障報告採取行動感覺像是盡職盡責。但這恰恰是問題所在。誤報看起來不像是漏洞，而像是判斷準確，像是發現了什麼問題。.

所以請大聲說出來： 你的顯示器也是一個系統。. 它會發起網路請求，解析回應，讀取快取。它也會出錯，而且出錯時，它會像你建造的其他一切一樣，悄無聲息地出錯。.

收據一：503，但並非系統故障

渲染失敗。 狀態=失敗：Director：意外的錯誤處理預測 (E9828) 在第 3 步（共 10 步）失敗了。這確實是個失敗──毋庸置疑。所以我的代理程式探測了預測端點，結果回傳了 503 錯誤，然後探測腳本呼叫了該 URL。 一次 並以此回應而成長。.

讀一遍，一個結論：服務中斷了。.

十二秒後的重新投票顯示，偵測器本身的測試預測結果與預期相符。 成功了. 503 錯誤出現在讀取路徑上，而不是產生路徑上。服務一直都能產生影像，但短暫無法告知我相關資訊。重試後，一切正常，10 次嘗試全部成功。.

實際交付內容：1080×1920分辨率，43.1秒，旁白音量平均為-22.4 dB，已透過以下方式確認： ffprobe 並非想當然。我今天早上檢查時，它仍然透過 CDN 提供服務。不是幻燈片。.

現在來說說值得仔細思考的部分。. 備用方案更便宜。. 讀取端點傳回 503 錯誤意味著可以跳過付費渲染，並交付更糟糕的結果——運行日誌也會記錄這一情況。 成功, 因為發布備用方案是可以接受的。我的團隊中沒有任何人會發出警報。我只會發布一個更糟糕的視頻，然後覺得這樣做更穩。.

收據二：三天內發現我自己的工具出現了一個漏洞

我連續三個早晨都在筆記裡寫道，我的SEO插件需要兩次API呼叫才能保存元資料。證據看起來天衣無縫：寫入操作返回成功，然後直接用GET方法訪問實時URL，結果顯示的是原始文章標題和摘要，而我自定義的標題和描述卻顯示在那裡。寫入，檢查，還是不對，再呼叫一次。我一共三次把這個問題作為供應商缺陷提交了報告。.

昨天我用清除快取的查詢字串重新取得了同一個URL，並且 Cache-Control: no-cache 標題。這兩個字段都有效且正確——而且一直如此。.

問題出在 GET 請求。它讀取的是一個快取頁面。三天來，API 一直有缺陷，但我現在幾乎可以肯定它從未存在過。 API 從來都不是不穩定的元件。問題出在我的儀器上，而我的儀器正是我唯一沒有想到要測試的東西。.

所以這篇文章就是個實驗。一次元資料寫入，一次驗證，啟用快取清除，不再進行第二次呼叫。如果這個理論真的有效，那麼它本身就應該適用於提出這個理論的文章。.

四分鐘後更新：情況穩定。. 我寫了一篇文章。然後，同一個URL在同一時間出現了兩種不同的結果——普通的GET請求返回了文章的原始標題和摘要，而清除緩存後的GET請求則返回了我剛剛寫的標題和描述。同一個頁面，同樣的操作，卻得到了兩種不同的結果，而其中只有一種是正確的。我連續三天發出的第二個請求實際上並沒有解決任何問題，它只是在給快取一些時間來更新資料。.

鏡子：紅色不能證明什麼，綠色也不能。

當天早上，我的圖像腳本已經列印出來了。 警告：Airtable 日誌記錄失敗 — UNKNOWN_FIELD_NAME: "名稱"" 然後離開了。 零. 這篇文章頂部的圖片也出現了同樣的問題。這已經是連續第五天了。.

今天早上我沒有靠猜測，而是直接閱讀了即時表結構。欄位如下： 圖片 ID、建立時間、圖片 URL、圖片模型、已儲存圖片、提示、狀態、網站、文章標題、任務參考、提示摘要、建議圖片類別、WordPress 媒體 ID、WordPress CloudFront URL、參考圖片. 沒有 姓名 字段寫入操作永遠無法成功。這不是不穩定——而是根本不可能成功，而且在過去五天裡，每次成功運行後，它都會以警告的形式發出自身信號，而表卻始終沒有收到任何數據。.

今天早上，我根據自己對代理人的定義，測量出了同一缺陷的結構性版本： 39 個技能文件，57,438 個單詞，217 次提及 retry、except 或 fallback，但沒有出現“assert”一詞。” 我的團隊已做好充分準備應對任何失敗的呼叫，但對於謊言，他們完全束手無策。無論哪種情況。.

偷竊三句台詞

1. 在相信失敗之前，請先從兩個不同的角度閱讀兩次。. 不同的端點或不同的緩存，相隔十秒。一次讀取結果只能是傳言，兩次一致的讀取結果才是證據。.

2. 問問自己，「破損的」東西能帶給你什麼。. 如果失敗的判決將你的代理人引導到更便宜、更快捷、品質更低的路徑，那麼這正是誤報的藏身之處——節省成本的備選方案會自行找到理由，而警報本身卻不會響起。.

3. 用控制語句將每個空的或失敗的讀取運算括起來。. 昨晚我的任務檢查器報告隊列為空，我之所以相信，只有一個原因：同樣的查詢語句，同樣的查詢格式，針對一個已知已滿的目標，返回結果卻是已滿。如果你的控制面板也顯示故障，那麼問題出在你的儀器上，而不是系統。.

這些都不是什麼稀奇古怪的事。差別在於，前者是報告實際發生的事情，後者只是報告其工具聲稱的結果。你已經知道不能輕信他人。 一次毫無成果的成功; 更難的自律在於不相信那些無需付出任何代價就能承認的失敗。這就是為什麼 監控先於自動化, ， 為什麼 十秒鐘健康檢查 勝過抱持希望的重試，原因何在？ “設定好就不用管了” 這仍然是這個領域最昂貴的謊言。昨天我統計了一下… 以天為單位的隊列，而不是以行為單位的隊列。 並在故障發生前一天發現了故障——同樣的原理，指向容量而不是警報。.

想讓管道工程變得枯燥乏味而不是充滿樂趣嗎？審核儀器才是幕後最真正的工作。 你可以放任不管的特工. 預約自動化策略會議 我們會找出你有哪些警報系統在欺騙你。.