部署運維

上線檢核清單範本（Go-Live Checklist Template） 適用標準：ITIL 4 Release Management、ISO/IEC 20000-1:2018 適用階段：部署上線階段（Deployment Phase） 負責角色：Release Manager、PM、Tech Lead 📑 章節目錄 文件資訊 上線概要 上線前置作業檢核 上線當日檢核 上線後驗證檢核 通訊與通知計畫 回退判定與流程 簽核記錄 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 上線檢核清單 文件編號 [專案代碼]-GLC-[版本號]-[日期] 版本 v[X.Y] 預定上線日期 [YYYY-MM-DD HH:mm] 上線視窗 [YYYY-MM-DD HH:mm] ~ [HH:mm] Release Manager [姓名] 核准者 [PM / IT Director] 2. 上線概要 項目 內容 上線類型 [全新上線 / 版本升級 / Hotfix / 設定變更] 影響範圍 [影響的模組/功能/用戶群] 預計停機時間 [N 分鐘 / 零停機] 影響用戶數 [N] 人 回退計畫 [有 / 無] → 參考 §7 相關 Change Request [CR-NNN] 3. 上線前置作業檢核 3.1 開發與測試 # 檢核項目 負責人 完成日 狀態 備註 1 所有功能開發完成並合併至 release branch [Dev Lead] [日期] [✅/❌/N/A] 2 Code Review 完成（所有 PR 已核准） [Dev Lead] [日期] [✅/❌/N/A] 3 單元測試通過率 ≥ [N]% [Dev] [日期] [✅/❌/N/A] 4 整合測試全數通過 [QA] [日期] [✅/❌/N/A] 5 UAT 簽核完成 [PO/使用者] [日期] [✅/❌/N/A] 6 效能測試報告 — 符合 NFR 標準 [QA/效能] [日期] [✅/❌/N/A] 7 安全掃描通過（Critical/High = 0） [AppSec] [日期] [✅/❌/N/A] 8 Regression Test 通過 [QA] [日期] [✅/❌/N/A] 3.2 部署準備 # 檢核項目 負責人 完成日 狀態 備註 9 部署手冊/腳本已更新並審閱 [DevOps] [日期] [✅/❌/N/A] 10 CI/CD Pipeline 驗證通過（Staging） [DevOps] [日期] [✅/❌/N/A] 11 資料庫 Migration Script 已測試 [DBA] [日期] [✅/❌/N/A] 12 回退腳本已準備並測試 [DevOps/DBA] [日期] [✅/❌/N/A] 13 設定檔已更新（環境變數/Config） [DevOps] [日期] [✅/❌/N/A] 14 SSL 憑證/網域確認有效 [Infra] [日期] [✅/❌/N/A] 15 第三方服務/API 就緒確認 [SA] [日期] [✅/❌/N/A] 16 容量/資源已到位（VM / K8s / DB） [Infra] [日期] [✅/❌/N/A] 3.3 文件與溝通 # 檢核項目 負責人 完成日 狀態 備註 17 Release Note 已完成 [PM/Dev] [日期] [✅/❌/N/A] 18 使用者手冊/教育訓練已更新 [PM/BA] [日期] [✅/❌/N/A] 19 維運文件（SOP/Runbook）已更新 [SRE/DevOps] [日期] [✅/❌/N/A] 20 內部上線通知已發送 [PM] [日期] [✅/❌/N/A] 21 外部用戶公告已發送（如需要） [PM/行銷] [日期] [✅/❌/N/A] 22 客服/Help Desk 已知悉異動內容 [PM] [日期] [✅/❌/N/A] 3.4 監控與告警 # 檢核項目 負責人 完成日 狀態 備註 23 監控 Dashboard 已設定 [SRE] [日期] [✅/❌/N/A] 24 告警規則已設定並測試 [SRE] [日期] [✅/❌/N/A] 25 Log 收集已確認正常 [SRE] [日期] [✅/❌/N/A] 26 健康檢查端點已設定 [Dev/DevOps] [日期] [✅/❌/N/A] 4. 上線當日檢核 4.1 上線前（T - 30 min） # 檢核項目 負責人 時間 狀態 備註 27 War Room 成員全數到位 [RM] [HH:mm] [✅/❌] 28 溝通管道確認（Teams/Slack channel） [RM] [HH:mm] [✅/❌] 29 最終 Go/No-Go 確認 [PM + 各角色] [HH:mm] [✅/❌] 30 生產環境備份完成 [DBA/Infra] [HH:mm] [✅/❌] 4.2 上線執行中 # 步驟 負責人 預計時間 實際時間 狀態 備註 31 [開始維護公告/流量切離] [RM] [HH:mm] [✅/❌] 32 [DB Migration 執行] [DBA] [HH:mm] [✅/❌] 33 [應用程式部署] [DevOps] [HH:mm] [✅/❌] 34 [設定檔/環境變數更新] [DevOps] [HH:mm] [✅/❌] 35 [快速健康檢查] [DevOps] [HH:mm] [✅/❌] 36 [流量恢復/維護公告移除] [RM] [HH:mm] [✅/❌] 5. 上線後驗證檢核 5.1 即時驗證（T + 15 min） # 檢核項目 負責人 狀態 備註 37 Health Check / Liveness 正常 [DevOps] [✅/❌] 38 核心功能 Smoke Test 通過 [QA] [✅/❌] 39 Log 無 Error/Exception 異常暴增 [SRE] [✅/❌] 40 監控指標正常（CPU/Memory/TPS） [SRE] [✅/❌] 41 資料庫連線正常 [DBA] [✅/❌] 5.2 穩定觀察期（T + 1~4 hr） # 檢核項目 負責人 狀態 備註 42 錯誤率維持正常水位 [SRE] [✅/❌] 43 回應時間無惡化 [SRE] [✅/❌] 44 無使用者回報問題 [客服/PM] [✅/❌] 45 排程任務正常執行 [DevOps] [✅/❌] 6. 通訊與通知計畫 階段 通知對象 通知方式 內容重點 負責人 上線前 1 週 內部團隊 Email/Teams 上線時程與影響 PM 上線前 1 天 外部用戶 公告/Email 維護視窗通知 PM 上線開始 War Room 成員 Teams Channel Go 指令 RM 上線完成 全體利害關係人 Email 完成通知 PM 異常/回退 管理層 + 用戶 電話 + Email 狀況說明 PM/RM 7. 回退判定與流程 7.1 回退觸發條件 # 條件 判定者 優先級 1 核心功能 Smoke Test 失敗 QA + PM 立即回退 2 Error Rate > [N]% 持續 [N] 分鐘 SRE 立即回退 3 P95 回應時間 > [N]ms 持續 [N] 分鐘 SRE 評估回退 4 資料完整性問題 DBA 立即回退 5 安全性事件 AppSec 立即回退 7.2 回退步驟摘要 # 步驟 負責人 預估時間 1 宣告回退決定 RM/PM 即刻 2 [流量切離/維護模式] DevOps [N] min 3 [應用程式回退至前版] DevOps [N] min 4 [DB rollback（如有）] DBA [N] min 5 [驗證回退成功] QA [N] min 6 [恢復流量] DevOps [N] min 8. 簽核記錄 階段 角色 姓名 簽核日期 結果 Go/No-Go PM [姓名] [日期] [Go / No-Go] Go/No-Go Tech Lead [姓名] [日期] [Go / No-Go] Go/No-Go QA Lead [姓名] [日期] [Go / No-Go] 上線完成確認 RM [姓名] [日期] [成功 / 回退] 觀察期結束 SRE [姓名] [日期] [穩定 / 待觀察] 9. 附錄 9.1 War Room 聯絡人 角色 姓名 電話 備註 Release Manager [姓名] [電話] DBA [姓名] [電話] DevOps [姓名] [電話] Dev Lead [姓名] [電話] 9.2 相關文件連結 文件 連結 Release Note [link] 部署手冊 [link] 回退計畫 [link] 監控 Dashboard [link] 📖 使用說明 使用時機 情境 使用方式 新系統首次上線 完整執行所有檢核項 版本升級 可依影響範圍簡化 §3.3 Hotfix 簡化版，但 §4, §5, §7 必須執行 設定變更 簡化版，聚焦 §4, §5 管理原則 上線前 48 小時完成所有前置作業檢核 Go/No-Go 會議需所有關鍵角色簽核 回退計畫必須事先測試驗證 觀察期結束前不可離開 War Room 💡 範例（以 HRMS 人力資源管理系統為例） 範例：Go/No-Go 決策 上線版本：HRMS v2.0.0（薪資模組重構 + 出缺勤 API 升級） 上線視窗：2024-06-15 02:00~04:00 (Saturday) ...

