SSDLC

監控與告警設定文件範本（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 系統架構圖（退役前） [附上退役系統目前的架構圖，標示將移除的元件] ...

資料庫設計文件範本（Database Design Document Template） 適用標準：ISO/IEC 11179（Metadata Registries）、DAMA DMBOK 2.0、ISO/IEC/IEEE 42010:2022 適用階段：系統設計階段（Design Phase） 負責角色：系統架構師（SA）、資料庫管理師（DBA） 📑 章節目錄 文件資訊 資料庫架構概觀 實體關聯模型（ER Diagram） 資料表設計 索引設計策略 資料關聯與完整性約束 命名規範 資料治理與安全 效能設計考量 資料遷移與版本控制 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 資料庫設計文件 文件編號 [專案代碼]-DBD-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 最後更新 [YYYY-MM-DD] 撰寫者 [SA/DBA 姓名] 審核者 [技術主管/架構師] 核准者 [專案經理] 版本歷程 版本 日期 修改人 修改內容 v1.0 [YYYY-MM-DD] [姓名] 初版發布 關聯文件 文件名稱 文件編號 關係 系統架構文件（SAD） [編號] 上游輸入 功能需求文件（FRD） [編號] 需求來源 API 規格文件 [編號] 介面對應 2. 資料庫架構概觀 2.1 資料庫技術選型 項目 選擇 說明 RDBMS [PostgreSQL / SQL Server / MySQL] [選型原因] 版本 [版本號] 部署模式 [Single / Primary-Replica / Cluster] [HA 需求] 字元集 [UTF-8 / UTF-16] 排序規則 [Collation] 2.2 資料庫實例配置 實例名稱 用途 主機 連接埠 備註 [DB_MAIN] 主要業務資料 [hostname] [port] Primary [DB_READ] 讀取副本 [hostname] [port] Read Replica [DB_ARCHIVE] 歷史資料歸檔 [hostname] [port] Archive 2.3 Schema 架構 [Database] ├── schema: core -- 核心業務資料表 ├── schema: auth -- 認證授權相關 ├── schema: audit -- 稽核軌跡 ├── schema: staging -- ETL 暫存區 └── schema: archive -- 歷史歸檔 3. 實體關聯模型（ER Diagram） 3.1 概念層 ERD（Conceptual ER Diagram） 呈現主要實體（Entity）之間的高階關係，不含欄位細節。 ...

資料遷移計畫範本（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] ...

