兩種方法論的誕生#

SRE 是把軟體工程原則應用在 IT 基礎設施與運維上的實踐。至於 DevOps，業界有多種定義，常見說法包括：

• 一套整合並自動化軟體開發與 IT 運維的實踐與工具，用來減少 toil 並加速交付
• 一套自動化、整合開發與運維流程的實踐、工具與文化哲學
• 開發（Development）與運維（Operations）的結合
• 結合人、流程、技術，持續為客戶提供價值
• 透過持續開發與整合來加速交付、確保品質的實踐

沒有一體適用的定義。DevOps 的內涵會因專案類型、領域與業務需求而變動。

為何先有 DevOps，後有 SRE#

DevOps 比 SRE 更早被提出，目的是用持續整合與持續開發來追上不斷成長的使用者需求：

• 工程團隊以自動化串起開發與運維協作
• 開發者預先告知運維新功能，運維準備好基礎設施迎接上線
• 但 DevOps 解決的是「交付速度」，無法回應「在難以管理的成長型基礎設施中維持可靠性」的痛點

SRE 為了補上這個缺口而生：

• 由 Google 的 Ben Treynor Sloss 發起
• 2000 年代初期 Google 的伺服器跨多個資料中心擴張到數千台，傳統運維手段失效
• 願景：把工程原則套用到運維、強調自動化、主動式根因分析與持續改進
• 基本準則：只建構你能輕鬆管理、且有資源可隨負載擴充的功能比例

SRE 與 DevOps 是「同一枚硬幣的兩面」。SRE 解決可靠性，DevOps 解決協作與速度。兩者協同，才能同時達到品質、可靠性與快速交付。

DevOps 的核心原則#

當不同 DevOps 定義落地時，差別在於「如何達成目標」，但底層方向一致：讓程式平順、快速地上線，滿足終端使用者需求。其核心原則包括：

• 打破穀倉（Silos breakdown）：開發與運維透明且規律地協作，彼此熟悉時間軸、流程與資料流
• 自動化（Automation）：自動化程式整合、部署與重複手動任務，提升正確性、減少 toil、節省開發時間
• 持續整合與持續部署（Continuous Integration and Continuous Deployment, CI/CD）：建立自動化管線，讓開發者可以自動建置、整合並部署多份程式碼
• 回饋迴路（Feedback loop）：開發、測試、SRE 與業務持續對工具與管線提出回饋，讓 DevOps 快速補強缺口
• 量測（Measuring）：以指標衡量產出，協助團隊邁向成功

任何 DevOps 實踐都應同時涵蓋「協作文化」與「自動化工具」這兩條腿。少了文化，自動化淪為形式；少了自動化，文化也無法維持規模。