回滾計畫範本（Rollback Plan Template）

Mon, 18 May 2026 00:00:00 +0000

回滾計畫範本（Rollback Plan）

參照標準：ITIL 4（Release and Deployment Management）/ ISO/IEC 20000-1:2018
文件用途：定義版本上線後若出現嚴重問題時的回復策略與操作步驟
適用階段：部署上線階段（Deployment Phase）— Change Enablement

📋 章節目錄

文件資訊
回滾觸發條件
回滾決策流程
回滾策略
回滾前準備
回滾執行步驟
資料庫回滾
回滾驗證
通知與溝通
回滾後行動

1. 文件資訊

📝 範本

項目	內容
文件編號	RP-{專案代碼}-{版本}-{序號}
文件名稱	{系統名稱} v{x.x.x} 回滾計畫
版本	v{主版本}.{次版本}
對應發佈版本	v{x.x.x}
建立日期	{YYYY-MM-DD}
撰寫者	{DevOps/SRE 姓名}
審核者	{Tech Lead / SM}
回滾時間窗口	上線後 {N} 小時內
最大容許停機	{N} 分鐘
回滾方式	Blue-Green / Canary Rollback / 全量回滾

📖 使用說明

回滾計畫是部署計畫的必要附件，每次上線都需準備
回滾時間窗口：超過此時間，資料可能已累積，回滾成本大幅增加
回滾方式取決於部署架構：
- Blue-Green：切換流量至舊版（秒級）
- Canary Rollback：停止灰度，流量回到舊版（秒級）
- 全量回滾：重新部署舊版 Image（分鐘級）

💡 範例

項目	內容
文件編號	RP-HRM-v2.1.0-001
對應發佈版本	v2.1.0
回滾時間窗口	上線後 4 小時內
最大容許停機	5 分鐘
回滾方式	Blue-Green（K8s Service 切換）

2. 回滾觸發條件

📝 範本

2.1 自動觸發（需設定監控告警）

條件 ID	觸發條件	監控指標	閾值
RT-AUTO-{xxx}	{條件描述}	{指標}	{閾值}

2.2 人工判斷觸發

條件 ID	觸發條件	判斷依據	決策者
RT-MANUAL-{xxx}	{條件描述}	{判斷依據}	{角色}

📖 使用說明

自動觸發：由監控系統偵測到異常時自動發起（或告警後快速決策）
人工判斷：需要人為判斷的複雜情境
觸發條件需事先定義並經團隊共識，避免上線時臨時爭論

💡 範例

2.1 自動觸發

條件 ID	觸發條件	監控指標	閾值
RT-AUTO-001	API 錯誤率飆升	HTTP 5xx Rate	> 5% 持續 3 分鐘
RT-AUTO-002	回應時間嚴重惡化	P95 Latency	> 5s 持續 5 分鐘
RT-AUTO-003	核心服務健康檢查失敗	Health Check	連續 3 次失敗
RT-AUTO-004	資料庫連線耗盡	DB Connection Pool	> 95% 使用率持續 2 分鐘

2.2 人工判斷觸發

條件 ID	觸發條件	判斷依據	決策者
RT-MANUAL-001	核心業務流程異常（薪資計算錯誤）	使用者回報 + 日誌確認	Tech Lead
RT-MANUAL-002	資安事件（疑似資料洩露）	資安告警 + SOC 確認	資安主管
RT-MANUAL-003	資料損壞（不一致/遺失）	DB 檢查確認	DBA + Tech Lead

3. 回滾決策流程

📝 範本

偵測異常 → 通知值班人員 → 初步評估（5 分鐘內）
│
├── 可快速修復（Hotfix） → 修復並部署 → 持續觀察
│
└── 無法快速修復 → 啟動回滾決策
│
├── 決策者確認回滾 → 執行回滾
│
└── 暫時降級（Feature Flag） → 持續觀察

決策權限矩陣

情境	決策者	升級時機
{情境}	{角色}	{超過 N 分鐘未解決時升級}

📖 使用說明

決策流程需在 5-15 分鐘內完成，避免長時間討論
權限矩陣確保深夜/假日也有人可做決策
Feature Flag 降級是比全量回滾更輕量的選項（如果有準備的話）

💡 範例

決策權限矩陣

情境	決策者	升級時機
上班時間（09-18）	Tech Lead → PM	10 分鐘未決定 → VP Engineering
下班/假日	值班 SRE → On-call Tech Lead	15 分鐘未回應 → VP Engineering
資安事件	資安主管（不論時段）	立即通知 CTO