需求異動申請表範本（Change Request Template） 適用標準：ISO/IEC/IEEE 15288:2023（系統生命週期）、ITIL 4 Change Management、CMMI 適用階段：需求分析階段 / 全生命週期（Requirements Phase / Cross-Phase） 負責角色：業務分析師（BA）、專案經理（PM）、變更管理委員會（CCB） 📑 章節目錄 變更申請資訊 變更描述 影響分析 變更方案 審核與決議 實施追蹤 變更驗收 📝 範本 1. 變更申請資訊 項目 內容 變更編號 CR-[YYYY]-[NNN] 申請日期 [YYYY-MM-DD] 申請人 [姓名 / 部門] 專案名稱 [專案名稱] 變更類型 [需求變更 / 設計變更 / 範圍變更 / 缺陷修正] 優先級 [Critical / High / Medium / Low] 緊急程度 [緊急 / 一般] 目前狀態 [Draft / Submitted / Under Review / Approved / Rejected / Implementing / Completed / Cancelled] 2. 變更描述 2.1 變更摘要 項目 內容 變更標題 [一句話描述變更內容] 變更原因 [為什麼需要這個變更] 業務背景 [觸發變更的業務情境或事件] 2.2 現行需求（As-Is） 需求編號 需求描述 文件來源 [REQ-NNN] [目前的需求描述] [BRD/FRD §N.N] 2.3 變更後需求（To-Be） 需求編號 變更後描述 變更差異摘要 [REQ-NNN] [修改後的需求描述] [新增/修改/刪除了什麼] 2.4 相關附件 附件名稱 說明 [附件1] [UI 原型 / 流程圖 / 規格書片段] 3. 影響分析 3.1 影響範圍評估 影響面向 受影響項目 影響程度 說明 功能模組 [受影響的模組清單] [High/Medium/Low] 資料庫 [Schema / Table 異動] [High/Medium/Low] API 介面 [受影響的 API] [High/Medium/Low] UI 畫面 [受影響的頁面] [High/Medium/Low] 外部系統 [受影響的介接系統] [High/Medium/Low] 文件 [需更新的文件] [High/Medium/Low] 測試案例 [需新增/修改的測試] [High/Medium/Low] 3.2 時程影響 項目 原定日期 變更後日期 延遲天數 [里程碑1] [YYYY-MM-DD] [YYYY-MM-DD] [N] days 上線日期 [YYYY-MM-DD] [YYYY-MM-DD] [N] days 3.3 成本影響 成本項目 追加工時（人天） 追加費用 說明 開發 [N] 人天 [金額] 測試 [N] 人天 [金額] 設計 [N] 人天 [金額] 其他 [N] 人天 [金額] 合計 [N] 人天 [金額] 3.4 風險評估 風險 ID 風險描述 發生機率 影響程度 緩解措施 R-1 [風險描述] [High/Med/Low] [High/Med/Low] [措施] 4. 變更方案 4.1 建議方案 項目 內容 方案說明 [概述如何實施此變更] 實施步驟 1. [步驟1]2. [步驟2]3. [步驟3] 需要資源 [人力/環境/工具] 預計工期 [N] 個工作天 測試範圍 [需要回歸測試的範圍] 4.2 替代方案（如有） 方案 說明 工時 優點 缺點 方案 A [說明] [N] 天 [優點] [缺點] 方案 B [說明] [N] 天 [優點] [缺點] 5. 審核與決議 5.1 審核記錄 審核者 角色 審核日期 決議 意見 [姓名] PM [YYYY-MM-DD] [Approve/Reject/Defer] [意見] [姓名] Tech Lead [YYYY-MM-DD] [Approve/Reject/Defer] [意見] [姓名] Business Owner [YYYY-MM-DD] [Approve/Reject/Defer] [意見] 5.2 CCB 決議 項目 內容 會議日期 [YYYY-MM-DD] 最終決議 [Approved / Rejected / Deferred / Need More Info] 核准條件 [附帶條件，如有] 預計實施版本 [Release / Sprint] 6. 實施追蹤 6.1 實施任務 任務 ID 任務描述 負責人 預計完成 實際完成 狀態 T-1 [修改設計文件] [姓名] [日期] [日期] [Done/In Progress/TODO] T-2 [修改程式碼] [姓名] [日期] [日期] [Done/In Progress/TODO] T-3 [更新測試案例] [姓名] [日期] [日期] [Done/In Progress/TODO] T-4 [執行回歸測試] [姓名] [日期] [日期] [Done/In Progress/TODO] 6.2 文件更新追蹤 文件名稱 更新內容 更新人 更新日期 狀態 [BRD / FRD / SAD] [章節 N.N] [姓名] [日期] [Done/Pending] 7. 變更驗收 項目 內容 驗收日期 [YYYY-MM-DD] 驗收人 [申請人 / Business Owner] 驗收結果 [Pass / Fail / Conditional Pass] 備註 [驗收意見] 📖 使用說明 變更管理流程 graph LR A[申請提出] --> B[影響分析] B --> C[CCB 審核] C -->|Approved| D[排入計畫] C -->|Rejected| E[結案通知] C -->|Deferred| F[暫緩追蹤] D --> G[實施變更] G --> H[驗證測試] H --> I[驗收結案] 各章節填寫指引 章節 填寫時機 負責人 重點說明 §1 申請資訊 提出申請時 申請人 正確分類與設定優先級 §2 變更描述 提出申請時 申請人/BA As-Is / To-Be 需明確對比 §3 影響分析 評估階段 SA/PM 需跨團隊協作評估 §4 變更方案 評估階段 SA/Tech Lead 提供可行方案供 CCB 決策 §5 審核決議 CCB 會議後 PM 記錄完整決議與附帶條件 §6 實施追蹤 實施期間 PM 追蹤每個任務進度 §7 驗收 實施完成後 申請人/QA 確認變更符合預期 優先級與緊急程度定義 優先級 定義 SLA Critical 阻擋上線/嚴重業務影響 24 hr 內決議 High 重大功能缺失 3 工作天內決議 Medium 功能改善/優化 7 工作天內決議 Low 可延後的改善建議 下次 Sprint Planning 討論 💡 範例（以 HRMS 人力資源管理系統為例） 範例：變更申請 項目 內容 變更編號 CR-2026-015 申請日期 2026-04-10 申請人 李美玲 / 人力資源部 專案名稱 HRMS 人力資源管理系統 變更類型 需求變更 優先級 High 緊急程度 一般 範例：變更描述 變更標題： 新增「彈性工時」假別類型與計算邏輯 ...