事件報告與根因分析範本（Incident Report & Root Cause Analysis） 參照標準：ITIL 4（Incident Management & Problem Management）/ ISO/IEC 20000-1:2018 / SRE Postmortem 文件用途：記錄生產環境事件、分析根本原因、制定改善行動，防止問題再次發生 適用階段：維運監控階段（Operations Phase）— Continuous Improvement 📋 章節目錄 事件摘要 時間軸 影響評估 根因分析 解決方案 改善行動計畫 經驗教訓 附錄 1. 事件摘要 📝 範本 項目 內容 事件編號 INC-{YYYYMMDD}-{序號} 事件標題 {一句話描述事件} 嚴重等級 SEV1（Critical）/ SEV2（Major）/ SEV3（Minor）/ SEV4（Low） 事件狀態 調查中 / 已解決 / 已關閉 發生時間 {YYYY-MM-DD HH:MM} (UTC+8) 偵測時間 {YYYY-MM-DD HH:MM} 解決時間 {YYYY-MM-DD HH:MM} 事件持續時間 {N} 分鐘/小時 MTTD {偵測時間 - 發生時間} MTTR {解決時間 - 偵測時間} 受影響系統 {系統/服務名稱} 受影響使用者 {人數/比例} 事件負責人 {Incident Commander} 報告撰寫者 {姓名} 報告日期 {YYYY-MM-DD} 📖 使用說明 嚴重等級定義： SEV1：核心業務完全中斷，影響全部使用者 SEV2：核心功能嚴重降級，影響大部分使用者 SEV3：非核心功能異常，影響部分使用者 SEV4：輕微異常，幾乎不影響使用者 MTTD（Mean Time To Detect）：衡量監控能力 MTTR（Mean Time To Resolve）：衡量恢復能力 事件報告需在事件解決後 3-5 個工作日 內完成 Blameless 原則：報告聚焦系統與流程改善，不歸咎個人 💡 範例 項目 內容 事件編號 INC-20260520-001 事件標題 HRMS 薪資查詢 API 持續回傳 500 Error 嚴重等級 SEV2（核心功能嚴重降級） 發生時間 2026-05-20 10:15 偵測時間 2026-05-20 10:18（Grafana 告警） 解決時間 2026-05-20 10:28（回滾完成） 事件持續時間 13 分鐘 MTTD 3 分鐘 MTTR 10 分鐘 受影響使用者 ~200 人（薪資查詢功能不可用） 事件負責人 張 SRE 2. 時間軸 📝 範本 時間 (UTC+8) 事件 執行者 備註 {HH:MM} {發生/偵測/行動/解決} {人員} {補充說明} 📖 使用說明 時間軸是事件報告最有價值的部分，需精確到分鐘 涵蓋：事件發生 → 偵測 → 通知 → 診斷 → 緩解 → 解決 → 驗證 資料來源：監控日誌、Slack 訊息時間戳、告警記錄 時間軸讓團隊復盤流程效率，找出可改善的環節 💡 範例 時間 (UTC+8) 事件 執行者 備註 10:12 v2.1.0 部署完成，新版上線 DevOps 林 K8s Green deployment 完成 10:15 薪資計算排程 CronJob 啟動（與 API 衝突） System 排程被新設定觸發 10:15 DB Lock 衝突開始，API 回應逾時 System PostgreSQL row-level lock 10:18 Grafana 告警：5xx rate > 5% Alert System #hrms-alerts 頻道 10:19 SRE 張確認告警，開始調查 SRE 張 檢查 Pod 日誌 10:21 確認問題：DB Lock contention SRE 張 pg_stat_activity 發現 lock wait 10:23 聯繫 Tech Lead 決策：啟動回滾 SRE 張 → Tech Lead 王 Slack 通訊 10:24 Tech Lead 確認回滾，授權執行 Tech Lead 王 10:25 開始執行回滾腳本 SRE 張 ./rollback-hrms-v2.1.0.sh 10:27 流量切換至 v2.0.3 完成 SRE 張 Blue deployment 10:28 健康檢查通過，冒煙測試通過 SRE 張 + QA 陳 服務恢復 10:30 通知團隊：服務已恢復 SRE 張 Slack + Email 10:45 通知受影響使用者：服務已恢復 PM 林 系統公告 3. 影響評估 📝 範本 3.1 業務影響 影響維度 評估 受影響功能 {功能清單} 受影響使用者數 {人數/比例} 收入損失 {金額/無法計量} 資料損失 {是/否，描述} SLA 違反 {是/否，影響 SLA 指標} 信譽影響 {高/中/低} 3.2 技術影響 影響維度 評估 受影響服務 {服務清單} 相依服務影響 {是否連鎖影響} 資料一致性 {是否受影響} 安全性影響 {是否有安全疑慮} 📖 使用說明 影響評估用於確認嚴重等級是否正確、作為改善優先級依據 業務影響由 PM/產品團隊提供；技術影響由工程團隊評估 SLA 違反需記錄，可能涉及客戶賠償或內部 KPI 💡 範例 3.1 業務影響 影響維度 評估 受影響功能 薪資查詢、薪資條下載 受影響使用者數 ~200 人（嘗試查詢薪資的員工） 收入損失 無直接收入損失（內部系統） 資料損失 無 SLA 違反 否（SLA 99.5% 月度，本月仍在 SLA 內） 信譽影響 低（事件持續 13 分鐘，非上班尖峰） 4. 根因分析 📝 範本 4.1 根本原因 Root Cause Statement： ...

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

