前言
在金融市場，每一秒都有意義。然而 2024 年 3~4 月間，我們卻發生「開盤三十分鐘」的嚴重慢盤，學到了關於技術敏捷與用戶感知的巨大教訓。
三十分鐘的慢盤，狠狠擊中了我們的盲點
那天早上，我還記得是星期一，一位產品 PM 回報：「今天開盤過了幾分鐘，為什麼還沒看到最新資料？」
一開始，我下意識想著：應該是單一用戶或網路線路出問題？但隨著越來越多用戶回饋「資料更新慢」，我們意識到：這不是偶發 bug，也不是使用者誤解，而是我們系統出了問題。即使我們緊急搶修恢復運作，但期間已造成三十分鐘的延遲！
我們習慣在開盤前做完所有初始化工作，確認快取正常、排程完成、伺服器就緒。但市場變了，資料量暴增、分析維度拉高，用戶習慣也跟著變化，「即刻容錯移轉，避免單點異常」不再是選項，而是基本需求。
拆解問題：我們的「假設」已不再成立
從技術層面來說，我們的設計本身沒有錯，但錯在於「預設」市場的節奏還跟過去一樣，服務能像過去一樣靠單一流程完成所有運作。我們快速召集後端與 SRE 工程團隊檢視架構流程，發現我們仍在依賴一個單點同步式的資料更新流程，它確保系統一致性與部署便利，但也拉長了資料真正可供用戶使用的時間。這在用戶眼中，就是「延遲」。
簡單來說，我們在等「所有就緒」才開始更新，但用戶根本等不了那一刻。
重寫時序邏輯：改變，就在當下開始
當下我們沒有妥協。
我們立刻將整個時序邏輯推倒重來，重構方向很明確：
- 非同步事件驅動：放棄同步排程，改用非同步訂閱發送機制，分散資料集中式處理。
- 佇列優先級重整：開盤初期資料與使用者查詢行為分離，優先保證核心報價揭示資訊更新。
- 即時容錯移轉：自動慢盤偵測，即時容錯移轉資訊源，不再依賴人為手動更新。
- 即時監控補強：加入每秒級資料延遲追蹤，確保異常及時回報。
光是這四個步驟，我們一週內完成開發與驗證，並在隔週一清晨部署上線。
最終資料延遲問題完全消失，用戶回報為零。
一次小改變，背後是整個思維的轉換
從「集中排隊逐一更新」到「資料來分散即時處理」，這不只是技術策略的改變，而是我們願不願意為用戶的節奏改變我們自己的節奏。
這次的經驗讓我深刻理解：
技術不是只為了讓系統跑得動，而是要讓用戶「來得及用」。在金融領域「快」才有價值，而我們身為工程師，若只滿足於系統的自我滿足感，終究會脫離使用者。
工程師的心聲：寫程式也是一種與時間的戰鬥
回想起那天，我其實有一點感動。
不是因為寫了一個多麼複雜的程式碼，而是我們團隊在發現問題後，不爭辯、不推拖，而是立刻投入解法的那份「默契」與「行動力」。
我們常說「用戶體驗很重要」，但真正做到從用戶視角出發，去感受、去承擔、去即時修正，那才是我們在 CMoney 所謂的工程師文化。
這不只是解一個 bug，而是我們坦誠失敗，選擇為用戶的節奏重新調整自己節奏的那一刻，讓我覺得這份職業很值得。
後記：從回報到部署，只花了一週
是的，一週。
這背後不是我們很神，而是我們的團隊文化一直相信：
- 改變是工程師的使命
- 用戶的需求，就是我們產品的北極星
- 技術再強，錯過用戶當下的需求，等於沒意義
如果你也是一個願意為用戶而改變節奏、願意與時間賽跑的工程師，歡迎加入我們。
