站點可靠性工程 (SRE) 和 DevOps 是兩個密切相關的 IT 實踐，可幫助團隊創建更好的軟件。無論您是開發人員還是高層管理人員，了解這兩種做法之間的差異（以及它們重疊的地方）將有助于您創建和維護高質量的軟件。

這篇文章解釋了SRE 和 DevOps 之間的異同。我們深入研究這兩種做法。他們的優勢、日常任務和首選工具，以解釋他們在軟件開發生命周期 (SDLC)中的不同角色，并幫助您評估哪些值得添加到團隊的日常運營中。

什么是 SRE？

站點可靠性工程 (SRE) 是一組實踐，使團隊能夠通過軟件工程自動執行重復的 IT 操作任務。SRE 自動化耗時的工作（代碼部署、事件響應、生產管理等），同時提高DevOps 基礎設施的可靠性。

SRE 背后的主要思想是，使用軟件來自動化 IT 系統的監督是一種比手動執行所有操作更具可擴展性、成本效益和可持續性的策略。其他基本的 SRE 原則是：

• 開發按預期運行的最簡單的系統。
• 接受沒有零風險這樣的事實，因此避免追求不必要的可靠性。
• 從一開始就計劃停機時間、網絡延遲和可擴展性風險。
• 爭取最大的系統可觀察性。
• 使團隊能夠以一致、穩定和可重復的方式構建和部署軟件。

SRE 彌合了開發和 ITOps 團隊之間的差距，賦予兩個部門權力：

• 開發人員可以盡快將新軟件投入生產。
• ITOps 了解到新部署符合公司的服務水平協議 (SLA)。

SLA 是 SRE 中的一個關鍵因素，因為這些數字設定了可接受的正常運行時間和響應時間的基準。其他重要的 SRE 指標是：

• 服務級別目標 (SLO)：這些指標跟蹤系統的服務級別（例如可用性或恢復時間）并確保您滿足基于 SLA 的期望。
• 服務水平指標 (SLI)：?SLI 使團隊能夠評估系統是否滿足其 SLO。錯誤率和系統吞吐量是 SLI 的典型示例。
• 錯誤預算：該指標規定了系統在不違反其 SLA 的情況下可以停機或運行不佳的最長時間。錯誤預算與RTO類似，但 SRE 團隊更主動地使用錯誤預算（通常用于決定何時將更新推送到生產環境）。

SRE解決什么問題？

SRE 幫助公司解決 IT 運營和軟件開發中常見的一系列問題。以下是最值得注意的：

• 無法滿足公司 SLA 設定的 IT 標準。
• 想要將新軟件發布到生產環境中的開發人員與不想導致操作問題的 ITOps 之間的關系過于緊張。
• 難以識別和解決性能問題和瓶頸。
• 上限或低效的可擴展性。
• 頻繁的服務停機和過多的計劃外停機。
• 缺乏系統或服務的可觀察性（本地或云端）。
• 慢速 MTTR（平均恢復時間，團隊從系統故障中恢復所需的平均時間）和 MTTD（平均檢測時間，從事件開始到團隊發現問題的平均時間）。
• 配置基礎設施的問題。
• 缺乏有效的事件響應計劃或災難恢復策略。
• 低效或不可靠的部署流程。
• 缺乏可用性管理的結構化方法。
• 軟件開發過程中有太多容易出錯的手動過程。
• 難以識別和主動緩解安全漏洞。
• 無法滿足合規需求。
• 使用云計算服務或基礎設施的問題（或者僅僅是因為云賬單過于昂貴）。

SRE 職責

每家公司都會讓他們的 SRE 專家承擔不同的職責，但您會在每個團隊中找到一些職責。以下是最常見的 SRE 任務列表：

• 使用服務器自動化來簡化重復且耗時的任務（部署服務器、設置軟件、運行網絡安全檢查等）。
• 定義和實施系統和服務的可靠性要求。
• 衡量可靠性目標（SLA、SLI、SLO 和錯誤預算）。
• 幫助開發人員構建和部署高度可用、可擴展和容錯的軟件。
• 做出有關部署新功能或應用程序的數據驅動決策。
• 執行容量規劃以預測未來的資源需求并確保系統處理不斷增加的流量或數據。
• 向上擴展系統以確保最佳性能或向下擴展以降低費用。
• 跟蹤系統的性能和可用性。
• 不斷尋找改進 IT 流程和程序的方法。
• 改進事件響應計劃，以最大限度地減少故障的影響，并在危機時刻快速恢復服務。
• 執行事后審查以確定故障的根本原因并防止將來發生類似事件。
• 開發（或監督創建）系統文檔。

