DevOps、SRE 與平台工程：現代軟體交付的三大支柱完整解析

1. DevOps (開發營運一體化)

定義與理念

DevOps 是一種結合了文化理念、實務和工具的方法，旨在提升組織快速交付應用程式和服務的能力。它作為對傳統 IT 模型中開發與營運團隊之間存在的「孤島」現象的回應而出現。DevOps 的核心是文化轉變，強調開發與營運團隊在整個軟體生命週期中的緊密協作、自動化和持續改進。

核心原則

• •

  協作與溝通

  促進開發、營運及其他團隊在整個軟體開發生命週期中的開放溝通與緊密協作。

• •

  自動化

  自動化重複性任務，如測試、整合和部署，以加速軟體交付並減少人為錯誤。

• •

  持續整合/持續交付 (CI/CD)

  透過自動化的建置、測試和部署流程，實現程式碼變更的頻繁整合和快速發布。

• •

  基礎設施即程式碼 (IaC)

  將基礎設施視為程式碼來管理，實現自動化、可擴充和一致的基礎設施配置。

• •

  持續監控與回饋

  持續監控系統和應用程式，及早發現問題，並透過回饋循環不斷改進效能和可靠性。

主要職責

DevOps 團隊主要專注於軟體交付管道和環境管理。

• CI/CD： 建立和維護建置與部署管道
• 基礎設施自動化： 透過 IaC 自動化配置資源
• 監控與營運支援： 實作應用程式監控和記錄檔
• 協作與賦能： 打破組織孤島，促進共同責任
• 事件回應： 透過自動化和測試預防事件發生

DevOps 解決的問題

• 降低開發與維護成本： 透過 CI/CD 和自動化測試
• 縮短發布週期： 更頻繁地交付新功能和修復
• 自動化和持續測試： 提高測試覆蓋率

常用工具

CI/CD 工具

Jenkins, CircleCI, GitHub Actions

版本控制

Git, GitHub, GitLab

IaC 工具

Ansible, Terraform, Pulumi

容器化與協調

Docker, Kubernetes

監控與記錄檔

Splunk, Datadog, ELK stack

專案管理

JIRA, Confluence, Slack

2. SRE (網站可靠性工程)

定義與理念

SRE 源於 Google，是一種將軟體工程原則應用於 IT 營運的學科，旨在創建高度可擴充和可靠的系統。它透過工程方法來解決營運挑戰，其首要目標是使服務更可靠和可擴充。

核心原則

• •

  服務水準目標 (SLO)

  定義服務的預期效能目標，如正常運行時間或回應時間，作為可靠性的基準。

• •

  擁抱風險

  接受 100% 可靠性不可行，透過「錯誤預算」（允許的停機時間）來平衡創新與穩定性。

• •

  消除苦力 (Toil)

  最大限度地減少重複性、手動且沒有成長價值的任務，透過自動化釋放工程師的精力。

• •

  自動化

  SRE 的核心原則，減少人為干預，提高系統可擴充性並減少錯誤。

• •

  事後無責檢討 (Blameless Post-mortems)

  在事件發生後進行學習，不歸咎個人，鼓勵學習和持續改進的文化。

主要職責

SRE 被描述為生產環境中服務「可靠性的守護者」。

• 可靠性規劃與 SLOs： 定義服務水準目標
• 監控與事件回應： 設置高階監控和警報系統
• 自動化與苦力消除： 自動化營運任務
• 效能與可擴充性工程： 負責服務的可擴充性
• 基礎設施與程式碼參與： 審查開發者的變更

SRE 解決的問題

• 縮短平均恢復時間 (MTTR)： 迅速回復到產品的穩定版本
• 縮短平均檢測時間 (MTTD)： 透過金絲雀發布早期發現問題
• 全面自動化： 解決手動操作導致的不一致和人為錯誤
• On-Call 和事件文件： 建立知識庫縮短故障排除時間
• 共享知識： 定期更新知識庫，彌補團隊間的知識鴻溝

常用工具

可觀測性工具

Prometheus, Grafana, Kibana

警報與事件管理

PagerDuty, Opsgenie, VictorOps

自動化工具

Terraform, Ansible, Puppet

容器協調

Kubernetes, Docker

混沌工程工具

Chaos Monkey, Gremlin

AWS 服務

Amazon EKS, AWS OpsWorks

3. SRE 與 DevOps 的差異與相似之處

核心差異

• •

  DevOps 是一種廣泛的文化和組織方法，側重於透過自動化、CI/CD 和共享職責來統一開發和營運。它強調「做什麼」：更快的迭代、流程效率和打破孤島。

• •

  SRE 是一種具體的工程實務，定義了「如何」實現營運目標。它引入了 SLOs、錯誤預算和操作手冊等正式結構來系統地管理可靠性和事件處理。

• •

  關係： SRE 可以被視為 DevOps 理念的實際實作，特別是在可靠性工程至關重要的情況下。DevOps 設立了協作和交付的願景，而 SRE 定義了實現和維護該願景所需的工程實務。

詳細比較