4. 回滾策略

📝 範本

4.1 回滾方式比較

方式	停機時間	適用場景	風險
{方式}	{時間}	{場景}	{風險}

4.2 本次採用策略

項目	說明
回滾方式	{Blue-Green / Canary / Rolling / 全量}
回滾目標版本	v{x.x.x}
預計停機時間	{N} 分鐘
資料庫回滾	是/否（需要/不需要）
Feature Flag	是/否（可局部降級）

📖 使用說明

選擇回滾策略需考量：停機影響、資料安全、回復速度
Blue-Green 最快（秒級切換）但需雙倍資源
有 DB Schema 變更時回滾最複雜，需額外評估
若有 Feature Flag，優先考慮關閉新功能而非全量回滾

💡 範例

4.1 回滾方式比較

方式	停機時間	適用場景	風險
Blue-Green 切換	< 30s	K8s Service selector 切換	新舊版 DB Schema 需相容
Canary 回滾	< 30s	灰度比例回 0%	僅灰度階段可用
K8s Rolling Rollback	2-5 min	`kubectl rollout undo`	過程中有混合版本
全量回滾 + DB Restore	15-30 min	DB Schema 不相容時	停機長、可能丟失資料

4.2 本次採用策略

項目	說明
回滾方式	Blue-Green（K8s 保留舊版 Deployment）
回滾目標版本	v2.0.3
預計停機時間	< 1 分鐘
資料庫回滾	否（DB Migration 向後相容）
Feature Flag	是（可先關閉 WebSocket 推播功能）

5. 回滾前準備

📝 範本

5.1 準備清單（部署前完成）

#	準備事項	負責人	狀態
1	{準備事項}	{人員}	☐
2	{準備事項}	{人員}	☐

5.2 環境快照

項目	備份位置	備份時間	保留期限
{項目}	{位置}	{時間}	{期限}

📖 使用說明

回滾準備必須在部署「前」完成，而非出問題才做
資料庫快照是最重要的準備（資料不可逆）
確認舊版 Image 仍可取得、舊版設定仍可存取

💡 範例

5.1 準備清單

#	準備事項	負責人	狀態
1	資料庫全量備份（pg_dump）	DBA	☑
2	保留舊版 Deployment（hrms-blue, replicas=0）	DevOps	☑
3	確認舊版 Image 可拉取：`hrms:v2.0.3`	DevOps	☑
4	備份 Kong 路由設定	DevOps	☑
5	確認 Feature Flag 可遠端關閉	後端組	☑
6	值班人員確認聯絡方式	SM	☑

5.2 環境快照

項目	備份位置	備份時間	保留期限
PostgreSQL Full Backup	Azure Blob / hrm-backup/	部署前 30 分鐘	7 天
Redis RDB Snapshot	Azure Blob / redis-backup/	部署前 30 分鐘	3 天
Kong Config Export	Git repo / infra/kong/	部署前 commit	永久
K8s Manifest (old)	Git repo / k8s/	部署前 Tag	永久

6. 回滾執行步驟

📝 範本

6.1 執行步驟（依序執行）

步驟	動作	命令/操作	預期結果	執行者
1	{動作}	{命令}	{預期}	{人員}
2	{動作}	{命令}	{預期}	{人員}

6.2 回滾腳本

#!/bin/bash
# Rollback Script - {系統名稱} v{x.x.x} → v{x.x.x}
# 使用方式：./rollback.sh
{腳本內容}

📖 使用說明

步驟需足夠詳細，讓非撰寫者也能執行
回滾腳本需事前測試（在 Staging 環境驗證）
每個步驟標明預期結果，便於判斷是否正確執行
腳本優先於手動操作（減少人為失誤）

💡 範例

6.1 執行步驟

步驟	動作	命令/操作	預期結果	執行者
1	確認決策	Slack 記錄回滾決策	決策者確認	SM
2	關閉新功能 Feature Flag	LaunchDarkly: `payroll-scheduler=OFF`, `ws-notification=OFF`	Flag 生效	後端組
3	切換流量至舊版	`kubectl patch svc hrms -p '{"spec":{"selector":{"version":"v2.0.3"}}}'`	流量轉到 Blue	DevOps
4	Scale up 舊版	`kubectl scale deploy hrms-blue --replicas=3`	3 Pod Running	DevOps
5	驗證舊版健康	`curl https://hrms.internal/health`	HTTP 200 + version=v2.0.3	DevOps
6	Scale down 新版	`kubectl scale deploy hrms-green --replicas=0`	0 Pod	DevOps
7	更新 Kong 路由	移除 `/ws` 路由	WebSocket 端點移除	DevOps
8	驗證完整功能	執行冒煙測試腳本	All Pass	QA