非功能性需求設計規格範本（NFR Design Specification Template） 適用標準：ISO/IEC 25010:2023（SQuaRE - 系統與軟體品質模型）、ISO/IEC/IEEE 29148:2018 適用階段：系統設計階段（Design Phase） 負責角色：系統架構師（SA）、效能工程師、SRE 📑 章節目錄 文件資訊 品質屬性總覽 效能設計（Performance） 可用性設計（Availability） 延展性設計（Scalability） 可靠性設計（Reliability） 可維護性設計（Maintainability） 可觀測性設計（Observability） 安全性設計（Security） 相容性設計（Compatibility） 驗證與測試策略 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 非功能性需求設計規格 文件編號 [專案代碼]-NFR-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 撰寫者 [SA 姓名] 審核者 [技術主管] 2. 品質屬性總覽 依 ISO/IEC 25010:2023 品質模型分類 品質屬性 子特性 目標等級 優先級 驗證方式 效能效率 時間行為、資源利用、容量 [目標] [High/Med/Low] [效能測試] 可用性 成熟度、容錯性、可恢復性 [目標] [High/Med/Low] [HA 測試] 延展性 水平/垂直擴展能力 [目標] [High/Med/Low] [負載測試] 可靠性 容錯、一致性 [目標] [High/Med/Low] [Chaos 測試] 可維護性 模組化、可測試性、可修改性 [目標] [High/Med/Low] [Code Review] 安全性 機密性、完整性、可用性 [目標] [High/Med/Low] [安全測試] 相容性 瀏覽器、裝置、整合 [目標] [High/Med/Low] [相容測試] 3. 效能設計（Performance） 3.1 效能目標 指標 日常目標 尖峰目標 測量方式 回應時間（P50） < [N]ms < [N]ms APM / Load test 回應時間（P95） < [N]ms < [N]ms APM / Load test 回應時間（P99） < [N]ms < [N]ms APM / Load test 吞吐量（TPS） ≥ [N] ≥ [N] Load test 並發用戶 [N] [N] Load test 錯誤率 < [N]% < [N]% Monitoring 3.2 效能設計策略 策略 適用場景 設計方案 快取 [高頻讀取、低頻更新] [快取層級/策略/TTL] 非同步處理 [非即時、耗時任務] [Message Queue + Worker] 連接池 [DB/HTTP 連線] [Pool size + timeout 設定] 分頁查詢 [大量資料列表] [Cursor-based / Offset pagination] 批次處理 [大量寫入] [Batch size + 排程策略] CDN [靜態資源] [CDN provider + cache policy] 3.3 效能預算（Performance Budget） 資源 預算 目前值 狀態 首頁載入（FCP） < [N]s [N]s [✅/⚠️/❌] 最大內容繪製（LCP） < [N]s [N]s [✅/⚠️/❌] 累計版面偏移（CLS） < [N] [N] [✅/⚠️/❌] 互動至下一次繪製（INP） < [N]ms [N]ms [✅/⚠️/❌] JS Bundle Size < [N]KB [N]KB [✅/⚠️/❌] API Response Size < [N]KB (avg) [N]KB [✅/⚠️/❌] 4. 可用性設計（Availability） 4.1 SLA 定義 服務 SLA 目標 允許停機/月 計算方式 [核心服務] [99.9%] [~43.8 min] Uptime / Total time [次要服務] [99.5%] [~3.6 hr] [背景服務] [99.0%] [~7.3 hr] 4.2 高可用設計 元件 HA 模式 Failover 時間 健康檢查 [元件] [Active-Active / Active-Passive / N+1] [N]s [HTTP/TCP/Custom] 4.3 停機策略 停機類型 通知時間 持續時間 影響範圍 核准 計畫性維護 [N 天前] [N hr] [描述] [PM/業務] 緊急修復 [即時] [N hr] [描述] [Tech Lead] 5. 延展性設計（Scalability） 5.1 擴展策略 維度 策略 設計 水平擴展（Scale-Out） [無狀態 + Load Balancer] [Auto-scaling rules] 垂直擴展（Scale-Up） [資料庫 / 特殊運算] [上限與遷移計畫] 資料擴展 [分區 / Sharding] [分區策略] 5.2 容量規劃 時間軸 預估用戶 預估資料量 預估 TPS 對應架構 上線 [N] [N] GB [N] [架構描述] 6 個月 [N] [N] GB [N] [是否需擴展] 1 年 [N] [N] GB [N] [擴展方案] 3 年 [N] [N] GB [N] [重大架構變更?] 6. 可靠性設計（Reliability） 6.1 容錯設計 故障場景 影響 容錯機制 降級方案 [單節點故障] [描述] [自動 failover] [N/A] [DB 連線失敗] [描述] [Circuit Breaker] [顯示快取資料] [外部 API 超時] [描述] [Retry + Timeout] [預設值/離線模式] [整個 AZ 故障] [描述] [Multi-AZ 部署] [部分功能降級] 6.2 Circuit Breaker 設計 服務 Open 條件 Half-Open 條件 Close 條件 Fallback [服務] [N 次失敗 in M 秒] [N 秒後] [N 次成功] [降級方案] 6.3 Retry 策略 場景 最大重試 退避策略 可重試條件 [HTTP call] [N] 次 [Exponential backoff + jitter] [5xx, timeout, network error] [DB operation] [N] 次 [Fixed interval] [Deadlock, connection lost] 7. 可維護性設計（Maintainability） 品質指標 目標 度量方式 程式碼覆蓋率 ≥ [N]% [CI/CD report] 技術債指標 [SQALE ≤ N days] [SonarQube] 模組耦合度 [低耦合] [Architecture fitness test] 部署頻率 [≥ N 次/週] [CI/CD metrics] 修復前置時間 [< N hr] [DORA metrics] 8. 可觀測性設計（Observability） 8.1 三大支柱 支柱 工具 設計 Metrics [Prometheus / CloudWatch] [RED + USE metrics] Logging [ELK / Loki] [Structured JSON, correlation ID] Tracing [Jaeger / Zipkin / OTEL] [Distributed tracing, 100% sampling for errors] 8.2 SLI/SLO 定義 SLI（指標） SLO（目標） 計算方式 告警閾值 Availability [99.9%] successful requests / total requests < 99.8% → Warning Latency (P95) [< 200ms] histogram_quantile(0.95) > 300ms → Warning Error Rate [< 0.1%] 5xx / total requests > 1% → Critical Throughput [≥ N TPS] rate(requests_total[5m]) < N*0.7 → Warning 9. 安全性設計（Security） 詳見安全設計文件（SecurityDesign_Template.md），此處僅摘要 NFR 指標 ...