最常見的誤區(qū)：

• DevOps 新概念，好高級哦
• SRE 是高級版 DevOps
• 運(yùn)維可以輕松轉(zhuǎn)身 DevOps 工程師

DevOps 和 SRE 定義

DevOps 是字面上 Dev 開發(fā) / Ops 運(yùn)維兩者組合， 嚴(yán)格意義上 DevOps 如下（via DevOps - Wikipedia）：

DevOps（Development 和 Operations 的組合詞）是一種重視“軟件開發(fā)人員（Dev） ”和“IT 運(yùn)維技術(shù)人員（Ops）”之間溝通合作的文化、運(yùn)動或慣例。

SRE 全稱是 Site Reliability Engineering，最早是由 Google 提出，并且在其工程實(shí)踐中發(fā)揚(yáng)光大。 他們還出了一本同名書籍「Site Reliability Engineering」， 讓這個理念在互聯(lián)網(wǎng)工程師圈子里廣泛傳播。

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ǎng)站穩(wěn)定性工程師是致力于打造「高擴(kuò)展、高可用系統(tǒng)」，并將其貫徹為原則的軟件工程師。

從定義來看，DevOps 是文化、運(yùn)動和慣例，而 SRE 是有嚴(yán)格任職要求的職位。 文化是軟性定義，文化有更多概念可以捏造，而 SRE 定義精準(zhǔn)，就少了想象空間（也可能 SRE 門檻高 ）。 按 Google 給出的說法是，SRE 工程師實(shí)踐了 DevOps 文化。這個觀點(diǎn)沒錯，但是國內(nèi)的 DevOps 逐步獨(dú)立出 DevOps 工程師， 所以在本文，我著重討論的是 DevOps 工程師和 SRE 工程師兩種職位對比。

兩者產(chǎn)生背景和歷史

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

互聯(lián)網(wǎng)浪潮之后，軟件由傳統(tǒng)意義上桌面軟件演變?yōu)槊嫦蚓W(wǎng)站、手機(jī)應(yīng)用。 這時候業(yè)務(wù)核心邏輯，比如交易，社交行為都不在用戶桌面完成，而是在服務(wù)器后端完成。 這給互聯(lián)網(wǎng)企業(yè)給予了極大操作空間：隨時可以改變業(yè)務(wù)邏輯，這促進(jìn)了業(yè)務(wù)快速迭代變更。 但即便這樣，Dev 和 Ops 是極其分裂的兩個環(huán)節(jié)。Ops 不關(guān)心代碼是如何運(yùn)作的，Dev 不知道代碼如何運(yùn)行在服務(wù)器上。

當(dāng)業(yè)界還沉浸在可以每周發(fā)布版本喜悅中時，2009 年，F(xiàn)licker 提出了每天發(fā)布 10+ 次概念，大大震撼了業(yè)界。 Flicker 提出了幾個核心理念：

• 業(yè)務(wù)快速發(fā)展，需要擁抱變更，小步快跑
• Ops 目標(biāo)不是為了網(wǎng)站穩(wěn)定和快速，而是推動業(yè)務(wù)快速發(fā)展
• 基于自動化工具提高 Dev / Ops 聯(lián)接：代碼版本管理、監(jiān)控
• 高效溝通：IRC / IM Robot（現(xiàn)在那些 ChatBot 套路，10 年前就被 Flicker 玩過了）
• 信任、透明、高效、互助的溝通文化

真是讓人難以想象，今天各種培訓(xùn)公司和一些知名大 V 在呼喚這些 DevOps 理念， 竟然在 2009 年一份幻燈片中就展現(xiàn)淋漓盡致。經(jīng)典總是不過時，在塵封下閃耀著智慧光芒。 有些人將 DevOps 和運(yùn)維自動化等同，這是只看到表象。 DevOps 目標(biāo)是提高業(yè)務(wù)系統(tǒng)交付速度，并為之提供相關(guān)工具、制度和服務(wù)。 一些個人或培訓(xùn)機(jī)構(gòu)添油加醋和衍生含義，都是圍繞這 DevOps 本質(zhì)而發(fā)散。

接下來聊聊 SRE 歷史， SRE 出現(xiàn)要晚一些。在 2003 年時候 Google 的 Ben Treynor 招募了幾個軟件工程師，這個團(tuán)隊(duì)設(shè)立目的是幫助 Google 生產(chǎn)環(huán)境服務(wù)運(yùn)行更穩(wěn)定、健壯、可靠。 不同于中小型規(guī)模公司，Google 服務(wù)于十幾億用戶服務(wù)，短暫服務(wù)不可用會帶來致命后果。 因此 Google 走在了時代最前面，SRE 產(chǎn)生了。 這個職位為大規(guī)模集群服務(wù)，小型團(tuán)隊(duì)不需要這樣職位設(shè)定（可能也招不起真正 SRE ）。 Google 在探索若干年之后，SRE 團(tuán)隊(duì)開始將自己心得體會寫在線上，并在 2016 年將此書出版。