標準作業程序範本（Standard Operating Procedure, SOP） 參照標準：ISO 9001:2015（Quality Management）/ ISO/IEC 20000-1:2018 / ITIL 4 文件用途：標準化維運操作流程，確保操作一致性、降低人為錯誤、加速新人上手 適用階段：維運監控階段（Operations Phase）— Operational Excellence 📋 章節目錄 文件資訊 目的與範圍 角色與職責 前置條件 操作步驟 驗證與確認 異常處理 安全注意事項 相關文件 變更歷史 1. 文件資訊 📝 範本 項目 內容 文件編號 SOP-{類別代碼}-{序號} 文件名稱 {操作名稱} 標準作業程序 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 / 作廢 建立日期 {YYYY-MM-DD} 生效日期 {YYYY-MM-DD} 下次審核日期 {YYYY-MM-DD}（至少每年） 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核准者 {姓名/角色} 適用系統 {系統/服務名稱} 機密等級 一般 / 限閱 / 機密 📖 使用說明 SOP 編號慣例：SOP-{類別}-{流水號} 類別代碼範例：DEP（部署）、INC（事件處理）、BAK（備份）、MON（監控） 每份 SOP 需定期審核（ISO 9001 要求），避免過時 狀態管理：草稿 → 審核中 → 核定（可執行）→ 作廢（新版取代） 機密等級決定誰可以存取此 SOP 💡 範例 項目 內容 文件編號 SOP-BAK-001 文件名稱 HRMS 資料庫每日備份標準作業程序 版本 v2.0 生效日期 2026-05-01 下次審核日期 2027-05-01 適用系統 HRMS PostgreSQL 16 (Azure Database) 2. 目的與範圍 📝 範本 2.1 目的 {說明此 SOP 為何存在、解決什麼問題} ...

版本發行說明範本（Release Notes） 參照標準：Keep a Changelog 1.1.0 / SemVer 2.0.0 / ISO/IEC/IEEE 12207:2017（Release Management） 文件用途：正式記錄每個版本的變更內容，供開發、維運、使用者了解版本差異 適用階段：部署上線階段（Deployment Phase）— Release Management 📋 章節目錄 文件資訊 版本摘要 新增功能（Added） 變更項目（Changed） 修復項目（Fixed） 棄用項目（Deprecated） 移除項目（Removed） 安全性修復（Security） 已知問題（Known Issues） 升級指南 相容性說明 1. 文件資訊 📝 範本 項目 內容 產品名稱 {系統名稱} 版本號 v{MAJOR}.{MINOR}.{PATCH} 發佈日期 {YYYY-MM-DD} 版本類型 Major / Minor / Patch / Hotfix 發佈人 {Release Manager 姓名} Git Tag {tag name} Build Number #{build} 對應里程碑 {Sprint/Milestone 名稱} 📖 使用說明 版本號遵循 SemVer 2.0.0： MAJOR：不相容的 API 變更 MINOR：向後相容的新功能 PATCH：向後相容的 Bug 修復 每次正式發佈（含 Hotfix）都需要 Release Notes Git Tag 與 Build Number 確保可從 Release Notes 追溯到原始碼 💡 範例 項目 內容 產品名稱 人力資源管理系統（HRMS） 版本號 v2.1.0 發佈日期 2026-05-20 版本類型 Minor 發佈人 林 DevOps Git Tag v2.1.0 Build Number #489 對應里程碑 Sprint 12 2. 版本摘要 📝 範本 概述 {用 2-3 句話描述本版本的核心主題與重要變更} ...

