Appearance
Schema Drift Detection
對應主管要求 ①完整稽核 + ⑤release monitoring。
Schema Drift Detection 是 Argus 對「DB 真實長相 vs. 帳本上應該長什麼樣」不一致的持續偵測機制。如果有人繞過 Plan 流程改了 schema（例：DBA 緊急 ssh + psql / 用 DBeaver 連 admin data source），Argus 會在 10 分鐘內偵測到並寫一筆 audit 事件。
為什麼存在
Argus 的核心承諾是「所有 DB schema 變更走 Plan → 審批 → Rollout → 留軌跡」。但現實有漏洞：
| 場景 | 帳本知道嗎 |
|---|---|
| 開發者開 Plan 改 schema | ✅ 完整 |
| DBA 用 AdminExecute 緊急直跑 且補單 | ✅ 但延遲 |
| DBA 用 AdminExecute 沒補單 | ❌ |
有人 ssh 進 prod 直接 psql 改 schema | ❌ |
| 有人用 DBeaver 連 admin data source 改 | ❌ |
沒有 drift detection 之前：Argus 以為 DB 是 X，實際 DB 是 Y，帳本跟現實長期脫鉤而無人察覺，月底稽核才發現已經來不及追責。
怎麼運作
Baseline 怎麼來：每次 TaskRun（Plan 跑完）完成時，Argus 自動把當下的 fingerprint 祝福成新 baseline。所以正常 Plan 路徑跑 schema 變更 不會 觸發 drift event。
三個關鍵價值
1. 把「未授權變更」變成可被偵測的事件
以前是「事後人工比對 DB 跟 schema 文件」，現在是「機器 10 分鐘掃一次，最多 10 分鐘內偵測到」。
2. 給 retroactive Plan 補單一個明確的觸發點
過往 DBA 緊急直跑後常拖延補單；現在 drift event 立刻出現在審計員眼前，逼著當下處理。
3. 把「DB schema 變更」變成可量化、可月報、可儀表板
argus_schema_drift_events_total{severity}Prometheus counter → Grafana- 月度 compliance report 段落「N 件未授權變更」
- 給高層看「合規健康度」的硬指標
對使用者的具體影響
| 角色 | 多了什麼 |
|---|---|
| DBA | AdminExecute 直跑後拖延補單會被自動點名；補完 Plan 後 drift 自動消失 |
| Auditor | sidebar 多一條列表，紅黃綠按嚴重度排序；點進去看 fingerprint 比對 + diff 摘要。SOP：處理 drift event |
| Security Officer | 多 4 條 audit_log method 可寫 SIEM rule |
| Workspace Admin | 多「Resolve」+「Trigger Re-check」按鈕（其他角色看不到） |
| 開發者 | 通常無感（不會直接動 schema 繞 Plan） |
三道 audit 軌跡
每次偵測 / 重檢 / 處理都寫獨立 audit_log row：
| Method | 觸發時機 | actor |
|---|---|---|
/argus.v1.SchemaDriftService/DriftDetected | runner 偵測到 drift 自動寫 | （system） |
/argus.internal.v1.SchemaDriftService/TriggerDriftCheck | 人按「立即重新檢查」 | users/<login_id> |
/argus.internal.v1.SchemaDriftService/ResolveDriftEvent | 人 Resolve 事件 | users/<login_id> |
三種解決路徑（resolved_via）
| via | 用法 |
|---|---|
retroactive_plan | 開一份 Plan 補做正式審批 — 最常見、最合規 |
manual_ack | 人工確認接受，不開 Plan — 非 prod 環境 OK，prod 不推薦 |
auto_match_allowlist | 符合白名單規則自動清除（Phase PR-2 開放） |
兩個 audit log 必看欄位
actor— 誰處理的（拉這條就可以追責）severity— Phase 1A 全warning；後續 PR-2 allowlist 上線後會有info（被允許的 drift）和error（高敏 schema 異動）
跟其他模組的關係
| 模組 | 關係 |
|---|---|
| Plan / Issue / Rollout | TaskRun 完成自動祝福 baseline，drift detection 才不會誤判 |
| SQL Editor | AdminExecute 是最常見的 drift 觸發源 |
| Audit Log | drift event 寫 audit_log，可被既有的 search / export pipeline 處理 |
| Release Monitoring | 5 個 Prometheus counter 串到 Grafana / Alertmanager |
已知限制（會在後續 PR 改善）
| 限制 | Phase | 影響 |
|---|---|---|
| diff_summary 第三段把已存在的 table 標成 "added" | PR-2 | 視覺上 diff 不夠精準；不影響 drift 偵測正確性 |
| 預設 10 分鐘掃一次，per-environment 不可調 | PR-2 | 大 schema instance (>1000 table) 預設頻率可能過高 |
| 沒 allowlist policy；任何 diff 都視為 drift | PR-2 | 對「合理的索引短暫變動」會誤報 |
| Baseline 只存 fingerprint 不存 metadata | PR-2 | diff_summary 細節有限 |