最近有一位朋友和我聊職業(yè)發(fā)展方向問題，聊了不少 DevOps 和 SRE 話題。 我?guī)啄昵皠偨佑|這兩個概念時也常常將之混淆，可惜當時沒有人來解答我困惑。 現在這雖然已經極為流行，但是我發(fā)現我這位朋友對這兩個職位還存在一些誤區(qū)。 于是我給了一些見解并整理成文章以饕大眾。
最常見的誤區(qū)：
- DevOps 新概念，好高級哦
- SRE 是高級版 DevOps
- 運維可以輕松轉身 DevOps 工程師
讓我一一給你講解吧。
DevOps 和 SRE 定義
DevOps 是字面上 Dev 開發(fā) / Ops 運維兩者組合， 嚴格意義上 DevOps 如下（via DevOps - Wikipedia）：
DevOps（Development 和 Operations 的組合詞）是一種重視“軟件開發(fā)人員（Dev） ”和“IT 運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。
SRE 全稱是 Site Reliability Engineering，最早是由 Google 提出，并且在其工程實踐中發(fā)揚光大。 他們還出了一本同名書籍「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.
我將其翻譯翻譯為中文：
網站穩(wěn)定性工程師是致力于打造「高擴展、高可用系統」，并將其貫徹為原則的軟件工程師。
從定義來看，DevOps 是文化、運動和慣例，而 SRE 是有嚴格任職要求的職位。 文化是軟性定義，文化有更多概念可以捏造，而 SRE 定義精準，就少了想象空間（也可能 SRE 門檻高 ??）。 按 Google 給出的說法是，SRE 工程師實踐了 DevOps 文化。這個觀點沒錯，但是國內的 DevOps 逐步獨立出 DevOps 工程師， 所以在本文，我著重討論的是 DevOps 工程師和 SRE 工程師兩種職位對比。
兩者產生背景和歷史
互聯網需求催生了 DevOps 。在最傳統軟件企業(yè)中，是只有 Dev 沒有 Ops， 那時 Ops 可能還是只是技術支持人員。開發(fā)按照瀑布流：需求分析、系統設計、開發(fā)、測試、交付、運行， 傳統軟件發(fā)布是一個重量級操作。一旦發(fā)布，Dev 幾乎不再直接操作。 80 后可能會記得 QQ 每年都會有一個大版本發(fā)布吧，QQ 2000 / 2003 / 2004 等等。 此時 Ops 不用和 Dev 直接高頻接觸，甚至針對一些純離線業(yè)務，壓根沒有設立 Ops 這個崗位。
互聯網浪潮之后，軟件由傳統意義上桌面軟件演變?yōu)槊嫦蚓W站、手機應用。 這時候業(yè)務核心邏輯，比如交易，社交行為都不在用戶桌面完成，而是在服務器后端完成。 這給互聯網企業(yè)給予了極大操作空間：隨時可以改變業(yè)務邏輯，這促進了業(yè)務快速迭代變更。 但即便這樣，Dev 和 Ops 是極其分裂的兩個環(huán)節(jié)。Ops 不關心代碼是如何運作的，Dev 不知道代碼如何運行在服務器上。
當業(yè)界還沉浸在可以每周發(fā)布版本喜悅中時，2009 年，Flicker 提出了每天發(fā)布 10+ 次概念，大大震撼了業(yè)界。 Flicker 提出了幾個核心理念：
- 業(yè)務快速發(fā)展，需要擁抱變更，小步快跑
- Ops 目標不是為了網站穩(wěn)定和快速，而是推動業(yè)務快速發(fā)展
- 基于自動化工具提高 Dev / Ops 聯接：代碼版本管理、監(jiān)控
- 高效溝通：IRC / IM Robot（現在那些 ChatBot 套路，10 年前就被 Flicker 玩過了）
- 信任、透明、高效、互助的溝通文化
原文 SlideShare 在這 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
真是讓人難以想象，今天各種培訓公司和一些知名大 V 在呼喚這些 DevOps 理念， 竟然在 2009 年一份幻燈片中就展現淋漓盡致。經典總是不過時，在塵封下閃耀著智慧光芒。 有些人將 DevOps 和運維自動化等同，這是只看到表象。 DevOps 目標是提高業(yè)務系統交付速度，并為之提供相關工具、制度和服務。 一些個人或培訓機構添油加醋和衍生含義，都是圍繞這 DevOps 本質而發(fā)散。
接下來聊聊 SRE 歷史， SRE 出現要晚一些。在 2003 年時候 Google 的 Ben Treynor 招募了幾個軟件工程師，這個團隊設立目的是幫助 Google 生產環(huán)境服務運行更穩(wěn)定、健壯、可靠。 不同于中小型規(guī)模公司，Google 服務于十幾億用戶服務，短暫服務不可用會帶來致命后果。 因此 Google 走在了時代最前面，SRE 產生了。
這個職位為大規(guī)模集群服務，小型團隊不需要這樣職位設定（可能也招不起真正 SRE ??）。 Google 在探索若干年之后，SRE 團隊開始將自己心得體會寫在線上，并在 2016 年將此書出版。
兩者的職能不同
DevOps 文化，那么就沒有一個具象職能要求。現在不少公司將 DevOps 職能單獨抽取出來，稱之為 DevOps 工程師。 那讓我們看看 DevOps 工程師關心什么：DevOps 文化目的是提交交付速度， DevOps 工程師就自然會關心軟件 / 服務的整個生命周期。
一個簡單的公式：速度 = 總量 / 時間，添上工程行業(yè)術語，即 交付速度 = （（功能特性 * 工程質量） / 交付時間） * 交付風險。
功能特性交給產品經理和項目經理管理，DevOps 工程師需要關心剩下幾個因素：工程質量 / 交付時間 / 交付風險。 DevOps 工程師職能如下：
- 管理應用全生命周期（需求、設計、開發(fā)、QA、發(fā)布、運行）
- 關注全流程效率提升，挖掘瓶頸點并將其解決
- 自動化運維平臺設計和研發(fā)工作（標準化、自動化、平臺化）
- 支持運維系統，包括 虛擬化技術、資源管理技術、監(jiān)控技術、網絡技術
SRE 關鍵詞是「高擴展性」「高可用性」。高擴展性是指當服務用戶數量暴增時， 應用系統以及支撐其服務（服務器資源、網絡系統、數據庫資源）可以在不調整系統結構，不強化機器本身性能 ，僅僅增加實例數量方式進行擴容。高可用性是指，應用架構中任何環(huán)節(jié)出現不可用時，比如應用服務、網關、數據庫 等系統掛掉，整個系統可以在可預見時間內恢復并重新提供服務。當然，既然是「高」可用， 那么這個時間一般期望在分鐘級別。SRE 職能可以概括為以下：
- 為 應用、中間件、基礎設施等提供 選型、設計、開發(fā)、容量規(guī)劃、調優(yōu)、故障處理
- 為業(yè)務系統提供基于可用性、可擴展性考慮決策，參與業(yè)務系統設計和實施
- 定位、處理、管理故障，優(yōu)化導致故障發(fā)生相關部件
- 提高各部件資源利用率
工作內容不同
職責不同導致兩個職位工作內容也不盡相同，我將 DevOps 工程師和 SRE 工程師職能列舉如下：
- DevOps
- 設定應用生命管理周期制度，扭轉流程
- 開發(fā)、管理 開發(fā)工程師 /QA 工程師使用 開發(fā)平臺系統
- 開發(fā)、管理 發(fā)布系統
- 開發(fā)、選型、管理 監(jiān)控、報警系統
- 開發(fā)、管理 權限系統
- 開發(fā)、選型、管理 CMBD
- 管理變更
- 管理故障
- SRE
- 管理變更
- 管理故障
- 制定 SLA 服務標準
- 開發(fā)、選型、管理 各類中間件
- 開發(fā)、管理 分布式監(jiān)控系統
- 開發(fā)、管理 分布式追蹤系統
- 開發(fā)、管理 性能監(jiān)控、探測系統（dtrace、火焰圖）
- 開發(fā)、選型、培訓 性能調優(yōu)工具
很有趣的對比，DevOps 和 SRE 都會關心應用生命周期，特別是生命周期里面中變更和故障。 但是 DevOps 工作內容是主要為開發(fā)鏈路服務，一個 DevOps Team 通常會提供一串工具鏈， 這其中會包括：開發(fā)工具、版本管理工具、CI 持續(xù)交付工具、CD 持續(xù)發(fā)布工具、報警工具、故障處理。 而 SRE Team 則關注更為關注變更、故障、性能、容量相關問題，會涉及具體業(yè)務，產出工具鏈會有： 容量測量工具、Logging 日志工具、Tracing 調用鏈路跟蹤工具、Metrics 性能度量工具、監(jiān)控報警工具等。
DevOps 和 SRE 關系
DevOps 首先是一種文化，后期逐漸獨立成一個職位；SRE 一開始就明確是一個職位； 不少同學把 DevOps 和 SRE 搞混，是被兩者表象鎖迷惑，看上去這兩者都有的工具屬性、自動化要求也相似。 甚至有一些開發(fā)同學把這類運維工作都統一理解為：服務器 + 工具 + 自動化。這是盲人摸象，管中窺豹。
從技能上來說，兩者都需要較強的運維技能。 在職業(yè)發(fā)展天花板上，DevOps 可能缺乏 SRE 在一些專業(yè)領域的技能： 計算機體系結構能力；高吞吐高并發(fā)優(yōu)化能力；可擴展系統設計能力；復雜系統設計能力；業(yè)務系統排查能力。 兩者都需要軟實力，但是 SRE 面臨復雜度更高，挑戰(zhàn)更大，要求也更高：
- 分析問題、解決問題能力
- 戰(zhàn)勝困難決心
- 面對挑戰(zhàn)熱情
- 自驅學習
DevOps 具有普遍意義，現代互聯網公司都需要 DevOps，但是并非所有團隊對高可用性、高擴展性存在需求，它們不需要 SRE。 DevOps 工程師掌握相關技能之后，也有機會可以發(fā)展為 SRE 工程師。 而一位合格 SRE 工程師，在有選擇情況下面，我相信不會去轉型為 DevOps 工程師。
從專業(yè)背景來看，無論是 DevOps 還是 SRE 工程師，都需要研發(fā)背景，前者需要開發(fā)工具鏈，后者需要有較強架構設計經驗。 如果有運維工程師想轉型成為 DevOps 或者 SRE，那么需要補上相關技術知識。 畢竟，不是會搭建一套 Jenkins + Kubernetes 就可以自稱為 DevOps / SRE 工程師。
怎么樣，有沒有解開這幾個常見誤區(qū)呢？希望你看到這里可以豁然開朗，最后附上兩個工程師的技能點， 期望有志成為這兩種工程師的同學，加油努力。
附錄：技能點
DevOps：
- Operator 技能
- Linux Basis
- 基本命令操作
- Linux FHS（Filesystem Hierarchy Standard 文件系統層次結構標準）
- Linux 系統（差異、歷史、標準、發(fā)展）
- 腳本
- Bash / Python
- 基礎服務
- DHCP / NTP / DNS / SSH / iptables / LDAP / CMDB
- 自動化工具
- Fabric / Saltstack / Chef / Ansible
- 基礎監(jiān)控工具
- Zabbix / Nagios / Cacti
- 虛擬化
- KVM 管理 / XEN 管理 / vSphere 管理 / Docker
- 容器編排 / Mesos / Kubernetes
- 服務
- Nginx / F5 / HAProxy / LVS 負載均衡
- 常見中間件 Operate（啟動、關閉、重啟、擴容）
- Linux Basis
- Dev
- 語言
- Python
- Go（可選）
- Java（了解部署）
- 流程和理論
- Application Life Cycle
- 12 Factor
- 微服務概念、部署、生命周期
- CI 持續(xù)集成 / Jenkins / Pipeline / Git Repo Web Hook
- CD 持續(xù)發(fā)布系統
- 基礎設施
- Git Repo / Gitlab / Github
- Logstash / Flume 日志收集
- 配置文件管理（應用、中間件等）
- Nexus / JFrog / Pypi 包依賴管理
- 面向 開發(fā) / QA 開發(fā)環(huán)境管理系統
- 線上權限分配系統
- 監(jiān)控報警系統
- 基于 Fabric / Saltstack / Chef / Ansible 自動化工具開發(fā)
- 語言
SRE：
- 語言和工程實現
- 深入理解開發(fā)語言（假設是 Java）
- 業(yè)務部門使用開發(fā)框架
- 并發(fā)、多線程和鎖
- 資源模型理解：網絡、內存、CPU
- 故障處理能力（分析瓶頸、熟悉相關工具、還原現場、提供方案）
- 常見業(yè)務設計方案和陷阱（比如 Business Modeling，N+1、遠程調用、不合理 DB 結構）
- MySQL / Mongo OLTP 類型查詢優(yōu)化
- 多種并發(fā)模型，以及相關 Scalable 設計
- 深入理解開發(fā)語言（假設是 Java）
- 問題定位工具
- 容量管理
- Tracing 鏈路追蹤
- Metrics 度量工具
- Logging 日志系統
- 運維架構能力
- Linux 精通，理解 Linux 負載模型，資源模型
- 熟悉常規(guī)中間件（MySQL Nginx Redis Mongo ZooKeeper 等），能夠調優(yōu)
- Linux 網絡調優(yōu)，網絡 IO 模型以及在語言里面實現
- 資源編排系統（Mesos / Kubernetes）
- 理論
- 容量規(guī)劃方案
- 熟悉分布式理論（Paxos / Raft / BigTable / MapReduce / Spanner 等），能夠為場景決策合適方案
- 性能模型（比如 Pxx 理解、Metrics、Dapper）
- 資源模型（比如 Queuing Theory、負載方案、雪崩問題）
- 資源編排系統（Mesos / Kurbernetes）
Ref
- DevOps - 維基百科，自由的百科全書
- Site reliability engineering - Wikipedia
- StuQ 技能圖譜
- The Twelve-Factor App （簡體中文）
- Google - Site Reliability Engineering
- What's the Difference Between DevOps and SRE? - YouTube
原文鏈接: DevOps 和 SRE - Log4D
歡迎關注我的微信公眾號：窺豹
3a1ff193cee606bd1e2ea554a16353ee
