SRE 維運方法論：從盤點到交接的六階段框架

「我們公司也想做 SRE / DevOps，要從哪裡開始？」這是我接諮詢時最常被問的問題。答案不是「先導 Kubernetes」，而是「先有方法論」。

工具會過時、技術會迭代，但怎麼維運一個系統的思維框架不會。本文整理我自己用了 5 年以上、跑過從新創到中型企業的維運方法，拆成六個階段，每個階段都含可執行清單。

階段一、盤點（Discovery）

核心問題：你不能維運你不認識的系統。

接手任何環境的第一週，先別碰任何 production 設定。先做盤點。

必做清單

系統清單：記下每個服務的名稱、用途、技術棧、最後更新時間、Owner
流量地圖：每個服務的入口（用戶請求 / 內部呼叫 / cron job）、每秒請求量、95p latency
依賴關係：誰依賴誰？關鍵路徑上有幾跳？哪個是單點故障？
資料流：寫入路徑、備份路徑、保存週期、資料分級（Public / Internal / Confidential / Restricted）
風險地圖：哪些服務掛了會直接損失營收？哪些 24h 內可以容忍？
權限與帳號：誰有 prod 寫入權限、誰是 break-glass、是否有 audit log

常見地雷

影子 IT：行銷部門偷偷部署的工具、業務部門用的 SaaS、十年前 RD 個人帳號跑的服務
遺忘的 cron job：某個 EC2 上每天凌晨 3 點跑的腳本，沒人記得作用
退休員工的單點知識：「這個系統只有 Alex 知道怎麼重開」

產出物

一份可分享的系統清單（建議用 Notion / Confluence / git-managed markdown）
風險矩陣（Severity × Likelihood）
「不知道」清單（盤點過程中發現的盲點）

階段二、設計（Design）

核心問題：未來 1-3 年的規模，現在的架構撐得住嗎？

盤點完後，開始判斷哪些要重構、哪些可以先撐。

必做清單

容量規劃：未來 12 個月預期成長率 × 現有 utilization → 必要擴容時點
冗餘策略：哪些服務需要 multi-region？哪些單 AZ 夠用？這跟營收影響度直接掛鉤
失效模式分析：每個元件可能怎麼壞？依賴它的服務會怎麼樣？（這就是 FMEA）
資料一致性決策：哪些地方接受 eventual consistency？哪些必須強一致？
安全邊界：對外網路、對內網路、特權網路怎麼劃分？預設 deny 還是 allow？

常見地雷

過度設計：為了未來擔心的「百萬 QPS」，用 Kubernetes 跑只有 100 QPS 的服務
不足設計：以為流量永遠這麼少，沒做 read replica、結果第一次行銷活動掛全站
資料庫遷移最後才考慮：發現 schema 是壞的，已經 5TB 資料

產出物

架構決策紀錄（ADR）：每個關鍵決策一份 markdown，記錄選擇與理由
容量規劃試算（Excel / Google Sheet 都行）
失效模式列表

階段三、部署（Deploy）

核心問題：每次發布都是冒險，怎麼讓冒險變成常規？

部署是 SRE / DevOps 工作中最頻繁的動作，所以最值得自動化。

必做清單

版本控制：所有部署設定（Dockerfile / Terraform / k8s YAML / CI 設定）都進 git
不可變基礎設施：禁止 SSH 進去手改設定。要改，改 git → CI → 重部署
多環境：至少 dev / staging / prod 三層，staging 與 prod 設定要 diff < 5%
發布策略：Blue-green / Canary / Rolling，依風險選擇
回滾路徑：每次部署都要能 30 秒內回到上一版（最簡單：CF Pages / Vercel / k8s rollout undo）
發布時段：避開高峰、避開週五下午、有人在的時段

常見地雷

「先上 prod 看看」：沒測過直接推
手動操作沒紀錄：DBA 直接 mysql> ALTER TABLE...，沒進 migration 工具
Rollback 沒練過：理論上能回，實際上沒人試過

產出物

部署 runbook（自動化能做的盡量自動，不能的列步驟）
發布 checklist（每次部署要問的 5 個問題）

階段四、監控（Monitor）