兩者的職能不同

現(xiàn)在不少公司將 DevOps 職能單獨(dú)抽取出來，稱之為 DevOps 工程師。 那讓我們看看 DevOps 工程師關(guān)心什么：DevOps 文化目的是提交交付速度， DevOps 工程師就自然會關(guān)心軟件 / 服務(wù)的整個生命周期。 一個簡單的公式：速度 = 總量 / 時間，添上工程行業(yè)術(shù)語，即 交付速度 = （（功能特性 * 工程質(zhì)量） / 交付時間） * 交付風(fēng)險。

功能特性交給產(chǎn)品經(jīng)理和項(xiàng)目經(jīng)理管理，DevOps 工程師需要關(guān)心剩下幾個因素：工程質(zhì)量 / 交付時間 / 交付風(fēng)險。 DevOps 工程師職能如下：

• 管理應(yīng)用全生命周期（需求、設(shè)計、開發(fā)、QA、發(fā)布、運(yùn)行）
• 關(guān)注全流程效率提升，挖掘瓶頸點(diǎn)并將其解決
• 自動化運(yùn)維平臺設(shè)計和研發(fā)工作（標(biāo)準(zhǔn)化、自動化、平臺化）
• 支持運(yùn)維系統(tǒng)，包括 虛擬化技術(shù)、資源管理技術(shù)、監(jiān)控技術(shù)、網(wǎng)絡(luò)技術(shù)

SRE 關(guān)鍵詞是「高擴(kuò)展性」「高可用性」。高擴(kuò)展性是指當(dāng)服務(wù)用戶數(shù)量暴增時， 應(yīng)用系統(tǒng)以及支撐其服務(wù)（服務(wù)器資源、網(wǎng)絡(luò)系統(tǒng)、數(shù)據(jù)庫資源）可以在不調(diào)整系統(tǒng)結(jié)構(gòu)，不強(qiáng)化機(jī)器本身性能 ，僅僅增加實(shí)例數(shù)量方式進(jìn)行擴(kuò)容。高可用性是指，應(yīng)用架構(gòu)中任何環(huán)節(jié)出現(xiàn)不可用時，比如應(yīng)用服務(wù)、網(wǎng)關(guān)、數(shù)據(jù)庫 等系統(tǒng)掛掉，整個系統(tǒng)可以在可預(yù)見時間內(nèi)恢復(fù)并重新提供服務(wù)。當(dāng)然，既然是「高」可用， 那么這個時間一般期望在分鐘級別。SRE 職能可以概括為以下：

• 為 應(yīng)用、中間件、基礎(chǔ)設(shè)施等提供 選型、設(shè)計、開發(fā)、容量規(guī)劃、調(diào)優(yōu)、故障處理
• 為業(yè)務(wù)系統(tǒng)提供基于可用性、可擴(kuò)展性考慮決策，參與業(yè)務(wù)系統(tǒng)設(shè)計和實(shí)施
• 定位、處理、管理故障，優(yōu)化導(dǎo)致故障發(fā)生相關(guān)部件
• 提高各部件資源利用率

工作內(nèi)容不同

職責(zé)不同導(dǎo)致兩個職位工作內(nèi)容也不盡相同，我將 DevOps 工程師和 SRE 工程師職能列舉如下：

• • DevOps
    • 設(shè)定應(yīng)用生命管理周期制度，扭轉(zhuǎn)流程
    • 開發(fā)、管理 開發(fā)工程師 /QA 工程師使用 開發(fā)平臺系統(tǒng)
    • 開發(fā)、管理 發(fā)布系統(tǒng)
    • 開發(fā)、選型、管理 監(jiān)控、報警系統(tǒng)
    • 開發(fā)、管理 權(quán)限系統(tǒng)
    • 開發(fā)、選型、管理 CMBD
    • 管理變更
    • 管理故障

• SRE
  • 管理變更
  • 管理故障
  • 制定 SLA 服務(wù)標(biāo)準(zhǔn)
  • 開發(fā)、選型、管理 各類中間件
  • 開發(fā)、管理 分布式監(jiān)控系統(tǒng)
  • 開發(fā)、管理 分布式追蹤系統(tǒng)
  • 開發(fā)、管理 性能監(jiān)控、探測系統(tǒng)（dtrace、火焰圖）
  • 開發(fā)、選型、培訓(xùn) 性能調(diào)優(yōu)工具

很有趣的對比，DevOps 和 SRE 都會關(guān)心應(yīng)用生命周期，特別是生命周期里面中變更和故障。 但是 DevOps 工作內(nèi)容是主要為開發(fā)鏈路服務(wù)，一個 DevOps Team 通常會提供一串工具鏈， 這其中會包括：開發(fā)工具、版本管理工具、CI 持續(xù)交付工具、CD 持續(xù)發(fā)布工具、報警工具、故障處理。 而 SRE Team 則關(guān)注更為關(guān)注變更、故障、性能、容量相關(guān)問題，會涉及具體業(yè)務(wù)，產(chǎn)出工具鏈會有： 容量測量工具、Logging 日志工具、Tracing 調(diào)用鏈路跟蹤工具、Metrics 性能度量工具、監(jiān)控報警工具等。