監控與告警設定文件範本（Monitoring & Alert Configuration Template） 適用標準：Google SRE Workbook、ISO/IEC 20000-1:2018（Service Monitoring） 適用階段：維運階段（Operations Phase） 負責角色：SRE、DevOps Engineer、Tech Lead 📑 章節目錄 文件資訊 監控策略概要 SLI / SLO 定義 監控指標設計 告警規則定義 Dashboard 設計 告警通知與升級 日誌監控策略 維護與檢討機制 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 監控與告警設定文件 文件編號 [專案代碼]-MON-[版本號]-[日期] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 負責人 [SRE / DevOps] 審核者 [Tech Lead / SA] 2. 監控策略概要 2.1 監控架構 層級 工具 用途 Infrastructure [Prometheus / CloudWatch / Azure Monitor] 主機/容器/網路 Application [APM: Datadog / New Relic / OpenTelemetry] 應用效能 Business [Custom metrics / Analytics] 業務指標 Logging [ELK / Loki / Azure Log Analytics] 日誌分析 Tracing [Jaeger / Zipkin / OpenTelemetry] 分散式追蹤 2.2 監控原則 原則 說明 Four Golden Signals Latency, Traffic, Errors, Saturation USE Method Utilization, Saturation, Errors（基礎設施） RED Method Rate, Errors, Duration（服務） Alerting Philosophy Alert on symptoms, not causes 3. SLI / SLO 定義 3.1 服務層級指標（SLI） SLI 定義 量測方式 資料來源 Availability 成功回應比例 success_requests / total_requests [Load Balancer / App] Latency 回應時間分佈 P50, P95, P99 [APM / Prometheus histogram] Throughput 處理量 Requests per second [Metrics] Error Rate 錯誤回應比例 5xx_count / total_count [Ingress / App] 3.2 服務層級目標（SLO） 服務 SLO 指標 目標值 Error Budget (月) 量測視窗 [API Service] Availability ≥ 99.9% 43.8 min 30 days rolling [API Service] P95 Latency < [N]ms — 30 days rolling [Web Frontend] Availability ≥ 99.5% 3.6 hr 30 days rolling [Batch Job] Success Rate ≥ 99.0% — Per execution 4. 監控指標設計 4.1 基礎設施指標 指標名稱 類型 描述 標籤 閾值 node_cpu_usage_percent Gauge CPU 使用率 host, instance warn: 80%, crit: 95% node_memory_usage_percent Gauge 記憶體使用率 host, instance warn: 85%, crit: 95% node_disk_usage_percent Gauge 磁碟使用率 host, mountpoint warn: 80%, crit: 90% node_network_errors_total Counter 網路錯誤數 host, interface crit: > [N]/min 4.2 應用程式指標 指標名稱 類型 描述 標籤 閾值 http_requests_total Counter HTTP 請求總數 method, path, status — http_request_duration_seconds Histogram 請求處理時間 method, path P95 < [N]s http_requests_errors_total Counter HTTP 錯誤數 method, path, status rate > [N]/min active_connections Gauge 活躍連線數 service warn: [N], crit: [N] db_connection_pool_active Gauge DB 連線池使用數 pool_name warn: 80%, crit: 95% queue_depth Gauge 訊息佇列深度 queue_name warn: [N], crit: [N] 4.3 業務指標 指標名稱 類型 描述 標籤 告警條件 [business_metric_1] Counter [描述] [labels] [condition] [business_metric_2] Gauge [描述] [labels] [condition] 5. 告警規則定義 5.1 告警嚴重度定義 嚴重度 定義 回應時間 通知方式 P1 - Critical 服務完全中斷 / 資料遺失 5 分鐘 PagerDuty + 電話 + SMS P2 - High 核心功能受損 / 效能嚴重惡化 15 分鐘 PagerDuty + Teams P3 - Medium 非核心功能異常 / 效能下降 1 小時 Teams Channel P4 - Low 預警 / 需關注但無立即影響 下個工作日 Email / Ticket 5.2 告警規則清單 Alert ID 名稱 嚴重度 條件 For 說明 ALT-001 ServiceDown P1 up == 0 1m 服務實例離線 ALT-002 HighErrorRate P1 error_rate > 5% 5m 錯誤率過高 ALT-003 HighLatency P2 p95_latency > [N]ms 5m 回應時間過慢 ALT-004 HighCPU P3 cpu_usage > 80% 10m CPU 使用率高 ALT-005 DiskAlmostFull P2 disk_usage > 85% 5m 磁碟空間不足 ALT-006 DBConnectionPoolHigh P2 pool_usage > 80% 5m DB 連線池接近上限 ALT-007 CertExpiringSoon P3 cert_expiry < 30d — 憑證即將到期 ALT-008 ErrorBudgetBurnRate P2 burn_rate > 1.0 1h Error Budget 消耗過快 5.3 告警規則範例（Prometheus AlertManager） groups: - name: [service_name].rules rules: - alert: [AlertName] expr: [PromQL expression] for: [duration] labels: severity: [critical/warning/info] team: [team_name] service: [service_name] annotations: summary: "[簡短摘要]" description: "[詳細描述，可含 {{ $labels }} 和 {{ $value }}]" runbook_url: "[Runbook 連結]" dashboard_url: "[Dashboard 連結]" 6. Dashboard 設計 6.1 Dashboard 清單 Dashboard 用途 目標受眾 更新頻率 Service Overview 服務健康狀態總覽 SRE / 管理層 10s API Performance API 效能細節 SRE / Dev 10s Infrastructure 基礎設施資源 Infra / SRE 30s Business Metrics 業務指標 PM / PO 1m SLO Tracking SLO 達成率與 Error Budget SRE / 管理層 1m 6.2 Service Overview Dashboard 設計 Panel 視覺化類型 指標 說明 Service Status Stat (up/down) up{service="…"} 紅綠燈 Request Rate Time Series rate(http_requests_total[5m]) QPS Error Rate Time Series error_rate 錯誤率趨勢 P95 Latency Time Series histogram_quantile(0.95, …) 延遲趨勢 Active Users Stat active_sessions 當前活躍用戶 SLO Status Gauge slo_compliance SLO 達標率 7. 告警通知與升級 7.1 通知路由 嚴重度 工作時間 (09-18) 非工作時間 假日 P1 On-call + Team Lead (即時) On-call + Backup (即時) On-call + Manager (即時) P2 On-call (15 min) On-call (30 min) On-call (30 min) P3 Teams Channel 下個工作日 下個工作日 P4 Email / Ticket — — 7.2 升級機制 時間 未回應動作 T + 5 min 重新通知 On-call T + 15 min 通知 Backup On-call T + 30 min 通知 Team Lead / Manager T + 60 min 通知 Director / VP 7.3 On-Call 輪值 週次 Primary Backup 電話 Week 1 [姓名] [姓名] [電話] Week 2 [姓名] [姓名] [電話] 8. 日誌監控策略 8.1 日誌等級與保留 Log Level 用途 保留期間 告警 ERROR 需處理的錯誤 90 days rate > [N]/min → P2 WARN 潛在問題 30 days rate > [N]/min → P3 INFO 正常營運記錄 14 days — DEBUG 開發除錯用 3 days (STG only) — 8.2 關鍵日誌監控 # 監控模式 觸發條件 告警 1 Exception stack trace rate > [N]/min P2 2 “OutOfMemoryError” 出現 1 次 P1 3 “Connection refused” rate > [N]/min P2 4 Authentication failure rate > [N]/min P2 (可能攻擊) 5 [自訂業務異常模式] [條件] [等級] 9. 維護與檢討機制 項目 頻率 負責人 說明 Alert Noise 檢討 每月 SRE 刪除/調整誤報告警 SLO 檢討 每季 SRE + PO 調整目標值 Dashboard 更新 需求變動時 SRE 新增/移除指標 Runbook 更新 每次事件後 SRE 補充處理步驟 On-Call 回顧 每月 SRE Team 改善值班體驗 10. 附錄 10.1 AlertManager 設定檔位置 檔案 位置 說明 alertmanager.yml [path] 通知路由設定 prometheus-rules/ [path] 告警規則目錄 grafana-dashboards/ [path] Dashboard JSON 10.2 相關文件 文件 連結 Runbook [link] SOP [link] Incident Response Plan [link] 📖 使用說明 建立監控的優先順序 Phase 1：健康檢查 + 基本告警（Service Up/Down, Error Rate） Phase 2：Golden Signals 完整覆蓋（Latency, Traffic, Errors, Saturation） Phase 3：SLI/SLO 追蹤 + Error Budget Phase 4：業務指標 + 進階分析 告警設計原則 原則 說明 Alert on symptoms 告警使用者可感知的症狀，非原因 Actionable 每個告警都必須有對應的處理動作 Low noise 避免無意義的告警（Alert fatigue） Have a runbook 每個告警必須連結到 Runbook 💡 範例（以 HRMS 人力資源管理系統為例） 範例：SLI/SLO 服務 SLI SLO Error Budget/月 HRMS API Availability ≥ 99.9% 43.8 min HRMS API P95 Latency < 200ms — 薪資批次作業 Success Rate ≥ 99.99% 0.44 min (每月一次不容失敗) 出缺勤打卡 Availability ≥ 99.95% (上班時段) 21.9 min 範例：告警規則 groups: - name: hrms.rules rules: - alert: HRMSHighErrorRate expr: | sum(rate(http_requests_total{service="hrms-api", status=~"5.."}[5m])) / sum(rate(http_requests_total{service="hrms-api"}[5m])) > 0.01 for: 5m labels: severity: critical team: hrms service: hrms-api annotations: summary: "HRMS API 錯誤率超過 1%" description: "目前錯誤率為 {{ $value | humanizePercentage }}，超過 SLO 閾值" runbook_url: "https://wiki/runbook/hrms-high-error-rate" - alert: HRMSPayrollJobFailed expr: hrms_payroll_job_status == 0 for: 1m labels: severity: critical team: hrms service: hrms-payroll annotations: summary: "HRMS 薪資計算作業失敗" description: "月薪計算批次作業執行失敗，需立即處理" runbook_url: "https://wiki/runbook/hrms-payroll-failure" 📌 審閱重點 ...

