上一篇講了資料在系統之間怎麼搬。我自己遇過同步壞掉，而且是用資料的人先發現的：報表的人或行銷來問「這個數字怎麼怪怪的」，負責同步的那一方才回頭去查。
這種發現方式有兩個問題：
- 太晚。 用資料的人發現時，錯的數字可能已經拿去做決定、已經拿去寄了一檔 EDM。
- 不一定會被發現。 數字「怪怪的」才會有人問。如果壞得剛好不明顯，例如少了一個分店的資料、少了 5% 的訂單，可能永遠沒人問。
這一篇講怎麼讓資料流自己先叫，而不是等人來問。
資料流壞掉的四種長相
先看資料同步實際會怎麼壞。四種常見的長相：
- 停了：排程沒跑、連線斷了。資料停在某個時間點不再更新。
- 少了：有跑，但只搬了一部分。例如某個分頁沒處理到、某個條件把一批資料濾掉了。
- 變形了：來源系統改了欄位名稱或型別，同步程式沒報錯，但某個欄位從此都是空的。直讀資料庫最容易遇到這種。
- 錯了：資料都在，但內容不對。例如時區搞錯，所有消費時間都差了 8 小時，「近 90 天」的名單就整批偏掉。
每一種都要用不同的檢查抓。
五種檢查
| 檢查 | 問的問題 | 抓得到 | 例子 |
|---|---|---|---|
| 新鮮度 | 最後一筆資料是什麼時候進來的？ | 停了 | 交易資料超過 26 小時沒更新就告警 |
| 筆數 | 這次進來的筆數，跟平常差多少？ | 少了 | 今天的訂單數只有上週同一天的一半 |
| 結構 | 欄位名稱、型別有沒有變？ | 變形了 | 來源多了一個欄位、某欄位改名 |
| 內容 | 值合不合理？ | 錯了、變形了 | 會員編號不能重複、不能是空的；狀態只能是幾個固定值 |
| 對帳 | 兩邊的總數對得上嗎？ | 少了、錯了 | 來源和目標的昨日消費總額 |
表格裡的門檻（26 小時、一半）只是示意，實際要看每條資料流的排程和平常的變動幅度。
新鮮度的門檻要跟資料的性質對齊。回到四類資料：交易資料一天同步一次，超過一天多一點才算異常；同意與退訂要即時，晚幾分鐘就該告警。同一套門檻套在所有資料上，不是太吵就是太鬆。
內容檢查可以寫成查詢。以 dbt 為例，它的資料測試是一段 select，專門找出違反條件的資料，「找到 0 筆就算通過」；內建四種：unique（不重複）、not_null（不是空的）、accepted_values（只能是某幾個值）、relationships（參照的資料要存在）（dbt 文件：Data tests）。不用 dbt 也可以照這個思路自己寫：每個檢查就是一段「找出壞資料」的查詢，結果是 0 筆才算過。
對帳是最後一道防線，前面四種都沒抓到的，對帳通常抓得到（見對帳不是會計的事）。
檢查失敗之後：停下來，還是繼續？
檢查出問題時，資料流要不要繼續往下送？
如果是要拿去寄 EDM 的名單，答案幾乎都是停下來。少了一半的名單寄出去，等於一半的會員沒收到；退訂資料沒更新的名單寄出去，可能違反個資法。寄錯收不回來，晚一天寄通常還來得及。
這跟 ETL 的一般原則一致：失敗時停下來，比帶著壞資料繼續好（見 ETL：資料搬運與轉換）。
每條資料流都要有一個負責人
「用資料的人先發現」還反映了另一件事：這條資料流沒有人在看。
告警設了，但發給誰？如果發到一個大家都靜音的群組，等於沒設。每一條資料流都應該能回答三件事：
- 誰負責它？
- 它壞了，誰會收到通知？
- 它的下游是誰？壞了要通知哪些用資料的人？
第三點常被漏掉。負責同步的人修好了，但用資料的人不知道前三天的名單是錯的，已經寄出去的那檔也沒人追。
AI 和 MCP 的角色
這一篇跟 AI 的關係最直接：AI 用過期的資料，會講得一樣有把握。
人看報表時，至少會注意到「這張報表是什麼時候的」。AI 透過 MCP 拿到資料，如果工具只回數字、不回時間，AI 就會把三天前的數字當成現在的講出來，語氣完全一樣肯定。
所以 MCP 工具的設計要做到：
- 每次回答都附資料截止時間。 工具回傳的不只是「符合條件的會員有 3,200 人」，還要有「資料截至昨天 23:00」。AI 回答時要把這句話帶出來。
- 新鮮度不合格時，工具自己標出來。 如果資料超過門檻沒更新，工具回傳時直接標「資料可能過期」，而不是交給 AI 判斷。
- 跟同意有關的查詢，過期就拒答。 退訂資料如果沒有即時更新，撈行銷名單的工具應該直接回「目前無法確認退訂狀態」，而不是回一份可能寄錯人的名單。
AI 也能幫忙處理告警。檢查失敗時，把失敗的檢查、最近的變更紀錄、上下游關係交給 AI，讓它先整理「可能是哪裡壞了、影響到哪些名單和報表」。最後怎麼處理還是人決定，但第一輪的整理很適合交給 AI。
相關主題
- 企業系統之間怎麼交換資料
- 對帳不是會計的事
- 下一篇：名單和報表的 ETL 怎麼規劃