比較面向	DevOps	SRE
新功能實作	負責實作新功能	確保新變更不會增加生產環境中的整體故障率
流程	從開發環境的角度進行變更	從生產環境的角度提供建議，以限制故障率
目標	加強開發與營運之間的協作，簡化軟體交付	透過主動監控和事件回應來維護服務正常運行時間
焦點	產品開發的連續性和速度	系統的可靠性、可擴充性和可用性
團隊結構	產品負責人、團隊負責人、軟體開發人員、QA 工程師等	具有營運和開發技能的工程師團隊
職位角色	簡化軟體交付流程，建置和維護 CI/CD 管道	對生產系統的可靠性負責，處理 On-Call、事件、最佳化
錯誤報告	負責除錯最終產品中的程式碼	向核心開發團隊報告錯誤，負責除錯基礎設施問題
測量指標	部署頻率和部署失敗率	錯誤預算、SLO、SLI 和 SLA
薪資 (美國)	$110,000 到 $140,000	$120,000 到 $150,000

相似之處

共同目標

SRE 和 DevOps 都旨在透過提高 IT 基礎設施的彈性和敏捷性來改進軟體開發和營運。

共同重點

兩者都專注於自動化、持續監控和最佳化系統效能，以減少停機時間和營運問題。

共同文化

它們都鼓勵一種共同責任的文化，即開發和營運團隊協同工作，以更快、更可靠地交付軟體。

4. 平台工程 (Platform Engineering)

定義與理念

平台工程是一個相對較新的學科，專注於設計和建置內部開發者平台 (Internal Developer Platform, IDP)。這些平台為軟體工程團隊提供自助服務功能，包括基礎設施、部署管道、監控工具等，使開發者能夠更獨立、更高效地工作。

核心原則

• •

  開發者體驗 (Developer Experience, DevEx)

  改善開發者的日常工作流程，減少認知負荷，讓他們專注於編寫程式碼而非管理基礎設施。

• •

  自助服務

  透過標準化、自動化的介面，讓開發團隊能夠自主存取所需的工具和資源。

• •

  標準化與抽象化

  將底層基礎設施複雜性抽象化，提供統一、簡化的介面給開發者使用。

• •

  可重用性

  建立可重用的元件和模板，避免重複造輪子，提高整體效率。

主要職責

• 內部平台開發： 設計和建置供內部開發團隊使用的平台
• 工具整合與標準化： 整合各種開發和營運工具
• 基礎設施抽象化： 將複雜技術包裝成易於使用的服務
• 開發者賦能： 透過文件、培訓和支援，幫助開發團隊
• 平台維護與改進： 持續改進平台功能

與 DevOps 和 SRE 的關係

平台工程是 DevOps 和 SRE 的補充，而不是競爭關係。

• 支援 DevOps： 建置底層基礎設施和內部工具，提高 DevOps 效率
• 與 SRE 目標一致： 考慮平台的可靠性和可擴充性
• 演進： 應對大規模實作 DevOps 和 SRE 所面臨的挑戰

平台工程的價值

對開發者的價值

• 減少認知負荷，專注於業務邏輯
• 自助服務能力，減少等待時間
• 標準化工具和流程，降低學習曲線

對組織的價值

• 提高開發速度和產品交付效率
• 標準化安全和合規實務
• 降低營運成本和技術債務

5. 實際應用情境與「哪個更好？」

實際應用情境

組織如何實際應用 DevOps、SRE 和平台工程：

新創公司或小型團隊

通常不會有獨立的 SRE 和 DevOps 職位，團隊成員身兼多職。他們會採用 DevOps 實務以追求速度，而可靠性是共同責任。

中型科技公司

可能會創建 DevOps 團隊（或「平台團隊」）來集中 CI/CD 和基礎設施的專業知識。如果可靠性要求提高，可能會組建 SRE 團隊來專門處理可用性和效能問題。

大型科技公司

DevOps 和 SRE 都深入實作。例如，Google 有龐大的 SRE 組織，同時也深植 DevOps 文化。Netflix 也大量投資於可靠性工程（推廣混沌工程）。這些公司不認為是 DevOps「或」SRE，而是 DevOps「和」SRE。

企業和受監管行業

也在採用 DevOps，但在合規性問題下可能較慢。他們也看到了 SRE 對於可靠性的價值，尤其是在停機可能產生嚴重後果的領域（如醫療保健）。

「哪個更好？」的結論

這不是一場「哪個更好」的比較，因為 DevOps 和 SRE 並非互斥，它們是互補的策略。一個成功的科技組織真正需要兩者兼備。SRE 可以被視為 DevOps 的一種實作方式，特別注重可靠性和工程嚴謹性。

• 如果組織面臨發布緩慢、交接環節多等問題，採用 DevOps 實務（自動化、協作團隊、CI/CD）將顯著提高速度和品質。

• 如果部署速度快但頻繁發生故障或效能問題，引入 SRE 實務（專注於可靠性工程、設定 SLOs、改進監控等）是明智的選擇。

• 在許多情況下，答案是逐步引入三者的元素。DevOps 帶來敏捷性，SRE 帶來保障，平台工程使這一切可持續和可擴充。

隨著平台工程的興起，問題變成了如何平衡三者：運用 DevOps 原則來推動團隊交付，運用 SRE 原則來保持服務健康，以及運用平台工程來使這一切可持續和可擴充。最終目標是實現快速、穩定、持續地向使用者交付價值。

總結

總結來說，DevOps、SRE 和平台工程是現代軟體交付中相互關聯且互補的領域，共同努力實現軟體產品的快速迭代和高可靠性。組織的成熟度、規模和具體需求將決定其如何結合和實作這些方法。

學習推薦

• Devop DevOps原理與實作
• Devsre SRE原理與實作