你是否常遇到「後台改了，前台沒變」的狀況？這不是系統壞了，而是資料還在「高速公路」上。
◆ 你以為「送出成功」就結束了嗎
在 PM 的世界裡，
只要按鈕按下去、轉圈圈跑完、跳出一個「成功」，
這件事就算結束了。
你可以很認真地理解流程、
很努力地拆邏輯、
很用心地寫規格、
甚至連資料流程圖都畫出來了。
但走到某一刻，你還是會突然疑惑：
為什麼剛剛改過的資料，畫面沒變？
為什麼後台和前台數字對不起來？
為什麼同一個帳號，兩個地方看到的都不一樣？你以為系統壞了。
RD 看了一眼，淡淡說一句：
「喔，這很正常，還沒同步完。」
「這個…Cache沒有清，等我清一下。」
那一瞬間，你會有一種被世界背叛的感覺。
原來在系統的世界裡，「立刻」這個東西，幾乎不存在。
◆ 資料離開按鈕之後，正在高速公路上漂流
在資料的世界裡，有幾個會讓 PM 頭很痛的東西：
同步、非同步、暫存、快取、Master、Slave。
你以為資料在送出的那一刻，就可以安心了，
好像已經「寫進去系統」了。
不，其實那只是它剛從交流道上高速公路的瞬間。
從使用者按下「送出」那一刻開始，
這筆資料可能會經歷：
在前端先暫存一下、
排進一個非同步的工作佇列、
被丟到某個快取伺服器、
再由主資料庫（Master）寫入、
過一陣子才被同步到備援或讀取節點（Slave / Replica）。中途任何一段塞車、繞路、延遲，
你在畫面上看到的結果，都會不太一樣。
如果你沒有這個「高速公路」的概念，
你就會一直以為：
「我剛剛不是已經送出了嗎？
為什麼系統好像還在發呆？」
◆ 資料旅行，就像一趟從台北開到高雄的旅程
想像一下，你和朋友約好從台北開車到高雄。
出發地一樣，目的地也一樣，
但實際發生的事情會是：
你開到一半突然尿急，只好先下交流道上廁所；
你朋友一開始開很快，但中途被夾在兩台龜速車中間，動彈不得；
你這條車道剛開始很順，過了一個交流道後，前面突然全部紅燈；
到高雄市區找停車位，停車場滿了，只能在外面排隊繞圈。最後，你比預計時間晚 20 分鐘到，
你朋友晚 50 分鐘才出現，
雖然大家都抵達了目的地，
但這中間發生了很多「不可控」的狀況。
資料的流動，其實就像這樣：
有時候快，有時候慢；
有時候超順，有時候塞爆；
有時候正常直達，有時候被迫繞路；
有時候你以為已經「到了」，
其實還卡在某一個系統的交流道口排隊。當我們只看「出發跟到達」，
當然會覺得一切都理所當然。
但是只要你多看一點中間發生了什麼，
很多「怪怪的現象」，就不再那麼神祕。
當理解這些之後，
要做的，就是將這些解釋給你的客戶聽，
因為他們也會跟你有一樣的疑惑、困擾、心急的心情。
◆ 畫面上看到的，不一定是當下的「真相」
在系統裡，畫面顯示的資料，常常不是「現在」，
而是「剛剛」——3 秒前、5 秒前、甚至 1 分鐘前。
你以為前端看到的是「真實資料」，
實際上常常是這幾種之一：
瀏覽器快取過的資料、
前端元件暫存的狀態、
CDN / Proxy 上還沒更新完的版本、
讀取節點（Slave / Replica）裡「稍微落後一點」的資料。對使用者來說，這些都長得一樣，
但對系統來說，這些只是「目前能最快拿出來給你看」的版本。
你說：「我明明已經在後台改好了，為什麼前台沒有變？」
RD 心裡的腳本可能是：
主資料庫已經更新，
Replica 還在追，
快取還沒過期，
CDN 還沒重新抓新版本。你看到的是「看起來沒變」，
但系統其實正在後台努力追上。
◆ PM 以為是 bug，RD 看的是「它正在努力活著」
很多 PM 應該都問過這幾句話：
「這邊為什麼還沒更新？」
「為什麼後台和前台不一致？」
「使用者剛改完，列表上怎麼還是舊的？」在 PM 的語言裡，這叫「怪怪的」。
在 RD 的語言裡，這叫「延遲中」。
對 RD 來說，真正可怕的不是「慢一點」，
而是「你以為寫進去了，其實根本沒落地」。
也就是說，比起「三秒後才看到新的資料」，
更可怕的是「永遠都看不到新的資料」。
所以工程師有時候會刻意：
先寫進暫存區、
排進非同步工作、
等確認真的寫到主資料庫，
再慢慢讓前台、快取、報表去追。這樣看起來會「慢一點」，
但系統比較不容易一瞬間整個炸掉。
◆ 一致性不是免費的，是拿錢和效能換來的
多數 PM 的直覺是：
「資料不就應該要一樣嗎？」
「為什麼後台和前台不能即時同步？」在系統的世界裡，有一個比較殘酷的事實：
如果你要「每一個地方」在「任何時間點」看到的資料都一模一樣，
那代價就是：
系統會變得很慢、
架構會變得很複雜、
可以承受的流量會變低、
任何一個環節出事，全系統一起陪葬。所以很多系統會選擇：
重要到不能出錯的東西，
用偏「強一致」的方式處理；
次要的、統計性的、報表類的、
就採用「最終一致性 (Eventual Consistency)」的設計，
也就是
有一小段時間會不一樣，
但最後會慢慢追上。甚至有些做法是，
每天找一個系統負載小的時段，
才進行數據報表的統計，
也許是每日凌晨3:00。
你眼中那個「怎麼還沒同步」，
有時候不是工程師懶，
而是大家一起做出的取捨。
◆ PM 看的是當下，系統看的是一整段旅程
PM 的畫面通常是這樣：
按下去 → 看到結果 → 這件事結束系統真正做的事，比你想像中多很多：
接到請求 → 驗證資料 → 排隊等待 → 寫進主資料庫
→ 複製到備援 → 更新快取 → 廣播事件 → 讓其他服務同步
→ 通知前端 → 前端再重新抓一次 → 畫面更新你關心的是那一瞬間的「有沒有變」。
系統在乎的是這整段過程能不能撐得住。
當你只看畫面上的一秒鐘，
很容易覺得「這一定是壞掉了」。
但如果你願意把時間拉長，
你會開始看到
資料其實一直在路上，
只是你以前沒有刻意去看它的「旅程」。
◆ 當 PM 開始在意「資料現在在哪裡」？
嗨，我是廣三。
在軟體開發裡繞了二十年，
有很長一段時間，我也跟很多 PM 一樣，
看到數字對不起來，就直接開口問：
「這到底是不是 bug？」
後來我慢慢調整自己的習慣，
每次遇到類似狀況時，
會先問自己幾個問題：
這筆資料現在可能在哪裡？
它是已經寫進主資料庫了，
還是在暫存區、快取裡、
或是還卡在非同步的佇列中？
這個畫面拿資料的地方，
是直接對主資料庫讀，
還是從 read replica、快取、或前端暫存撈？
這個差異是短暫的，
還是已經超過合理範圍？當你開始這樣思考時，
你不只是在看「畫面怪怪的」，
而是在追蹤一筆資料，
它從按鈕被點下到真正落地，
中間經歷了什麼。
也就是說，你不再只是在問：
「為什麼不一樣？」
而是開始跟 RD 一起討論：
「我們要接受多大的延遲？」
「在哪些地方一定要強一致？」
「哪些可以讓資料慢一點追上？」
那一刻起，
你就不再只是覺得自己被系統耍，
而是開始慢慢看懂
在那些你看不到的地方，
系統為了不要掛掉，
到底做了多少事。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
留言