無法處理訊息佇列

預期成果：為這套系統設計或檢查 無法處理訊息佇列 (Dead-Letter Queue)，並讓資料保持正確、安全且容易維護。 使用者情境：匯入資料 `row-73` 因日期格式錯誤而失敗五次。Amazon SQS 會把訊息移到無法處理訊息佇列。團隊預先設定的警示接著通知操作人員。解析器修好後，操作人員用安全速度重新投遞一小批訊息。 技術概念或控制措施：無法處理訊息佇列 (Dead-Letter Queue)。 適用理由：同一則訊息持續失敗，不該一直回到主要佇列時，可以使用這種佇列。要保存原因、來源、嘗試次數、訊息時間和安全的重新投遞方式。 不應使用的情況：不要因為第一次短暫失敗就移走訊息，也不要忽略持續變長的佇列。原因尚未修好前，不可直接重新投遞；流程若要求嚴格順序，移走一項也可能破壞順序。 工程要求：定義輸入、輸出、介面約定，以及任何情況都不能破壞的規則。說明授權與輸入檢查範圍。定義失敗、逾時、重試和重複執行只生效一次的規則。也要定義資料搬移與相容限制。 營運要求：加入監控訊號與隱藏敏感資料的記錄。設定容量上限並寫好操作手冊。測試復原與回復上一版的流程。 驗收條件：介面約定與失敗路徑測試通過。重試或部分失敗時，資料與授權規則仍正確。效能上限、監控、復原與回復上一版的方法都已驗證。 證據與限制（證據邊界）：沒有一份官方標準能管到全部內容。不同團隊、平台或框架的用法可能不同。 待確認：程式執行環境、資料位置、流量形態、資料一致需求和安全邊界。也要確認相容期間、服務目標（SLO）與回復上一版的限制。