【轉帖】DevOps和SRE的區別

DevOps和SRE的區別

https://zhuanlan.zhihu.com/p/87598465

 

DevOps 和 SRE

最近有一位朋友和我聊職業發展方向問題，聊了很多 DevOps 和 SRE 話題。 我幾年前剛接觸這兩個概念時也經常將之混淆，惋惜當時沒有人來解答我困惑。 如今這雖然已經極爲流行，可是我發現我這位朋友對這兩個職位還存在一些誤區。 因而我給了一些看法並整理成文章以饕大衆。

最多見的誤區：

• DevOps 新概念，好高級哦
• SRE 是高級版 DevOps
• 運維能夠輕鬆轉身 DevOps 工程師

DevOps 和 SRE 定義

DevOps 是字面上 Dev 開發 / Ops 運維二者組合， 嚴格意義上 DevOps 以下（via DevOps - Wikipedia）：

DevOps（Development 和 Operations 的組合詞）是一種重視「軟件開發人員（Dev） 」和「IT 運維技術人員（Ops）」之間溝通合做的文化、運動或慣例。

SRE 全稱是 Site Reliability Engineering，最先是由 Google 提出，而且在其工程實踐中發揚光大。 他們還出了一本同名書籍「Site Reliability Engineering」， 讓這個理念在互聯網工程師圈子裏普遍傳播。

Google 對 SRE 解釋是（via Site Reliability Engineering - Wikipedia）：

Site reliability engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to operations whose goals are to create ultra-scalable and highly reliable software systems.

我將其翻譯翻譯爲中文：

網站穩定性工程師是致力於打造「高擴展、高可用系統」，並將其貫徹爲原則的軟件工程師。

從定義來看，DevOps 是文化、運動和慣例，而 SRE 是有嚴格任職要求的職位。 文化是軟性定義，文化有更多概念能夠捏造，而 SRE 定義精準，就少了想象空間（也可能 SRE 門檻高 😄）。 按 Google 給出的說法是，SRE 工程師實踐了 DevOps 文化。這個觀點沒錯，可是國內的 DevOps 逐步獨立出 DevOps 工程師， 因此在本文，我着重討論的是 DevOps 工程師和 SRE 工程師兩種職位對比。

二者產生背景和歷史

互聯網需求催生了 DevOps 。在最傳統軟件企業中，是隻有 Dev 沒有 Ops， 那時 Ops 可能仍是隻是技術支持人員。開發按照瀑布流：需求分析、系統設計、開發、測試、交付、運行， 傳統軟件發佈是一個重量級操做。一旦發佈，Dev 幾乎再也不直接操做。 80 後可能會記得 QQ 每一年都會有一個大版本發佈吧，QQ 2000 / 2003 / 2004 等等。 此時 Ops 不用和 Dev 直接高頻接觸，甚至針對一些純離線業務，壓根沒有設立 Ops 這個崗位。

互聯網浪潮以後，軟件由傳統意義上桌面軟件演變爲面向網站、手機應用。 這時候業務核心邏輯，好比交易，社交行爲都不在用戶桌面完成，而是在服務器後端完成。 這給互聯網企業給予了極大操做空間：隨時能夠改變業務邏輯，這促進了業務快速迭代變動。 但即使這樣，Dev 和 Ops 是極其分裂的兩個環節。Ops 不關心代碼是如何運做的，Dev 不知道代碼如何運行在服務器上。

當業界還沉浸在能夠每週發佈版本喜悅中時，2009 年，Flicker 提出了天天發佈 10+ 次概念，大大震撼了業界。 Flicker 提出了幾個核心理念：

• 業務快速發展，須要擁抱變動，小步快跑
• Ops 目標不是爲了網站穩定和快速，而是推進業務快速發展
• 基於自動化工具提升 Dev / Ops 聯接：代碼版本管理、監控
• 高效溝通：IRC / IM Robot（如今那些 ChatBot 套路，10 年前就被 Flicker 玩過了）
• 信任、透明、高效、互助的溝通文化

真是讓人不可思議，今天各類培訓公司和一些知名大 V 在呼喚這些 DevOps 理念， 居然在 2009 年一份幻燈片中就展示淋漓盡致。經典老是不過期，在塵封下閃耀着智慧光芒。 有些人將 DevOps 和運維自動化等同，這是隻看到表象。 DevOps 目標是提升業務系統交付速度，併爲之提供相關工具、制度和服務。 一些我的或培訓機構添油加醋和衍生含義，都是圍繞這 DevOps 本質而發散。

