停止條件寫得太乾淨,反而先砍到承重牆

停止條件寫得太乾淨,反而先砍到承重牆

現象

約二十條長期排程的自動化任務,各配一張評分卡,規則寫得很整齊:觀察期內沒達標,就停用。做完當下感覺乾淨——直到重新看那張清單。內容產出、資料入庫、每日彙整、風險控管、例行巡檢,這些任務混在同一張表裡,套著同一條規則。它們是流程本身在跑,不是為了驗證某個假設而存在。指標不好,代表做法爛;不代表這件事不用做。水管漏水不能直接關總閘——實驗性的花園灑水可以說停就停,廚房的水得先接好臨時管線,才敢拆舊的。

分界點

判斷一條自動化該不該被停掉,關鍵是「停掉之後有沒有人接手」。停了會讓某個環節直接空出來,它是必要線;停了只是少一組數據,它是實驗線。這條界線跟指標高低沒有關係,是先於指標存在的屬性——寫規則之前就該先問過的問題,不是靠事後的 KPI 表格去回答。

容易誤判的原因

治理規則寫久了容易「一致性上癮」:同一份表格套同一套停止條件,看起來嚴謹、公平,改起來也省事。但一致性只在對象同質的時候才成立。把命脈流程和探針實驗放進同一張表,一致性反而變成風險——嚴謹的規則,套錯對象一樣會出事。另一種誤判是把「沒有 KPI」直接當成「該停」,但很多必要線只是還沒想好怎麼量測,不是沒有價值。這兩種誤判長得都很像「認真做治理」,其實是把判斷偷懶地外包給一張表格。

確認方式

後來的做法:每條線加一個類別欄,強制二選一,停止條件改成兩套語意。實驗線觸發即停,不需要替代方案。必要線觸發時只能做四件事之一——換做法、重做、換執行者、降低頻率,而且要等替代方案實際跑通之後,舊做法才能關閉。順序很重要:先接上新的,再拆掉舊的,中間不留真空期。至於那些缺量測指標的必要線,處置是設一個補齊期限,逾期就走「換做法」流程,而不是直接下架。這條分類線後來套進約二十條登錄線,大多數判定為必要線,少數是實驗線,兩邊分別重新檢查了一次規則本身有沒有被真的用到。

留給未來的話

任何淘汰機制上線前,先問一句:這批東西是同一類嗎。停止條件的本質是資源回收,回收之前要先確認,被回收的不是承重牆。規則的價值在於它有沒有正確區分對象——一個月後再檢查一次,有沒有任何一條線真的因為規則被換法或降頻,零次,代表規則寫得太鬆。

— 邱柏宇


A Kill Switch That’s Too Clean Cuts the Load-Bearing Wall First

The Setup

Roughly twenty long-running scheduled jobs, each given a scorecard, each governed by one rule: fail to hit target during the observation window, get shut down. It felt clean the day it shipped. Then came a second look at the list. Content publishing, data ingestion, daily digests, risk checks, routine audits — these weren’t hypotheses waiting to be validated. They were the pipeline itself. A bad number means the method is bad. It doesn’t mean the job stops mattering. A burst pipe doesn’t get fixed by shutting the main valve — an experimental garden sprinkler can be turned off on the spot, but the kitchen line needs a temporary hookup before the old pipe comes out.

Where the Line Actually Falls

The question that decides whether a job should be killable is whether anything fills the gap once it’s gone. If cutting it leaves a hole in the workflow, it’s load-bearing. If cutting it just means one less dataset, it’s experimental. That split has nothing to do with how good or bad the KPI looks — it’s a property that exists before any metric gets attached, and it needs answering before the rule gets written, not after.

Why It’s Easy to Get Wrong

Governance rules age into a craving for consistency: one table, one kill condition, looks rigorous, looks fair, is cheap to maintain. But consistency only holds when the things being governed are actually alike. Mixing critical infrastructure with exploratory probes on the same sheet turns a rigorous-looking rule into a real risk. A second trap: treating “no KPI yet” as “should be killed.” Plenty of load-bearing jobs simply haven’t had their metric worked out — that’s a measurement gap, not a value judgment.

How to Check

The fix: add a category column, force a binary choice, and split the kill condition into two different grammars. Experimental lines trigger, they stop, no replacement needed. Load-bearing lines trigger, and only four moves are allowed — change the method, redo it, swap who runs it, or lower the frequency — and the old approach can’t be retired until the replacement is actually running. Order matters: connect the new one first, then disconnect the old, no gap in between. For load-bearing lines still missing a metric, the fix is a deadline to fill the gap, after which it falls into the “change method” track instead of getting dropped. Applied across roughly twenty registered jobs, most landed on the load-bearing side, a handful on the experimental side, and both got a follow-up check to see whether the rule was actually being used.

One Thing Worth Carrying Forward

Before any garbage collection mechanism goes live, ask one question first: is this batch actually one category. The whole point of a kill condition is resource recovery, and recovery only works if the thing being recovered isn’t a load-bearing wall. A rule’s value isn’t how much it covers — it’s whether it tells the two apart correctly. Check back in a month: if not a single line got changed or throttled under the rule, the condition was written too loose.

— 邱柏宇

延伸閱讀