高風險變更的判斷準則

何時用這份文件 你正在審批一個 issue，想確認它算不算高風險、要不要走嚴格流程。

核心定義

高風險 = 一旦出錯，回滾代價大或業務影響大或不可逆。

不是「DDL」「DML」這種粗粒度分類；是「這次特定的變更」的具體判斷。

八項判斷標準

任一條件成立 → 視同高風險。

1. 目標環境 = production

任何 prod 變更默認高風險。

2. 大表（>10M rows）

加索引、加欄位、調 schema 都會放大成本。即便 SQL 寫得對，可能影響：

• IOPS 飆高
• replication lag
• 鎖等待
• VACUUM 受阻

「我們的表多大算大」可以放進 workspace 規則自動判斷。

3. 不可逆動作

動作	為什麼不可逆
DROP TABLE	資料全沒；除非有備份
DROP COLUMN	該欄位的資料全沒
TRUNCATE	全表清空
DROP DATABASE	整個 DB 沒
DROP INDEX UNIQUE	之後可能塞進重複資料
改變欄位型別且窄化	例：int → smallint，超出範圍的值就沒
改欄位語意（同名但意思變了）	應用層讀到的資料解讀全變

4. 大範圍 DML

• UPDATE 估計影響 >100k rows
• DELETE 估計影響 >100k rows
• 全表 UPDATE / DELETE（無 WHERE 或 WHERE 1=1）

5. 跨服務 contract change

外部服務會讀的 schema 改動：

• 改欄位名（contract break）
• 改欄位型別（reader 端解析錯）
• 加 NOT NULL constraint（舊 writer 不知道）
• 改 default 值（舊 reader 不知道）

「我們改 DB」≠「我們改了 DB」。Schema 是跨服務 contract。

6. 高負載期間

時段	為什麼
業務高峰（上午尖峰 / 午餐 / 下午尖峰）	鎖等待時間翻倍；錯誤代價放大
大促 / 活動期	同上
月底結算	報表查詢密集，DB 已負載偏高

→ 對應 高風險變更窗口 政策。

7. 凍結期

任何在凍結期間（季末、大促前 48h、release cut 前後）的 prod 變更，默認 視同高風險，需走凍結期 override 流程。

8. 政策觸發

Workspace 有客製 SQL Review 規則時，任何被標 error 的變更（即便提交者 override 通過）視同高風險。

判斷流程

這個 issue 是不是高風險？
        │
        ▼
┌───────────────────────────┐
│ 跑一遍 8 項判斷            │
└───────────────────────────┘
        │
        ▼
   任一條件成立？
        │
        ├─ 是 → 高風險：
        │       1. 確認走窗口（[high-risk-window](/operations/runbooks/high-risk-window)）
        │       2. 確認有回滾計畫
        │       3. 確認業務 owner 知情
        │       4. 確認影響評估完整
        │       5. 確認執行 DBA 在線
        │       任一 NO → 不批 / 留 comment 補
        │
        └─ 否 → 一般風險：走標準審批流程

高風險不等於「不能批」

高風險 ≠ 阻擋。它代表「要走更嚴格的流程」。

• 該批的還是批，但要求補完 checklist
• 該駁的駁，理由具體
• 該等的等，安排到正確窗口

同類風險的具體例子

加索引（看似安全，實際分情境）

場景	風險級別
Dev 小表加索引	低
Prod 大表加索引 + CONCURRENTLY + 凌晨窗口	中
Prod 大表加索引（沒用 CONCURRENTLY）	高（會鎖表）
Prod 大表加索引 + 業務尖峰時段	高

加欄位

場景	風險級別
加 nullable column，default null	低
加 NOT NULL column 不給 default	高（舊資料怎麼辦？）
加 NOT NULL column with default	中（要看 DB 引擎能否 fast path）
加 column with default 含 expression now()	高（每筆要算）

Backfill

場景	風險級別
小表（< 100k）一次 UPDATE	低
大表單一 UPDATE 無 WHERE	高
大表分批 backfill，每批 < 10k	中
用 job 程式 backfill（不在 Argus 跑）	不在審批範圍，但要明確記載

文件範本

審批高風險變更時，建議要求提交者在 Issue 描述包含這四段：

## 影響評估
- 預估執行時長：
- 預估影響 row 數 / 表 size：
- 預期鎖：
- 業務影響：

## 回滾計畫
- 反向 SQL：
- 預估回滾時長：
- 不可回滾的部分：

## 驗證計畫
- 執行中如何監測：
- 完成後如何驗證：
- 業務指標 baseline：

## 通知與協調
- 業務 owner：
- DBA on-call：
- 窗口時間：

紅旗清單

看到以下任一項 → 直接 reject 或留 comment 要求拆分 / 補充：

• 「應該不會有問題」（沒做評估）
• 「之前在 staging 跑過 OK」（但 prod 資料量不同）
• 「等不及審批週期」（需要走緊急流程而非繞過）
• 「順便改一下這個」（一個 Issue 想做兩件事）
• 「先這樣再說」（沒有後續計畫）
• 沒有 plan check / plan check 全 override

相關

• 任務：審批一個 issue
• 窗口：高風險變更窗口
• 應變：緊急回滾
• 設定：Plan Check 規則設定