DevOps和SRE

之前總是把SRE和DevOps混為一談，總覺得這兩個是同一種東西在不同公司的叫法，知道前兩天google又放出了《The Site Reliability Workbook》 ，書中對比了SRE和DevOps的異同。今日重新看wikepedia上DevOps的的定義 ，發現兩者雖有共同點，但本質上卻不同。

DevOps（Development和Operations的組合詞）是一種重視“軟件開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。透過自動化“軟件交付”和“架構變更”的流程，來使得構建、測試、發布軟件能夠更加地快捷、頻繁和可靠。（via Wikipedia）

DevOps不是一個實體，而是行業中運維和研發協作的一種理念、文化，SRE是什么？在《Site Reliability Engineering》中Google的工程師也給出了答案

SRE is what happens when you ask a software engineer to design an operations team.

SRE是你讓一個軟件工程師組件一個運維團隊的產物，它本質上是一個實體，是一個團隊一個工種，是對DevOps的實踐。說的形象一點，DevOps是一個Interface，SRE是實現這個interface的class，兩者之間必然有異同，The Site Reliability Workbook 中給我們列出來一部分，我大概翻譯一下。

DevOps 和SRE建立在變革的基礎上了，沒有改變何談提升。

DevOps的核心是協作，SRE的核心是共享。但兩者的主要價值都是貫穿整個組織把各個團隊聯結在一起。

維護變更和穩定性的平衡是SRE最重要的工作，小二頻的變更、自動化測試和交付很重要。

工具很重要，用什么工具甚至能決定能做什么，但也不必太過分糾結于工具。其實API的設計好壞比在API之上任何工具的設計好壞更重要。

量化對SRE和DevOps來說都極為重要，對SRE來說SLOs是最主要的指標，當然沒有衡量標準就沒有SLO。 對DevOps而言，衡量通常用有些比如系統的輸出，反饋循環的持續時間等等。無論是實踐還是理論，SRE和DevOps都得用數據說話。

在管理生產服務的過程中總是免不了出問題，SRE和DevOps都實行不問責的事故處理方式。

歸根到底，DevOps或SRE是一種全局工作，兩者都希望通過某種特定的方式使得分散的部分組織協同的更好。 速度是SRE和DevOps都想要的結果。

SRE和Devops有好多共同點，但也有有些明顯的不同之處，DevOps是一種泛化的哲學和文化概念。 它能比SRE產生更多的變體，DevOps在實踐中具體是什么還得看上下文環境。它不太關注系統運行的太多細節，而是專注于打破阻礙組織協同的壁壘。

另一方面，SRE的職責相對狹窄，通常是面向服務（以最終用戶為導向），而不是整體業務導向。 因此，它為了是系統運行更高效產生出一些武斷的知識框架（比如錯誤預算……）。 雖然作為一個職業，SRE高度了解激勵及其影響，但它反過來卻相對于孤島化和信息障礙等主題保持沉默。 它將支持CI和CD，不一定是因為業務案例，而是因為所涉及的操作實踐得到了改進。 或者，換句話說，SRE相信與DevOps相同的東西，但原因略有不同。 作為一個具體的職業，SRE對他們產生的影響高度敏感，反而對信息壁壘不太關注。SRE支持持續集成和持續交付不是因為商業需求，而是因為持續集成和持續交付涉及到運維。 換句話說，SRE和DevOps相信同樣的事，但不是因為同樣的原因。

DevOps 運維

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。