核心問題：系統壞了，誰先知道？是你還是客戶？

三支柱

Metrics：時間序列數字（CPU / Memory / QPS / Latency）— Prometheus / CloudWatch / Datadog
Logs：結構化文字事件（請求 log / 錯誤 stack trace）— Loki / ELK / Cloudflare Logs
Traces：跨服務請求追蹤（誰呼叫了誰）— Jaeger / Tempo / OpenTelemetry

SLI / SLO / SLA

SLI（Service Level Indicator）：實際測量值，如「P95 latency = 250ms」
SLO（Service Level Objective）：內部目標，如「99% 請求 P95 < 300ms」
SLA（Service Level Agreement）：對客戶的合約承諾，通常比 SLO 寬鬆

設計訣竅：SLI 必須能直接告訴你「客戶看到什麼」。CPU 99% 但客戶請求都正常，那是健康的。

Alert 設計

黃金原則：每個 alert 都要對應一個可執行的動作。不能執行就不要 alert（不然只是 noise）
分層：P1（立刻起床）、P2（隔天上班看）、P3（每週彙整）
避免 alert 疲勞：alert too noisy → 工程師會自動忽略，等於沒監控

產出物

每個服務一份 SLO 文件（指標、目標、誤差預算）
Alert runbook（收到這個 alert 怎麼辦）
戰情室 dashboard（高階主管看的、工程師看的兩套）

階段五、應變（Respond）

核心問題：incident 發生時，是「演練過」還是「現場學」？

Incident Response 結構

Incident Commander（IC）：指揮者，不寫 code，負責協調與決策
Tech Lead：實際操作的人，由 IC 指派
Communications Lead：對內對外溝通，避免 IC 被打擾
Scribe：記錄時間軸與決策

個人接案 / 小團隊版本：一個人扮多角，但要明確切換角色（避免「我又指揮又動手又回客戶訊息」）

Severity 分級

Severity	定義	回應時間
SEV-1	完全 down 或重大資料外洩	立即（含半夜）
SEV-2	部分功能 down 或顯著降速	1 小時
SEV-3	小範圍 bug，不影響核心	隔天

Post-Mortem 文化

Blameless：對事不對人。不是「Alex 推錯版本」，而是「我們的部署流程沒有阻擋這類錯誤」
5 Whys：每個 root cause 至少問 5 次「為什麼」
Action Items：每個 PM 都要產出可追蹤的改善項目，且 30 天內完成
Learning Review：對團隊分享，避免重蹈覆轍

產出物

Incident response runbook
Post-mortem 模板
月度 / 季度 incident review

階段六、交接（Handoff）

核心問題：明天你不在了，這套系統還能跑嗎？

必做清單

Runbook：每個常見操作都有「step by step」文件，不依賴口頭傳承
Onboarding：新人第一週讀什麼、第二週做什麼、第一個月可以單獨值班嗎？
權限交接：員工離職前，明確 checklist 撤銷哪些權限
單點知識消解：哪些事只有一個人會？要 pair / shadow / 寫文件

常見地雷

「文件後面再寫」：永遠不會寫
「KT 一次就好」：學的人沒記住，教的人沒留下
退休員工的密碼還沒撤：3 個月後出事

產出物

每個服務的 Runbook
Onboarding checklist
員工離職 checklist

結語：方法論不是 SOP

這份方法論不是用來照本宣科的 SOP — 是用來對齊團隊認知的框架。每個階段的具體做法會因為團隊規模、產業性質、預算而不同，但思考的維度是共通的。

如果你的團隊正在從「沒有方法論」往「有方法論」走，建議的優先順序：

盤點（最低成本、最高 leverage）
應變（incident 來了就會痛，痛了就會學）
部署（每天都做，最值得自動化）
監控（沒監控的維運是賭博）
設計（重大改動才用得到）
交接（看似最後，但其實平時就在做）

想討論你的維運挑戰？

如果你的團隊在某個階段卡住，歡迎免費諮詢 30 分鐘。我會根據你的實際狀況，給出可執行的下一步建議。

此方法論 v1 持續更新中。Roadmap：v1.1 加 Toil 量化、v1.2 加 ChatOps、v1.3 加 AI-augmented 維運。