Appearance
處理一筆 Schema Drift Event
何時用這份文件 你是 auditor / securityOfficer / workspaceDBA，sidebar 「Schema 漂移事件」上有 OPEN 的 event 待處理。 不確定 drift detection 是什麼？先讀 Schema Drift Detection 概念。
前置條件
- 帳號有
bb.driftEvents.list+bb.driftEvents.get（readOnlyAuditor / workspaceDBA 都有；workspaceAdmin / securityOfficer 還有.resolve+.trigger） - 已登入 Argus
進入列表
左下 Workspace Settings → Audit & Compliance → Schema 漂移事件
或直接 URL：/drift-events。
列表預設只顯示 OPEN — 上面有三個統計徽章：
- 待處理 N — 還沒人處理的
- ERROR N — 高嚴重度（PR-2 後才會出現）
- WARNING N — 中嚴重度（Phase 1A 預設全 WARNING）
切換右上 status filter 可看歷史 RESOLVED / IGNORED。
點進一筆 event
每筆 event 包含：
| 區塊 | 內容 |
|---|---|
| 頂部徽章 | severity / status / detected_at |
| Fingerprint 比對 | 預期（baseline）vs. 實際（live）的 SHA-256 縮寫 |
| 差異摘要 | 新增表 / 移除表 / 異動表 三張卡片 + 樣本表名（最多 5 個） |
| 處理紀錄 | （若已 resolved）actor + 時間 + 處理方式 + 備註 |
| 兩個按鈕 | 立即重新檢查（Trigger）+ 標記處理（Resolve） |
第一步：先按「立即重新檢查」
點 立即重新檢查 同步跑一次 drift check：
- 結果 無漂移：DB 真實狀態跟 baseline 對上了 → 通常是 schemasync runner 已抓到新 schema 且 TaskRun blessing 已祝福；通常代表這條 event 已過期，可直接標 RESOLVED
- 結果 依然有漂移：DB 真實狀態跟 baseline 還是不一致 → 進入下一步判斷
第二步：判斷怎麼處理
| 情境 | 推薦 via |
|---|---|
| DBA 緊急直跑了 DDL 沒補單，現在補正式 Plan 後就會正常 | retroactive_plan |
| 變更已經是事實 + 不會再改 + 是 dev / staging 環境 | manual_ack |
| 你確定這是個 false positive（例如：autovacuum 改 stats 不該觸發 — Phase 1A 仍可能誤報） | ignored |
| 真的有惡意變更需要 forensics | 先別 resolve — 開 incident，把 event resource name 記下、抓 audit_log，找變更時間附近的 connection 來源 |
第三步：按「標記處理」打開 Resolve dialog
| 欄位 | 怎麼填 |
|---|---|
| 標記為 | RESOLVED — 已解決（推薦）或 IGNORED — 可忽略（false positive 才用） |
| 處理方式 | 上一步選的 via |
| 備註（選填） | 寫一句話讓未來看 audit log 的人知道情境，例：「事件 #1234 retroactive Plan #5678 已通過」 |
按 確認 → 寫入 schema_drift_event + audit_log。
選了 retroactive_plan 後
Dialog 內會出現一條藍色提示：
選擇「補一份 retroactive Plan」之後，到此資料庫所屬的 project 開一份 Plan 走正式審批；Plan 跑過後下次 runner tick 會重新祝福 baseline，殘餘漂移自動清除。
開啟 Projects 清單 →
按連結會帶你去 Projects 列表，從那邊進 project → 新增 Plan。這條 drift event 你已標 RESOLVED，跟你後續開不開 Plan 是兩件事（不會自動連動 — 開 Plan 是你跟 DBA 的下一步工作）。
第四步：確認 audit log 寫了
到 Workspace Settings → Audit & Compliance → Audit log 找：
method = /argus.internal.v1.SchemaDriftService/ResolveDriftEvent
actor = users/<你的 login_id>
time = 剛才這條 row 就是你動作的證據；月底 compliance report 會自動把這類 row 統計。
跟 DBA 流程的銜接
如果 via 選 retroactive_plan：
反模式 — 看到立刻喊停
| 行為 | 為什麼不該 |
|---|---|
| 不重新檢查就直接 Resolve | 可能 event 已過期；先 trigger 確認 |
全部用 manual_ack 結案 | 月底 compliance report 會把 manual_ack 比例列為健康度指標，高了會被檢視 |
看到 ERROR 嚴重度就 ignored | ERROR 是高敏 schema 異動，需要 forensics，不該繞過 |
| 直接到 PG 改 schema_drift_event 表 | 繞過 audit_log，反而留下「未授權變更稽核紀錄」的 metadata；用 UI |
常見錯誤
| 訊息 / 現象 | 含意 | 處理 |
|---|---|---|
| 「找不到此漂移事件」 | event resource name 過期或拼錯 | 回列表重新點 |
| 點 Resolve 出現「resolver identity unavailable」403 | session 過期 | 重新登入 |
| 點 Trigger 出現「db_schema not synced yet」412 | schemasync runner 還沒跑過此 DB | 等下次 sync (10 分鐘) 或手動 Sync database |
| Resolve 成功但 event 還在 OPEN | 抓到的是另一筆同 db 的新 event | 列表預設按時間倒序，找對的那筆 |
相關
- 概念：Schema Drift Detection
- 概念：SQL Editor — AdminExecute
- 任務：查詢 audit log
- DBA：用 AdminExecute 緊急直跑（drift 最常見的觸發源）