工作總結

發表時間：2026-03-16

[優質]2026年投資公司技術骨干轉正工作總。

半年試用期，說長不長，說短不短。轉正述職是個形式，但手里的活兒騙不了人。下面幾個數字，算是對這180多天的一個交代：

核心交易系統全年可用性99.99%，這個小數點后兩位是硬扛下來的。三季度處理過3次突發性能瓶頸，其中兩次是盤中交易量瞬間沖到峰值的CPU滿載。另外，配合業務上了三個新模塊，“智能對賬”上線后，財務部兩個人半天的人工核對變成了半小時自動跑完。關于系統卡頓或數據延遲的生產投訴，從上半年的7起降到下半年的2起——這兩起還都是因為網絡運營商割接，跟我們自己的代碼沒半毛錢關系。

數字背后，是三場硬仗，也是三次差點翻車的教訓。

第一仗：給五年的老代碼做“心臟搭橋”

業務部每天晨會必看的持倉分析模塊，跑批時間越來越長。最開始三小時，后來四小時，最夸張的一天跑了五個半小時，直接耽誤八點半的數據匯總。業務領導在會上拍桌子，我們只能低頭。

常規套路都試過：加索引、擴內存、上SSD，效果撐不過兩周。我帶著兩個核心開發蹲了兩天，把跑批邏輯從頭到尾捋了一遍——不看不知道，一看嚇一跳。五年前的老代碼，處理兩億條持倉數據用的還是嵌套游標循環，相當于用算盤算導彈軌跡。

問題找到了，但重構風險極高。這模塊一天不用，業務就瞎眼。我們只能做“不停跳搭橋”：新寫一套基于集合運算的批處理邏輯，在測試環境壓了三天三夜，把邊界條件全跑爛了。上線那天晚上，我盯著屏幕，手心冒汗。跑批開始，監控曲線從三小時的平臺直接掉到四十分鐘的斜坡，綠色信號亮起來的時候，旁邊同事遞過來一瓶水，我才發現后背濕透了。

但第二天就出幺蛾子了。有個小眾產品的持倉匯總對不上，財務打電話來問。趕緊回滾查詢邏輯，發現是重構時漏了一種特殊分紅場景的權重算法。趕緊補丁修復，前后折騰了兩小時。這事兒讓我明白：再完美的重構，也得留足觀察期。后來我們定了個規矩，核心模塊重構后必須雙軌運行一周，新舊邏輯同時跑，對賬一致才能切流量。

第二仗：網關被“擠爆”的四十分鐘

八月中旬，市場異動，成交量瞬間放大。下午兩點十三分，監控大屏開始飆紅——持倉網關的連接數直線上升，緊接著是報錯，再接著是風控模塊響應超時。群里消息刷屏，老板電話直接打到我手機上。

我當時在機房調試設備，手機一響就知道出事了。第一反應不是接電話，是切到跳板機，一把拉下網關對風控的強依賴開關，改成異步降級。這動作保證了即使網關掛掉，核心交易的風控底線還在。然后才回老板電話：“正在處理，預計二十分鐘。”

排查過程其實挺笨的。先用top看負載，不高；再看日志，全是連接超時。最后用lsof查進程限制，才發現文件句柄數跑滿了——系統默認1024，當天并發連接數沖到2000多，直接捅破窗戶紙。改配置、重啟服務，全程四十分鐘。恢復后業務正常，但復盤時后背發涼：如果當時沒第一時間切斷依賴，風控模塊一癱，交易就可能被熔斷，那損失就不是四十分鐘能填回來的。

這件事暴露了兩個漏洞：一是服務器初始化腳本里沒調大文件句柄數，這是歷史欠賬；二是限流熔斷機制只在核心鏈路上有，網關這種邊緣服務沒覆蓋。后來我們把所有中間件、網關、緩存服務的初始化配置全過了一遍，新增了自動告警和限流策略。現在每次新服務上線，第一件事就是檢查內核參數。

第三仗：把財務大姐的Excel“翻譯”成代碼

“智能對賬”這個需求，最開始產品經理給的需求文檔寫了十幾頁，什么“提升效率”“優化體驗”，全是虛的。我拉著他直接去找財務部負責對賬的王姐，讓她打開電腦，當著我們的面操作一遍。

結果發現，她每天要打開五個Excel文件，復制粘貼數據到第六個文件里，再用VLOOKUP比對差異。最費眼睛的一步，是手動標記那些對不上的賬，經常看到眼花。我們問：哪一步最煩？她說：“每次復制粘貼完，還得數一數條數對不對，生怕漏了。”

這就對了。我們把她的操作拆成十幾個步驟，用代碼一個個實現。開發過程中，每做完一個小功能，就請她來測試環境點兩下。第一次原型出來，她把界面上的按鈕位置調了個個兒，說“我習慣右手點，放左邊別扭”。改。第二次，她說“你們這個差異標紅太刺眼，能不能改成淡黃色”。改。第三次，她試了半個小時，抬頭說：“行了，這個比我那個Excel強。”

?讀書筆記吧DsBJ1.coM深度干貨: