回滾計畫範本（Rollback Plan Template）
回滾計畫範本（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 均為向後相容，無需資料庫回滾 ...