維運中斷:殺死生產力的不是工作量,是被切碎的時間

On-call 那篇講「怎麼設計告警、誰值班」,Toil 那篇講「用 50% 護欄別讓維運吃光工程時間」。但這兩條之間,漏了一個每天都在發生、卻很少被當成問題來管的東西:中斷(interrupts)——那些一則則的 ticket、臨時被問的問題、隨手丟來的 page。它們單看每個都不大,合起來卻能讓一個工程師一整天「很忙,但什麼都沒推動」。這篇講中斷為什麼這麼貴,以及怎麼在團隊層級管它。

中斷的成本,不是時間,是被切碎的時間

先破一個直覺:一個 5 分鐘的中斷,真正的代價不是那 5 分鐘。是它打斷了你的心流,而事後要花 20、30 分鐘才能重新爬回剛剛的思考狀態(ramp-up)。所以中斷殺死的不是「工作時間」,是「連續的、能做深度工作的時間」。這件事的殘酷之處在於:同樣的中斷總量,散開來、還是收成一塊,產出天差地遠:

兩列的中斷總時間一模一樣,產出卻天差地遠。① 散開的中斷,每一個後面都拖一段重新進入狀態的 ramp-up,把工作切成一小段一小段的碎片——深度工作幾乎歸零。② 同樣的中斷收成一塊,左邊就留下一整段不被打斷的時間。所以管中斷,不是管「總量」,是管「碎片化」——這也是為什麼「隨時被打斷一下」比「集中被打斷一次」傷得多

Interrupt shield:用一個人的專注,換回一整隊的專注

既然碎片化才是真正的敵人,團隊層級的解法就很清楚:別讓每個人都分到一點中斷(結果全員被切碎、整隊零深度工作),而是指定一個人(或一對)這段時間當「盾」,接下所有中斷,其餘的人換到完整、不被打斷的時間。下一輪再輪替:

左邊每人各接一點中斷,結果是四個人全被切碎、整隊零深度工作。右邊指定一個人當盾接下全部中斷,另外三人就換到完整不被打斷的時間,下週再輪替。這筆交易很划算:拿一個人的專注,換回其餘 N−1 個人的專注。配套是「盾」要把時間極化——這段時間就全職處理中斷,不要一邊接 ticket 一邊想推專案,那等於兩頭都做不好

反思

我衡量團隊產能,看的是「完整時間塊」,不是「忙不忙」

帶團隊久了,我對「忙」越來越不信任。一個團隊可以每個人都很忙、都在加班、ticket 都有回、Slack 秒讀秒回——然後季度目標一項都沒動。因為沒有任何一個人,拿到過連續三小時去做真正需要思考的事。忙,是中斷餵出來的假象;產出,來自不被打斷的整塊時間。 所以我現在 review 團隊健康,不看「大家忙不忙」,看一個更誠實的數字:這週,每個人拿到了幾個「不被打斷的兩小時」? 這個數字,幾乎直接對應我們能不能做出需要動腦的東西。把它當指標之後,我對會議、對「同步一下」、對隨手的 @,都變得小氣很多——因為我知道我砍掉的不是幾分鐘,是別人一整段的心流。

半推半就的 available,是最糟的狀態

「我一邊做專案、一邊隨時看一下 Slack」,聽起來很負責,其實是所有狀態裡最差的一種:你既沒有真的專注(隨時準備被拉走,思考永遠停在淺層),中斷的回應也慢(卡在專案的脈絡裡切不過去)。50/50 的 available,是專注和回應兩頭空。 這也是 interrupt shield 的精髓——它逼你極化:要嘛全職當盾、要嘛完全被保護,不要待在中間。我對自己也套同一條規矩:當我決定今天要進 deep work,就把通知關掉、明確跟團隊說「今天找 X,先別找我」。這不是不負責——恰恰相反,它是把「負責回應」這件事,清楚交給此刻該做它的那個人,而不是每個人都心不在焉地半接著。

中斷率一直升高,是症狀,不是「該多請人」

最後一個是 lead 最容易做錯的判斷。當一個服務的 ticket 越來越多,直覺反應是「人手不夠,再加一個人來接」。但中斷率持續升高,幾乎總是上游有東西壞了的症狀:一個沒做好生產就緒的服務、一堆本該自動化卻沒做的 toil、一份過期的 runbook 讓同一個問題被一問再問。加人去接中斷,只是把症狀吸收掉,反而讓真正的病灶更難被看見——你花錢買了「看起來還撐得住」,代價是永遠不去修那個一直在生 ticket 的源頭。所以我把「中斷量」當成一個 SLI 在追:它一路往上,代表該回頭修的不是排班表,是那個源頭。這也收束回 SRE 的底層信念——它對「人的時間」也做可靠度工程:專注,跟服務的正常運轉一樣,是一種會被侵蝕、必須主動保護的資源。