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