年會上銷售抱走現金紅包，IT研發部連「勤勤懇懇獎」都沒有：一篇掘金連載，把老技術部的困境攤開來

這篇文章的素材來自掘金創作者「TF男孩」於2026年9月28日發布的連載《IT風雲錄》第三篇。該系列以第一人稱職場見聞的形式連載，上一篇講中年程式設計師離開大公司去了小公司，這一篇則繼續拆大公司技術部裡的問題。以下內容均出自作者自述，屬於個人經歷分享，並非經過查證的機構調查，先交代清楚。

年會現場：現金一疊疊發下去，技術部沒有名字

作者描述的場景很有畫面感。公司年會上，營收與利潤年增都超過三成，老闆搬來一堆現金當場分發：張三三萬、李四十三萬、王五二十五萬，銷售一部十萬、客服二部五萬。IT研發部無論團隊還是個人，全都榜上無名。

作者的觀察是，公司把部門分成幾種：銷售類是盈利部門，行政、人力、財務是成本部門，研發類則視情況而定，可能是盈利，也可能是成本。而這家公司的技術部，顯然被歸到了後者。

技術部的老員工反應是失落。作者的轉述是：每年都這樣，「熱鬧是別人的，和自己沒關係」，連保潔、保安都有個「勤勤懇懇獎」，程式設計師什麼都沒有。

兩次事故：一次死機數小時，一次把客人擋在門外

老闆對技術部的不滿，作者認為主要來自系統的脆弱性。每年最關鍵的行銷活動時，服務幾乎都會出狀況。折騰的軌跡也很典型：從雲伺服器改自建機房，又從機房遷回雲端。

作者親歷的第一次事故，是運行人員在活動尚未結束時登上後臺看彙總數據，大量即時計算把資料庫壓垮，服務停不掉，死機後數小時才重啟成功。事後領導說資料庫差就買資料庫，技術部討論後決定不買。理由寫得很直白：買多少？買了之後若再出問題，就處於輿論的被動面。

第二次不算宕機，是限流。大量用戶湧入，一部分人被擋在外面，App 上不停彈出 500 錯誤，行銷人員不敢再推廣。事後技術部排查出的原因是：一個頁面呼叫了 12 個不同介面，其中一個介面被連續呼叫 35 次，資料庫壓力直接拉到百分之百，靠禁止用戶訪問才沒有崩潰。

一個版本號，看穿整個部門的處事邏輯

文章裡最生動的段落，是一場關於版本號的攻防。產品想把版本從「3.1.19」升到「3.2」，後端負責人說不行，版本號必須是三位數。產品退讓，問「3.1.19 beta」行不行，他要做測試版的用戶數據比對。回答還是不行，理由是程式按每個點切分出數字、挨個比大小，測試版字串塞不進這套邏輯。

產品再問：直接比較版本號字串行嗎？他想了想，說行。但接著補了一句：既然當時定好了規則，就不要再變了。最終產品放棄了版本號規劃。

作者對這位後端負責人的描寫相當尖銳：Java 服務仍是單體架構，就是 Java 連資料庫讀寫數據，運維經常檢測出大量慢 SQL，沒有用 Redis、ES，更談不上 Flink、MQ、CI/CD。他牴觸微服務，說微服務沒用。作者把技術守舊與性格固執畫上等號：因為固執所以守舊，因為憑老技術能活，所以可以保持固執。

總監這邊也不順。總監是 App 開發出身，不懂服務端，出問題就找後端；後端則覺得架構設計是總監的事，做好了功勞也是總監的，「不優化是本分，優化是情分」。業務部門抱怨提需求排不上，但技術部多數人看起來並不忙，也不加班。幾個業務主管一碰頭，發現各自的需求都沒被開發。

一篇個人見聞，為何值得看

這篇文章的價值不在於揭露某家具名公司，而在於它把幾個常被分開談的現象串了起來：紅利分配向盈利部門傾斜、研發被視為成本中心、老技術人的路徑依賴、跨部門需求響應的空轉。這些環節彼此餵養，構成作者所說的「規範體系下無法跳出的循環」。

當然，這終究是一位入職不久的員工的單方視角，技術部內部的實際運作、公司的完整分配邏輯，文章並未提供對照說法。但對許多在大型組織裡寫程式的人來說，那個年會畫面大概不陌生：熱鬧是別人的，自己守著一套跑了十年的單體架構，等下一次大促活動的壓力測試。