SRE VS DevOps
前言
Site Reliability Engineering (SRE) 和 DevOps 是目前相當熱門的開發與運維文化，有著很高的相似程度。SRE是什麼？它與DevOps有什麼關係？本文將對兩者之間的異同點進行簡單的討論。
SRE產生背景
SRE發散思維
Google公司在發展過程中，同樣也遇到了運維人員與開發人員目標矛盾的問題，開發人員專注於創建新功能並推向生產，運維人員卻試圖保證生產穩定性。為了緩解這兩個部門的矛盾，Google的一位工程副總裁Ben Treynor考慮出了一種新的解決方案。招募及內部轉崗具有研發背景的軟件工程師後不再獨立屬於系統管理員團隊或者ops團隊，而是獨立設計創造軟件系統來維護系統運行以及替代傳統模型中的人工操作，實現解決方案自動化。
站點可靠性工程(SRE)崗位隨即應運而生。SRE工程師負責生產環境的穩定性，但同時又致力於新功能和運維改進。Google認為SRE團隊應由50％的軟件工程師和50％的系統管理員組成。軟件工程師通過軟件來實現歷史上手工解決的問題，並且與開發人員輕鬆集成，促進代碼質量改進和自動化測試等。團隊目的是幫助Google生產環境服務運行更穩定、健壯、可靠。
DevOps和SRE區別
SREs VS DevOps
DevOps的概念就是將開發與運維結合起來，定義系統的行為，並瞭解需要做些什麼來彌補兩個團隊之間的“鴻溝”。這個概念背後的理論是關於使兩個團隊合而為一需要做些什麼。但SRE卻談到了"如何"做到。它是通過使用正確的工作方法，工具等將理論部分擴展到有效的工作流程。這還涉及到在每個人之間分擔責任，並使每個人都具有相同的目標和願景。
我們通過DevOps的5個原則來對比下DevOps和SRE的區別：
減少部門間的孤島
大型企業中通常都會有比較複雜的組織架構，很多團隊之間都是獨立工作，各自發布各自的產品，並沒有與公司其他部門溝通交流，因此，部門之間瞭解不夠，不能從整體上把控全局。
DevOps的工作是減少這些鴻溝，並確保團隊中不存在與公司其他部門不符的團隊。他們以共同的願景將團隊最小化並橋接到一個小組中。
SRE不再關注公司中有多少鴻溝，而是在談論如何讓所有人參與討論。這是通過使用整個公司相同的工具和技術來完成的，例如公司中臺。
故障接受程度
SRE故障標識符
儘管DevOps的概念是在故障發生之前進行處理和應對，但是現實情況千變萬化，我們無法完全避免故障發生。DevOps通過將故障視為必然發生的事情來接受這一點，通過事後覆盤等方式總結經驗來幫助團隊學習和成長。
在SRE看來，故障雖然不可避免，但是可以通過制定一個公式來平衡事故與新版本之間的關係來實現此目標。換句話說，SRE希望確保沒有太多故障或失敗，即使這些失敗的經驗是我們學習成長的途徑。
SRE通過兩個關鍵標識符來衡量該公式：服務水平指標（SLI）和服務水平目標（SLO）。SLI是隨時間變化的指標，例如請求延遲，每秒請求的吞吐量或每個請求的失敗。這些通常會隨時間彙總，然後轉換為比率，平均值或受閾值限制的百分位數。SLO源自此閾值，百分比或數量，表示SLI在一段時間內（例如“過去30天”或“本季度”）內SLI累積成功的目標。
在Google，區分SLO和服務水平協議（SLA），這是服務商對使用者的可靠性保證。SLA中的可用性SLO通常比內部可用性SLO寬鬆。
實施漸進式改革
企業希望經常發佈產品，不斷更新產品，並且讓團隊人員可以持續關注新技術。
DevOps和SRE都是針對此目標的，但是是以漸進的方式處理的。DevOps和SRE都希望快速發展，Google指出SRE強調在這樣做的同時降低故障成本。
工具和自動化
職責不同導致兩個職位工作內容也不盡相同，從而導致工具也略微不同。
DevOps工作內容是主要為開發鏈路服務，一個DevOps團隊通常會提供一串工具鏈，這其中會包括：開發工具、版本管理工具、CI持續交付工具、CD持續發佈工具、報警工具、故障處理。
而SRE團隊則關注更為關注變更、故障、性能、容量相關問題，會涉及具體業務，產出工具鏈會有：容量測量工具、Logging 日誌工具、Tracing 調用鏈路跟蹤工具、Metrics 性能度量工具、監控報警工具等。
但是目的是一樣的，都是希望通過消除手動操作來為開發人員和運維人員提供價值。
結果度量
度量結果
DevOps和SRE團隊都需要確保他們朝著正確的方向發展，DevOps度量結果偏向自動化實現程度及項目交付的速度，SRE度量結果更加偏向於可靠性與穩定性。
SRE關鍵詞是「高擴展性」「高可用性」。高擴展性是指當服務用戶數量暴增時，應用系統以及支撐其服務（服務器資源、網絡系統、數據庫資源）可以在不調整系統結構，不強化機器本身性能 ，僅僅增加實例數量方式進行擴容。高可用性是指，應用架構中任何環節出現不可用時，比如應用服務、網關、數據庫 等系統掛掉，整個系統可以在可短時間內恢復並重新提供服務。
DevOps和SRE關係
DevOps with SRE
DevOps和SRE都接受一種理念，即為了改進，變更是必要的。
合作是DevOps工作的核心，有效共享和合作是SRE發揮作用的必要條件。與DevOps一樣，SRE也具有跨組織共享的強大價值，這樣更容易打破團隊之間的鴻溝。
生產服務器故障發生時，SRE和DevOps都應該進行各自的事故覆盤，目的為了消除無意義的爭論與甩鍋以及知識沉澱。
使用正確的工具至關重要，工具在一定程度上決定了工作效率。
結果度量是DevOps和SRE如何工作的關鍵。對於SRE, SLOs (服務質量目標) 決定著是否改善和優化服務。當然，如果沒有度量以及在產品、基礎設施/SRE和業務之間的跨團隊合作，就不可能有SLOs。對於DevOps，結果度量行為通常用於理解流程的輸出是什麼，反饋週期的持續時間是什麼等等。
DevOps或SRE是一種整體行為，願景就是用一種特定的工作方式共同協作，促使整個團隊運營的更好。
DevOps和SRE在其日常工作中存在非常大的重疊。正如托爾斯泰說過的：有效的操作方法都是相似的，而失敗的方法都有各自的失敗之處。
結論
在IT運維整體領域的許多方面，雖然兩者多多少少有些不同，但實際DevOps和SRE在實踐和理念上都非常接近。兩者都有助於合併開發人員和運維人員，同時承擔相似的責任，並專注於實現自動化和可靠性。實施任何一個都是一個較長的過程，而不是一個快速解決方案。DevOps關注的範圍更廣，因此很難將每一步都規範成一個具體的流程，但正是因為廣泛的關注，前期遇到的阻力可能會跟小。SRE將大部分時間花費在技術和流程方面的職責上，與其他團隊合作，提供適當的監控、事件響應和管理，共同實現可靠性的目標。
歸根到底，無論是DevOps還是SRE，都面臨著同樣的目標與願景：讓生產環境變得更好---不管被稱為什麼！
