您應該了解的 DevOps 和 SRE 之間的 5 個基本區別
已發表: 2021-02-22信息技術和軟件開發領域經常將 DevOps 與 SRE 混為一談，意思相同。 但是，兩者之間存在巨大差異。 儘管站點可靠性工程 (SRE) 近年來受到了廣泛關注，但 DevOps 的存在時間要長得多（甚至在 DevOps 一詞出現之前）。
簡而言之，DevOps 和 SRE 都是為了更快地交付軟件而實施的實踐。 兩者之間的唯一區別在於他們的方法。 DevOps 專注於縮短軟件開發生命週期，而 SRE 專注於消除系統弱點以達到相同的目的。
在本文中，我們將探討 DevOps 和 SRE 彼此不同的基本方式。 在我們這樣做之前，讓我們先了解一下 DevOps 和 SRE 是什麼。
目錄
什麼是 DevOps？
用 DevOps 手冊和鳳凰計劃的作者 Gene Kim 的話來說，
“DevOps 是 [the] 一套文化規範和技術實踐，[使] 計劃工作從開發等到測試到運營的快速流動，同時保持世界級的可靠性、運營和安全性。 DevOps 不是關於你做了什麼，而是你的結果是什麼。”
因此，DevOps 主要專注於轉變組織內部的文化實踐，以加快軟件開發生命週期 (SDLC)。 它不針對個人、團體或職位。 DevOps 旨在加強信息技術運營和軟件開發團隊之間的協作。
它做什麼以及如何做並不重要。 只有過程的結果才能得到承認。
DevOps 使用一組原則來加強軟件工程團隊對生產系統的了解，並使 IT 運營團隊能夠更有效地將差異上報給開發團隊。 事實上，SRE 通過促進主動測試、速度、允許可觀察性和提高服務可靠性，在 DevOps 組織中發揮著至關重要的作用。 DevOps 鼓勵每個以 DevOps 為中心的組織按照其模型 CALMS 中概述的文化原則進行操作。
什麼是 SRE？
SRE 是 Site Reliability Engineering 的縮寫，是谷歌負責監督技術運營的高級副總裁 Ben Treynor 創造的一個術語。
Drew Farnsworth（來自 Green Lane Design）解釋說：“我通常喜歡將 SRE 視為一個開發控制操作的系統。 在這個系統中，環境被分解為 IT 堆棧的最基本組件，並在硬件中採用了最佳實踐。”
從本質上講，具有軟件開發專業知識的 SRE 團隊的任務是解決系統生產中的問題，同時在交付速度和系統可靠性之間保持平衡。 通過這種方式，SRE 方法將運營角色下的軟件開發人員聚集在一起，以應用結構化的工程實踐來維護組織的政策。
他們確保系統始終可用並高效運行，以便軟件團隊開發技術服務以提高系統的可靠性。 SRE 有責任在任何潛在的弱點發展為重大問題之前識別它。
DevOps 與 SRE：DevOps 和 SRE 之間的主要區別
在實踐中，DevOps 和 SRE 應該被視為互補的學科，其中 SRE 作為以 DevOps 為中心的結構的一部分，專注於提高其技術服務的可靠性。 因此，基本上沒有 DevOps 與 SRE 之類的東西。
因此，我們在本節中所做的是評估 DevOps 和 SRE 之間的根本區別。
實施變革
為了更新頻繁，用戶可以訪問更新和更相關的技術，DevOps 和 SRE 都打算加快步伐。 然而，DevOps 謹慎地逐步推進，而 SRE 則考慮了加快行動失敗的成本。
兩者都實施自動化並使用工具來實現這一目的。
將失敗視為常態
DevOps 在接受失敗並將其視為學習壓迫方面非常重要。 出於這個原因，它通過接受失敗是過程的一部分而不是專注於使系統 100% 容錯來鼓勵一種無可指責的文化。 這方面的一個例子是 Netflix 及其 Simian Army。
另一方面，SRE 支持無可指責的事後分析。 這背後的目的是確定失敗的原因，分配責任並努力避免將來發生類似的失敗。 系統可以經歷多少次故障包含在錯誤預算中。 SLI、SLO 和 SLA 指標確定了這一點，以降低生產成本。 基本上，SRE 採用主動監控和警報實踐來避免潛在的故障。
從世界頂級大學在線學習軟件開發課程。 獲得行政 PG 課程、高級證書課程或碩士課程，以加快您的職業生涯。
自動化與創新
DevOps 非常重視自動化。 在以 DevOps 為中心的環境中，這意味著系統盡可能地自動化，從而導致發布乏味。 開發人員提交代碼後，以下大多數活動（如果不是全部）必須自動化。
因此，DevOps 追求 CI/CD 的原因是為了以更高的速度開發高質量的系統。
SRE 追求 CI/CD 的原因是不同的，它們的目的是降低失敗的成本。 部署和備份等操作中的任何常見、通用或重複性任務都被認為不太值得關注。 因此，SRE 會留出特定的時間來避免操作繁瑣。 這樣做是為了讓他們可以從事更具吸引力的任務，例如執行或創新新技術或與架構相關的活動。
結帳：面向初學者的 DevOps 項目
打破組織孤島
在部署過程中，開發人員和運營商會發生衝突。 雖然開發人員會在編碼後立即部署功能，但操作人員專注於使系統可用，這會阻礙部署過程。
DevOps 和 SRE 的不同之處在於它們如何消除組織中的孤島。
正如 The DevOps Handbook 中所解釋的，DevOps 通過包括小批量操作和更好地管理配置等實踐來解決這個問題。
SRE 不僅旨在優化團隊之間的流程，還有助於生產中的系統。 他們通過作為顧問融入團隊並通過分擔運行系統的責任來支持開發人員來做到這一點。 這就是 SRE 如何打破組織中的孤島。
衡量成功的實施
DevOps 指標都是關於運營速度的； 這包括部署的頻率、部署時間以及遇到問題的頻率。
根據 Puppet 和 DORA 的 2017 年報告，衡量 DevOps 的成功實施取決於以下幾點：
- 部署發生的頻率
- 代碼提交與其部署之間的持續時間
- 部署失敗的頻率
- 從部署失敗中恢復所需的時間
這些反饋循環旨在幫助 DevOps 提高系統質量，同時促進實驗中的變化。
另一方面，SRE 致力於改進系統，同時牢記其可靠性。 它考慮以下關鍵指標來確定成功的實施：
- 服務水平目標 (SLO)
- 服務水平指標 (SLI)
- 服務水平協議 (SLA)
上述指標是系統可靠性的指標。 這些指標預先確定變更發布是否會投入生產。
在 SRE 中，這些速度和質量指標在構建錯誤預算和提高系統可靠性而不是開發新功能時會派上用場。
閱讀：印度的 DevOps 工程師薪水
結論
Google 發布了一本關於他們如何在其生產系統中實施站點可靠性工程的電子書，其中 Treynor 將 SRE 解釋為，
“當您要求軟件工程師設計運營團隊時，就會發生 SRE。”
當談到 DevOps 和 SRE 的不同之處時，您需要記住的是，SRE 是由開發人員而不是運營團隊驅動的。 維護和監控都主要在開發人員的控制之下。 這就是這兩個學科的主要區別。
如果您有興趣了解有關大型 DevOps、全棧開發的更多信息，請查看 upGrad 和 IIIT-B 的軟件開發執行 PG 計劃 - 全棧開發專業化，該計劃專為工作專業人士設計，並提供 500 多個小時的嚴格培訓， 9 個以上的項目和任務，IIIT-B 校友身份，實用的實踐頂點項目和頂級公司的工作協助。