SRE 的好處

以下是采用 SRE 帶來的所有優勢的概述：

• 提高系統和服務的正常運行時間和可用性。
• 更好的應用可擴展性和性能。
• 更快、更可靠、更安全的軟件交付。
• 重復性任務和流程的自動化。
• 更多容錯服務，故障更少（影響更小）。
• 生產中的錯誤明顯減少。
• 更好地了解服務運行狀況。
• 整個 SDLC 中出現人為錯誤的可能性較小（加上開發人員有更多時間進行創新）。
• 深入了解產品生態系統（開發、測試、階段和生產）。
• 全面提高安全性（事件預防、災難恢復計劃、風險緩解、最新安全實踐、更多冗余等）。
• 更短的 MTTR 和 MTTD。
• 在事件發生時識別根本原因的更多上下文。
• 提高客戶滿意度和保留率。
• 由于更少的停機時間、更好的可擴展性和資源的最佳使用，降低了運營成本。
• 更好地控制和使用技術債務。

SRE 工具

SRE 團隊依靠各種工具來自動化流程和管理系統。以下是您可能會在任何 SRE 工具堆棧中找到的內容：

• 性能優化工具：這些平臺幫助 SRE 團隊識別和解決軟件系統中的性能瓶頸。Apache JMeter 和 LoadRunner 是最受歡迎的選項。
• 配置管理工具：?SRE 專家使用這些平臺來自動化基礎設施的供應和配置。Terraform、Ansible、Puppet、Pulumi和 Chef 是最常見的選項。
• 監控和日志記錄工具：這些平臺跟蹤軟件系統的性能和可用性。首選 SRE 監控工具是Prometheus和New Relic，而Elasticsearch和Kibana是流行的日志記錄解決方案。
• 事件管理工具：?SRE 團隊使用這些平臺來最小化故障的影響（包括對最終用戶和公司財務的影響）。PagerDuty、VictorOps 和 OpsGenie 是三個常見的選擇，而 OP5、PageDuty 和 xMatters 是首選事件警報工具。
• 容器化工具：這些平臺使團隊能夠將軟件打包到容器中，容器是可移植的代碼包，可以在任何環境中無縫運行。Kubernetes、Rancher 和 Portainer是行業標準，Docker Swarm也享有相當大的追隨者。
• 安全工具：這些平臺確保系統安全并符合標準和法規。一些常見的 SRE 安全工具是 Nessus、OpenVAS 和 Wireshark。
• 項目規劃和管理工具：?SRE 部門使用這些工具來協調職責并創建統一的信息源。大多數團隊都依賴于 Jira 和 Confluence 的組合。

什么是 DevOps？

DevOps 是一組實踐和原則，使公司能夠縮短 SDLC 并提高代碼質量。使用 DevOps，編寫代碼的團隊還負責在生產中維護它，而負責后期制作職責的員工也參與開發。

DevOps 改進了軟件開發的文化和組織方面。以下是該方法的主要目標：

• 打破軟件開發 (Dev) 和 IT 運營 (Ops) 團隊之間的孤島。
• 確保快速發布穩定、安全的軟件。
• 減少團隊從構思到代碼部署所需的時間。
• 提高軟件的整體質量。

在日常實踐中，DevOps 遵循精益或敏捷方法論。以下是 DevOps 的主要原則：

• 確保開發和 ITOps 團隊的任務重疊。
• 接受失敗并快速失敗（但永遠不要重復同樣的錯誤兩次）。
• 通過小的增量更新逐步引入更改，而不是將大量更改部署到生產中。
• 爭取更頻繁地發布。
• 使用自動化來加速 DevOps 管道并最大限度地減少容易出錯的手動任務的數量。
• 持續衡量成功（一些典型的DevOps 指標是更改的提前期、部署頻率、恢復服務的時間和更改失敗率）。

DevOps 解決什么問題？

DevOps 解決了大型軟件開發團隊和項目中常見的各種問題。以下是推動公司轉向 DevOps 的最常見問題：

