工作總結
發表時間：2026-04-10[精選]技術員轉正工作總結。
入職三個月，轉正了。趁熱打鐵把這陣子干的活、踩的坑、攢下的經驗捋一捋。我不太會寫那種漂亮話，就按時間順序，把幾個實實在在的事擺出來。
先說那次凌晨的宕機。試用期第二周，凌晨兩點多，監控報警——業務系統訪問大面積超時。我從床上爬起來，連VPN、跳板機，心里罵了一句：怕什么來什么。先看負載，0.8，正常；CPU，20%，正常；內存，剩余3G，正常。再查磁盤IO，也不高。那就怪了。繼續往下翻連接數，發現已經飆到上限了，而且每個連接的狀態都是“Locked”。順著鎖往上追，查到一條新上的統計SQL——開發同事寫了個大表關聯，沒加索引，直接把核心業務表鎖死了。當時我手動kill掉那幾條慢查詢，臨時把統計接口下線，業務在25分鐘后恢復。25分鐘里，有15分鐘在排查，10分鐘在執行。事后我拉上開發和產品，把執行計劃打印出來貼在白板上，逐行看。問題很明顯：測試環境數據量只有線上的1%，索引效果被完全掩蓋。我們定了一條規矩：所有多表關聯查詢，必須先拿脫敏后的生產數據樣本在預發環境跑執行計劃，DBA簽字才能上線。這事之后，我養成個習慣：每次變更前，先在腦子里過一遍——這操作最壞會怎樣？回滾怎么弄？告警閾值設了沒？
再說一個看起來不起眼但差點出大事的。那次配合廠家換UPS輸出開關，斷電、驗電、掛接地線，每一步都按規程來。合閘送電后，有一路設備頻繁重啟。用萬用表量電壓，波動不大；拿示波器抓波形，零地電壓峰值接近6V。查到最后，是配電柜接地銅排上一個M6螺栓沒擰緊，扭矩螺絲刀一測，只有2.3Nm（標準是5Nm）。那個端子藏在幾根粗線后面，我驗收時只看了顯眼的地方。問題不大，后果不輕——電源在這種環境下長期工作，壽命肯定打折。那天下午我花了兩小時，把機柜里所有接地端子重擰一遍，還用熱成像掃了每個連接點。從那以后，我的巡檢清單上加了一條：關鍵電氣連接必須用扭矩螺絲刀復核，拍照留底。帶新同事看現場時，我會專門指著那些角落說：別光看指示燈，螺絲才是鬼故事多發地。
日常的活其實沒那么刺激。每周兩次巡檢，看磁盤SMART數據、看日志有沒有異常報錯、看備份是不是真能恢復——上個月我試著恢復了一個舊備份，發現有個腳本路徑寫錯了，恢復失敗。趕緊改了，并把備份恢復演練從季度一次改成月度一次。三個月下來，累計處理工單18件，參與變更12次，沒出過人為事故。有幾次是小毛病：證書快過期了、磁盤慢扇區增多了、一個進程的內存泄漏了。這些事不寫出來顯得沒分量，但說實話，系統穩定靠的就是把這些“小毛病”在變成大故障之前摁住。
說個有點感觸的。項目沖刺那周，同時上三個模塊，我基本住值班室了。凌晨兩點剛做完存儲遷移，對講機喊：日志采集器掛了，數據積壓。跑過去一看，進程僵死，重啟后反復崩潰。用strace跟蹤系統調用，發現它在寫一個不存在的目錄——配置文件路徑里多了個空格。就這一個字符，折騰到凌晨四點。第二天早上，客戶那邊的運維負責人打電話來，說昨天峰值扛住了，數據沒丟，謝謝。我靠在椅子上，窗外剛下過雨，心里沒什么激動，就一個念頭：問題解決了，而且下次我知道怎么更快。
試用期也暴露了自己不少短板。比如容器網絡那一塊，有次兩個pod之間通信超時，我查了半天才發現是calico的MTU配置和底層物理網卡不匹配。這塊知識不扎實，以后得補。另外，文檔寫得還是不夠細——有時候自己看明白，同事照著做就卡住。下一步我打算：6月底前，把備份恢復演練從季度改成月度，并寫一個傻瓜式操作指南；9月底前，把所有核心服務的磁盤、證書、進程巡檢腳本化，不用人工去盯；年底前，整理一份《常見故障排查手冊》，把“現象→排查步驟→根因→解決”寫成模板，給新同事少走彎路。
三個月不長，但夠我掂量出自己的斤兩。技術員這崗位，不靠說，靠出了問題能頂上去、能查清楚、能從根本上解決。以上是我轉正期間的實際工作情況，請領導審閱。
- 欲了解工作總結網的更多內容，可以訪問：工作總結