系統退役計畫範本（System Retirement Plan Template） 適用標準：ISO/IEC/IEEE 15288:2023（System Life Cycle - Disposal Process） 適用階段：維運階段 — 退役處理（Operations — Retirement Phase） 負責角色：PM、SA、DBA、Infra、資安 📑 章節目錄 文件資訊 退役概要 影響分析 資料處置計畫 基礎設施釋放計畫 相依系統處理 溝通計畫 退役執行步驟 驗證與確認 風險與應變 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 退役計畫 文件編號 [專案代碼]-RTP-[版本號]-[日期] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 預計退役日 [YYYY-MM-DD] 負責人 [PM / SA] 審核者 [IT Director / CISO] 2. 退役概要 項目 內容 系統名稱 [退役系統名稱] 系統用途 [一句話描述系統功能] 上線日期 [YYYY-MM-DD] 服務年限 [N] 年 退役原因 [被取代 / 業務需求消失 / 技術不支援 / 成本效益] 替代系統 [新系統名稱] 或 [無] 影響用戶數 [N] 人 退役方式 [立即下線 / 漸進退場 / 唯讀保留期] 2.1 退役判定準則 準則 說明 是否滿足 替代系統已上線並穩定 [新系統 GAP 已關閉] [✅/❌] 使用者已完成遷移 [N]% 已切換至新系統 [✅/❌] 資料已完成遷移/封存 [全量遷移完成] [✅/❌] 相依系統已解耦 [所有介接已切換] [✅/❌] 法規保留要求已確認 [保留年限/方式已確定] [✅/❌] 3. 影響分析 3.1 利害關係人影響 利害關係人 影響描述 嚴重度 緩解措施 [內部使用者] [無法再使用舊系統] [Low] [已遷移至新系統] [外部合作夥伴] [API 中斷] [Medium] [提前通知 + 新 API 對接] [報表使用者] [歷史報表查詢] [Medium] [資料封存 + 查詢介面] 3.2 功能影響盤點 功能模組 狀態 替代方案 備註 [模組 A] 已遷移至新系統 [新系統模組 X] [模組 B] 功能廢除 無 [業務確認不再需要] [模組 C] 部分功能無替代 [Manual process / 新建] ⚠️ GAP 3.3 合規與法規要求 法規/政策 要求 資料保留期 處理方式 [個資法] 個人資料銷毀或去識別化 — [銷毀/去識別化] [商業法] 財務交易記錄保留 [N] 年 [封存至 Archive] [公司政策] [內部規範] [N] 年 [方式] 4. 資料處置計畫 4.1 資料分類與處置 資料類別 資料表/儲存 筆數 大小 處置方式 備註 已遷移資料 [tables] [N] [N]GB 驗證後刪除 遷移至新系統 法規保留資料 [tables] [N] [N]GB 封存至冷儲存 保留 [N] 年 個人資料 [tables] [N] [N]GB 去識別化/銷毀 依個資法 暫存/Log [tables] [N] [N]GB 直接刪除 無保留價值 附件/檔案 [storage] [N] [N]GB [遷移/封存/刪除] 4.2 資料封存規格 項目 內容 封存格式 [SQL dump / Parquet / CSV + Schema] 封存位置 [Cold Storage / Archive Vault] 加密方式 [AES-256 / 由保管庫管理] 存取方式 [申請制 / 限特定角色] 保留期限 [N] 年，到期後 [自動銷毀 / 覆審] 驗證方式 [Checksum / Restore test] 4.3 資料銷毀證明 銷毀項目 方式 執行日 執行人 驗證人 證明文件 [DB data] [TRUNCATE + VACUUM / Secure erase] [日期] [DBA] [資安] [存證編號] [File storage] [Secure delete / Disk wipe] [日期] [Infra] [資安] [存證編號] [Backup tapes] [Degauss / Physical destruction] [日期] [Infra] [資安] [存證編號] 5. 基礎設施釋放計畫 5.1 資源盤點 資源類型 名稱/ID 規格 月費 處置方式 預計釋放日 VM / 主機 [hostname/ID] [spec] $[N] [刪除/重新用途] [日期] Database [instance name] [spec] $[N] [刪除] [日期] Storage [bucket/share] [N]GB $[N] [資料移出後刪除] [日期] Load Balancer [name] — $[N] [刪除] [日期] DNS Record [domain] — — [刪除/轉向] [日期] SSL Certificate [CN] — — [不續約] [到期日] Monitoring [Dashboard/Alert] — — [刪除] [日期] 5.2 成本節約估計 項目 月費 年費 備註 計算資源 $[N] $[N] 儲存 $[N] $[N] 授權 (License) $[N] $[N] 維護合約 $[N] $[N] 合計節省 $[N] $[N] 6. 相依系統處理 6.1 上游系統（呼叫退役系統的系統） 來源系統 介接方式 呼叫頻率 處理方式 負責人 狀態 [System A] REST API [N] calls/day 切換至新系統 API [PM of A] [✅/❌] [System B] DB Link [N] queries/day 移除 DB Link [DBA] [✅/❌] 6.2 下游系統（退役系統呼叫的系統） 目標系統 介接方式 影響 處理方式 狀態 [System C] Event publish [訂閱者需取消] 通知訂閱者 [✅/❌] 6.3 共用元件 元件 共用者 可否移除 處理方式 [Shared DB] [系統列表] [否] [僅移除退役系統的 Schema] [Message Queue] [系統列表] [是/否] [移除 Topic / 保留] 7. 溝通計畫 時間點 對象 內容 方式 負責人 T - 90 天 所有使用者 退役預告 + 遷移指引 Email + 公告 PM T - 60 天 相依系統負責人 技術切換時程 會議 SA T - 30 天 所有使用者 最後提醒 + 進入唯讀期 Email + In-app PM T - 7 天 全體 最終通知 Email + Teams PM T day IT 團隊 執行退役 War Room RM T + 1 天 全體 退役完成通知 Email PM 8. 退役執行步驟 # 步驟 負責人 預估時間 前置條件 狀態 1 切換至唯讀模式 DevOps [N] min T-30d 通知完成 2 最終資料備份 DBA [N] hr 唯讀模式已啟用 3 驗證最終備份完整性 DBA [N] hr 備份完成 4 DNS 移除/轉向 Infra [N] min 5 停止應用程式服務 DevOps [N] min DNS 已處理 6 移除相依系統連線設定 SA/DevOps [N] hr 相依系統已切換 7 資料封存（法規保留） DBA [N] hr 備份驗證通過 8 資料銷毀（非保留資料） DBA/Infra [N] hr 封存完成 9 基礎設施釋放 Infra [N] hr 資料處置完成 10 監控/告警移除 SRE [N] min 服務已停止 11 文件更新（架構圖/CMDB） SA [N] hr 全部完成 12 退役完成確認 PM — 全部驗證通過 9. 驗證與確認 9.1 退役前驗證 # 驗證項目 方法 預期結果 狀態 1 新系統功能涵蓋率 UAT 驗收 100% 功能可替代 [✅/❌] 2 資料遷移完整性 Count + Sample 驗證 差異 = 0 [✅/❌] 3 相依系統已切換 連線測試 無對退役系統的呼叫 [✅/❌] 4 使用者已遷移 登入統計 活躍用戶 = 0 [✅/❌] 9.2 退役後驗證 # 驗證項目 方法 預期結果 狀態 1 舊系統不可存取 URL/IP 測試 Connection refused / 404 [✅/❌] 2 新系統運作正常 Smoke Test 全數通過 [✅/❌] 3 封存資料可存取 Restore 測試 資料完整可讀 [✅/❌] 4 無殘留資源 CMDB / Cloud Console 檢查 資源已清除 [✅/❌] 5 成本已停止計費 帳單確認 下月帳單減少 [✅/❌] 10. 風險與應變 # 風險 影響 機率 應變措施 1 使用者未完成遷移 業務中斷 Medium 延長唯讀期 + 人工協助 2 發現未識別的相依系統 相依系統異常 Medium 保留 DNS 轉向頁 30 天 3 法規保留期判定錯誤 合規風險 Low 法務覆審 + 寧可多保留 4 封存資料無法還原 資料遺失 Low 保留完整備份至驗證通過 5 退役後需要回溯查詢 業務查詢困難 Medium 建立簡易查詢介面 for 封存資料 11. 附錄 11.1 系統架構圖（退役前） [附上退役系統目前的架構圖，標示將移除的元件] ...

