工作總結
發表時間：2026-04-012026年周末值班故障處理小結[范例]。
周五晚上十一點，手機震了。我看了一眼，數據庫連接數告警，閾值800，實際1176。
第一反應不是慌，是罵自己——昨天下班前才跟小張說“那個報表接口先上吧，周末流量不大”。這話現在聽起來像廢話。
連上VPN，查processlist，一堆Sending data狀態的查詢堆在那，來源IP指向剛上線的那臺應用服務器。我讓小張也起來看了，他在群里回了個“臥槽”，然后說“我那個接口的SQL”。我沒接話，先干活。
執行kill命令清連接的時候，手有點抖。不是因為緊張，是知道這次是我自己放過去的。清理完異常連接，業務開始恢復，但接口響應還是慢。打開慢查詢日志一看，order_detail表全表掃描，那張表現在有四百多萬行數據。創建聯合索引的時候，我在命令行里敲ALTER TABLE，盯著屏幕等了兩分鐘。這兩分鐘里，支付回調失敗了三次。
索引建完，接口響應從8秒掉到120毫秒。連接數回落到200左右。整個過程12分鐘。
我讓小張去查那三次失敗的支付回調，手動觸發重試。他說好，然后補了一句“組長，那個SQL我寫的時候覺得數據量不大……”我說先干活，明天再說。
掛了電話，我給運維總監發了條消息，簡要說明了故障情況和處理過程，提了一句“根源在我把關不嚴”。他回了四個字：“周一細聊。”
周六上午十點，線上復盤會。我沒讓小張寫檢討，也沒讓大家輪流發言。我直接把自己的操作記錄投屏出來，從收到告警到索引建完，每一步怎么走的，當時怎么判斷的，都過了一遍。然后說：“這個故障，根因是我沒卡住那個SQL。但除了我，還有三個漏洞——監控閾值設高了，慢查詢沒有獨立預警，應急預案文檔里缺了‘連接數暴增’這一節。”
小張在語音里沉默了一會兒，問了一句：“那我那個接口還繼續用嗎？”我說用，但代碼得改，分頁邏輯重新寫，下午四點前提交。
會后我列了個清單。第一條就是改監控閾值。之前數據庫連接數告警閾值是800，但數據庫最大連接數設的是1000，中間只有200的緩沖。按上周的流量峰值來看，從正常值200漲到800，最快一次只用了7分鐘。這個緩沖窗口太窄了。我把閾值調到500，同時在Grafana上加了一個慢查詢數量面板，每分鐘超過5次就給值班群發釘釘。這個慢查詢預警其實上季度就提過，當時手頭在趕另一個雙十一的壓測項目，想著“先放一放”，結果一放就放到出了故障。
第二條是整理應急預案。我把這次用到的命令——show processlist、kill、ALTER TABLE加索引的完整語法，連帶著怎么判斷哪個SQL該殺、哪個索引該建的邏輯，都寫進了操作手冊。還加了幾個坑：比如創建大表索引時建議用pt-online-schema-change而不是直接ALTER，避免鎖表時間過長。寫完后發群里，讓每個人周末抽時間在自己的測試環境跑一遍。
第三條是重新審核本周要上線的代碼。我挨個查了涉及數據庫變更的提交記錄，又找出3處索引缺失和2處分頁邏輯可能存在的深分頁問題。其中有一個是另一個同事老周寫的，他看了之后說“這個確實沒注意”，然后自己改完重新提測。
下午小張把改好的代碼提交了，我跑了一遍壓測，接口響應穩定在200毫秒以內，慢查詢日志干干凈凈。
周日下午，我在做那個“觀測清單”的模板。其實就是一張表：接口名、預期QPS、核心表、慢查詢閾值、索引命中情況。以后每個上線的接口必須附帶這個，否則不給合并。這不是什么新點子，就是之前一直沒落到紙面上。我一邊做一邊想，如果這個清單三個月前就有了，周五晚上的故障大概率不會發生。
總監那條“周一細聊”的消息，我到現在還沒想好怎么回。要說責任，確實在我——評審放水、監控閾值沒優化、應急預案不完整，這些都不是小張的問題。但我更在意的是另一件事：為什么明知道慢查詢預警該做，卻一直沒排上優先級？為什么明知道那個SQL有隱患，卻說了“先上吧”？這些不是流程能解決的，是我自己在這類事情上不夠較真。
周一早會，我打算先把觀測清單推下去，然后把上周五的故障處理過程在團隊里再過一遍。這次不說“反思”，就說“我當時怎么想的，哪步錯了”。小張那幾句“數據量不大”的話，其實我挺熟悉的——我自己當年也說過類似的話，然后捅了更大的婁子。經驗這東西，有時候是護身符，有時候就是麻痹藥。 dSbJ1.com
故障處置那12分鐘，從監控告警到索引生效，時間精確到分鐘。但真正讓我覺得需要調整的，是那12分鐘之外的很多東西。那些日常里覺得“差不多就行”的決定，最后都會變成某個深夜手機震動的原因。
這個周末，我補了三樣東西：監控、文檔、流程。但最該補的，是我自己對“差不多”這兩個字的警惕。
- 需要更多的工作總結網內容，請訪問至：工作總結
