題目與使用場景
資料「有值」不代表「新鮮」。重點是把業務可用時間轉成可計算指標，並定位延遲發生在採集、傳輸、處理或發布環節。
面試官考察什麼
- 是否區分事件時間、到達時間、處理完成時間與服務時間。
- 是否按資料集、分割區與業務用途定義不同 SLO。
- 是否記錄血緣、執行、品質與新鮮度證據。
- 是否避免把單次工作成功當成資料可用。
- 是否設計告警抑制、升級、補數與回放路徑。
- 是否把新鮮度違約連結到下游使用者影響。
作答前的釐清問題
- 資料集的業務截止時間、更新頻率與時區是什麼？
- 新鮮度從事件發生、落地還是可查詢開始計算？
- 哪些分割區、欄位與下游報表是關鍵路徑？
- 可接受的延遲、缺口與回補窗口是多少？
- 上游能否提供事件時間、批次 ID 與重試資訊？
- 違約時要凍結報表、標記資料還是繼續服務？
30 秒回答框架
「我先依業務截止時間定義可查詢新鮮度，分別記錄事件、落地與發布時間。每個關鍵資料集按分割區計算 freshness SLI，結合血緣、執行狀態、行數與品質斷言定位延遲來源。告警分成預警與違約，避免工作成功但資料缺口被隱藏。恢復包含重試、補數、回放與下游標記，再用使用者影響和 SLO 預算衡量改進。」
分步驟深入解答
步驟 1：定義時間語意。 明確事件時間與可查詢時間，處理遲到事件、時區與夏令時，不只使用工作結束時間。
步驟 2：定義 SLI/SLO。 例如按分割區計算「截止時間前可查詢的比例」，為關鍵報表與探索資料設定不同目標。
步驟 3：收集執行證據。 記錄工作執行、輸入輸出分割區、血緣、行數、空值與品質斷言，並關聯到資料版本。
步驟 4：定位延遲。 把端到端延遲拆成採集、傳輸、排隊、計算與發布，區分上游沒有資料和下游處理失敗。
步驟 5：設計告警。 預警關注剩餘時間與趨勢，違約關注實際影響；按資料集與分割區去重，設定靜默、升級與負責人。
步驟 6：恢復與回放。 使用冪等批次、斷點與補數範圍，修復後重跑受影響分割區；對外說明資料狀態與更新時間。
步驟 7：複盤改進。 統計 SLO 預算消耗、根因占比與誤報，調整排程、容量、分割策略或資料產品承諾。
高品質示範回答
「這張收入報表的業務截止時間是每天 08:00，使用當地時區。我把 freshness 定義為當天分割區在 08:15 前可查詢，另記錄事件到落地的延遲。監控從工作元資料讀取輸入輸出分割區、血緣、行數與品質斷言；工作成功但分割區未到仍算新鮮度風險。08:00 前依剩餘時間預警，08:15 後依報表影響升級。恢復按批次 ID 冪等補數並標記報表狀態，複盤按採集、傳輸與計算根因統計預算消耗。」
常見錯誤
- 只監控工作成功 → 隱藏分割區缺口 → 檢查可查詢分割區與業務截止時間。
- 只用處理結束時間 → 遲到事件被誤判 → 保留事件、落地與發布時間。
- 所有資料集一個門檻 → 丟失業務優先級 → 按用途和關鍵路徑分級。
- 告警沒有負責人與升級 → 發現後無人處理 → 綁定窗口與恢復動作。
- 補數直接覆蓋 → 重複或版本不明 → 記錄冪等批次、範圍與版本。
追問及應對
追問 1：上游沒有事件時間怎麼辦？
先用落地時間作臨時指標並標註限制，推動上游補充事件時間與批次元資料。
追問 2：資料遲到但使用者暫時不受影響？
同時記錄技術 SLI 與使用者影響，依業務承諾決定是否消耗預算。
追問 3：如何避免告警風暴？
按資料集與血緣聚合根因告警，使用預警窗口、去重、靜默與升級策略。
追問 4：補數期間下游怎麼辦？
發布資料狀態與更新時間，凍結或標記關鍵報表，禁止把不完整結果當最終值。
追問 5：怎樣驗證 SLO 代表業務？
回訪報表使用者，比較違約與決策延誤、客戶影響等結果，定期校準窗口。
追問 6：遲到資料改變歷史分割區怎麼辦？
定義回補窗口與版本語意，記錄重算範圍，通知下游快取與增量模型。
追問 7：最有價值的改進是什麼？
優先修復占用最多預算且影響關鍵使用者路徑的根因，不只增加儀表板。