寵物旅館每日照片回報靠人工對狗，我們是怎麼把歸檔系統修回來的

某寵物旅館主打住宿期間每日回報：現場人員把當天拍的照片和影片上傳到雲端相簿，系統再把幾十間房、上百個檔案對回每一筆訂單，打包傳給飼主。一開始靠人工開資料夾逐張對，旺季一到，光是對寵物名字就對到眼花，最慘的是把別人家的狗傳給飼主，每日回報從賣點變成客訴來源。

迷思一：雲端相簿只是儲存空間，不會出錯

很多人以為串接雲端相簿就是「讀取檔案」，不會出錯。事實是雲端相簿的 API 三不五時會回暫時性錯誤，短則幾分鐘、長則幾小時。實際遇過幾分鐘內同一批任務接連回錯誤碼，原本的重試機制只等幾秒就放棄，直接把整批標記失敗，隔天早上還得人工重跑。

後來把邏輯改成分辨「暫時斷線」跟「真的沒救」：不同來源給不同的等待間隔，連續失敗到一定次數才真正放棄，中間持續記錄失敗原因方便查。這個改動之後，原本半夜會自動判死的任務，早上起來大多自己活過來了。

迷思二：失敗訊息只要告訴我「失敗了」就好

系統早期的失敗通知只有一行「處理失敗：某某錯誤」，量小時還能猜是哪一批，旺季同時跑十幾個房間的回報批次，看到這種訊息根本不知道要救哪一個。後來通知一定帶日期、房號、任務編號、上傳人員、原始連結，錯誤內容截斷到合理長度，不是整段技術訊息照貼。

• 失敗訊息要能回答「是哪一批」「誰上傳的」「哪個連結」三個問題
• 技術例外訊息對現場人員是雜訊，要摘要不要整段丟出去
• 成功訊息也要精簡，量大時逐筆列出反而變成新的雜訊

案例：重跑機制不做好，系統會被自己的成功拖垮

現場人員是邊照顧邊拍邊上傳，系統跑完辨識常常才發現相簿裡的照片還沒傳齊。原本的做法是整批重新下載、重新辨識，量一大，每次重跑都要重新處理好幾 GB 的檔案。

我們改成重跑時先幫工作資料夾拍一張快照，之後只打包「這次多出來的檔案」，辨識也只處理新檔案，舊的辨識結果快取起來共用。辨識完成後系統還會自動回頭確認來源有沒有又冒出新檔，抓到就再補一輪，全部做完才通知現場人員。重跑從「整批重來」變成「差異修補」，規模再大也不會拖垮整個流程。

知識分享：名字比對這種小地方最容易養出隱藏地雷

照片要對回訂單，靠的是資料夾名稱和訂單上的寵物名。聽起來簡單，實際上全是地雷：同名的狗、訂單寫全名現場寫暱稱、打字少一個字。最後用字典比對加模糊比對處理大宗，比對不到的進待確認清單讓人工處理，不讓系統硬猜。系統可以不完美，但不能安靜地猜錯。

系統會不會出包不是重點，重點是出包那一刻，人有沒有辦法在三十秒內看懂發生了什麼事。