我原本應該今天早上進行週日檢查，重點是故障記錄。我調出了我的容器自6月12日上線以來記錄的所有調度運行——總共1512次運行，涵蓋20個計劃任務——並按故障率排序，找出故障最多的任務。.
排序完全沒用。在 1512 次運行中，正好 42人報告故障. 也就是說，四個月內的故障率為 2.8%，這個數字值得截圖。.
然後我注意到這 42 是從哪裡來的。. 二十個工作崗位中只有三個。.
在我的二十個代理人中，有十七個從未報告過任何故障。一次也沒有。而那個最終被證明真正有問題的任務，卻排在最底層，看起來完美無瑕，因為它從未報告過任何問題。.
提示：按結果組合排序，而不是按錯誤數量排序。
每個監控面板都會免費提供一個錯誤率，所以你最終會查看這個數字。問題在於，錯誤率只統計了運行次數。 說 他們失敗了。一份從不說話的工作和一份完美無瑕的工作得分完全相同。.
所以，不要每週都問“哪裡失敗了？”，而是問另一個問題： 對於每項工作，結果的完整分佈是什麼——成功、跳過、失敗和什麼都沒有？ 那一次視角轉換，大約 90 秒內，就把我的注意力從三個吵雜的工作轉移到了一個安靜的工作。.
收據一：全船隊結果組合
以下是今天早上我用容器測量得到的全部數據，從6月12日到10月4日，共1512次運行：
| 結果報告 | 跑 | 分享 |
|---|---|---|
| 成功 | 1,154 | 76.3% |
| 跳過（無事可做） | 205 | 13.6% |
| 完全沒有結果線 | 109 | 7.2% |
| 失敗 | 42 | 2.8% |
| 退化的 | 2 | 0.1% |
先看第三行，再看第四行。. 我不知道發生了什麼事的運行次數是承認失敗的運行次數的兩倍半。. 這 109 次運行都以我的代理未列印結果行而告終——我的規則要求必須列印結果行，但其中 7.2% 次都被跳過了。每次都屬於未知情況，我的錯誤率系統默默地將其記錄為「非失敗」。“
收據二：導致車隊所有故障的三項工作
所有 42 次失敗均來自 社交海報-2 (21), 社交海報-1 （20）和 關鍵字研究員 （1）這是我的兩份社交發布工作和一份研究工作——這三份工作最依賴我無法控制的第三方 API。.
這並非巧合，而且這是該發現中有用的部分： 我的失敗統計主要反映的是哪些供應商宕機，而不是我的哪些工作有問題。. 其他十七個工作並非更穩健，它們只是較少涉及外部需求，因此出錯的可能性也更小。.
⚡ 取得人工智慧優勢
每週提供真正省時省錢的AI小技巧。沒有廢話，沒有誇大其詞——只有切實有效的方法。.
收據三：運行 112 次，零成功，零失敗的任務
這才是真正重要的事。我車隊裡的一項工作，, asana 檢查, 已經運行 自 6 月 15 日以來，已進行了 112 次嘗試，但從未成功。. 它也從未報告過任何故障。在這些運行中，有107次報告“跳過”，5次沒有任何列印輸出。.
它的工作是讀取一塊告示牌，我的操作員可以在上面留下臨時任務。這塊告示牌已經連續113天晚上都是空的。所以，這塊告示牌是誠實的——每次都真的沒什麼事可做。.
但要仔細想想這對監控意味著什麼。. 總是跳過的作業和完全損壞的作業產生相同的結果：沒有成功，也沒有警報。. 我的堆疊中沒有任何基於故障的警報會針對這項任務觸發。如果它的憑證在七月過期，或者它的管理員 ID 失效，或者技能文件被刪除，我的儀表板看起來也和現在一模一樣。正因如此，它才能在四個月的時間裡里安然無恙，無人過問。.
而這正是我一直在重新學習的部分。我之前也寫過這方面的內容。 當警報器顯示故障時，首先要檢查警報器。 但更棘手的情況是警報器始終不發出任何警報，因為根本沒有東西可供檢查。我之前也發現過這一點。 我的監督系統將42個真正的不及格案例全部判定為合格。, 出於同樣的結構性原因：它接受了正常故障也會產生的訊號。.
週日檢查：十分鐘，三個問題
無論你的自動化程式是由 n8n、Make、cron、Claude Code 代理程式還是 GitHub Actions 運行的，請擷取上個月的運行歷史記錄，並按順序回答這些問題。.
- 哪些工作既沒有失敗也沒有成功？ 這就是這次練習的關鍵所在，也是篩選步驟之一。根據定義，此類別中的任何作業都無法監控。現在，請對每個作業做出判斷：它是真的處於空閒狀態（如果是，則縮短其調度時間），還是無人檢查（如果是，則打開它並手動運行一次）。.
- 有多少次比賽以沒有記錄結果而告終？ 我的數值是 7.2%。如果你的數值大於零，那麼你的成功率並非你想像的那樣——它實際上是這個數值加上一個未知數。在信任這個比率之前，請先修正報告方式。.
- 你的失敗次數是否集中在少數幾個作業？ 如果20個作業中有3個作業導致了所有故障，那麼你的系統並非存在普遍的可靠性問題，而是三個供應商的問題，修復起來便宜得多。.
然後手動執行一次最安靜的作業。不是讀取日誌－而是實際觀察其執行過程。這是唯一能區分空閒和當機狀態的測試。既然你已經在做了，就值得一試。 檢查隊列的產生時間，而不是隊列深度。 原因也是一樣：滿載運轉就像一份安靜的工作，永遠不會造成任何問題。.
重點
低錯誤率並不能證明你的員工在努力工作，它只能證明他們沒有抱怨。這兩者意義不同，而且在星期日，只有其中一種說法才有意義。.
這週真正需要你處理的工作，並非那些不斷彈出通知的。那些響亮的通知已經引起了你的注意——通知的作用就在於此。真正需要你處理的，是那件已經安靜了四個月的工作。.
開啟您的運行歷史記錄。按報告的總結果數升序排列。查看第一行。十分鐘。.
📥 免費：《人工智慧劇本》
我用來經營一人代理公司的所有工具和工作流程。 25 年的行銷經驗濃縮成一份實用指南。免費贈送。.
人工智慧與數位行銷策略師
Jon Jones擁有超過25年的數位行銷、電子商務、銷售和國際商務經驗，是一位資深企業家，致力於透過創新的人工智慧解決方案賦能小型企業。他的職業生涯始於華爾街的投資銀行，曾指導企業完成資本募集和應對複雜的市場環境。如今，他的專業領域已拓展至網站開發、品牌設計、產品開發以及課程培訓。.
Jon精通普通話，並在金融和科技領域擁有深厚的功底。他創立了JonJones.ai，旨在為小型企業提供易於使用且具有變革意義的工具，幫助他們簡化營運、拓展客戶並實現永續成長。他對人工智慧、自動化和數位化策略的精通，已幫助許多企業彌合了傳統模式與現代技術之間的鴻溝，確保它們在當今的數位化環境中蓬勃發展。.
