工作總結

發表時間：2026-04-19

2026年建設銀行個人工作總結。

干一線運維這些年，我有個很深的體會：系統不出事的時候，沒人覺得你重要；一出事，第一個找的就是你。所以我的工作邏輯很簡單——把問題摁死在冒頭之前，萬一真冒了頭，也得最快速度按下去。下面是我這一年的干活筆記，全是真碰過的釘子，沒有漂亮話。

1. 那次ATM“吞卡”的破事，讓我重新認識了溫度

年初，一個離行式自助點的存取款一體機頻繁報“現金模塊通訊超時”。第一次去，斷電重啟，好了。兩小時后電話又響。第二次去，換數據線，刷固件，管了半天。第三次，我差點把主板換了。

說實話，那幾天我走路都在想這破機器到底什么毛病。第四次去，我沒急著動手，搬了把椅子坐旁邊，盯著它的自檢流程。突然發現一個細節：設備啟動后，內部溫度讀數從32度飆升到58度只用了幾分鐘。拿測溫槍一掃機芯倉，好家伙，散熱風扇轉速只有標稱的一半。風道堵了厚厚一層灰，熱量散不出去，控制芯片熱得不干活了。

我沒只換風扇。按施工規范，拆了整塊主板，用壓縮空氣把每個散熱鰭片吹透，還在機柜側面加了一個輔助排風扇，專門調了風道方向。同時改了巡檢項——以后每次巡檢必須用紅外測溫槍打一下機柜內溫度，記在臺賬上。這套搞完，那臺機器再也沒犯過老毛病。后來我把這個案例寫進了《常見故障排除手冊》，加了一條：“凡是通訊類偶發故障，先看溫度，再看信號，最后才動主板。”這順序能省你半天時間。

2. 那次磁盤寫滿，差點釀成生產事故

二季度，核心業務系統的一個日志分區突然100%寫滿。交易響應從毫秒級掉到秒級，柜員那邊已經開始罵了。我緊急擴了空間、清舊日志，15分鐘后恢復。但這事不能就這么過去。

復盤時我發現，日志輪轉策略還是五年前的配置——每天凌晨輪轉，保留7天。現在業務量是五年的四倍，7天的日志就有200多G。更蠢的是，監控只告警磁盤使用率超過90%，但告警發出來的時候，往往已經來不及了。

我干了兩件事。第一，改成每小時輪轉一次，保留3天熱數據，壓縮后轉儲到備份服務器保留90天。第二，寫了一個自動清理腳本，每15分鐘跑一次，檢查使用率超過85%就自動刪除最老的歸檔日志，同時發一條預警到運維群。腳本部署后，磁盤告警從每周平均4次降到了0次，連續跑了三個月沒出問題。這讓我意識到，很多所謂的“突發故障”，其實是慢性病拖出來的。你只要肯花半天時間把歷史數據翻一遍，總能找到規律。

3. 那次和業務部門“扯皮”，我學會了用數據說話

有一次，業務部門投訴某報表系統“慢得沒法用”，說我們運維沒搞好網絡。我ping了一下，延遲正常。查服務器負載，CPU、內存都低。最后翻應用日志，發現一個查詢語句每次要掃描300萬行數據。

我把這條SQL拖出來，放到測試庫上一跑，果然是全表掃描。截圖、執行計劃、耗時統計，三樣東西打包發郵件給業務部門，附了一句：“這個查詢建議加個索引，或者改一下查詢條件。現在這寫法，換什么網絡都快不起來。”業務那邊剛開始還不認，說以前都能用。我直接把去年同期的日志拉出來對比——那時候數據量才80萬行，現在300萬行，當然慢。數據擺在那，他們沒話說了，老老實實找開發加索引。

這事之后，我養成了一個習慣：凡是接到性能投訴，第一件事不是解釋，是拿數據。數據比嘴巴管用一萬倍。

4. 那次誤操作，讓我永遠改了操作規范

說起來丟人。去年有一次，我要在測試環境重啟一個服務，結果ssh窗口開多了，一頓操作猛如虎，重啟的是生產環境的日志采集器。十幾秒后，監控大屏上那個網點斷聯了。我當時后背一下就濕了。

?讀書筆記吧精品索引: