# Rollback Standards（回滾標準）

## 概述

本標準定義回滾觸發條件矩陣、自動 vs 手動回滾決策流程，以及與錯誤預算的整合方式。確保每一次部署都有明確、可量化的回滾策略，而非依賴主觀判斷。

---

## 核心原則

- **可量化觸發條件**：回滾觸發必須有明確的數值門檻，絕不使用「看起來有問題」等主觀描述
- **三層決策模型**：自動回滾（Auto）→ 輔助回滾（Assisted）→ 手動回滾（Manual）
- **錯誤預算整合**：當錯誤預算低於 10% 時，自動將輔助回滾升級為自動回滾
- **強制事件記錄**：每次回滾都必須寫入部署日誌並觸發事故回應流程

---

## 觸發條件矩陣

### 自動回滾（Auto-Rollback）

系統自動執行，無需人工干預：

| 指標 | 觸發門檻 |
|------|---------|
| 錯誤率 | > 2× 基線，持續 5 分鐘 |
| 健康檢查失敗 | 連續 3 次 |
| P99 延遲 | > 5× 基線，持續 3 分鐘 |

### 輔助回滾（Assisted-Rollback）

系統發出警報，由值班工程師確認後執行：

| 條件 | 說明 |
|------|------|
| SLO 違反 | 非關鍵路徑的 SLO 違反 |
| 錯誤預算剩餘 | < 10%（此時升級為自動回滾） |

### 手動回滾（Manual-Rollback）

由開發者評估後決定是否執行：

| 條件 | 說明 |
|------|------|
| 延遲惡化 | 仍在 SLO 範圍內的效能下降 |
| 外觀問題 | 使用者可見但不影響功能的問題 |

---

## 嚴重性矩陣

| 等級 | 觸發方式 | 處理時限 | 通知對象 |
|------|---------|---------|---------|
| P0 | 自動 | < 2 分鐘 | 全體相關人員 |
| P1 | 自動 | < 5 分鐘 | 值班工程師 |
| P2 | 輔助 | < 15 分鐘 | 團隊主管 |
| P3 | 手動 | < 1 小時 | 開發者 |

---

## 錯誤預算整合

當錯誤預算剩餘 < 10% 時：

1. 輔助回滾自動升級為自動回滾
2. 觸發事故事件記錄
3. 暫停後續部署，直到預算恢復

---

## 回滾方法比較

| 方法 | 執行時間 | 風險 | 前置條件 |
|------|---------|------|---------|
| Blue-Green 切換 | < 30 秒 | 低 | 雙環境基礎設施 |
| Feature Flag 關閉 | < 5 秒 | 極低 | Feature Flag 系統 |
| DNS 切換 | 60-120 秒 | 中 | 多區域設定 |
| 程式碼 Revert | 數分鐘 | 中 | 乾淨的 git 歷史 |
| 資料庫還原 | 數小時 | 高 | 已驗證的備份 |

---

## 回滾前後檢查清單

### 回滾前（Pre-Rollback）

- [ ] 確認回滾目標版本是健康的
- [ ] 確認資料庫遷移向後相容
- [ ] 通知相關利害關係人

### 回滾後（Post-Rollback）

- [ ] 確認健康檢查在目標版本通過
- [ ] 將回滾事件寫入部署日誌
- [ ] 開立事故單進行根因分析
- [ ] 更新錯誤預算追蹤

---

## 相關標準

- [deployment-standards.md](deployment-standards.md) — 部署基礎策略
- [cd-deployment-strategies.md](cd-deployment-strategies.md) — 部署策略選用矩陣
- AI 格式：[../ai/standards/rollback-standards.ai.yaml](../ai/standards/rollback-standards.ai.yaml)


**Scope**: universal