DevOps 和 SRE 關(guān)系

DevOps 首先是一種文化，后期逐漸獨(dú)立成一個職位；SRE 一開始就明確是一個職位； 不少同學(xué)把 DevOps 和 SRE 搞混，是被兩者表象鎖迷惑，看上去這兩者都有的工具屬性、自動化要求也相似。 甚至有一些開發(fā)同學(xué)把這類運(yùn)維工作都統(tǒng)一理解為：服務(wù)器 + 工具 + 自動化。這是盲人摸象，管中窺豹。

從技能上來說，兩者都需要較強(qiáng)的運(yùn)維技能。 在職業(yè)發(fā)展天花板上，DevOps 可能缺乏 SRE 在一些專業(yè)領(lǐng)域的技能： 計算機(jī)體系結(jié)構(gòu)能力；高吞吐高并發(fā)優(yōu)化能力；可擴(kuò)展系統(tǒng)設(shè)計能力；復(fù)雜系統(tǒng)設(shè)計能力；業(yè)務(wù)系統(tǒng)排查能力。 兩者都需要軟實(shí)力，但是 SRE 面臨復(fù)雜度更高，挑戰(zhàn)更大，要求也更高：

DevOps 具有普遍意義，現(xiàn)代互聯(lián)網(wǎng)公司都需要 DevOps，但是并非所有團(tuán)隊(duì)對高可用性、高擴(kuò)展性存在需求，它們不需要 SRE。 DevOps 工程師掌握相關(guān)技能之后，也有機(jī)會可以發(fā)展為 SRE 工程師。 而一位合格 SRE 工程師，在有選擇情況下面，我相信不會去轉(zhuǎn)型為 DevOps 工程師。

從專業(yè)背景來看，無論是 DevOps 還是 SRE 工程師，都需要研發(fā)背景，前者需要開發(fā)工具鏈，后者需要有較強(qiáng)架構(gòu)設(shè)計經(jīng)驗(yàn)。 如果有運(yùn)維工程師想轉(zhuǎn)型成為 DevOps 或者 SRE，那么需要補(bǔ)上相關(guān)技術(shù)知識。 畢竟，不是會搭建一套 Jenkins + Kubernetes 就可以自稱為 DevOps / SRE 工程師。

給大家推薦一個靠譜的培訓(xùn)機(jī)構(gòu)--馬哥教育

馬哥教育DevOps 特訓(xùn)班

馬哥Linux云計算SRE課程

教學(xué)模式采用的是【雙軌驅(qū)動】，即技能實(shí)戰(zhàn)能力和綜合面試能力。保證學(xué)員入職后2-3年內(nèi)的職業(yè)發(fā)展，而且就業(yè)和架構(gòu)師兩個部分，考慮到了學(xué)員的實(shí)際需求，滿足運(yùn)維更深層次的進(jìn)階，可以更全面、更匹配的提高個人能力。

技能實(shí)戰(zhàn)：專業(yè)成長線路，保證基礎(chǔ)核心知識；20+生產(chǎn)環(huán)境企業(yè)級案例，攻克技術(shù)難點(diǎn)。

綜合能力：7條高薪關(guān)鍵路徑，保障高薪就業(yè)率，打造全面人才。

從項(xiàng)目環(huán)境到后期答疑，都采取了十分完善的措施，1：1仿真的云環(huán)境，專業(yè)配套的課程手冊，盡可能地保證每位學(xué)員都能提高實(shí)戰(zhàn)水平。而且，PK小組、助學(xué)獎勵、試用期幫扶和優(yōu)秀獎勵等服務(wù)，也保證了學(xué)習(xí)干貨的同時，也能提高趣味性，學(xué)員完全不用擔(dān)心課程質(zhì)量。

課程中引入了多云案例，更新優(yōu)化30+技術(shù)模塊，所有的實(shí)戰(zhàn)項(xiàng)目均來自一線互聯(lián)網(wǎng)大廠，全是真實(shí)生產(chǎn)環(huán)境會遇到的項(xiàng)目。細(xì)心的教學(xué)確保你能切實(shí)掌握項(xiàng)目的總體思路、步驟及方法，提升你的項(xiàng)目實(shí)戰(zhàn)能力，積累自己的方法論，學(xué)完以后在工作中能高效、準(zhǔn)確的完成各個項(xiàng)目。

怎么樣，有沒有解開這幾個常見誤區(qū)呢？希望你看到這里可以豁然開朗 期望有志成為這兩種工程師的同學(xué)，加油努力。

鏈接：https://zhuanlan.zhihu.com/p/87598465