回滾計畫範本（Rollback Plan）

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

📋 章節目錄

1. 文件資訊
2. 回滾觸發條件
3. 回滾決策流程
4. 回滾策略
5. 回滾前準備
6. 回滾執行步驟
7. 資料庫回滾
8. 回滾驗證
9. 通知與溝通
10. 回滾後行動

1. 文件資訊

📝 範本

📖 使用說明

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

💡 範例

2. 回滾觸發條件

📝 範本

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

2.2 人工判斷觸發

📖 使用說明

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

💡 範例

2.1 自動觸發

2.2 人工判斷觸發

3. 回滾決策流程

📝 範本

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

決策權限矩陣

📖 使用說明

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

💡 範例

決策權限矩陣

4. 回滾策略

📝 範本

4.1 回滾方式比較

4.2 本次採用策略

📖 使用說明

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

💡 範例

4.1 回滾方式比較

4.2 本次採用策略

5. 回滾前準備

📝 範本

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

5.2 環境快照

📖 使用說明

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

💡 範例

5.1 準備清單

5.2 環境快照

6. 回滾執行步驟

📝 範本

6.1 執行步驟（依序執行）

6.2 回滾腳本

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

📖 使用說明

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

💡 範例

6.1 執行步驟

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 相容性評估

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

📖 使用說明

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

💡 範例

7.1 DB Migration 相容性評估

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

8. 回滾驗證

📝 範本

8.1 冒煙測試清單

8.2 監控確認

📖 使用說明

• 回滾後必須執行驗證，確認系統已恢復正常
• 冒煙測試覆蓋核心功能路徑
• 監控指標確認效能/錯誤率已恢復正常水位
• 驗證通過後才能宣佈回滾完成

💡 範例

8.1 冒煙測試清單

8.2 監控確認

9. 通知與溝通

📝 範本

9.1 通知時序

9.2 通知範本

回滾開始通知：

[系統公告] {系統名稱} 回滾通知
時間：{YYYY-MM-DD HH:MM}
影響：{描述影響}
預計恢復：{預計時間}

📖 使用說明

• 透明溝通建立信任，避免使用者恐慌
• 通知需簡潔明確：發生什麼、影響什麼、何時恢復
• 分層通知：內部團隊（立即）→ 管理層（5 分鐘內）→ 使用者（10 分鐘內）

💡 範例

9.1 通知時序

10. 回滾後行動

📝 範本

10.1 立即行動（24 小時內）

10.2 Root Cause Analysis

📖 使用說明

• 回滾不是結束，而是問題解決的開始
• 24 小時內需完成緊急事項（如客戶溝通、暫時方案）
• RCA（Root Cause Analysis）需在 3-5 個工作日內完成
• 重點是改善流程，避免相同問題再次發生（Blameless PostMortem）

💡 範例

10.1 立即行動

10.2 Root Cause Analysis

📌 範本使用注意事項

1. 本範本依據 ITIL 4 Release and Deployment Management 與 ISO/IEC 20000-1:2018 編製
2. 回滾計畫必須在部署「前」完成並經審核，不是出問題才寫
3. 搭配「部署指引範本」使用 — 部署與回滾是一體兩面
4. 搭配「事件報告/RCA 範本」使用 — 回滾後需正式記錄與分析
5. 建議每季度在 Staging 環境進行「回滾演練」（Rollback Drill），驗證計畫可行性