最近有一位朋友和我聊職業(yè)發(fā)展方向問(wèn)題，聊了不少 DevOps 和 SRE 話(huà)題。 我?guī)啄昵皠偨佑|這兩個(gè)概念時(shí)也常常將之混淆，可惜當(dāng)時(shí)沒(méi)有人來(lái)解答我困惑碗暗。 現(xiàn)在這雖然已經(jīng)極為流行，但是我發(fā)現(xiàn)我這位朋友對(duì)這兩個(gè)職位還存在一些誤區(qū)梢夯。 于是我給了一些見(jiàn)解并整理成文章以饕大眾言疗。

最常見(jiàn)的誤區(qū)：

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

讓我一一給你講解吧厨疙。

sre-and-devops.png

DevOps 和 SRE 定義

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

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

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

Google 對(duì) 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)」手负，并將其貫徹為原則的軟件工程師涤垫。

從定義來(lái)看，DevOps 是文化竟终、運(yùn)動(dòng)和慣例蝠猬，而 SRE 是有嚴(yán)格任職要求的職位。 文化是軟性定義统捶，文化有更多概念可以捏造榆芦，而 SRE 定義精準(zhǔn)，就少了想象空間（也可能 SRE 門(mén)檻高 ??）喘鸟。 按 Google 給出的說(shuō)法是匆绣，SRE 工程師實(shí)踐了 DevOps 文化。這個(gè)觀點(diǎn)沒(méi)錯(cuò)什黑，但是國(guó)內(nèi)的 DevOps 逐步獨(dú)立出 DevOps 工程師崎淳， 所以在本文，我著重討論的是 DevOps 工程師和 SRE 工程師兩種職位對(duì)比愕把。

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

互聯(lián)網(wǎng)需求催生了 DevOps 拣凹。在最傳統(tǒng)軟件企業(yè)中，是只有 Dev 沒(méi)有 Ops礼华， 那時(shí) Ops 可能還是只是技術(shù)支持人員咐鹤。開(kāi)發(fā)按照瀑布流：需求分析拗秘、系統(tǒng)設(shè)計(jì)圣絮、開(kāi)發(fā)、測(cè)試雕旨、交付扮匠、運(yùn)行， 傳統(tǒng)軟件發(fā)布是一個(gè)重量級(jí)操作凡涩。一旦發(fā)布棒搜，Dev 幾乎不再直接操作。 80 后可能會(huì)記得 QQ 每年都會(huì)有一個(gè)大版本發(fā)布吧活箕，QQ 2000 / 2003 / 2004 等等力麸。 此時(shí) Ops 不用和 Dev 直接高頻接觸，甚至針對(duì)一些純離線(xiàn)業(yè)務(wù)育韩，壓根沒(méi)有設(shè)立 Ops 這個(gè)崗位克蚂。

qq-2004.png

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

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

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

flicker.png

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

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

接下來(lái)聊聊 SRE 歷史， SRE 出現(xiàn)要晚一些厌秒。在 2003 年時(shí)候 Google 的 Ben Treynor 招募了幾個(gè)軟件工程師读拆，這個(gè)團(tuán)隊(duì)設(shè)立目的是幫助 Google 生產(chǎn)環(huán)境服務(wù)運(yùn)行更穩(wěn)定、健壯简僧、可靠建椰。 不同于中小型規(guī)模公司，Google 服務(wù)于十幾億用戶(hù)服務(wù)岛马，短暫服務(wù)不可用會(huì)帶來(lái)致命后果棉姐。 因此 Google 走在了時(shí)代最前面屠列，SRE 產(chǎn)生了。

這個(gè)職位為大規(guī)模集群服務(wù)伞矩，小型團(tuán)隊(duì)不需要這樣職位設(shè)定（可能也招不起真正 SRE ??）笛洛。 Google 在探索若干年之后，SRE 團(tuán)隊(duì)開(kāi)始將自己心得體會(huì)寫(xiě)在線(xiàn)上乃坤，并在 2016 年將此書(shū)出版苛让。

兩者的職能不同

DevOps 文化，那么就沒(méi)有一個(gè)具象職能要求∈铮現(xiàn)在不少公司將 DevOps 職能單獨(dú)抽取出來(lái)狱杰，稱(chēng)之為 DevOps 工程師。 那讓我們看看 DevOps 工程師關(guān)心什么：DevOps 文化目的是提交交付速度厅须， DevOps 工程師就自然會(huì)關(guān)心軟件 / 服務(wù)的整個(gè)生命周期仿畸。