接下來聊聊 SRE 歷史， SRE 出現要晚一些。在 2003 年時候 Google 的 Ben Treynor 招募了幾個軟件工程師，這個團隊設立目的是幫助 Google 生產環境服務運行更穩定、健壯、可靠。 不一樣於中小型規模公司，Google 服務於十幾億用戶服務，短暫服務不可用會帶來致命後果。 所以 Google 走在了時代最前面，SRE 產生了。 這個職位爲大規模集羣服務，小型團隊不須要這樣職位設定（可能也招不起真正 SRE 😊）。 Google 在探索若干年以後，SRE 團隊開始將本身心得體會寫在線上，並在 2016 年將此書出版。

二者的職能不一樣

如今很多公司將 DevOps 職能單獨抽取出來，稱之爲 DevOps 工程師。 那讓咱們看看 DevOps 工程師關心什麼：DevOps 文化目的是提交交付速度， DevOps 工程師就天然會關心軟件 / 服務的整個生命週期。 一個簡單的公式：速度 = 總量 / 時間，添上工程行業術語，即 交付速度 = （（功能特性 * 工程質量） / 交付時間） * 交付風險。

功能特性交給產品經理和項目經理管理，DevOps 工程師須要關心剩下幾個因素：工程質量 / 交付時間 / 交付風險。 DevOps 工程師職能以下：

• 管理應用全生命週期（需求、設計、開發、QA、發佈、運行）
• 關注全流程效率提高，挖掘瓶頸點並將其解決
• 自動化運維平臺設計和研發工做（標準化、自動化、平臺化）
• 支持運維繫統，包括 虛擬化技術、資源管理技術、監控技術、網絡技術

SRE 關鍵詞是「高擴展性」「高可用性」。高擴展性是指當服務用戶數量暴增時， 應用系統以及支撐其服務（服務器資源、網絡系統、數據庫資源）能夠在不調整系統結構，不強化機器自己性能 ，僅僅增長實例數量方式進行擴容。高可用性是指，應用架構中任何環節出現不可用時，好比應用服務、網關、數據庫 等系統掛掉，整個系統能夠在可預見時間內恢復並從新提供服務。固然，既然是「高」可用， 那麼這個時間通常指望在分鐘級別。SRE 職能能夠歸納爲如下：

• 爲 應用、中間件、基礎設施等提供 選型、設計、開發、容量規劃、調優、故障處理
• 爲業務系統提供基於可用性、可擴展性考慮決策，參與業務系統設計和實施
• 定位、處理、管理故障，優化致使故障發生相關部件
• 提升各部件資源利用率

工做內容不一樣

職責不一樣致使兩個職位工做內容也不盡相同，我將 DevOps 工程師和 SRE 工程師職能列舉以下：

• DevOps
• 設定應用生命管理週期制度，扭轉流程
• 開發、管理 開發工程師 /QA 工程師使用 開發平臺系統
• 開發、管理 發佈系統
• 開發、選型、管理 監控、報警系統
• 開發、管理 權限系統
• 開發、選型、管理 CMBD
• 管理變動
• 管理故障

• SRE
• 管理變動
• 管理故障
• 制定 SLA 服務標準
• 開發、選型、管理 各種中間件
• 開發、管理 分佈式監控系統
• 開發、管理 分佈式追蹤系統
• 開發、管理 性能監控、探測系統（dtrace、火焰圖）
• 開發、選型、培訓 性能調優工具

頗有趣的對比，DevOps 和 SRE 都會關心應用生命週期，特別是生命週期裏面中變動和故障。 可是 DevOps 工做內容是主要爲開發鏈路服務，一個 DevOps Team 一般會提供一串工具鏈， 這其中會包括：開發工具、版本管理工具、CI 持續交付工具、CD 持續發佈工具、報警工具、故障處理。 而 SRE Team 則關注更爲關注變動、故障、性能、容量相關問題，會涉及具體業務，產出工具鏈會有： 容量測量工具、Logging 日誌工具、Tracing 調用鏈路跟蹤工具、Metrics 性能度量工具、監控報警工具等。

DevOps 和 SRE 關係

DevOps 首先是一種文化，後期逐漸獨立成一個職位；SRE 一開始就明確是一個職位； 很多同窗把 DevOps 和 SRE 搞混，是被二者表象鎖迷惑，看上去這二者都有的工具屬性、自動化要求也類似。 甚至有一些開發同窗把這類運維工做都統一理解爲：服務器 + 工具 + 自動化。這是盲人摸象，管中窺豹。

