運維手冊範本(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 {操作名稱}#
| 項目 | 內容 |
|---|
| 操作目的 | {為什麼要做} |
| 執行頻率 | 手動觸發 / 每日 / 每週 / 每月 |
| 預估時間 | {分鐘} |
| 影響範圍 | {影響說明} |
| 所需權限 | {權限} |
步驟:
# Step 1: {說明}
{指令}
# Step 2: {說明}
{指令}
# Step 3: 驗證
{驗證指令}
預期結果:{描述}
注意事項:
📖 使用說明#
- 每個操作程序需為「任何值班人員照著做就能完成」的細緻度
- 指令建議可直接複製貼上執行(含變數說明)
- 常見操作如:重啟服務、清除快取、手動觸發排程、擴縮容
💡 範例#
3.1 重啟 API 服務#
| 項目 | 內容 |
|---|
| 操作目的 | 解決因 Memory Leak 導致的回應緩慢 |
| 執行頻率 | 手動觸發(當 Memory > 90%) |
| 預估時間 | 3 分鐘 |
| 影響範圍 | API 短暫不可用 2-5 秒(Rolling Restart) |
| 所需權限 | AKS Contributor |
步驟:
# Step 1: 確認目前 Pod 狀態
kubectl get pods -n hrms-prod -l app=hrms-api
# Step 2: 執行 Rolling Restart
kubectl rollout restart deployment/hrms-api -n hrms-prod
# Step 3: 等待完成
kubectl rollout status deployment/hrms-api -n hrms-prod --timeout=120s
# Step 4: 驗證所有 Pod 正常
kubectl get pods -n hrms-prod -l app=hrms-api
# 確認 STATUS=Running, READY=1/1, RESTARTS=0
預期結果:所有 Pod 為新版本,Memory 使用率降至 < 50%
3.2 清除 Redis 快取#
| 項目 | 內容 |
|---|
| 操作目的 | 清除過期/錯誤的快取資料 |
| 執行頻率 | 手動觸發 |
| 預估時間 | 1 分鐘 |
| 影響範圍 | 清除後首次存取較慢(Cache Miss) |
| 所需權限 | Redis Data Contributor |
步驟:
# 選項 A: 清除特定 Key Pattern
redis-cli -h hrms-cache.redis.cache.windows.net -p 6380 --tls \
--scan --pattern "hrms:employee:*" | xargs redis-cli DEL
# 選項 B: 清除全部快取(慎用)
redis-cli -h hrms-cache.redis.cache.windows.net -p 6380 --tls FLUSHDB
# 驗證
redis-cli -h hrms-cache.redis.cache.windows.net -p 6380 --tls DBSIZE
3.3 手動擴容 API Pod#
| 項目 | 內容 |
|---|
| 操作目的 | 因應突發流量增加服務實例數 |
| 預估時間 | 2 分鐘 |
| 影響範圍 | 無停機 |
步驟:
# 查看目前 replica 數
kubectl get deployment/hrms-api -n hrms-prod
# 擴容至指定數量(例如 5)
kubectl scale deployment/hrms-api -n hrms-prod --replicas=5
# 確認擴容完成
kubectl rollout status deployment/hrms-api -n hrms-prod
4. 告警處理#
📝 範本#
4.1 告警等級定義#
| 等級 | 名稱 | 定義 | 回應時間 |
|---|
| P1 | Critical | 服務全面中斷,影響所有使用者 | ≤ {分鐘} |
| P2 | High | 核心功能異常,部分使用者受影響 | ≤ {分鐘} |
| P3 | Medium | 非核心功能異常,服務降級 | ≤ {小時} |
| P4 | Low | 效能下降、日誌警告 | 下一工作日 |
4.2 告警處理程序#
告警:{告警名稱}#
| 項目 | 內容 |
|---|
| 告警來源 | {監控工具} |
| 告警條件 | {觸發條件} |
| 告警等級 | P1 / P2 / P3 / P4 |
| 可能原因 | 1. {原因 A} 2. {原因 B} |
處理步驟:
- {診斷步驟}
- {修復步驟}
- {驗證步驟}
升級條件:{何時需要升級至上一層}
📖 使用說明#
- 告警處理是 Runbook 最核心的章節
- 每個告警需有明確的處理流程,值班人員可依 SOP 操作
- 處理步驟需包含:診斷 → 修復 → 驗證 三個階段
- 若無法自行解決,需定義升級路徑與條件
💡 範例#
4.1 告警等級定義#
| 等級 | 名稱 | 定義 | 回應時間 |
|---|
| P1 | Critical | HRMS 服務完全中斷 | ≤ 15 分鐘 |
| P2 | High | 核心功能(請假/薪資)不可用 | ≤ 30 分鐘 |
| P3 | Medium | 報表功能異常、部分頁面緩慢 | ≤ 2 小時 |
| P4 | Low | 日誌 Warning 增加、非尖峰時段效能降低 | 下一工作日 |
告警:API 回應時間 > 500ms (P95)#
| 項目 | 內容 |
|---|
| 告警來源 | Grafana (Prometheus metrics) |
| 告警條件 | http_request_duration_seconds{quantile="0.95"} > 0.5 持續 5 分鐘 |
| 告警等級 | P3 |
| 可能原因 | 1. DB 慢查詢 2. Redis 連線池耗盡 3. 外部 API 逾時 4. Pod 資源不足 |
處理步驟:
# 1. 確認哪些端點慢
kubectl logs -n hrms-prod -l app=hrms-api --tail=100 | grep "slow"
# 2. 檢查 DB 連線狀態
# 查看 Application Insights → Dependencies → 是否有慢查詢
# 3. 檢查 Redis
redis-cli -h hrms-cache... INFO clients
# 確認 connected_clients 是否異常高
# 4. 若為資源不足,擴容
kubectl top pods -n hrms-prod
kubectl scale deployment/hrms-api -n hrms-prod --replicas=5
升級條件:處理 30 分鐘仍未解決,升級至開發 Lead
告警:Pod CrashLoopBackOff#
| 項目 | 內容 |
|---|
| 告警來源 | Kubernetes Event |
| 告警條件 | Pod restart count > 3 in 10 minutes |
| 告警等級 | P2 |
處理步驟:
# 1. 查看異常 Pod
kubectl get pods -n hrms-prod | grep -v Running
# 2. 查看 Pod 事件
kubectl describe pod {pod-name} -n hrms-prod | tail -20
# 3. 查看容器日誌
kubectl logs {pod-name} -n hrms-prod --previous
# 4. 常見原因與處理
# - OOMKilled → 增加 memory limit 或排查 memory leak
# - Config error → 檢查 ConfigMap/Secret 是否正確
# - DB connection refused → 確認 DB 狀態
5. 故障排除決策樹#
📝 範本#
{問題症狀}
├── 檢查 A?
│ ├── 是 → {處理方式 1}
│ └── 否 → 檢查 B?
│ ├── 是 → {處理方式 2}
│ └── 否 → {升級}
📖 使用說明#
- 決策樹幫助值班人員快速定位問題根因
- 從症狀出發,逐步排除可能原因
- 每條路徑最終應導向一個「處理方式」或「升級」
💡 範例#
使用者反映「無法登入」#
使用者無法登入
├── 其他使用者也無法登入?
│ ├── 是(全面性問題)
│ │ ├── API Health Check 正常?
│ │ │ ├── 否 → 重啟 API 服務(見 3.1)
│ │ │ └── 是 → AD 連線正常?
│ │ │ ├── 否 → 聯絡 AD 管理員(見聯絡人表)
│ │ │ └── 是 → 檢查 Redis Session Store
│ │ │ ├── Redis 異常 → 重啟 Redis / 清除 Session
│ │ │ └── Redis 正常 → 升級至開發 Lead
│ └── 否(個別使用者問題)
│ ├── 帳號是否被鎖定?
│ │ ├── 是 → AD 解鎖帳號
│ │ └── 否 → 密碼是否過期?
│ │ ├── 是 → 引導使用者重設密碼
│ │ └── 否 → 確認該使用者在 HRMS 中是否有效
系統回應緩慢#
系統回應緩慢
├── 全部功能都慢,還是特定功能?
│ ├── 全部都慢
│ │ ├── CPU/Memory 是否超過 80%?
│ │ │ ├── 是 → 擴容(見 3.3)
│ │ │ └── 否 → 檢查 DB 連線數是否滿載
│ │ │ ├── 是 → 重啟 API(釋放連線池)
│ │ │ └── 否 → 檢查外部服務回應時間
│ └── 特定功能慢
│ ├── 該功能是否有 DB 查詢?
│ │ ├── 是 → 檢查執行計畫是否有 Full Table Scan
│ │ └── 否 → 檢查外部 API 依賴
6. 緊急聯絡人#
📝 範本#
6.1 內部聯絡人#
| 等級 | 角色 | 姓名 | 電話 | 值班時間 |
|---|
| L1 | 值班工程師 | {姓名} | {電話} | {時間} |
| L2 | 資深工程師 | {姓名} | {電話} | {時間} |
| L3 | 開發 Lead / 架構師 | {姓名} | {電話} | {時間} |
| Mgmt | IT 主管 | {姓名} | {電話} | 重大事件時 |
6.2 外部聯絡人#
| 服務/廠商 | 聯絡方式 | 支援時間 | 合約編號 |
|---|
| {廠商} | {電話/Email} | {時間} | {編號} |
6.3 升級路徑#
| 條件 | 升級對象 | 方式 |
|---|
| L1 處理 {N} 分鐘未解決 | L2 | {方式} |
| L2 處理 {N} 分鐘未解決 | L3 | {方式} |
| P1 事件 | L3 + Mgmt | 立即 |
📖 使用說明#
- 聯絡人清單需保持最新(人員異動時立即更新)
- 值班表建議以月為單位排定
- P1 事件需同時通知管理層,不可等到「處理不了」才升級
💡 範例#
6.1 內部聯絡人#
| 等級 | 角色 | 姓名 | 電話 | 值班時間 |
|---|
| L1 | 值班工程師 | 依值班表 | 見 Teams On-Call 群 | 7x24 |
| L2 | 資深 DevOps | 周維運 | 0933-xxx-xxx | 工作日 09-18 |
| L3 | 架構師 | 吳開發 | 0955-xxx-xxx | 重大事件 |
| Mgmt | IT 副總 | 黃資訊 | 0912-xxx-xxx | P1 事件 |
7. SLA 與 SLO#
📝 範本#
7.1 服務等級目標(SLO)#
| 指標 | 目標 | 計算方式 | 量測週期 |
|---|
| 可用性(Availability) | ≥ {%} | Uptime / Total Time | 月 |
| 回應時間 P95 | ≤ {ms} | 95th percentile | 日 |
| 錯誤率 | ≤ {%} | 5xx / Total Requests | 日 |
| 資料備份 RPO | ≤ {時間} | 最新備份距今 | 即時 |
| 服務恢復 RTO | ≤ {時間} | 停機到恢復 | 每次事件 |
7.2 SLA 違反處理#
| SLO 違反情境 | 處理方式 |
|---|
| 可用性 < {%} | {處理方式} |
| 連續 {N} 天 P95 > {ms} | {處理方式} |
7.3 Error Budget#
| 指標 | 月 Error Budget | 已消耗 | 剩餘 |
|---|
| 可用性 99.9% | 43.2 分鐘/月 | {分鐘} | {分鐘} |
📖 使用說明#
- SLO 為內部營運目標,SLA 為對外承諾(通常 SLO > SLA)
- Error Budget 概念:在未超出 Budget 前可執行風險性變更;Budget 耗盡時凍結變更
- RPO(Recovery Point Objective):可接受的資料遺失時間
- RTO(Recovery Time Objective):可接受的服務恢復時間
💡 範例#
7.1 服務等級目標#
| 指標 | 目標 | 計算方式 | 量測週期 |
|---|
| 可用性 | ≥ 99.9%(月停機 ≤ 43 分鐘) | (1 - downtime/total) × 100% | 月 |
| API P95 回應時間 | ≤ 200ms | Prometheus histogram | 日 |
| Error Rate (5xx) | ≤ 0.1% | 5xx responses / total | 日 |
| RPO | ≤ 1 小時 | 最新備份距今 | 即時 |
| RTO | ≤ 4 小時 | 停機至恢復 | 每次事件 |
8. 維護窗口與排程作業#
📝 範本#
8.1 定期維護窗口#
| 維護類型 | 排程 | 時段 | 影響 | 通知方式 |
|---|
| {類型} | {頻率} | {時段} | {影響} | {通知} |
8.2 排程作業(Scheduled Jobs)#
| 作業名稱 | 排程 (Cron) | 用途 | 預估耗時 | 失敗處理 |
|---|
| {作業} | {cron 表達式} | {用途} | {時間} | {處理} |
8.3 排程作業監控#
| 作業名稱 | 成功指標 | 失敗告警 | 逾時設定 |
|---|
| {作業} | {指標} | {告警方式} | {逾時} |
📖 使用說明#
- 維護窗口需事先公告,減少對使用者的影響
- 排程作業需有監控,確保失敗時能及時發現
- 每個排程作業需定義「失敗時該怎麼辦」
💡 範例#
8.2 排程作業#
| 作業名稱 | 排程 (Cron) | 用途 | 預估耗時 | 失敗處理 |
|---|
| 薪資月結計算 | 0 2 1 * *(每月 1 日 02:00) | 計算上月薪資 | 45 分鐘 | 告警 → 手動排查 → 重跑 |
| 假額年度重置 | 0 0 1 1 *(每年 1/1 00:00) | 重置年度假額 | 10 分鐘 | P2 告警 → DBA 協助 |
| 資料庫備份 | 0 */6 * * *(每 6 小時) | Full Backup | 15 分鐘 | P2 告警 → DevOps 處理 |
| 日誌歸檔 | 0 3 * * *(每日 03:00) | 壓縮 7 天前日誌 | 5 分鐘 | P4,隔日處理 |
| AD 同步 | */30 * * * *(每 30 分鐘) | 同步員工資料 | 2 分鐘 | 3 次失敗告警 |
9. 備份與還原#
📝 範本#
9.1 備份策略#
| 資料類型 | 備份方式 | 頻率 | 保留天數 | 儲存位置 |
|---|
| {類型} | {全量/增量} | {頻率} | {天數} | {位置} |
9.2 還原程序#
| 步驟 | 操作 | 指令 | 預估時間 |
|---|
| 1 | {操作} | {指令} | {時間} |
| 2 | {操作} | {指令} | {時間} |
9.3 還原驗證#
9.4 備份驗證排程#
| 驗證類型 | 頻率 | 方式 | 負責人 |
|---|
| 備份完整性 | {頻率} | {方式} | {姓名} |
| 還原演練 | {頻率} | {方式} | {姓名} |
📖 使用說明#
- 備份必須定期驗證(未驗證的備份等於沒有備份)
- 還原演練建議每季執行一次,確認 RTO 達標
- 備份儲存位置需與主系統不同區域(異地備份)
💡 範例#
9.1 備份策略#
| 資料類型 | 備份方式 | 頻率 | 保留天數 | 儲存位置 |
|---|
| PostgreSQL | Azure Automated Backup (Full) | 每日 | 35 天 | Azure LRS → GRS |
| PostgreSQL | Point-in-Time Recovery (PITR) | 連續 | 7 天 | Azure |
| Redis | RDB Snapshot | 每 6 小時 | 7 天 | Azure Blob Storage |
| 應用程式設定 | Git (IaC) | 每次變更 | 永久 | Azure DevOps Repo |
| 檔案儲存 | Azure Blob Versioning | 即時 | 90 天 | Azure GRS |
9.2 還原程序(PostgreSQL PITR)#
| 步驟 | 操作 | 指令 | 預估時間 |
|---|
| 1 | 選擇還原時間點 | Azure Portal → PostgreSQL → Restore | 1 分鐘 |
| 2 | 建立還原伺服器 | 還原至新伺服器 hrms-db-restore | 30-60 分鐘 |
| 3 | 驗證資料正確性 | 連線新伺服器確認資料 | 10 分鐘 |
| 4 | 切換連線字串 | 更新 K8s Secret 指向新 DB | 5 分鐘 |
| 5 | 重啟應用程式 | kubectl rollout restart | 3 分鐘 |
10. 附錄#
📝 範本#
10.1 常用指令速查表#
10.2 環境變數清單#
| 變數名稱 | 用途 | 來源 |
|---|
| {變數} | {用途} | ConfigMap / Secret / Environment |
10.3 已知問題與 Workaround#
| 問題 | 影響 | Workaround | 預計修復 |
|---|
| {問題} | {影響} | {處理方式} | {時程} |
📖 使用說明#
- 速查表方便值班人員快速找到常用指令
- 已知問題記錄避免重複排查相同問題
- 環境變數清單幫助理解系統設定
💡 範例#
10.1 常用指令速查表#
| 用途 | 指令 |
|---|
| 查看所有 Pod | kubectl get pods -n hrms-prod |
| 查看 Pod 日誌 | kubectl logs -f {pod} -n hrms-prod |
| 進入 Pod Shell | kubectl exec -it {pod} -n hrms-prod -- /bin/sh |
| 查看資源使用 | kubectl top pods -n hrms-prod |
| 查看 HPA 狀態 | kubectl get hpa -n hrms-prod |
| 查看 Ingress | kubectl get ingress -n hrms-prod |
| DB 連線測試 | psql -h hrms-db... -U hrms_app -d hrmsdb -c "SELECT 1" |
| Redis 連線測試 | redis-cli -h hrms-cache... -p 6380 --tls PING |
10.3 已知問題#
| 問題 | 影響 | Workaround | 預計修復 |
|---|
| 薪資報表匯出超過 5000 筆會逾時 | 少數使用者 | 分批匯出或使用篩選條件 | v1.1.0 |
| AD 同步偶爾超時(每月 1-2 次) | 新員工延遲出現 | 手動觸發同步作業 | 調查中 |
📌 範本使用注意事項
- 本範本依據 ITIL 4 Service Operation 與 ISO/IEC 20000-1:2018 編製
- Runbook 為活文件,每次系統變更需同步更新
- 建議納入 Git 版本控制,追蹤變更歷程
- 新進維運人員應以本文件作為入門參考
- 搭配「部署指南範本」使用,構成完整的部署與維運文件體系