資料遷移計畫範本（Data Migration Plan Template） 適用標準：ISO/IEC 25024（資料品質）、DAMA DMBOK 2.0（Data Management） 適用階段：部署上線階段（Deployment Phase） 負責角色：DBA、Data Engineer、SA、PM 📑 章節目錄 文件資訊 遷移概要 來源與目標分析 遷移策略 資料映射規則 資料清洗與轉換規則 驗證策略 風險與應變 時程與里程碑 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 資料遷移計畫 文件編號 [專案代碼]-DMP-[版本號]-[日期] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 負責人 [DBA / Data Engineer] 審核者 [SA / PM] 2. 遷移概要 項目 內容 遷移類型 [全量遷移 / 增量遷移 / 混合式] 來源系統 [舊系統名稱 + 版本] 目標系統 [新系統名稱 + 版本] 遷移目的 [系統升級 / 平台轉換 / 整併 / 雲遷移] 資料量估計 [N] GB / [N] 筆記錄 停機視窗 [YYYY-MM-DD HH:mm ~ HH:mm] 遷移方式 [Big Bang / Phased / Parallel Run] 3. 來源與目標分析 3.1 來源系統 項目 內容 資料庫類型 [RDBMS: SQL Server / Oracle / PostgreSQL / NoSQL] 版本 [ver] Schema 數量 [N] Table 數量 [N] 總資料量 [N] GB 編碼 [UTF-8 / Big5 / …] 3.2 目標系統 項目 內容 資料庫類型 [RDBMS / NoSQL / Data Lake] 版本 [ver] Schema 設計 [New / Modified / Same] 字元編碼 [UTF-8] 3.3 遷移範圍 資料分類 資料表 筆數(估) 大小(估) 優先級 備註 Master Data [table list] [N] [N]MB P1 Transaction Data [table list] [N] [N]GB P1 Historical Data [table list] [N] [N]GB P2 Config/Lookup [table list] [N] [N]KB P1 Attachments/BLOB [storage] [N] [N]GB P2 3.4 排除範圍 資料類型 排除原因 [暫存資料/Log] [無業務價值] [超過 N 年的歷史資料] [封存處理] 4. 遷移策略 4.1 遷移方式比較 方式 說明 優點 缺點 適用場景 Big Bang 一次性全量搬遷 簡單明確 停機時間長 資料量小/可停機 Phased 分批搬遷 降低風險 需處理雙寫 資料可分割 Parallel Run 新舊並行 最安全 成本最高 核心業務系統 選定策略：[Big Bang / Phased / Parallel Run] ...

運維手冊範本（Runbook） 參照標準：ITIL 4 Service Operation / ISO/IEC 20000-1:2018 第 8.5 節「Service delivery」 文件用途：提供系統日常維運、告警處理、故障排除的標準化操作程序 適用階段：營運維護階段（Operations & Maintenance） 📋 章節目錄 文件資訊 系統概述 常見操作程序 告警處理 故障排除決策樹 緊急聯絡人 SLA 與 SLO 維護窗口與排程作業 備份與還原 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 RB-{專案代碼}-{序號} 文件名稱 {系統名稱} 運維手冊 版本 v{主版本}.{次版本} 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 維護者 {姓名/團隊} 適用環境 Production / Staging / All 版本歷程 版本 日期 修改人 修改內容 v1.0 {日期} {姓名} 初版 📖 使用說明 Runbook 為活文件，需隨系統變更持續更新 任何維運操作變更需同步更新本文件 建議每季審閱一次，確保內容與現況一致 💡 範例 項目 內容 文件編號 RB-HRM-001 文件名稱 HRMS 運維手冊 維護者 DevOps 團隊 — 周維運 適用環境 Production 2. 系統概述 📝 範本 2.1 系統架構 {架構圖 — 包含所有元件與連接關係} 2.2 元件清單 元件名稱 技術堆疊 部署位置 端點 用途 {元件} {技術} {位置} {URL/IP} {說明} 2.3 相依服務 外部服務 用途 端點 擁有者 SLA {服務} {用途} {端點} {團隊} {SLA} 2.4 存取方式 環境 入口 認證方式 備註 {環境} {URL/方式} {認證} {備註} 📖 使用說明 系統概述幫助值班人員快速了解系統全貌 元件清單需包含所有運行中的服務（含背景 Worker、排程任務等） 相依服務標明擁有者，出問題時知道找誰 💡 範例 2.2 元件清單 元件名稱 技術堆疊 部署位置 端點 用途 hrms-api .NET 8 Web API AKS hrms-prod ns https://hrms-api.internal:443 後端 API hrms-web React 18 + Nginx AKS hrms-prod ns https://hrms.company.com 前端 SPA hrms-worker .NET 8 Worker Service AKS hrms-prod ns N/A（內部處理） 背景排程任務 PostgreSQL v16 Azure DB for PostgreSQL hrms-db.postgres.database.azure.com:5432 主資料庫 Redis v7 Azure Cache for Redis hrms-cache.redis.cache.windows.net:6380 Session + Cache 3. 常見操作程序 📝 範本 3.1 {操作名稱} 項目 內容 操作目的 {為什麼要做} 執行頻率 手動觸發 / 每日 / 每週 / 每月 預估時間 {分鐘} 影響範圍 {影響說明} 所需權限 {權限} 步驟： ...

