消除 Toil:把重複的維運當成待消滅的 bug

第一篇說 SRE 的內核是「維運可以被工程化」。這篇講的 toil,就是那個要被工程化掉的東西。很多人以為 toil 就是「辛苦的工作」,其實不是——它是一類有明確特徵的工作,而且如果你不主動砍它,它會自然膨脹到吃光你所有做工程的時間。

什麼是 toil(以及什麼不是)

Toil 指的是「跟跑生產服務有關、但具備下面這些特徵」的工作。符合越多,它就越是 toil:

分清楚一件事很重要:toil ≠ 所有討厭的工作。 開會、寫文件、規劃、回 email 這些是 overhead,雖然也佔時間,但不是 toil。Toil 特指那種手動、重複、機器本來就能做、做完系統卻沒變好的操作——手動重啟服務、手動改設定、手動處理每一次一樣的告警。也不是說一點 toil 都不能有;少量 toil 可以接受,關鍵是不能讓它膨脹。

一個很常見的模糊地帶是「手動測試算不算 toil?」——答案是看哪一種,而分界正好落在「無長期價值」這條。每次 release 都手動點一遍相同的 regression 流程,六個特徵全中,是教科書級的 toil,該把它自動化掉;但探索性測試(人憑經驗到處戳、找出新的邊界情況)、第一次測一個全新功能、UX 測試,這些需要人的判斷、每次都在探索新東西、也很難自動化——它們有累積,不是 toil。一句判準:「這次手動測完,下次還要一模一樣再測一遍嗎?」 會,就是 toil;不會、每次都在用判斷探索,就是有價值的人力。

為什麼一定要砍:它會隨規模線性成長

Toil 最危險的特徵是「隨服務規模線性成長」。服務長大一倍,手動維運的量也大約長一倍。如果你放著不管,需要的人力就會跟著規模一路往上,直到把團隊淹沒:

更糟的是惡性循環:toil 越多 → 越沒空寫自動化 → toil 繼續累積 → 更沒空……因為 toil 總是「緊急」(告警在響、服務要重啟),而自動化總是「重要但不緊急」,永遠被救火排擠到明天。為了打斷這個循環,Google 設了一條有名的護欄:SRE 花在 toil 的時間應該低於 50%,另一半必須拿去做「能減少未來 toil」的工程。這條線是刻意的——不強制圈出工程時間,它一定會被 toil 吃光。

怎麼砍(但不是全砍)

砍 toil 的主要武器就是自動化:把重複的手動操作寫成程式、做成自助工具、讓系統自己修復。但有個重要的前提——不是所有 toil 都值得自動化。 自動化本身有成本,你得算一筆帳:自動化的投資 vs 未來能省下的 toil × 發生頻率。一年才做一次的操作,花兩週去自動化它,通常不划算;但每天要做、每次十分鐘的,自動化的投報率就極高。所以砍 toil 不是無腦全自動化,而是挑投報率高的先下手。

反思

Toil 的本質不是「累」,是「沒有累積」

我以前會把「這工作好煩、好累」跟「這是 toil」畫上等號,後來發現重點根本不在累不累,而在做完有沒有留下東西。蓋一個新功能很累,但它有累積、系統變好了,那不是 toil;手動重啟服務第一百次同樣累,但系統一點沒變、下次還得再來,那就是 toil。這個區分讓我更清楚該保護什麼——我要守住的是「有累積」的時間,砍掉的是「純消耗」的時間。把人放在會累積的地方,把純消耗交給機器,這才是 SRE 說「工程化」的真正意思。

50% 上限是一條「刻意的護欄」,不是理想值

我最欣賞 50% 這條線的地方,是它承認了一個現實:如果不硬性圈出工程時間,它一定會被救火吃光。 因為 toil 永遠比較「緊急」,自動化永遠比較「重要但不緊急」,而緊急的事總是贏。50% 不是說「理想上花一半在 toil」,而是「上限」——一條逼你把重要不緊急的事保護起來的護欄。這跟我做任何長期投資的紀律一樣:重要但不緊急的事,不主動圈時間保護,就永遠不會發生。

別為了自動化而自動化

砍 toil 也要防走火入魔——不是所有 toil 都值得自動化。我看過有人花一個月自動化一個一季才跑一次、五分鐘就做完的流程,純粹因為「手動很不 SRE」。但那筆帳算下來根本虧。自動化是手段不是信仰,判準永遠是那筆 ROI:投資 vs 省下的 toil × 頻率。這又回到 先確認痛點再上重武器——先看這個 toil 到底痛不痛、夠不夠頻繁,值得了再自動化。把力氣花在天天在痛的那幾件事上,比追求「零手動」的潔癖實在得多。