一個(gè)簡(jiǎn)單的公式：速度 = 總量 / 時(shí)間，添上工程行業(yè)術(shù)語(yǔ)朗和，即 交付速度 = （（功能特性 * 工程質(zhì)量） / 交付時(shí)間） * 交付風(fēng)險(xiǎn)错沽。

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

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

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

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

工作內(nèi)容不同

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

• DevOps
  • 設(shè)定應(yīng)用生命管理周期制度关带，扭轉(zhuǎn)流程
  • 開(kāi)發(fā)侥涵、管理 開(kāi)發(fā)工程師 /QA 工程師使用 開(kāi)發(fā)平臺(tái)系統(tǒng)
  • 開(kāi)發(fā)、管理 發(fā)布系統(tǒng)
  • 開(kāi)發(fā)宋雏、選型芜飘、管理 監(jiān)控、報(bào)警系統(tǒng)
  • 開(kāi)發(fā)磨总、管理 權(quán)限系統(tǒng)
  • 開(kāi)發(fā)嗦明、選型、管理 CMBD
  • 管理變更
  • 管理故障
• SRE
  • 管理變更
  • 管理故障
  • 制定 SLA 服務(wù)標(biāo)準(zhǔn)
  • 開(kāi)發(fā)蚪燕、選型娶牌、管理 各類(lèi)中間件
  • 開(kāi)發(fā)、管理 分布式監(jiān)控系統(tǒng)
  • 開(kāi)發(fā)馆纳、管理 分布式追蹤系統(tǒng)
  • 開(kāi)發(fā)诗良、管理 性能監(jiān)控、探測(cè)系統(tǒng)（dtrace鲁驶、火焰圖）
  • 開(kāi)發(fā)鉴裹、選型、培訓(xùn) 性能調(diào)優(yōu)工具

很有趣的對(duì)比，DevOps 和 SRE 都會(huì)關(guān)心應(yīng)用生命周期径荔，特別是生命周期里面中變更和故障督禽。 但是 DevOps 工作內(nèi)容是主要為開(kāi)發(fā)鏈路服務(wù)，一個(gè) DevOps Team 通常會(huì)提供一串工具鏈猖凛， 這其中會(huì)包括：開(kāi)發(fā)工具赂蠢、版本管理工具、CI 持續(xù)交付工具辨泳、CD 持續(xù)發(fā)布工具虱岂、報(bào)警工具、故障處理菠红。 而 SRE Team 則關(guān)注更為關(guān)注變更第岖、故障、性能试溯、容量相關(guān)問(wèn)題蔑滓，會(huì)涉及具體業(yè)務(wù)，產(chǎn)出工具鏈會(huì)有： 容量測(cè)量工具遇绞、Logging 日志工具键袱、Tracing 調(diào)用鏈路跟蹤工具、Metrics 性能度量工具摹闽、監(jiān)控報(bào)警工具等蹄咖。

DevOps 和 SRE 關(guān)系

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

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

• 分析問(wèn)題、解決問(wèn)題能力
• 戰(zhàn)勝困難決心
• 面對(duì)挑戰(zhàn)熱情
• 自驅(qū)學(xué)習(xí)

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

從專(zhuān)業(yè)背景來(lái)看熊镣，無(wú)論是 DevOps 還是 SRE 工程師，都需要研發(fā)背景募书，前者需要開(kāi)發(fā)工具鏈绪囱，后者需要有較強(qiáng)架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)富岳。 如果有運(yùn)維工程師想轉(zhuǎn)型成為 DevOps 或者 SRE苔货，那么需要補(bǔ)上相關(guān)技術(shù)知識(shí)茧痕。 畢竟瘤载，不是會(huì)搭建一套 Jenkins + Kubernetes 就可以自稱(chēng)為 DevOps / SRE 工程師跳芳。

怎么樣柑蛇，有沒(méi)有解開(kāi)這幾個(gè)常見(jiàn)誤區(qū)呢苟耻？希望你看到這里可以豁然開(kāi)朗吱瘩，最后附上兩個(gè)工程師的技能點(diǎn)荷逞， 期望有志成為這兩種工程師的同學(xué)媒咳，加油努力。

附錄：技能點(diǎn)

DevOps：

