SDLC 與 SRE 的契合#
軟體開發生命週期（Software Development Lifecycle, SDLC）是一套提供開發者、測試者、需求分析師、設計師與支援工程師協作的流程框架。SDLC 起源於 1960 年代，幫助團隊以模型化的方式建構與交付大型系統。
從瀑布到敏捷#
- 瀑布模型（Waterfall）：線性流程，每個階段依賴前一階段產出；適合需求穩定的小型系統
- 隨著雲端興起與需求快速變化，瀑布模式無法跟上市場節奏
- 敏捷方法論（Agile methodology） 因此成為主流；雖然 Agile 早在 1970 年代就被提出，卻直到 2009 年前後才被廣泛採用
- 今日 SDLC 普遍採用敏捷，強調持續協作、持續溝通與持續改進
SRE 原則與 Agile 高度契合。SRE 在 Agile 流程下能充分發揮，協助組織建立穩健的開發與交付體系。
Figure 1.1: Waterfall SDLC model
Figure 1.2: Agile methodology in SDLC
SRE 的傳統位置：交付後的維運#
最常見的誤解是把 SRE 當成只在最後階段才登場的角色。在許多組織裡，這個階段被稱為「支援」、「監控」、「維護」或「運維」階段。SRE 在這裡的工作包括：
- 接手並擁有正式環境（production）軟體應用
- 觀察程式行為是否符合預期
- 處理使用者投訴與技術工單
- 評估基礎設施是否撐得住負載
- 開發各種工具、控制與能力，協助開發者順利發布並提早抓出問題
範例：電商網站的支付服務#
想像 production 監控告警顯示支付服務間歇性丟出 HTTP 500，雖無客戶投訴，SRE 已透過主動監控發現異常。SRE 第一時間排查、定位原因，必要時將問題交回開發者修復。
這種「先客戶一步發現問題」的能力，是 SRE 投入監控與工具開發的直接成果。
SRE 的進階角色：從規劃到測試全程涉入#
雖然 SRE 看似落在 Agile 流程末端，但實務上越成熟的組織越會讓 SRE 從最一開始就介入：
- 提供正式環境（production）的真實流量、擴充、容錯、負載平衡與資料複寫等資訊
- 協助業務分析師與設計師建立貼近真實的應用視角
- 在規劃、設計、測試三階段提早抓出技術風險
案例：搜尋模組的隱藏負載問題#
一個搜尋模組在 QA 測試時只有單次失敗，原本被視為可忽略。SRE 介入後提供了「每日存取人次」資料並執行負載與混沌測試（chaos testing），結果顯示模組無法承受真實流量。最終 QA、SRE 與開發團隊共同決定擴充伺服器並重寫輕量化查詢，避免了上線後的大規模故障。
Figure 1.3: SRE involvement in various phases of Agile
SRE 在 Agile 各階段的具體職責#
下列為 SRE 在 Agile 各階段的常見任務分工：
- 規劃（Plan）：分析師捕捉需求；SRE 提供生產環境真實數據協助規劃
- 設計（Design）：與業務分析師、軟體架構師、產品負責人、設計師、DevOps SME 共同決定資料流、架構圖與技術棧
- 開發（Develop）：開發者撰寫前後端，DevOps 建置 CI/CD 管線
- 環境就緒（Environment readiness）：SRE 建立監控儀表板，DevOps 透過 CI/CD 部署開發、測試與正式環境
- 測試（Test）：QA 執行回歸與遞增測試，SRE 額外負責負載測試與混沌測試
- SRE 審查（SRE review）：SRE 與測試、開發共同檢視高影響修補，並執行 production 一輪健全性測試（sanity test）
- 部署（Deploy）：DevOps 透過 CI/CD 將程式部署上線
- 監控（Monitoring）：SRE 持續觀察系統表現、處理事件與技術工單
一個常被忽略的價值是：SRE 在 Agile 流程中既是「最末端」也是「最全程」的角色，這正是它能在現代複雜系統中扮演關鍵協調者的原因。