6.2 回滾腳本

#!/bin/bash
# Rollback Script - HRMS v2.1.0 → v2.0.3
# 使用方式：./rollback-hrms-v2.1.0.sh
set -euo pipefail
echo "=== HRMS Rollback: v2.1.0 → v2.0.3 ==="
echo "開始時間: $(date -Iseconds)"
# Step 1: Scale up old version
echo "[1/5] Scaling up v2.0.3 (Blue)..."
kubectl scale deploy hrms-blue --replicas=3 -n hrms
kubectl rollout status deploy/hrms-blue -n hrms --timeout=120s
# Step 2: Switch traffic
echo "[2/5] Switching Service to v2.0.3..."
kubectl patch svc hrms-api -n hrms \
-p '{"spec":{"selector":{"version":"v2.0.3"}}}'
# Step 3: Verify health
echo "[3/5] Verifying health..."
sleep 5
HEALTH=$(curl -s -o /dev/null -w "%{http_code}" https://hrms.internal/health)
if [ "$HEALTH" != "200" ]; then
echo "ERROR: Health check failed! Manual intervention required."
exit 1
fi
# Step 4: Scale down new version
echo "[4/5] Scaling down v2.1.0 (Green)..."
kubectl scale deploy hrms-green --replicas=0 -n hrms
# Step 5: Remove WebSocket route
echo "[5/5] Removing WebSocket route from Kong..."
curl -s -X DELETE http://kong-admin:8001/routes/hrms-websocket
echo "=== Rollback Complete: $(date -Iseconds) ==="
echo "請執行冒煙測試驗證: ./smoke-test.sh"

7. 資料庫回滾

📝 範本

7.1 DB Migration 相容性評估

Migration	描述	向後相容	回滾方式
{Migration 名稱}	{描述}	是/否	{回滾方式}

7.2 資料庫回滾步驟（若需要）

步驟	動作	命令	風險
1	{動作}	{命令}	{風險}

📖 使用說明

向後相容的 Migration：新增欄位/表 → 不需回滾（舊版忽略新欄位即可）
不相容的 Migration：刪除/重命名欄位 → 必須回滾
資料庫回滾最危險，可能造成資料遺失，需事先做好備份
原則：盡量設計向後相容的 Migration（Expand-Contract Pattern）

💡 範例

7.1 DB Migration 相容性評估

Migration	描述	向後相容	回滾方式
AddNotificationLogs	新增 notification_logs 表	✅ 是	不需回滾（舊版不使用此表）
AddSchedulerColumns	payroll 表新增 3 個 nullable 欄位	✅ 是	不需回滾（舊版忽略）

✅ 本版所有 Migration 均為向後相容，無需資料庫回滾

部署管理 on Eric 個人部落格

回滾計畫範本（Rollback Plan Template）

回滾計畫範本（Rollback Plan）

📋 章節目錄

1. 文件資訊

📝 範本

📖 使用說明

💡 範例

2. 回滾觸發條件

📝 範本

2.1 自動觸發（需設定監控告警）

2.2 人工判斷觸發

📖 使用說明

💡 範例

2.1 自動觸發

2.2 人工判斷觸發

3. 回滾決策流程

📝 範本

決策權限矩陣

📖 使用說明

💡 範例

決策權限矩陣

4. 回滾策略

📝 範本

4.1 回滾方式比較

4.2 本次採用策略

📖 使用說明

💡 範例

4.1 回滾方式比較

4.2 本次採用策略

5. 回滾前準備

📝 範本

5.1 準備清單（部署前完成）

5.2 環境快照

📖 使用說明

💡 範例

5.1 準備清單

5.2 環境快照

6. 回滾執行步驟

📝 範本

6.1 執行步驟（依序執行）

6.2 回滾腳本

📖 使用說明

💡 範例

6.1 執行步驟

6.2 回滾腳本

7. 資料庫回滾

📝 範本

7.1 DB Migration 相容性評估

7.2 資料庫回滾步驟（若需要）

📖 使用說明

💡 範例

7.1 DB Migration 相容性評估