DevOps和SRE的區別是什么?有好的培訓機構嗎?
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
- 管理變更
- 管理故障
- DevOps
- 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 特訓班
![圖片](http://haohuigou.com/wp-content/themes/module/themer/assets/images/lazy.png)
![圖片](http://haohuigou.com/wp-content/themes/module/themer/assets/images/lazy.png)
馬哥Linux云計算SRE課程
教學模式采用的是【雙軌驅動】,即技能實戰能力和綜合面試能力。保證學員入職后2-3年內的職業發展,而且就業和架構師兩個部分,考慮到了學員的實際需求,滿足運維更深層次的進階,可以更全面、更匹配的提高個人能力。
技能實戰:專業成長線路,保證基礎核心知識;20+生產環境企業級案例,攻克技術難點。
綜合能力:7條高薪關鍵路徑,保障高薪就業率,打造全面人才。
![圖片](http://haohuigou.com/wp-content/themes/module/themer/assets/images/lazy.png)
從項目環境到后期答疑,都采取了十分完善的措施,1:1仿真的云環境,專業配套的課程手冊,盡可能地保證每位學員都能提高實戰水平。而且,PK小組、助學獎勵、試用期幫扶和優秀獎勵等服務,也保證了學習干貨的同時,也能提高趣味性,學員完全不用擔心課程質量。
課程中引入了多云案例,更新優化30+技術模塊,所有的實戰項目均來自一線互聯網大廠,全是真實生產環境會遇到的項目。細心的教學確保你能切實掌握項目的總體思路、步驟及方法,提升你的項目實戰能力,積累自己的方法論,學完以后在工作中能高效、準確的完成各個項目。
![圖片](http://haohuigou.com/wp-content/themes/module/themer/assets/images/lazy.png)
![圖片](http://haohuigou.com/wp-content/themes/module/themer/assets/images/lazy.png)
![圖片](http://haohuigou.com/wp-content/themes/module/themer/assets/images/lazy.png)
![圖片](http://haohuigou.com/wp-content/themes/module/themer/assets/images/lazy.png)
怎么樣,有沒有解開這幾個常見誤區呢?希望你看到這里可以豁然開朗 期望有志成為這兩種工程師的同學,加油努力。
鏈接:https://zhuanlan.zhihu.com/p/87598465