題干與適用場景
這是資料工程師常見的品質治理設計題。重點不是列出檢查清單，而是說明失敗紀錄從發現、隔離、修正到重播的完整生命週期，同時維持正常路徑的吞吐與正確性。
面試官考察什麼
- 能否區分 schema、業務規則、重複、延遲與毒丸紀錄。
- 能否設計保留原文、失敗原因與來源位置的隔離區。
- 能否用冪等鍵、版本化規則與可稽核狀態實現安全重播。
- 能否說明背壓、告警、隱私、保留期限與責任邊界。
回答前需要釐清的問題
先確認輸入是批次、訊息流或兩者並存；是否允許有效紀錄先提交；事件是否有穩定的 event_id、業務時間與來源 offset；修正後要重播原始事件還是重新從上游取得；以及合規要求的保留期限與敏感欄位處理方式。
30 秒回答架構
我會把流程分成不可變原始層、檢查路由層、有效資料路徑與 quarantine 路徑。每筆失敗紀錄都保存原文、來源定位、規則版本、失敗原因與狀態；有效紀錄依 event_id 冪等寫入。修正後透過版本化轉換或更正來源，在隔離區產生重播批次，沿同一條冪等寫入路徑執行，再用指標與抽樣對帳證明沒有遺失或重複。
分步驟深入解答
1. 先保留事實，再做路由
入口先寫入不可變原始層或可重播日誌，記錄 source、partition/offset、接收時間、event_id 與 payload hash。解析或 schema 檢查失敗時，不要直接丟掉；將紀錄與錯誤碼送進 quarantine。通過檢查的紀錄進入正常處理。
2. 設計可操作的隔離紀錄
隔離表至少包含 payload（或受控引用）、失敗欄位、規則名稱與版本、首次失敗時間、來源定位、重試次數、修正批次與狀態。狀態可用 open、readyforreplay、replayed、rejected。敏感欄位按最小權限加密或只存指標；保留期限由合規與排障需求共同決定。
3. 讓重播與正常寫入共用正確性邊界
修正規則必須版本化，不能覆寫原始紀錄。重播工作讀取指定狀態與規則版本，先在影子目標或小批次驗證，再呼叫與即時路徑相同的轉換與寫入邏輯。目標表以 event_id 加業務版本作冪等鍵，並明確定義 upsert、忽略或產生新版本的語意。
4. 處理重複、延遲與毒丸紀錄
重複訊息依 event_id、來源 offset 或去重視窗辨識，不能只把 offset 當業務身份。延遲事件依業務時間進入補算或更正流程，並說明水位線影響。反覆失敗的毒丸紀錄要限制重試、轉人工或永久拒絕，避免占滿消費者。
5. 用可觀測性證明系統正常
分別監控有效通過率、依規則與來源統計的 quarantine 數量、未處理年齡、重播成功率、重複寫入衝突、端到端延遲與資料新鮮度。品質門檻觸發告警或暫停單一來源，而不是直接暫停全部流程。定期將原始、有效、隔離與重播計數對帳。
高品質示範回答
我會先釐清輸入語意與一致性要求，再將原始事件寫入不可變儲存，接著做 schema、業務規則、重複與時序檢查。通過者走正常路徑，以 event_id 加業務版本冪等寫入；失敗者進隔離區，保存原文引用、來源 offset、失敗規則版本、錯誤詳情與狀態，絕不靜默丟棄。修正時不改原始事件，而是建立有審批與批次號的重播工作，在小批次驗證後重用正常轉換與寫入路徑。最後以通過率、隔離積壓年齡、重播成功率、寫入衝突與計數對帳做告警與稽核；敏感欄位按最小權限保護，保留期限遵循合規要求。
常見錯誤
- 檢查失敗就丟掉或只印 log，無法找回原文。
- 只存錯誤字串，沒有來源 offset、規則版本與 event_id。
- 重播另寫一套邏輯，導致即時與補數結果不一致。
- 用「重試到成功」處理毒丸紀錄，造成無界積壓。
- 只看整體成功率，不按來源、規則與年齡拆分。
追問及應對
隔離資料含有個人資訊時怎麼辦？
只保留排障所需的最小欄位，敏感 payload 加密並限制存取；原文透過受控引用取回，所有存取與到期刪除都要有稽核證據。
重播期間新資料仍持續流入怎麼辦？
使用獨立重播批次與事件版本，寫入端依冪等鍵合併。若需要順序，為分割區或實體設定邊界，並記錄衝突決策。
何時要暫停整條流程？
只有不相容 schema、目標不可寫或資料損壞風險會污染有效路徑時才暫停。單一規則或來源異常優先隔離該分支。
如何證明沒有漏資料？
以輸入批次或 offset 範圍建立帳本，對帳原始、有效、隔離、重播與拒絕數量，抽樣核對 event_id 集合，並把未決紀錄年齡納入 SLO。