健康食品電商庫存打架事件：一場自動調撥引發的深夜驚魂

某家經營健康食品的電商，旗下兩個品牌站臺共用同一批庫存池，倉庫端常常人工調來調去，庫管人員每天花大量時間對帳。我們幫他們做了一套自動調撥系統，理論上很美：本站庫存低於門檻就自動向對端拉貨，省下人工。上線後第一週，半夜警報response響個不停，兩端庫存像坐雲霄飛車一樣互相拉扯。

迷思：自動化等於設好規則就沒事

很多老闆以為自動調撥就是寫一條「庫存不足就補」的規則，丟給系統跑就好。實際上這種雙向調撥系統最大的坑，是沒設計「保底值」會讓兩端陷入無限拉扯：A站拉光B站的貨，B站庫存見底又反過來向A站拉，訂單量大的時段甚至一天內來回振盪十幾次，倉庫實際庫存跟系統顯示的完全對不上。

• 調撥規則要分品牌、分情境：門檻與拉貨量不能一套規則打天下
• 轉出後對端必須保留最低庫存（保底值），否則兩端互打
• 跨站扣減要包在同一個資料庫交易內完成檢查、扣減、紀錄，避免中途出錯留下半套資料
• 調撥歷程要留紀錄且要讓非工程師看得懂，客服才能自己查而不是每次都找工程師

案例：DTU 打滿不是流量的錯

上線後系統效能一度打滿，主機CPU使用率卻只有兩三成，很多人這時候直覺會想「加大主機規格」。我們實際追下去發現真正的兇手是資料庫的I/O，不是運算量，是幾張核心大表（訂單、購物車）完全沒有索引，查一次購物車徽章數量要掃過三千多頁資料，訂單自動取消排程更是每次都全表掃描近九千頁。補了五個索引之後，同樣的查詢從三千多頁降到個位數頁，主機規格完全沒動，帳單反而變便宜。

效能問題九成不是流量太大，是懶得建索引又不想承認。

知識分享：邊界案例是被真實用戶戳出來的

這家電商有非會員也能下單收禮的機制，資料表設計上收件人資料跟會員帳號共用同一把主鍵。上線一段時間後才發現，非會員收件人在特定流程下會踩到一個資料庫外鍵限制，導致整筆訂單卡死付不了款。這種問題平常測試很難測到，因為多數測試情境都預設「收件人是會員」，真正把系統逼出裂縫的永遠是那個你沒想過的邊界情境，例如訂閱扣款回呼失敗沒補建紀錄、退款失敗後金流卡死無法重試。系統上線不是終點，是開始蒐集這些邊界案例的起點。