工作總結

發表時間：2026-04-21

2026年中公轉正工作總結。

三個月試用期，說白了就是一場沒完沒了的“救火演習”。轉正那天領導拍了拍我肩膀說“辛苦了”，我心里想的卻是：這才哪到哪，系統里還埋著多少雷，我自己都沒底。

說幾個真刀真槍的事。

日志輪轉那個斜杠，坑了整個團隊三個月

入職第一周，我被分配去盯一套老舊的數據采集服務。說實話，頭幾天完全是告警驅動的活法——半夜三點磁盤寫滿，爬起來擴分區；早上七點CPU sys飆高，查出來是某個內核參數沒優化。最讓我崩潰的是，有個“/var/log 使用率超過90%”的告警，幾乎每隔兩天就來一次，每次都得手動刪日志、重啟服務。來回折騰了三四回，我實在忍不了了。

一個周五下午，我把過去三個月的告警歷史全部拉出來，用awk統計了一下觸發頻率。結果你猜怎么著？光是這個磁盤告警就占了總告警量的40%，而且每次發生的時間點都差不多——凌晨兩點到四點之間。這簡直令人難以置信，同一個坑，團隊每周要踩兩回。

我翻進那臺機器的/etc/logrotate.d/，看了一眼myservice的配置。問題簡單得讓人想罵人：輪轉路徑寫的是/var/log/myservice/*.og，少了個“l”，應該是*.log。就這一個字符的差別，導致輪轉從來沒真正執行過。我當場改了配置，順手用Python寫了個小腳本，每天早上六點檢查所有logrotate配置文件的語法，順便掃描各分區日志目錄的增長率，超過閾值就往釘釘群里丟一條警告。腳本很簡單，核心就二十行，但跑起來之后，那個告警再也沒出現過。

這件事讓我明白一個道理：真正的運維不是比誰處理故障快，而是比誰能讓故障根本不會發生。

一次504，讓我學會了“先看日志再看人”

第二周周三下午兩點半，業務方突然在群里炸了——API網關大量返回504。我當時的反應和所有人一樣：先看網關自己的健康檢查，正常；再看后端服務進程，也在跑；再看數據庫連接池——好家伙，活躍連接數飆到了上限的兩倍。我趕緊切到慢查詢日志，抓到一條SQL，平時30毫秒，當天執行了12秒還沒完。后來才知道，是運營部一個同事跑了個不帶索引的全表統計，直接堵死了連接池。

從收到告警到定位根因，我用了9分鐘。說實話，這9分鐘里有6分鐘是彎路——我先去查了nginx的連接數、看了網絡重傳率，甚至懷疑過交換機丟包。后來強迫自己冷靜下來，按標準流程走：先看上游響應時間，再看數據庫負載。找到那條慢查詢后，我直接kill掉會話，臨時調大連接池上限，業務在三分鐘內恢復。

但真正讓我在轉正答辯里有底氣說的，是后面補的三件事。第一，我給那張表加上了聯合索引，把同類查詢的執行時間壓到50ms以內。第二，我在數據庫中間件層配置了慢查詢自動熔斷——執行超過5秒的SQL直接拒絕，并且往運維群發一條告警。第三，我寫了一個crontab，每天凌晨把慢查詢日志里Query_time超過1秒的SQL匯總成報告，自動發郵件給開發組長。

這三件事做完后的第二周，同樣的場景又出現了一次——有人跑了個不帶索引的統計，但這次熔斷機制直接在5秒后拒絕了請求，業務完全沒受影響。我在復盤文檔里專門記了一筆：“熔斷閾值設5秒是因為觀察過正常業務的P99響應時間是800ms，留了充足的余量。”這段細節后來被團隊當成了模板。

換硬盤那次，差點把陣列搞崩

機房有一臺存儲節點亮黃燈，顯示一塊硬盤故障。按照標準流程，我應該先確認RAID狀態，然后熱插拔換盤，最后等重建完成。但我把舊盤拔出來之后，陣列卡突然報警，日志里出現“Unexpected sense”錯誤碼，緊接著陣列卡把另一塊健康盤也標記成了“Foreign”。當時我后背一下子就濕了——那臺機器上跑著兩百多G的日志數據，如果陣列崩了，恢復起來至少半天。

手邊沒有備用陣列卡，我不敢亂動。猶豫了五分鐘，還是決定先別強制上線，老老實實去查廠商的官方文檔。翻了半小時，在一個技術論壇的角落里找到一篇帖子，說這個型號的陣列卡固件有bug，熱插拔時可能會誤判，必須先升級固件再換盤。我按照步驟升級固件，重新插回舊盤，等陣列狀態恢復正常，再換上新盤。重建過程花了四個小時，我就在機房里守著，每隔半小時看一次進度條，生怕再出幺蛾子。

?讀書筆記吧dsbj1.COm速成指南: