DevOps 和 SRE

alswl發表於2018-09-09
dev

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

最常見的誤區：

  • DevOps 新概念，好高階哦
  • SRE 是高階版 DevOps
  • 運維可以輕鬆轉身 DevOps 工程師

讓我一一給你講解吧。

sre-and-devops.png
image via YouTube

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 這個崗位。

qq-2004.png

網際網路浪潮之後，軟體由傳統意義上桌面軟體演變為面向網站、手機應用。 這時候業務核心邏輯，比如交易，社交行為都不在使用者桌面完成，而是在伺服器後端完成。 這給網際網路企業給予了極大操作空間：隨時可以改變業務邏輯，這促進了業務快速迭代變更。 但即便這樣，Dev 和 Ops 是極其分裂的兩個環節。Ops 不關心程式碼是如何運作的，Dev 不知道程式碼如何執行在伺服器上。

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

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

flicker.png

原文 SlideShare 在這 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

真是讓人難以想象，今天各種培訓公司和一些知名大 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 工程師需要關心剩下幾個因素：工程質量 / 交付時間 / 交付風險。 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
    • 語言
      • Pytho
      • 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+1、遠端呼叫、不合理 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）

Ref

原文連結: DevOps 和 SRE - Log4D

歡迎關注我的微信公眾號：窺豹

窺豹

如果對你有幫助，給作者 ￥2 買張彩票吧。

3a1ff193cee606bd1e2ea554a16353ee

相關文章