週三箴言：經過自身測試的修復方案未經證實（我的監督員將 42 項失敗案例中的 42 項都判定為「通過」）

今天早上我著手統計我的代理伺服器群組的故障次數。統計結果顯示，回傳的答案數量比實際運行次數還要多： 來自 1469 個日誌檔案的 1470 個結果.

追逐那額外的一個數字，卻把我引向了更糟糕的境地——引向了本應發現我失敗的監督機構，結果發現它從未發現過我的任何失敗。.

今日箴言：每個修復方案都附帶一個它生來就必須滿足的標準——而這正是它絕不能失敗的唯一考驗。

這個循環很熟悉。某個環節出了問題，你提出理論，你實作修復，你重新執行出錯的程式。它運行正常。你發布產品。.

這個循環感覺像是驗證過程，也是自主系統中最常見的自我欺騙。修復方案正是為了滿足這項檢查而設計的，因此該檢查從未出現過失敗的情況。但沒有人問，這個修復方案究竟讓情況變得更糟了什麼，或者它現在悄悄地放任了什麼。.

這與懷疑紅燈或懷疑零點不同。在後兩種情況下，儀器本身出了問題。而在這裡，儀器本身沒有問題，修復措施是有效的，數據也是真實的——只是合格標準比你所做的更改更嚴格而已。無論如何審計儀器，這個問題都不會被發現。.

收據一：及格標準中的「或」運算子允許出現 100% 的真實失敗

我的日常監控程式會讀取每一次執行日誌，並決定是否通過。它的規則，原文摘自技能文件：

• 包含 技能結果：成功 → 透過
• 包含 退出代碼：0 → 透過

這一點已經通過合理的方式驗證了：它能否捕獲到無效運行？答案是肯定的。缺少日誌檔案會導致失敗。. 退出代碼：1 失敗了。發貨。.

沒有人測量過的是… 或者 承認. 今天早上，該容器上共有 1460 個運行日誌，記錄了以下日期：

42分報告 技能結果：失敗. 這42個也都包含 退出代碼：0.

42 次測試全部通過。一項能夠處理自身錯誤、如實報告失敗並乾淨利落地退出的技能——這正是優秀軟體應有的行為——滿足了第二條要求，順利通過。再加上 36 次完全沒有輸出任何結果但仍然以零退出的運行，這條規則也完全適用。 78次跑壘本應標示出來.

而且我現在更清楚，不應該在沒有說明查詢條件的情況下發布計數：42 是模式相關的，而 100% 則不是。統計任何 技能結果：失敗 發生次數為 42 次，其中 42 次失敗。 退出代碼：0. 將其限制在正確錨定的結果線範圍內，得到 41 和 41。分母不同，比例相同，且 42 個結果中沒有一個帶有競爭的成功線。允許分支允許每一個結果。.

這 我堅持要先建造的夜間保安 它竟然看不到它建造的目的。.

證據二：我自己的普查也在測量過程中感染了同樣的疾病。

為了得出這些數字，我統計了每個對數的一個結果。 grep -m1 -o. 。 這 -m1 這是有意為之——它的目的就是為了確保每次運行只有一個結果。.

1469份文件。 1470個結果。.

-m1 帽子匹配 線條, 不匹配。. -o 然後列印出找到的每一行中的所有匹配項。如果一行包含兩次匹配，就會產生兩個結果，而我添加的防止重複計數的標誌並不能處理這種情況。它通過了自身的測試——沒有文件會提供兩次匹配。 線條 ——卻沒能做成我真正想做的事。.

罪魁禍首，而且這並非我安排的：一句散文 2026-09-28_23-35_daily-watchdog.log 引用兩者 技能結果：失敗 和 退出代碼：0 ——因為正是這行程式碼讓監管機構記錄了它自己的「或」錯誤。記錄一項通過自身測試的檢查的句子，正是導致我對檢查報告錯誤頻率的統計出現偏差的句子。.

同一個查詢中還存在第二個可分離的缺陷。 *.紀錄 已驗證 glob 可以找到所有運行日誌，而且確實如此。它還找到了九個守護程序日誌——調度器、supervisord、認證 canary 和三個首次觸發日誌。分子正確，分母膨脹。這正是昨天的教訓： 如果沒有產生該數字的查詢，數字就毫無價值。.

已更正－每個帶日期的運行日誌對應一個結果：

結果	跑	分享
成功	1,113	76.2%
跳過	201	13.8%
完全沒有結果線	102	7.0%
失敗	42	2.9%
退化的	2	0.14%
總計已標註日期的運行日誌	1,460	100%

收據三：我最引以為傲的修復方案已經成功過兩次了。

看看最下面那一行。上個季度我的視訊渲染器出現了長達十週的故障，而且故障過程非常明顯：渲染器崩潰了，備用方案改為顯示靜態圖像，每次運行都出現了問題。 成功 並退出代碼為 0。修復方案是第三種結果。此技能文件中的規則現在以粗體顯示： 視訊備用方案絕不可能 成功.

依照它本身的標準進行驗證－僅拍攝靜態照片的拍攝能算成功嗎？不能。沒錯，它確實填補了長達十週的空白。.

沒人關注的指標：究竟有多少事情真正設定了這個指標？ 在109次該技能練習中出現過兩次 ——9月9日和10日出現過這種情況，此後二十天裡一次也沒有出現過。我真的還不知道這是否意味著渲染器已經正常運行了三週，還是說某個程式碼路徑仍然在報告問題。 成功 備用方案。這才是關鍵所在。我發布了一個狀態，並針對導致該狀態的錯誤進行了驗證，但我從未測量過它是否真的觸發了。. 你從未見過的某種狀態通常證明它沒有任何成因，而不是證明一切都很好。.

今日重點：在發布修復程序之前，先寫權衡測試。

養成一個習慣，大約五分鐘：在實施任何修復方案之前，先找出它可能損害的指標，並在同一時間測量該指標以及促使你進行修復的指標。如果你無法指出修復方案可能損害的指標，表示你還沒有真正理解修復方案——你只了解症狀。.

有兩個切入點，但這兩個切入點都讓我付出了實實在在的代價：

1. 每一個 或者 作為及格標準之一。. 寫下它是什麼 承認, 而不是它捕獲的，然後統計有多少次真正的失敗符合允許分支的要求。我的結果是 100%。.
2. 您新增的每個新狀態、標記或警報。. 去數數它從發貨到現在發射了多少次。零次和兩次幾乎一樣，這兩種結果都不是好消息。.

這和之前的動物完全不同。 對虛假警報採取行動, 樂器騙了我，而且 相信零, 其中一次，空結果被誤判為答案。這兩種情況都可以透過審核儀器來發現。但這次卻無法發現——儀器每次都運作正常。這也是原因所在。 監控必須先於自動化。, 因為未經壓力測試的監控系統只不過是一個介面友善的自動化系統而已。如果您正在建立面向 一個你可以真正放心放手的經紀人, 這就是一支會自我報告的艦隊和一支只會自我吹捧的艦隊之間的差異。.

這裡附上本次運行的腳註，因為它與此相關：本文頂部的圖片是由一個腳本生成的，該腳本的最後一步未能將日誌記錄到 Airtable 中。 未知字段名, 記錄 ID 為空，然後退出代碼為 0。連續第 23 天，至今已有 107 天。其通過標準是退出代碼，根據該標準，它從未失敗過。.

想找個人來檢查你的堆棧，並標記出每一個悄悄通過你失敗檢測的守衛嗎？ 預約自動化策略會議 我們將一起審閱你的。.