運維手冊範本(Runbook)

參照標準:ITIL 4 Service Operation / ISO/IEC 20000-1:2018 第 8.5 節「Service delivery」
文件用途:提供系統日常維運、告警處理、故障排除的標準化操作程序
適用階段:營運維護階段(Operations & Maintenance)


📋 章節目錄

  1. 文件資訊
  2. 系統概述
  3. 常見操作程序
  4. 告警處理
  5. 故障排除決策樹
  6. 緊急聯絡人
  7. SLA 與 SLO
  8. 維護窗口與排程作業
  9. 備份與還原
  10. 附錄

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 APIAKS hrms-prod nshttps://hrms-api.internal:443後端 API
hrms-webReact 18 + NginxAKS hrms-prod nshttps://hrms.company.com前端 SPA
hrms-worker.NET 8 Worker ServiceAKS hrms-prod nsN/A(內部處理)背景排程任務
PostgreSQLv16Azure DB for PostgreSQLhrms-db.postgres.database.azure.com:5432主資料庫
Redisv7Azure Cache for Redishrms-cache.redis.cache.windows.net:6380Session + Cache

3. 常見操作程序

📝 範本

3.1 {操作名稱}

項目內容
操作目的{為什麼要做}
執行頻率手動觸發 / 每日 / 每週 / 每月
預估時間{分鐘}
影響範圍{影響說明}
所需權限{權限}

步驟:

# Step 1: {說明}
{指令}

# Step 2: {說明}
{指令}

# Step 3: 驗證
{驗證指令}

預期結果:{描述}

注意事項

  • {注意 1}
  • {注意 2}

📖 使用說明

  • 每個操作程序需為「任何值班人員照著做就能完成」的細緻度
  • 指令建議可直接複製貼上執行(含變數說明)
  • 常見操作如:重啟服務、清除快取、手動觸發排程、擴縮容

💡 範例

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 告警等級定義

等級名稱定義回應時間
P1Critical服務全面中斷,影響所有使用者≤ {分鐘}
P2High核心功能異常,部分使用者受影響≤ {分鐘}
P3Medium非核心功能異常,服務降級≤ {小時}
P4Low效能下降、日誌警告下一工作日

4.2 告警處理程序

告警:{告警名稱}
項目內容
告警來源{監控工具}
告警條件{觸發條件}
告警等級P1 / P2 / P3 / P4
可能原因1. {原因 A} 2. {原因 B}

處理步驟:

  1. {診斷步驟}
  2. {修復步驟}
  3. {驗證步驟}

升級條件:{何時需要升級至上一層}


📖 使用說明

  • 告警處理是 Runbook 最核心的章節
  • 每個告警需有明確的處理流程,值班人員可依 SOP 操作
  • 處理步驟需包含:診斷 → 修復 → 驗證 三個階段
  • 若無法自行解決,需定義升級路徑與條件

💡 範例

4.1 告警等級定義

等級名稱定義回應時間
P1CriticalHRMS 服務完全中斷≤ 15 分鐘
P2High核心功能(請假/薪資)不可用≤ 30 分鐘
P3Medium報表功能異常、部分頁面緩慢≤ 2 小時
P4Low日誌 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 / 架構師{姓名}{電話}{時間}
MgmtIT 主管{姓名}{電話}重大事件時

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重大事件
MgmtIT 副總黃資訊0912-xxx-xxxP1 事件

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 回應時間≤ 200msPrometheus 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 Backup15 分鐘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 備份策略

資料類型備份方式頻率保留天數儲存位置
PostgreSQLAzure Automated Backup (Full)每日35 天Azure LRS → GRS
PostgreSQLPoint-in-Time Recovery (PITR)連續7 天Azure
RedisRDB 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 → Restore1 分鐘
2建立還原伺服器還原至新伺服器 hrms-db-restore30-60 分鐘
3驗證資料正確性連線新伺服器確認資料10 分鐘
4切換連線字串更新 K8s Secret 指向新 DB5 分鐘
5重啟應用程式kubectl rollout restart3 分鐘

10. 附錄

📝 範本

10.1 常用指令速查表

用途指令
{用途}{指令}

10.2 環境變數清單

變數名稱用途來源
{變數}{用途}ConfigMap / Secret / Environment

10.3 已知問題與 Workaround

問題影響Workaround預計修復
{問題}{影響}{處理方式}{時程}

📖 使用說明

  • 速查表方便值班人員快速找到常用指令
  • 已知問題記錄避免重複排查相同問題
  • 環境變數清單幫助理解系統設定

💡 範例

10.1 常用指令速查表

用途指令
查看所有 Podkubectl get pods -n hrms-prod
查看 Pod 日誌kubectl logs -f {pod} -n hrms-prod
進入 Pod Shellkubectl exec -it {pod} -n hrms-prod -- /bin/sh
查看資源使用kubectl top pods -n hrms-prod
查看 HPA 狀態kubectl get hpa -n hrms-prod
查看 Ingresskubectl 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 次)新員工延遲出現手動觸發同步作業調查中

📌 範本使用注意事項

  1. 本範本依據 ITIL 4 Service Operation 與 ISO/IEC 20000-1:2018 編製
  2. Runbook 為活文件,每次系統變更需同步更新
  3. 建議納入 Git 版本控制,追蹤變更歷程
  4. 新進維運人員應以本文件作為入門參考
  5. 搭配「部署指南範本」使用,構成完整的部署與維運文件體系