工作總結
發表時間：2026-04-11中班工作總結〔2026推薦〕。
這段時間排的中班，下午四點到夜里十二點，正好接白班的尾巴，再把手頭的事交給夜班。這個班次最磨人的不是技術難度，是接手時經常面對一堆“觀察中”的爛攤子。
講兩個最近實打實處理過的故障，一個數據庫的，一個日志采集的。
上個月中旬，下午四點半我剛坐到工位，白班同事交接說：“核心查詢接口有點慢，觀察中，你們再看看。”我登錄監控一看，應用服務器CPU 85%，數據庫負載正常，但連接池活躍數198，最大配置才200。這不是“有點慢”，是馬上要崩。趕緊抓線程堆棧，jstack發現一百多個線程卡在JDBC連接獲取上。追慢查詢日志，有張熱表的查詢執行時間從50毫秒漲到4秒。再往前翻變更記錄，凌晨有個數據同步任務改了那張表的結構，加了一個非索引字段當查詢條件。改的人早下班了，也沒通知任何人。
換去年，我第一反應肯定是重啟應用清連接池，先恢復再說。但今年我改了個習慣——先看變更關聯，再動手。我確認了慢查詢的SQL，臨時在那張表上建了個復合索引。問題來了：DBA說這個表不能在線加索引，會鎖業務。我查了下，表大小不到20G，用pt-online-schema-change跑，大概三分鐘能搞定。但走變更審批流程要填單子、找組長批、找DBA確認，這一套下來少說十五分鐘。我直接給組長打了個電話：“業務快掛了，我先用pt-osc做，事后補單子。”組長猶豫了三秒，同意了。索引建完，連接池立刻降到正常水位，接口恢復。從發現問題到解決，總共27分鐘，其中15分鐘花在等審批和打電話溝通上。
事后我補了單子，也干了一件事：在監控系統里加了兩個預警。一個是連接池使用率超過80%就報警，另一個是把慢查詢閾值從2秒降到500毫秒，并且把慢查詢日志和表結構變更記錄做了關聯——雖然這個關聯是半自動的，我寫了個腳本每天凌晨跑，把前一天的變更記錄和慢查詢日志匹配，生成報告發到群里。上周這個腳本還真抓到一個類似的隱患，提前扼殺了。相比去年，同樣原因導致的數據庫連接池問題出現過四次，今年到現在只這一次。
第二個案例是日志采集積壓。我們用的自研Filebeat采集容器日志到Kafka，某天晚上八點，我發現三個節點的日志延遲從秒級漲到40分鐘。查Filebeat的registry文件，發現有個日志文件的inode被復用了——docker的json.log輪轉后，新文件可能復用舊文件的inode（overlay2存儲驅動下常見），導致Filebeat不停重試同一個文件段，卡死在那里。去年的處理方式簡單粗暴：重啟Filebeat，清空registry，重新采集。后果是丟幾分鐘日志，而且那次正好丟了某個關鍵錯誤日志，后來排查問題少了線索，被研發罵了一頓。
這次我沒重啟。我先停了Filebeat，備份registry，然后用python腳本手動解析偏移量。registry是個json文件，里面記錄了每個文件的source路徑和當前offset。我用os.stat拿到出問題文件的inode，然后在registry里找到inode匹配的那條記錄，把offset往前調了512字節（保證不丟數據），再寫回去。啟動Filebeat，日志從調整后的位置繼續采集，一條沒丟。整個恢復過程用了八分鐘，其中寫腳本花了五分鐘——那個腳本我現在還留著，遇到類似情況直接跑。
事后我把日志輪轉策略改了：從基于大小（100MB輪轉）改成基于時間（每小時輪轉一次，保留24個），并在輪轉時強制chattr +C關閉寫時復制，避免inode復用。另外在Filebeat配置里加了close_timeout: 5m和clean_removed: true。上周有個新來的同事遇到同樣問題，直接跑我的腳本，五分鐘搞定，他跟我說：“這破事終于不用再折騰了。”我聽了挺高興。
- 讀書筆記吧（DSbj1.CoM）小編好專題推薦:
- 中班配班工作總結?|?幼兒中班教師工作總結?|?幼兒園中班工作總結?|?中班主班教師工作總結?|?中班月工作總結推薦?|?2026工作總結
設備維護這塊也有變化。以前巡檢靠人盯著監控大屏，兩小時看一眼，經常等報警來了盤已經壞了。今年我把所有硬盤的SMART數據、RAID卡日志、電源冗余狀態全接進了Prometheus，用node_exporter的textfile功能定期采集。預警閾值不是等壞道擴散，而是看趨勢——比如“Pending Sector”從0變成1就發釘釘消息。上個月有塊SSD的磨損壽命到了87%，預警提前三天觸發。我跟業務方商量好，凌晨兩點做了熱備替換，整個切換過程業務零感知。放在去年，這種盤往往等到讀寫報錯才發現，那時候得停業務換盤，至少折騰一小時。
說到工藝標準，最近我把服務器初始化的檢查項從15條擴到32條。新增的包括：net.core.somaxconn調大（防止高并發下連接隊列溢出）、vm.max_map_count調大（ES容器需要）、關掉avahi-daemon和ModemManager這些沒用的服務，還有NTP同步偏差閾值設成10毫秒。但擴充完沒多久就出了個洋相——驗收一臺新機器時，我忘了檢查net.ipv4.conf.all.rp_filter，結果那臺機器出現非對稱路由丟包，業務偶發超時。排查了兩個小時才發現。后來我把所有內核參數的校驗做成了ansible role，每次驗收跑一遍ansible all -m shell -a 'sysctl -a'，跟基線做diff。現在驗收不只是“能ping通、能ssh就過”，而是跑一套故障注入測試，比如模擬網卡丟包5%，看系統日志有沒有異常。
最后說個中班特有的糟心事。下午四點接白班的班，交接記錄經常寫“監控有點波動，觀察中”。上周五我五點一看，磁盤使用率已經從82%漲到94%——他們說的“波動”其實是某個日志輪轉沒生效，/var/log/messages已經撐到28G。我趕緊手動清理，順手寫了個crontab每天凌晨壓縮歸檔。第二天白班同事看到郵件，給我發消息：“你們中班干活真狠。”我回他：“你們下次別留坑就行。”
- 想了解更多工作總結的資訊，請訪問：工作總結