從技能上來講，二者都須要較強的運維技能。 在職業發展天花板上，DevOps 可能缺少 SRE 在一些專業領域的技能： 計算機體系結構能力；高吞吐高併發優化能力；可擴展系統設計能力；複雜系統設計能力；業務系統排查能力。 二者都須要軟實力，可是 SRE 面臨複雜度更高，挑戰更大，要求也更高：

DevOps 具備廣泛意義，現代互聯網公司都須要 DevOps，可是並不是全部團隊對高可用性、高擴展性存在需求，它們不須要 SRE。 DevOps 工程師掌握相關技能以後，也有機會能夠發展爲 SRE 工程師。 而一位合格 SRE 工程師，在有選擇狀況下面，我相信不會去轉型爲 DevOps 工程師。

從專業背景來看，不管是 DevOps 仍是 SRE 工程師，都須要研發背景，前者須要開發工具鏈，後者須要有較強架構設計經驗。 若是有運維工程師想轉型成爲 DevOps 或者 SRE，那麼須要補上相關技術知識。 畢竟，不是會搭建一套 Jenkins + Kubernetes 就能夠自稱爲 DevOps / SRE 工程師。

怎麼樣，有沒有解開這幾個常見誤區呢？但願你看到這裏能夠豁然開朗，最後附上兩個工程師的技能點， 指望有志成爲這兩種工程師的同窗，加油努力。

附錄：技能點

DevOps：

• Operator 技能
• Linux Basis
• 基本命令操做
• Linux FHS（Filesystem Hierarchy Standard 文件系統層次結構標準）
• Linux 系統（差別、歷史、標準、發展）

• 腳本
• Bash / Python

• 基礎服務
• DHCP / NTP / DNS / SSH / iptables / LDAP / CMDB

• 自動化工具
• Fabric / Saltstack / Chef / Ansible

• 基礎監控工具
• Zabbix / Nagios / Cacti

• 虛擬化
• KVM 管理 / XEN 管理 / vSphere 管理 / Docker
• 容器編排 / Mesos / Kubernetes

• 服務
• Nginx / F5 / HAProxy / LVS 負載均衡
• 常見中間件 Operate（啓動、關閉、重啓、擴容）

• Dev
• 語言
• Python
• Go（可選）
• Java（瞭解部署）

• 流程和理論
• Application Life Cycle
• 12 Factor
• 微服務概念、部署、生命週期
• CI 持續集成 / Jenkins / Pipeline / Git Repo Web Hook
• CD 持續發佈系統

• 基礎設施
• Git Repo / Gitlab / Github
• Logstash / Flume 日誌收集
• 配置文件管理（應用、中間件等）
• Nexus / JFrog / Pypi 包依賴管理
• 面向 開發 / QA 開發環境管理系統
• 線上權限分配系統
• 監控報警系統
• 基於 Fabric / Saltstack / Chef / Ansible 自動化工具開發

SRE：

• 語言和工程實現
• 深刻理解開發語言（假設是 Java）
• 業務部門使用開發框架
• 併發、多線程和鎖
• 資源模型理解：網絡、內存、CPU
• 故障處理能力（分析瓶頸、熟悉相關工具、還原現場、提供方案）

• 常見業務設計方案和陷阱（好比 Business Modeling，N+一、遠程調用、不合理 DB 結構）
• MySQL / Mongo OLTP 類型查詢優化
• 多種併發模型，以及相關 Scalable 設計

• 問題定位工具
• 容量管理
• Tracing 鏈路追蹤
• Metrics 度量工具
• Logging 日誌系統

• 運維架構能力
• Linux 精通，理解 Linux 負載模型，資源模型
• 熟悉常規中間件（MySQL Nginx Redis Mongo ZooKeeper 等），可以調優
• Linux 網絡調優，網絡 IO 模型以及在語言裏面實現
• 資源編排系統（Mesos / Kubernetes）

• 理論
• 容量規劃方案
• 熟悉分佈式理論（Paxos / Raft / BigTable / MapReduce / Spanner 等），可以爲場景決策合適方案
• 性能模型（好比 Pxx 理解、Metrics、Dapper）
• 資源模型（好比 Queuing Theory、負載方案、雪崩問題）
• 資源編排系統（Mesos / Kurbernetes）

發佈於 17:38