寵物電商後台改版血淚史：那些主管沒說但很重要的坑
一家寵物用品電商的後台系統優化實錄，從匯出功能到監控告警，拆解那些「看起來很小」卻能拖垮團隊的技術債與流程盲點。
- 把外部服務的暫時性錯誤與真正的系統故障分開處理，監控才不會狼來了
- 資料驗證的必填欄位如果沒做好早退機制，會讓錯誤訊息淹沒真正的問題
- UI 好不好用不是美學問題，是有沒有人蹲在使用者旁邊看他怎麼操作
某家寵物用品電商找上我們的時候，後台已經是那種「能動就好、沒人敢動」的狀態。行銷想匯出「買過某款貓砂的會員名單」做再行銷，工程師得手動下 SQL；監控系統三天兩頭跳告警，值班的人已經麻木到看到紅字先按靜音再說。這篇整理幾個我們實際處理過、值得分享的踩雷經驗。
迷思一：匯出功能是小事，隨便寫寫就好
客戶原本的需求聽起來很單純：選幾個商品、選個日期區間，把買過的會員名單匯出來。但魔鬼在細節：商品貨號會改版，同一款飼料可能換過三次貨號，如果只比對「現在的貨號」，等於漏掉一半歷史訂單。我們改成用訂單明細裡的商品 ID 去比對，涵蓋貨號變更前後的紀錄，行銷才不會拿著殘缺名單去做再行銷，白白燒廣告預算。
- 商品挑選器支援貨號、名稱關鍵字搜尋，一次最多選20項
- 日期區間給快捷選項，上個月、前三個月、前六個月、本年度，不用每次手動點日曆
- 匯出前先給查詢摘要：不重複會員數、訂單數、總金額，讓行銷自己抓語感，避免撈錯範圍才發現
迷思二：監控告警越多越安心
這家電商串接了外部的商品比價平台做同步，那個平台三不五時會回傳暫時性的伺服器忙碌訊號，本來是正常現象，卻被系統一律當成嚴重錯誤記錄，六分鐘內就能把監控告警炸出來，值班同事半夜爬起來看，結果只是對方系統在重啟。我們把「暫時性故障」和「真正的系統錯誤」分開處理，短暫的忙碌訊號降級成警告紀錄，只有真正的權限錯誤或程式例外才會觸發告警。監控的意義是讓人相信紅燈，不是讓人學會無視紅燈。
告警系統如果狼來了三次，第四次真的失火也沒人理你
迷思三：後台難用是使用者不習慣，不是設計問題
每日銷售報表的商品設定介面，客戶的營運同仁反映「每次換季要一筆一筆刪除舊商品，像在拔牙」。我們沒有急著加新功能，而是先觀察營運同仁實際操作一輪，發現真正卡住的是兩件事：一是沒有操作說明，新人上手全靠問前輩口耳相傳；二是刪除只能單筆處理，換季要刪十幾項商品得點十幾次確認。解法很樸實：加一份圖文操作指南，加一個全選批次刪除。上線後，原本要處理快十分鐘的換季作業，兩分鐘搞定。
我們的做法
系統穩不穩，不是看功能多，是看你怎麼處理錯誤
常見問題
- 電商後台的會員名單匯出，為什麼常常撈不齊？
- 多半是因為只比對「現在的貨號」。同一款商品換過幾次貨號，就會漏掉一半歷史訂單。改用訂單明細裡的商品 ID 比對，才能涵蓋貨號變更前後的紀錄，行銷才不會拿殘缺名單燒廣告預算。
- 監控告警設得越多越安全嗎？
- 不是。把外部服務的暫時性忙碌訊號一律當成嚴重錯誤，會把告警炸滿、半夜叫醒值班的人。要把「暫時性故障」和「真正的系統錯誤」分開，只有真的權限錯誤或程式例外才觸發告警，人才會願意相信紅燈。
- 後台很難用，是使用者不習慣還是設計問題？
- 通常是設計問題。與其急著加功能，先蹲在使用者旁邊看他實際操作一輪，常會發現卡點是缺操作說明、或少了批次刪除這種樸實需求，補上去就能把十分鐘的作業縮到兩分鐘。