部署指南範本（Deployment Guide） 參照標準：ITIL 4 Release Management / ISO/IEC 20000-1:2018 第 8.5.2 節「Release management」 文件用途：提供系統部署的標準化步驟指引，確保可重複、可追蹤、可回滾的部署流程 適用階段：部署與上線階段（Release & Deployment） 📋 章節目錄 文件資訊 部署概述 先決條件 部署架構 部署步驟 驗證程序 回滾程序 監控確認 聯絡窗口 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 DG-{專案代碼}-{序號} 文件名稱 {系統名稱} v{版本} 部署指南 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 計畫部署日期 {YYYY-MM-DD HH:mm} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核准者 {姓名/角色} 版本歷程 版本 日期 修改人 修改內容 v1.0 {日期} {姓名} 初版 📖 使用說明 依據 ITIL 4 Release Management 實務，每次部署需有正式的部署指南 文件需在部署前完成審核，未經核准不得執行部署 適用於所有環境（SIT / UAT / Staging / Production）部署 💡 範例 項目 內容 文件編號 DG-HRM-003 文件名稱 HRMS v1.0.0 正式環境部署指南 計畫部署日期 2026-10-15 22:00（維護窗口） 核准者 IT 副總 — 黃資訊 2. 部署概述 📝 範本 2.1 部署資訊摘要 項目 內容 部署類型 新系統上線 / 版本升級 / Hotfix / 組態變更 部署版本 {Application Version} 目標環境 {環境名稱} 部署方式 全量部署 / 滾動更新 / 藍綠部署 / 金絲雀部署 預估停機時間 {分鐘/小時} / 零停機 影響範圍 {受影響的服務/使用者} 維護窗口 {起始時間} ~ {結束時間} 2.2 變更內容摘要 變更編號 類型 描述 {CR/JIRA 編號} 功能/修復/組態 {簡述} 2.3 部署風險評估 風險等級 說明 高/中/低 {為何此等級} 📖 使用說明 部署類型決定所需的審核層級與流程嚴格度 Hotfix 可簡化流程但仍需記錄 預估停機時間需告知業務方，以便安排使用者通知 💡 範例 2.1 部署資訊摘要 項目 內容 部署類型 新系統上線 部署版本 HRMS v1.0.0 (Build #2026.10.12.1) 目標環境 Production (Azure AKS - hrms-prod) 部署方式 藍綠部署（Blue-Green Deployment） 預估停機時間 零停機（流量切換時間 < 30 秒） 影響範圍 全公司員工（約 2,000 人） 維護窗口 2026-10-15 22:00 ~ 2026-10-16 02:00 3. 先決條件 📝 範本 3.1 核准與簽核 項目 狀態 確認人 日期 變更審核委員會（CAB）核准 ☐ {姓名} {日期} 測試報告簽核 ☐ {姓名} {日期} 業務方確認上線同意 ☐ {姓名} {日期} 回滾計畫審核 ☐ {姓名} {日期} 3.2 技術先決條件 項目 驗證方式 狀態 {基礎設施就緒} {驗證命令/方式} ☐ {相依服務可用} {驗證命令/方式} ☐ {資料庫備份完成} {驗證命令/方式} ☐ {SSL 憑證有效} {驗證命令/方式} ☐ {DNS 設定確認} {驗證命令/方式} ☐ 3.3 部署所需權限 系統/資源 所需權限 帳號 {系統} {權限} {帳號} 📖 使用說明 所有先決條件需在部署開始前全部確認（Checklist 全部打勾） 任何一項未完成則不得啟動部署 資料庫備份是最關鍵的先決條件，未備份禁止部署 💡 範例 3.2 技術先決條件 項目 驗證方式 狀態 AKS 叢集節點 ≥ 4 kubectl get nodes 確認 Ready ☑ PostgreSQL 資料庫完整備份 確認 Azure Backup 最新備份 < 1 小時 ☑ Redis Cache 可連線 redis-cli ping 回應 PONG ☑ AD 連線正常 測試 LDAP bind ☑ Container Registry 映像已推送 az acr repository show-tags 確認 v1.0.0 存在 ☑ SSL 憑證效期 > 30 天 openssl s_client 確認到期日 ☑ 4. 部署架構 📝 範本 4.1 目標環境架構圖 {架構圖或 Mermaid 圖} 4.2 環境資訊 元件 主機/端點 規格 備註 Application Server {Host/IP} {CPU/RAM} {說明} Database {Host/IP:Port} {版本/規格} {說明} Cache {Host/IP:Port} {版本/規格} {說明} Load Balancer {Host/IP} {類型} {說明} Storage {Host/Path} {容量} {說明} 4.3 網路與防火牆規則 來源 目的 Port Protocol 用途 {來源} {目的} {Port} TCP/UDP {用途} 📖 使用說明 架構圖幫助部署人員理解全貌，建議使用 Mermaid 或繪製圖示 網路規則需在部署前確認已開通，避免部署後才發現連線失敗 機敏資訊（密碼、連線字串）不寫入文件，使用 Secret Manager 或變數引用 💡 範例 4.1 目標環境架構圖 Internet → Azure Front Door → AKS Ingress → Service ├── hrms-api (3 replicas) ├── hrms-worker (2 replicas) └── hrms-web (3 replicas) ↓ PostgreSQL (Azure DB for PostgreSQL) Redis (Azure Cache for Redis) Azure Blob Storage 5. 部署步驟 📝 範本 5.0 部署前通知 時間 對象 通知方式 內容 部署前 {N} 小時 {對象} {方式} {內容} 5.1 資料庫變更 步驟 指令/操作 預期結果 確認者 1 {SQL / Migration 指令} {預期輸出} {姓名} 2 {SQL / Migration 指令} {預期輸出} {姓名} 5.2 應用程式部署 步驟 指令/操作 預期結果 確認者 1 {部署指令} {預期輸出} {姓名} 2 {部署指令} {預期輸出} {姓名} 5.3 組態更新 步驟 指令/操作 預期結果 確認者 1 {組態變更指令} {預期結果} {姓名} 5.4 流量切換 步驟 指令/操作 預期結果 確認者 1 {切換指令} {預期結果} {姓名} 📖 使用說明 步驟需按執行順序排列，不可跳步 每步驟需有具體指令（可複製貼上執行）與預期結果 「確認者」在部署時簽名確認該步驟已完成 資料庫變更必須先於應用程式部署（確保 schema 相容） 機敏值（密碼）用環境變數或 Secret 引用，不寫死 💡 範例 5.2 應用程式部署 步驟 指令/操作 預期結果 確認者 1 kubectl set image deployment/hrms-api hrms-api=hrmacr.azurecr.io/hrms-api:v1.0.0 -n hrms-prod deployment.apps/hrms-api image updated DevOps 2 kubectl rollout status deployment/hrms-api -n hrms-prod --timeout=300s deployment successfully rolled out DevOps 3 kubectl set image deployment/hrms-web hrms-web=hrmacr.azurecr.io/hrms-web:v1.0.0 -n hrms-prod deployment.apps/hrms-web image updated DevOps 4 kubectl rollout status deployment/hrms-web -n hrms-prod --timeout=300s deployment successfully rolled out DevOps 5 確認所有 Pod 狀態正常：kubectl get pods -n hrms-prod 所有 Pod 狀態為 Running，READY 1/1 DevOps 6. 驗證程序 📝 範本 6.1 Smoke Test（冒煙測試） 測試項目 驗證方式 預期結果 實際結果 Pass/Fail {基本功能 1} {驗證方式} {預期} {實際} {基本功能 2} {驗證方式} {預期} {實際} 6.2 健康檢查 端點/服務 驗證指令 預期回應 實際回應 Pass/Fail {端點} {指令} {預期} {實際} 6.3 整合驗證 驗證項目 驗證方式 預期結果 實際結果 Pass/Fail {外部系統連接} {指令/操作} {預期} {實際} 6.4 部署成功判定標準 標準 說明 所有 Smoke Test 通過 — 健康檢查端點回應 200 持續 5 分鐘 無 Critical/High Alert 部署後 15 分鐘內 日誌無異常 Error 抽查近 100 條 Log 📖 使用說明 驗證程序在部署完成後立即執行，決定是否接受本次部署 Smoke Test 覆蓋核心業務路徑（如登入、主要功能），不需全面測試 若任何 P1 驗證失敗，立即啟動回滾程序 💡 範例 6.1 Smoke Test 測試項目 驗證方式 預期結果 實際結果 Pass/Fail 首頁可存取 curl -s -o /dev/null -w "%{http_code}" https://hrms.company.com 200 200 Pass 員工登入 使用測試帳號登入 成功進入首頁 成功 Pass 請假申請 建立一筆特休假申請 申請成功，狀態=待審核 成功 Pass 薪資查詢 查詢本月薪資明細 顯示薪資資料 成功 Pass 6.2 健康檢查 端點/服務 驗證指令 預期回應 實際回應 Pass/Fail API Health curl https://hrms-api.company.com/health {"status":"healthy"} 同預期 Pass DB 連線 curl https://hrms-api.company.com/health/db {"status":"connected"} 同預期 Pass Redis 連線 curl https://hrms-api.company.com/health/cache {"status":"connected"} 同預期 Pass 7. 回滾程序 📝 範本 7.1 回滾觸發條件 條件 決策者 {觸發條件 1} {角色} {觸發條件 2} {角色} 7.2 回滾步驟 步驟 指令/操作 預期結果 確認者 1 {回滾指令} {預期} {姓名} 2 {回滾指令} {預期} {姓名} 7.3 資料庫回滾 步驟 指令/操作 預期結果 確認者 1 {DB 回滾指令} {預期} {姓名} 7.4 回滾後驗證 驗證項目 方式 預期結果 {驗證項} {方式} {預期} 7.5 回滾時間預估 項目 預估時間 應用程式回滾 {分鐘} 資料庫回滾 {分鐘} 驗證完成 {分鐘} 總計 {分鐘} 📖 使用說明 每次部署必須有回滾計畫，這是 ITIL 4 Release Management 的核心要求 回滾步驟需預先演練驗證，不可「部署當天第一次嘗試回滾」 資料庫回滾是最複雜的部分（若有 schema 變更），需特別規劃 藍綠部署的回滾最簡單：切回舊版流量即可 💡 範例 7.1 回滾觸發條件 條件 決策者 Smoke Test 失敗 2 項以上 DevOps Lead 部署後 15 分鐘內出現 Critical Alert DevOps Lead 業務方回報核心功能異常 IT 副總 部署超過維護窗口仍未完成 DevOps Lead + PM 7.2 回滾步驟（藍綠部署） 步驟 指令/操作 預期結果 確認者 1 通知團隊啟動回滾 Teams 群組通知已發送 DevOps Lead 2 kubectl rollout undo deployment/hrms-api -n hrms-prod rollback to previous revision DevOps 3 kubectl rollout undo deployment/hrms-web -n hrms-prod rollback to previous revision DevOps 4 kubectl rollout status deployment/hrms-api -n hrms-prod successfully rolled out DevOps 5 執行 Smoke Test 驗證回滾成功 所有項目 Pass QA 6 通知業務方服務已恢復 Email/Teams 通知已發送 PM 8. 監控確認 📝 範本 8.1 部署後監控期間 項目 內容 加強監控期間 部署後 {N} 小時 監控人員 {姓名/值班表} 告警通知管道 {方式} 8.2 關鍵監控指標 指標 正常範圍 告警門檻 監控工具 API 回應時間 (P95) < {ms} > {ms} {工具} Error Rate < {%} > {%} {工具} CPU 使用率 < {%} > {%} {工具} Memory 使用率 < {%} > {%} {工具} 活躍連線數 < {N} > {N} {工具} 8.3 日誌檢查項目 日誌類型 檢查重點 工具/指令 Application Log {重點} {工具} Access Log {重點} {工具} Error Log {重點} {工具} 📖 使用說明 部署後加強監控是確保部署穩定的最後一道防線 監控期間內若指標異常，仍可啟動回滾 建議部署後 24 小時為加強監控期，48 小時後轉為一般監控 💡 範例 8.2 關鍵監控指標 指標 正常範圍 告警門檻 監控工具 API P95 回應時間 < 200ms > 500ms Grafana + Prometheus Error Rate (5xx) < 0.1% > 1% Azure Monitor CPU 使用率 < 60% > 85% Azure Monitor Memory 使用率 < 70% > 90% Azure Monitor Pod Restart Count 0 > 2 Kubernetes Dashboard DB Connection Pool < 80% > 95% Application Insights 9. 聯絡窗口 📝 範本 角色 姓名 電話 備用聯絡 職責 部署指揮 {姓名} {電話} {備用} 部署決策、Go/No-Go 判定 DevOps 工程師 {姓名} {電話} {備用} 執行部署操作 DBA {姓名} {電話} {備用} 資料庫變更 開發 Lead {姓名} {電話} {備用} 技術問題排除 QA {姓名} {電話} {備用} 部署驗證 業務窗口 {姓名} {電話} {備用} 業務確認 📖 使用說明 部署當天所有窗口需保持電話暢通 部署指揮負責 Go/No-Go 決策與回滾決定 建議建立即時通訊群組（如 Teams/Slack War Room）方便即時溝通 💡 範例 角色 姓名 電話 備用聯絡 職責 部署指揮 黃資訊（IT 副總） 0912-xxx-xxx Teams Go/No-Go 決策 DevOps 周維運 0933-xxx-xxx Teams 執行部署 DBA 趙資料 0922-xxx-xxx Teams DB Migration 開發 Lead 吳開發 0955-xxx-xxx Teams 問題排查 QA 林品質 0966-xxx-xxx Teams Smoke Test 10. 附錄 📝 範本 10.1 部署 Checklist 總表 階段 檢查項 確認 時間 確認者 部署前 CAB 核准 ☐ 部署前 資料庫備份完成 ☐ 部署前 通知使用者 ☐ 部署中 DB Migration 完成 ☐ 部署中 應用程式部署完成 ☐ 部署後 Smoke Test 通過 ☐ 部署後 健康檢查正常 ☐ 部署後 監控指標正常 ☐ 部署後 通知使用者服務恢復 ☐ 10.2 相關文件 文件 說明 {文件名} {用途} 10.3 術語定義 術語 定義 CAB Change Advisory Board，變更諮詢委員會 Blue-Green 藍綠部署，同時維護兩套環境，透過流量切換完成零停機部署 Smoke Test 冒煙測試，部署後快速驗證核心功能 Rollback 回滾，將系統恢復至部署前的版本 Maintenance Window 維護窗口，預先規劃的系統維護時段 📖 使用說明 Checklist 在部署當天使用，逐項確認並記錄時間 此 Checklist 同時作為部署紀錄保存，不可事後補填 💡 範例 10.1 部署 Checklist（已執行） 階段 檢查項 確認 時間 確認者 部署前 CAB 核准 ☑ 10/13 15:00 黃資訊 部署前 PostgreSQL Full Backup ☑ 10/15 21:30 趙資料 部署前 Email 通知全公司維護 ☑ 10/15 18:00 PM 部署中 DB Migration (3 scripts) ☑ 10/15 22:05 趙資料 部署中 K8s Deployment 更新 ☑ 10/15 22:15 周維運 部署後 Smoke Test (5/5 Pass) ☑ 10/15 22:30 林品質 部署後 監控 15 分鐘無告警 ☑ 10/15 22:45 周維運 部署後 通知服務恢復 ☑ 10/15 22:50 PM 📌 範本使用注意事項 ...