
演示無法過夜:一次模擬環境當機後,我們將 preflight 移至 CI
上個月為一個團隊交付了模擬環境的自動化腳本,在交付前最後一輪的批次執行演示中,於凌晨兩點半失敗。日誌僅顯示一行超時錯誤,環境直接鎖死,隔天早上我們對著螢幕重新安裝了一整套依賴套件。復盤時大家一片沉默,因為這個問題其實「早就預防過」——操作手冊(runbook)裡明明寫著。
深度內容,技術探索,設計思考

上個月為一個團隊交付了模擬環境的自動化腳本,在交付前最後一輪的批次執行演示中,於凌晨兩點半失敗。日誌僅顯示一行超時錯誤,環境直接鎖死,隔天早上我們對著螢幕重新安裝了一整套依賴套件。復盤時大家一片沉默,因為這個問題其實「早就預防過」——操作手冊(runbook)裡明明寫著。

上個月我們給業務端上線一套內容異常檢測,第一週就撞上老毛病:模型很「熱」,把高分的異常件全撈出來,人工複審佇列三天堆了三千多筆。業務端的結論只有一句:「這麼多誤報我們沒辦法看,先別用了。」

上個月我們在一條識別鏈路裡花了一整週排查「模型在特定品類上變差」。最後定位到的根本原因和模型評分本身關係不大——是上游一條時間視窗滑移的鏈路事件,把檢測任務的可用數據拉長了,再疊加一個只有部分團隊知道的離峰運行改動,導致高價值樣本的比對視窗整體向後滑了一段。

上個月協助一個內部團隊進行意圖分類服務的性能除錯。區域監控顯示 P99 延遲從 310ms 悄悄漲到 740ms,持續了大約三天才有人發出警報。模型沒變、GPU 沒變、prompt 模板也沒動——第一反應是去找基礎設施團隊,查了一下午也沒找到異常點。最後真正的原因出在請求閘道層:一個上線時沒有任何監控覆蓋的限流中介軟體

上個月二點檔的發布任務,同一個 bug 報了三次。第一次,腳本自建自清理;第二次,它把異常吞掉變成空結果;第三次,它自己探測自己寫的檔案,探測結果反過來又變成重試條件,空轉了四十分鐘。直到我們把「判斷該不該重試」從執行行程裡搬出去,這種活鎖才停下來。記錄一下。

上次給客戶的演示排在下午三點,早上的例行巡檢裡,我把主後端從 A 池切換到了 B 池,想趁沒流量的時候試一次真正的故障轉移。結果切換腳本在健康檢查這一步卡了 38 分鐘,差點把演示拖成事故。這篇把當時的除錯記錄和後來落地的三條規則寫下來,都是我們自己踩過的坑。

上個月我們將線上推理從雲端 API 切換到本機 router,流量數據相當亮眼:P95 延遲從 1400ms 降至 220ms,月底帳單節省了約七成。我們按照計畫完成切換、觀察一週並匯報結果。

上週把我們本地推理叢集接上生產環境的最後一週,CI 全綠、監控全綠、fallback 鏈路演練也「成功」了。結果第一次真正擋住上游流量的那天,復原動作的第一步就卡住了——我們按故障預案滾動重啟「不健康的節點」,排出來的一台其實是最健康的那台。

上個月,我們把團隊的本地推論路由從內網上的舊節點遷到了各工作站的本地埠。聽起來只是改幾個位址,實際踩坑踩了整整五天。記錄一下,給同樣在做這件事的同行參考。