SDLC 的演變脈絡#
軟體組織為了交付更快、品質更高、更可靠的系統，這幾十年間嘗試過多種 SDLC 模型。SRE 與 DevOps 都是在 1990 至 2000 年代誕生，並隨市場需求逐漸成熟。
SRE 與 DevOps 與開發團隊和諧運作，是現代軟體成功的關鍵配方。但是否同時採用兩者、或只用其一、甚至完全不用，仍視組織規模、需求、預算等因素而定。
從瀑布到 Agile：第一次跳躍#
瀑布模型（Waterfall）是 1990 年代主流，但問題是：
- 線性流程，每階段須等前一階段完成
- 各團隊各做各的，互不知對方時程
- 開發要等所有服務都建好整合才能交給測試，期間 QA 閒置
- 一個專案週期 6 個月到 1 年，需求只能在最初收集
- 中途出現新需求得排到下一個專案；對快速迭代的市場已不堪用
Figure 2.5: Waterfall model in software development lifecycle
Agile 的誕生#
為了解決這些問題，Agile 應運而生：
- 一組支撐持續開發與持續交付的最佳實踐
- Sprint 短則 1 ～ 2 週，每次只交付小批功能
- 提早暴露問題、提早調整
- 推動微服務架構（micro-service architecture），各服務獨立建置、測試與部署，不影響整個應用
Figure 2.6: Agile methodology in SDLC
Agile 的瓶頸：開發與運維仍然各做各的#
雲端與行動使用者快速增加，應用流量爆量，組織需要更強的運維能力，但 Agile 本身沒有解決：
- 開發與運維仍各自孤立，沒有共通工具與語彙
- 同一用例可能用不同工具解，浪費時間與金錢
- 開發者不熟 production 行為，例如不知道高流量下該如何配置服務、沒有實作自動拉起的故障復原
DevOps 的補位#
DevOps 是把「開發 + 運維 + 自動化」綁在一起：
- 透過自動化工具讓開發、測試、運維協作有共同管道
- 跨團隊看到彼此時程、方法、可重用的工具
- 建置與部署的責任移交 DevOps 管線，開發者專注寫程式
- 取消手動介入，提升整體品質與速度
Agile + DevOps 是現代專案的最低標。但只到這裡仍無法保證 24/7 的高可用，因此 SRE 才會被加入。
Figure 2.7: Agile methodology with DevOps in SDLC
SRE 的最後一塊拼圖#
當應用對外承諾 24/7 可用，運維必須升級：
- 運維不能只停在 L1/L2 支援
- 由開發工具、實作自助服務（self-service）與自我修復（self-healing）的工程師組成
- 建立互動式儀表板與自動化告警，提早於使用者察覺前發現問題
- 跨足程式與基礎設施排錯能力，能在 production 直接落地解法
Figure 2.8: Agile methodology with SRE in SDLC
五個演進階段#
從零到完整，新時代 SDLC 大致可以拆成這幾個階段：
- 瀑布：線性、孤立
- Agile：迭代、回饋封閉迴路
- Agile + DevOps：開發與運維打開協作通道
- Agile + SRE：可靠性、可擴充性與運維工程化
- Agile + DevOps + SRE：完整版本，速度與可靠性同時被照顧
SRE 與 DevOps 在 SDLC 中的多個階段會重疊，但角色不同。把它們分清楚並讓兩者分工互補，是現代成熟組織的共同選擇。
