題目與適用情境
一張每日批次 factordersettlements 資料表每天處理約 1000 萬筆訂單事件，來自 12 個來源系統。財務團隊在 UTC 07:00 開始關帳。目前排程系統只回報工作是否完成，因此綠色狀態仍可能對應延遲分區、整個來源缺漏、訂單版本重複，或彙總金額與來源端不一致。
請設計資料品質 SLO，以及落實這些目標的控制措施。每個來源系統會提供控制清單，其中包含來源、幣別和營業日維度的資料筆數與總金額。原始事件可重播 30 天，更正資料可能在 24 小時內抵達。兩種使用者的要求不同：財務只能使用已驗證資料，分析師可以使用清楚標示的預覽資料。
回答需要涵蓋 SLI、目標值、規則執行位置、發布閘門、責任歸屬、警示路由、錯誤預算動作、事件復原和上線驗證。1000 萬筆事件、12 個來源、截止時間、保留期和文中的目標值都是面試假設；正式環境的目標需要使用者共同確認，並以歷史量測校準。本題的核心能力是為資料產品建立可運作的品質契約，因此歸入 data。這套工作從事件發生前開始，一直延伸到驗證與政策複查。
面試官評估重點
第一，應徵者能否把「高品質資料」改寫成可觀測的使用者結果。即時性、完整性、有效性、一致性、準確性和唯一性對應不同故障。一個綜合品質分數可能用多條通過的規則掩蓋一條零容忍的重複資料。
第二，應徵者能否選擇可信的分母。拿今天筆數和昨天比較可以發現大幅異常，卻無法證明完整性。來源端控制清單、變更日誌位移區間或獨立帳本，更能說明原本應該抵達什麼。
第三，應徵者能否區分 SLI 規格和量測實作。「財務在關帳前取得已驗證資料」描述使用者結果；只量測排程工作結束時間，會漏掉發布、資料目錄、權限和下游讀取失敗。好的回答會在接近使用者的邊界量測，並寫清楚量測盲點。
第四，每種失敗是否已對應預定動作。硬性不變條件需要阻擋發布或隔離資料；警告需要負責人和複查路徑；電話通知應代表緊急的使用者影響。「每條規則失敗都發警示」會把設計責任推給值班人員，並製造雜訊。
最後，應徵者能否讓責任分工真正可執行。資料生產方、平台工程師、資料集負責人和財務可以共同承擔品質責任，但每條規則、每次事件和每項例外仍需要一位直接負責人和升級路徑。
回答前需要釐清的問題
- 財務所說的「就緒」是什麼？ 如果關帳必須在 07:00 使用已驗證資料，就要量測財務何時能查詢驗證版本，而非最後一個轉換工作何時結束。如果預覽有價值，應使用獨立狀態和契約發布。
- 哪一項獨立證據定義完整性和正確性？ 來源端清單可以支援資料筆數與金額核對。沒有清單時，可使用位移、來源快照或帳本總額；統計量波動檢查只能標為異常偵測，不能當作完整性證明。
- 業務鍵和更新模型是什麼？ 唯一性可能約束
(sourceid, orderid, version)，訂單目前狀態則需要為每筆訂單選出有效版本。延遲更正會同時改變檢查邏輯和驗證生命週期。 - 哪些失敗可以降級，哪些必須阻擋？ 業務鍵缺漏、版本重複或帳本不一致會破壞關帳，應該阻擋驗證。選用的行銷屬性異常時，可以隔離受影響資料並繼續驗證財務欄位。
- SLO 視窗裡有多少個品質事件？ 每日批次管線每月觀測點太少，無法有意義地表達 99.9%。滾動 60 個工作日中至少 59 次準時驗證，粒度更容易解釋。
- 誰可以略過失敗閘門？ 例外需要核准人、受影響使用者、到期時間、理由和稽核紀錄。值班工程師不能在事件中默默改寫財務契約。
- 系統具備什麼復原能力？ 30 天原始資料重播支援確定性重建。如果來源端歷史可變或不完整，復原方案和證據要求也要調整。
30 秒回答架構
「我會先從財務要做的決策出發，再分別定義已驗證資料的即時性、來源清單核對、業務鍵完整性、有效性和唯一性 SLI。我會在使用者邊界量測已驗證資料表，並把零容忍的財務不變條件與允許使用錯誤預算的時效目標分開。
結構描述檢查放在發布前，資料列檢查放在擷取階段，業務規則放在轉換後，端到端核對負責驗證閘門。財務只讀取帶版本的驗證檢視表；分析師可以主動選擇帶標示的預覽檢視表。每條規則都要有動作、負責人和操作手冊。我會先在一個來源上以影子模式執行，拿已知事件檢驗偵測效果，調整誤報，演練重播；即時性錯誤預算耗盡後，預先約定的政策會改變工程優先順序。」
分步深入解析
第一步：定義資料產品和使用者結果
為已驗證的結算資料集寫一份契約，不必列出所有可能的檢查。契約要寫明資料集版本、營業日、使用者、負責人、驗證截止時間、更正規則和稽核證據。兩種使用模式必須清楚：
preliminary：較早可用，可能有已聲明的延遲來源，禁止用於財務關帳；certified：指定版本不可變，所有硬閘門均已通過，並帶有清單和品質結果 ID；superseded：已有更正版本取代目前版本，舊證據仍可查詢。
這個狀態模型可以防止排程系統的綠色狀態意外變成業務保證。財務只查詢 certified；探索性使用者可以用確定性換取時效，但不會削弱財務契約。
第二步：把每個 SLI 寫成合格事件除以應評估事件
使用使用者可見的結果和定義明確的統計單位。這個情境的即時性 SLI 可以從以下版本開始：
freshness_sli =
在 UTC 06:30 前已驗證且可查詢的工作日分區數
/ 應交付的工作日分區數
初始_slo = 滾動 60 個工作日內至少 59 個合格分區這個目標在財務關帳前留下 30 分鐘，並在範例視窗中允許一次延遲驗證。兩個數值都需要與財務協商，並用歷史表現驗證。在使用者查詢結果或資料目錄狀態上確認指定版本可讀；排程完成時間只作為診斷訊號。
其他維度各自使用獨立的成功標準：
- 完整性： 所有預期來源清單均已抵達，資料筆數和關鍵鍵值涵蓋率完成核對。
- 唯一性： 已驗證分區內
(sourceid, orderid, version)重複數為零。 - 有效性： 必填鍵存在，契約控制欄位符合允許的型別、值域和範圍。
- 一致性： 彙總前依照來源、幣別和營業日核對資料筆數與金額。
- 更正時效： 已受理更正需要在約定視窗內產生新的驗證版本。
只看內部形態很難推斷準確性。一筆金額資料可以格式有效且業務鍵唯一，金額本身仍可能錯誤。來源端控制總額、帳本核對、業務抽樣和下游結果檢查，比格式規則提供更強的證據。
第三步：明確區分硬性不變條件、SLO 和診斷指標
把規則分成三類，動作會更容易理解：
- 硬性不變條件： 任何違規都阻擋驗證，例如業務鍵缺漏、版本重複或財務總額沒有核對一致。
- 可預算目標： 在書面政策規定的範圍內允許偶發失約，例如驗證截止時間或更正周轉時間。
- 診斷指標： 協助調查但不直接定義使用者是否成功，例如資料量日增減 20%。
不要為了套用錯誤預算公式，把硬性正確性要求改成「允許一定比例的錯誤資料列」。一筆高金額重複訂單的影響可能大於數千個無害的選用空值。每個目標及其後果需要獨立；綜合儀表板分數可以彙整趨勢，但不能覆蓋阻擋規則。
第四步：把檢查放在最早且有效的邊界
在資料生產方和轉換程式的 CI 中執行結構描述相容性與契約範例。擷取階段檢查解析、必填信封欄位、來源身分、位移連續性和冪等性；能夠明確識別的錯誤資料依原因碼隔離。轉換後檢查業務鍵、參照關係、版本選擇、幣別規則和來源切片。發布階段執行清單與帳本核對，並驗證這個驗證版本確實可查詢。
同一條規則不必到處重複。使用五筆固定資料的非空值單元測試能驗證程式路徑，對真實正式來源的說明力很弱。正式環境的彙總檢查可以發現問題，卻可能來不及保護中間使用者。變更前放一個低成本預防檢查，資料入口放執行期檢查，承諾被使用的位置放端到端檢查。
以下是與工具無關的示意偽 YAML，不對應任何產品的具體語法：
dataset: finance.fact_order_settlements
owner: finance-data
consumer: daily-close
certification_deadline_utc: "06:30"
rules:
- name: required_business_key
dimension: completeness
scope: row
pass_ratio: 1.0
action: block_and_quarantine
- name: unique_order_version
dimension: uniqueness
scope: [source_id, order_id, version]
pass_ratio: 1.0
action: block_certification
- name: source_manifest_reconciliation
dimension: consistency
scope: [source_id, currency, business_date]
pass_ratio: 1.0
action: block_certification_and_page_owner第五步：使用獨立核對並切片檢視結果
從完整的預期來源清單出發，把已接收的彙總結果左連接上去，才能看見完全沒有交付的來源。只從已接收資料出發做左連接，會讓缺漏來源直接消失。金額先按原幣別核對，避免有損轉換。清單 ID、來源水位、轉換版本、資料表快照和規則結果應一併記錄。
依來源、地區、幣別、事件類型和管線階段切片。一項全域 99.99% 通過率可能掩蓋一個低流量來源完全中斷。一個已知的延遲來源也不應從擷取、轉換和發布三個階段發出內容相同的電話通知。把警示路由到最先出現且可執行的故障邊界，同時保留下游診斷資訊並抑制衍生警示。
歷史區間適合做資料量異常偵測，但季節性、促銷和新來源上線都可能帶來合理變化。在獨立控制總額確認損失前，異常只是一項調查證據。
第六步：讓閘門、例外和責任歸屬可執行
每條規則都要聲明嚴重程度、動作、直接負責人、備援負責人、升級對象、操作手冊和最長回應時間。一種實用分工是：
- 來源結構描述或清單失敗：資料生產方負責修正，擷取負責人控制影響範圍；
- 傳輸、去重或排程失敗：資料平台負責復原；
- 語意轉換或核對失敗：資料集負責人負責診斷和重建；
- 業務定義有爭議：財務資料負責人決定契約，並經過可稽核的變更審查。
例外會產生明確的降級版本，或讓資料集繼續保持預覽狀態。記錄核准人、業務為何接受風險、影響哪些使用者，以及例外何時到期。禁止覆蓋失敗結果，也不能默默讓驗證別名指向未檢查分區。
第七步：讓錯誤預算政策真正改變決策
本例即時性 SLO 在滾動 60 個工作日中只有一次延遲分區預算。既要統計消耗量，也要觀察消耗速度。一次延遲會耗盡全部預算；發布錯誤的財務驗證分區則直接觸發事件政策，不受剩餘即時性預算影響。
失約前先約定動作。當消耗速度預測顯示唯一一次容許失約已處於風險中時，複查最主要原因並驗證復原能力。預算耗盡後，暫停高風險管線變更、優先安排可靠性工作，並要求負責人核准退出標準。這些後果讓 SLO 成為決策工具；沒有後果的儀表板只是報表。
如果偵測結果與使用者事件無關，或電話通知精準度很低，應複查 SLI。可以把量測點移近財務、增加遺漏切片或放寬雜訊較大的診斷指標。不能為了消除執行雜訊而放寬硬性不變條件；需要修正量測實作或路由。
第八步：漸進上線、演練復原並證明涵蓋率
先在一個來源上只評估不設閘門，並回放一段有代表性的 14 到 30 天歷史視窗。注入受控故障：移除一個來源、複製一個訂單版本、破壞結構描述、延遲發布，以及在資料筆數不變的情況下改金額。確認預期規則、負責人和操作手冊只觸發一次。
接著先對一個低風險來源啟用閘門，再按來源重要性擴大，最後保護驗證發布。驗收條件包括：種子故障偵測涵蓋、沒有錯誤驗證分區、電話誤報率有上限、使用者能讀取證據、原始事件可確定性重播，以及能在財務截止前復原。在正確性允許時，只掃描變更分區並量測規則成本；品質系統如果經常拖過自己要保護的截止時間，會削弱整條管線。
上線後要複查使用者人工發現而警示遺漏的事件，也要複查沒有實際影響的警示。這兩組樣本分別暴露涵蓋缺口和低精準度規則。資料模型變更時同步版本化品質契約，要求資料生產方與使用者審查，並為每次驗證保留當時使用的完整規則集。
高品質示範回答
「我會先從財務視角定義服務：指定結算分區已經驗證、可查詢、完成核對，並在關帳前可用。DAG 完成狀態只是一項診斷，所以我會探測發布版本，並保存對應的來源清單、資料表快照、程式版本和品質結果。
即時性方面，我可以先提議滾動 60 個工作日中至少 59 個分區在 06:30 前驗證，再結合財務要求和歷史表現校準。正確性使用獨立硬閘門：所有來源清單必須到齊；按來源和營業日核對資料筆數與原幣別金額；業務鍵必須完整；(sourceid, orderid, version) 必須唯一。我不會用一個平均分數讓阻擋失敗通過。
檢查分布在多個邊界。CI 捕捉不相容結構描述和轉換案例；擷取階段檢查信封、位移與冪等，並隔離可識別問題；轉換階段檢查語意和參照規則；發布階段做獨立核對，並確認指定版本可讀。財務只能讀取驗證別名，分析師可以使用帶來源狀態與品質狀態的預覽檢視表。
每項失敗都對應一個動作和一位負責人。資料生產方處理來源契約問題，平台團隊處理傳輸，資料集負責人處理轉換和驗證。例外有時限、對使用者可見，並由財務負責人核准。即使即時性預算還有餘額，錯誤的驗證分區也屬於事件。
我會先在歷史分區上以影子模式執行規則，分別注入缺少來源、重複鍵、結構描述破壞、延遲和資料筆數不變但金額錯誤的故障，再對一個來源啟用閘門。只有偵測、路由、重播、電話誤報率和規則耗時達到驗收條件才繼續擴大。如果唯一一次可容忍的延遲被消耗，約定政策就會把資源從功能開發轉向可靠性，直到退出條件滿足。」
常見錯誤
- 只監控工作成功 → 工作結束後仍可能發布不完整或不可讀的資料 → 在使用者邊界量測驗證物件。
- 把昨日筆數當作完整性證明 → 正常業務變化和無聲缺少來源的表現相似 → 使用清單、位移、快照或其他受控總額核對。
- 把所有檢查合成一個分數 → 多條選用規則通過會掩蓋一條財務不變條件 → 每個關鍵維度使用獨立門檻和動作。
- 對每月一次的每日事件設定 99.9% → 分母無法表達這種精度 → 選擇粒度有意義的統計單位和視窗。
- 給所有錯誤資料列分配錯誤預算 → 筆數忽略業務價值和硬性完整性 → 把零容忍不變條件與可預算時效分開。
- 每條規則失敗都打電話通知 → 一個來源故障會形成沒有行動價值的警示瀑布 → 只通知最先出現且有負責人的邊界，並抑制下游衍生警示。
- 讓值班人員默默略過閘門 → 使用者無法判斷風險，稽核證據也會消失 → 使用已核准、有到期時間且使用者可見的例外。
- 只測試正常路徑 → 關帳事件中才發現復原過程不確定 → 強制執行前注入代表性故障並演練重播。
- 每次都新增昂貴的全表掃描 → 品質檢查吃掉自己要保護的即時性餘量 → 在安全前提下使用增量檢查加週期性全量核對。
追問與回答
追問一：來源系統無法提供控制清單怎麼辦？
依獨立性為替代證據排序。來源快照、資料庫日誌序列區間、訊息位移、帶校驗碼的檔案清單和獨立產生的帳本，都比目標資料表自己的筆數更強。歷史區間可以發現異常，但要明確說明它無法證明完整性；對關鍵來源，應把控制清單或控制總額交付寫入資料生產方契約。
追問二：財務要求永遠不允許延遲怎麼辦？
隱含的 100% 目標無法為可靠性工作提供優先順序機制，也可能無法營運。量化接近這項要求所需的備援、重播時間、來源相依性和成本。財務正確性繼續使用硬閘門；即時性使用可量測目標，並增加更嚴格的期望目標。業務、工程和維運需要明確同意回應政策。
追問三：分區驗證後又收到更正資料怎麼辦？
產生新的不可變驗證版本，把它與舊版本和更正清單關聯，重新執行所有受影響的核對規則，核准通過後再以原子方式切換驗證別名。舊證據繼續保留供稽核。更正周轉時間應單獨量測，因為原始即時性 SLI 無法描述已知錯誤的修復速度。
追問四：數百個資料集如何避免警示疲勞？
依使用者影響為資料集分級，規則沒有直接負責人就不能電話通知，只針對可執行的 SLO 風險或硬閘門失敗通知。相關規則失敗依最早故障相依項目彙整，警告進入複查佇列，並定期把電話通知與真實使用者事件核對。長期低精準度規則應該停用或重寫。
追問五：串流管線需要改什麼？
把每日一次驗證機會換成事件時間視窗或使用者分鐘數。即時性從事件時間量到可查詢狀態，完整性使用關閉水位或來源位移，延遲事件另有更正政策。短視窗和長視窗同時監控錯誤預算消耗速度；需要立即隔離的逐筆或逐鍵硬性不變條件繼續保留。
追問六：如何評估資料品質工具？
先看契約適配，再看功能數量。驗證資料列與彙總規則、複合鍵唯一性、增量執行、失敗資料證據、結果版本化、排程閘門、責任中繼資料、API、警示路由和正式規模成本。把同一套種子故障跑過各候選工具；精美儀表板無法彌補端到端核對缺漏或發布閘門無法執行。