• 新功能和更新的上市時間較慢。
• 軟件項目中有太多的誤解、代碼返工和延誤。
• 開發人員、IT 運營團隊成員和業務領導者之間的溝通效率低下。
• 模糊的軟件交付流程。
• 代碼質量和應用程序性能差。
• 表現不佳的開發團隊。
• 不必要的高 IT 成本。
• 軟件漏洞太多。
• 不穩定和錯誤的部署環境。
• 無效的軟件測試程序。
• 整個軟件交付過程中有太多耗時的手動任務。
• 開發和 ITOps 團隊的員工保留率低。
• 新開發人員入職緩慢，以及開發人員離開公司時出現的問題。

開發運營職責

DevOps 團隊的確切職責因組織而異，但每個團隊都執行一些任務。以下是常見職責列表：

• 創建、維護和優化軟件創建管道。
• 監督從開發到生產的整個軟件開發生命周期。
• 組織沖刺（每周、每兩周或每月）以管理工作流程和分配任務。
• 創建和配置支持軟件交付過程的服務器、網絡和其他組件。
• 編寫腳本并使用工具來自動執行構建、測試和部署軟件等任務。
• 監控錯誤并解決管道問題。
• 優化應用程序和服務性能。
• 識別并解決發展瓶頸。
• 設計、實施和領導災難恢復策略。
• 跟蹤系統中的所有軟件和硬件組件。
• 確保系統安全并且所有團隊都遵循DevOps 安全最佳實踐。
• 執行混沌工程（一種故意“破壞事物”并監控系統如何響應壓力的策略）。

開發運營的好處

以下是您在組織中采用 DevOps 的主要好處列表：

• 更快的上市時間。
• 更好地使 IT 項目與業務目標保持一致（任何合理的IT 戰略計劃的核心）。
• 更高效的軟件開發團隊。
• 提高軟件質量，減少生產缺陷。
• 提高業務敏捷性和響應市場變化的能力。
• 更穩定的應用程序和服務。
• 大規模有效部署和管理應用程序的能力，使 IT 能夠跟上業務增長的步伐。
• 一個運轉良好的、計劃好的軟件交付管道（從概念和開發到后期制作監控和升級）。
• 更短的發布周期。
• 減少對手動任務的依賴。
• 改進性能監控和分析。
• 由于更好的應用程序性能、更少的錯誤和更頻繁的更新，更快樂的客戶和最終用戶。
• 提高安全性并提高識別和解決軟件相關風險的能力。
• 由于在 SDLC 期間重復性任務減少和人工干預需求減少，因此節省了 IT 成本。
• 始終追求改進、優化和創新的團隊文化。

開發運營工具

以下列出了組建有效的 DevOps 團隊所需的工具類型：

• 源代碼管理工具：這些平臺使團隊能夠跟蹤源代碼、跟進問題并執行代碼審查。最流行的工具是Git和 Mercurial。
• 容器化平臺：這些工具使工程師能夠創建在不同 IT 環境中無縫運行的基于容器的應用程序。兩種常用的解決方案是Kubernetes 和 Docker。
• CI/CD 工具：?CI/CD代表持續集成和持續交付，一種通過自動化頻繁向用戶交付更新的方法。流行的CI/CD 工具的例子有Jenkins、Bamboo 和 CircleCI，
• 配置管理工具：這些平臺使 DevOps 工程師能夠自動化與基礎架構相關的任務，例如配置和維護。大多數團隊使用 Ansible、Terraform 或 Puppet。
• 監控工具：這些解決方案幫助 DevOps 團隊監控應用程序并對故障和風險做出及時響應。Splunk、Nagios和 Raygun 是常見的選擇。
• 協作和規劃工具：團隊間協作是 DevOps 的核心，因此每個團隊都有一個或多個工具來集中信息和規劃項目。與 SRE 一樣，大多數 DevOps 使用 Jira 和 Confluence。

SRE 比。DevOps：關鍵區別

SRE 和 DevOps 有很多相似之處（相同的工具、對自動化的強調、傳統上獨立團隊之間的橋梁等），但這是兩種截然不同的實踐。

下表列出了 SRE 和 DevOps 之間的主要區別：

通過 SRE 或 DevOps（或兩者）將 IT 提升到一個新的水平

SRE 和 DevOps 是現代軟件開發的兩個基石實踐。雖然他們側重于 IT 的不同方面，但都致力于提高軟件產品的可靠性和質量。選擇這兩種做法中的任何一種都不會出錯。另外，請記住 SRE 和 DevOps 并不相互排斥。如果您擁有足夠的資源和足夠的內部人才，那么同時采用這兩種做法始終是一個值得做出的決定。