• Operator 技能
  • Linux Basis
    • 基本命令操作
    • Linux FHS（Filesystem Hierarchy Standard 文件系統(tǒng)層次結(jié)構(gòu)標(biāo)準(zhǔn)）
    • Linux 系統(tǒng)（差異种远、歷史涩澡、標(biāo)準(zhǔn)、發(fā)展）
  • 腳本
    • Bash / Python
  • 基礎(chǔ)服務(wù)
    • DHCP / NTP / DNS / SSH / iptables / LDAP / CMDB
  • 自動(dòng)化工具
    • Fabric / Saltstack / Chef / Ansible
  • 基礎(chǔ)監(jiān)控工具
    • Zabbix / Nagios / Cacti
  • 虛擬化
    • KVM 管理 / XEN 管理 / vSphere 管理 / Docker
    • 容器編排 / Mesos / Kubernetes
  • 服務(wù)
    • Nginx / F5 / HAProxy / LVS 負(fù)載均衡
    • 常見(jiàn)中間件 Operate（啟動(dòng)坠敷、關(guān)閉妙同、重啟、擴(kuò)容）
• Dev
  • 語(yǔ)言
    • Python
    • Go（可選）
    • Java（了解部署）
  • 流程和理論
    • Application Life Cycle
    • 12 Factor
    • 微服務(wù)概念膝迎、部署粥帚、生命周期
    • CI 持續(xù)集成 / Jenkins / Pipeline / Git Repo Web Hook
    • CD 持續(xù)發(fā)布系統(tǒng)
  • 基礎(chǔ)設(shè)施
    • Git Repo / Gitlab / Github
    • Logstash / Flume 日志收集
    • 配置文件管理（應(yīng)用、中間件等）
    • Nexus / JFrog / Pypi 包依賴(lài)管理
    • 面向 開(kāi)發(fā) / QA 開(kāi)發(fā)環(huán)境管理系統(tǒng)
    • 線(xiàn)上權(quán)限分配系統(tǒng)
    • 監(jiān)控報(bào)警系統(tǒng)
    • 基于 Fabric / Saltstack / Chef / Ansible 自動(dòng)化工具開(kāi)發(fā)

SRE：

• 語(yǔ)言和工程實(shí)現(xiàn)
  • 深入理解開(kāi)發(fā)語(yǔ)言（假設(shè)是 Java）
    • 業(yè)務(wù)部門(mén)使用開(kāi)發(fā)框架
    • 并發(fā)限次、多線(xiàn)程和鎖
    • 資源模型理解：網(wǎng)絡(luò)芒涡、內(nèi)存柴灯、CPU
    • 故障處理能力（分析瓶頸、熟悉相關(guān)工具费尽、還原現(xiàn)場(chǎng)赠群、提供方案）
  • 常見(jiàn)業(yè)務(wù)設(shè)計(jì)方案和陷阱（比如 Business Modeling，N+1旱幼、遠(yuǎn)程調(diào)用查描、不合理 DB 結(jié)構(gòu)）
  • MySQL / Mongo OLTP 類(lèi)型查詢(xún)優(yōu)化
  • 多種并發(fā)模型，以及相關(guān) Scalable 設(shè)計(jì)
• 問(wèn)題定位工具
  • 容量管理
  • Tracing 鏈路追蹤
  • Metrics 度量工具
  • Logging 日志系統(tǒng)
• 運(yùn)維架構(gòu)能力
  • Linux 精通柏卤，理解 Linux 負(fù)載模型冬三，資源模型
  • 熟悉常規(guī)中間件（MySQL Nginx Redis Mongo ZooKeeper 等），能夠調(diào)優(yōu)
  • Linux 網(wǎng)絡(luò)調(diào)優(yōu)闷旧，網(wǎng)絡(luò) IO 模型以及在語(yǔ)言里面實(shí)現(xiàn)
  • 資源編排系統(tǒng)（Mesos / Kubernetes）
• 理論
  • 容量規(guī)劃方案
  • 熟悉分布式理論（Paxos / Raft / BigTable / MapReduce / Spanner 等）长豁，能夠?yàn)閳?chǎng)景決策合適方案
  • 性能模型（比如 Pxx 理解、Metrics忙灼、Dapper）
  • 資源模型（比如 Queuing Theory匠襟、負(fù)載方案、雪崩問(wèn)題）
  • 資源編排系統(tǒng)（Mesos / Kurbernetes）

Ref

• DevOps - 維基百科该园，自由的百科全書(shū)
• Site reliability engineering - Wikipedia
• StuQ 技能圖譜
• The Twelve-Factor App （簡(jiǎn)體中文）
• Google - Site Reliability Engineering
• What's the Difference Between DevOps and SRE? - YouTube

原文鏈接: DevOps 和 SRE - Log4D

歡迎關(guān)注我的微信公眾號(hào)：窺豹

窺豹

如果對(duì)你有幫助酸舍，給作者 ￥2 買(mǎi)張彩票吧。

3a1ff193cee606bd1e2ea554a16353ee