有很多人問過我想了解一下 SRE 這個(gè)崗位，這是個(gè)很大的話題，在這篇博客中把想到的一些介紹一下吧。

SRE 到底是什么？這是一個(gè)最早由 Google 提出的概念，我的理解是，用軟件解決運(yùn)維問題。標(biāo)準(zhǔn)化，自動(dòng)化，可擴(kuò)展，高可用是主要的工作內(nèi)容。這個(gè)崗位被提出的時(shí)候，想解決的問題是打破開發(fā)人員想要快速迭代，與運(yùn)維人員想要保持穩(wěn)定，拒絕頻繁更新之間的矛盾。

SRE 目前對于招聘來說還是比較困難。一方面，這個(gè)崗位需要一定的經(jīng)驗(yàn)，而應(yīng)屆生一般來說不會(huì)有運(yùn)維復(fù)雜軟件的經(jīng)歷；另一方面就是很多人依然以為這就是“運(yùn)維”工程師，認(rèn)為做的是一些低級重復(fù)的工作，對這個(gè)工作有排斥。最根本的，其實(shí)這個(gè)崗位尋找的要么是具有運(yùn)維經(jīng)驗(yàn)的開發(fā)人員，要么是具有軟件開發(fā)技能的運(yùn)維工程師。所以比較難以找到合適的人。

在現(xiàn)實(shí)生活中，不同公司的 SRE 崗位大有不同，有一些甚至可能還是傳統(tǒng)運(yùn)維的名字換了一個(gè)崗位名稱。

比如螞蟻金服有兩種 SRE，一種是負(fù)責(zé)穩(wěn)定性的，就是大家所理解的 SRE；另一種叫做資金安全 SRE，并不負(fù)責(zé)服務(wù)正常運(yùn)行，而是負(fù)責(zé)金錢數(shù)目正確，對賬沒有錯(cuò)誤，工作內(nèi)容以開發(fā)為主，主要是資金核對平臺和核對規(guī)則（沒有做過，只是個(gè)人理解）。某種意義上說，已經(jīng)不算是 SRE 而是專業(yè)領(lǐng)域的開發(fā)了。

Netflix^[1] （2016年）的模式是誰開發(fā)，誰維護(hù)。SRE 負(fù)責(zé)提供技術(shù)支持，和咨詢服務(wù)。Netflix 在全球 170 個(gè)國家有服務(wù)，Core SREs 只有 5 個(gè)人。

微軟有專門的 Game Streaming SRE^[2] ，負(fù)責(zé) XBox 在線游戲的穩(wěn)定性。

所以不同公司的 SRE 的內(nèi)容各有偏重，取決于公司要提供什么樣的服務(wù)。

我們可以學(xué)習(xí)網(wǎng)絡(luò)分層的方式，將 SRE 大致的工作內(nèi)容從下往上分成 3 個(gè)大類：

1. Infrastructure：主要負(fù)責(zé)最基礎(chǔ)的硬件設(shè)施，網(wǎng)絡(luò)，類似于 IaaS，做的事情可參考 DigitalOcean

2. Platform：提供中間件技術(shù)，開箱即用的一些服務(wù)，類似于 PaaS，做的事情可參考 Heroku, GCP, AWS 等

3. 業(yè)務(wù) SRE：維護(hù)服務(wù)，應(yīng)用，維護(hù)業(yè)務(wù)的正常運(yùn)行

Infrastructure

Infrastructure 和 Platform SRE 其實(shí)可有可無，這些年商業(yè)化的服務(wù)其實(shí)越來越多了，比如，如果公司選擇全部在 AWS 部署自己的服務(wù)的話，那么就不需要自己建立 Datacenter，維護(hù)網(wǎng)絡(luò)之類的工作了，只需要幾個(gè) AWS 專家即可。

如果有的話，工作內(nèi)容也可大可小?？梢詮墓芾碣徺I的 VPS 開始，也可以從采購硬件服務(wù)器開始。

我覺得 Infrastructure SRE 的工作內(nèi)容可以這樣定義：

1. 負(fù)責(zé)服務(wù)器的采購，預(yù)算，CMDB 管理。要知道（能查詢到）每一臺的負(fù)責(zé)人是誰，在干什么。這個(gè)非常重要，如果做不好，會(huì)造成極大的資源浪費(fèi)。
2. 提供可靠軟件的部署環(huán)境，一般是虛擬機(jī)，或者 bare mental。
3. 操作系統(tǒng)的版本統(tǒng)一維護(hù)，Linux 發(fā)行版的版本，Kernel 的版本等。
4. 維護(hù)機(jī)器上的基礎(chǔ)軟件，比如 NTP，監(jiān)控代理，其他的一些代理。
5. 提供機(jī)器的登錄方式，權(quán)限管理，命令審計(jì)。
6. 維護(hù)一套可觀測性的基礎(chǔ)設(shè)施，比如監(jiān)控系統(tǒng)，log 系統(tǒng)，trace 系統(tǒng)。
7. 維護(hù)網(wǎng)絡(luò)，大公司可能都會(huì)自己設(shè)計(jì)機(jī)房內(nèi)的網(wǎng)絡(luò)。其中包括：
1. 網(wǎng)絡(luò)的連通，這個(gè)是必要的。對于上層用戶（Platform SRE）來說，交付的服務(wù)應(yīng)該是任意兩個(gè) IP 是可以 ping 通的，即管理好 3 層以下的網(wǎng)絡(luò)。
2. NAT 服務(wù)
3. DNS 服務(wù)
4. 防火墻
5. 4 層負(fù)載均衡，7 層負(fù)載均衡
6. CDN
7. 證書管理

每一項(xiàng)既可以是一個(gè)很大的團(tuán)隊(duì)，也可以只有一個(gè)人去對商業(yè)化的 Infra 服務(wù)?？梢允褂瞄_源的產(chǎn)品，也可以自己研發(fā)。

Platform SRE

Infrastructure SRE 維護(hù)的是基礎(chǔ)設(shè)施，Platform SRE 使用他們提供的基礎(chǔ)設(shè)施建立軟件服務(wù)，讓公司內(nèi)的開發(fā)者可以使用開箱即用的軟件服務(wù)，比如 Queue，Cache，定時(shí)任務(wù)，RPC 服務(wù)等等。

主要的工作內(nèi)容有：

1. RPC 服務(wù)：讓不同的服務(wù)可以互相發(fā)現(xiàn)并調(diào)用
2. 私有云服務(wù)
3. 隊(duì)列服務(wù)，比如 Kafka 或者 RabbitMQ
4. 分布式的 cronjob 服務(wù)
5. Cache
6. 網(wǎng)關(guān)服務(wù)：反向代理的配置
7. 對象存儲(chǔ)：s3
8. 其他一些數(shù)據(jù)庫：ES，mongo 等等。一般來說，關(guān)系型數(shù)據(jù)庫會(huì)有 DBA 來運(yùn)維，但是 NoSQL 或者圖數(shù)據(jù)庫一般由 SRE 維護(hù)。
9. 內(nèi)部的開發(fā)環(huán)境：
1. SCM 系統(tǒng)，比如自建的 Gitlab
2. CI/CD 系統(tǒng)
3. 鏡像系統(tǒng)，比如 Harbor
4. 其他的一些開發(fā)工具，比如分布式編譯，Sentry 錯(cuò)誤管理等等
10. 一些離線計(jì)算環(huán)境，大數(shù)據(jù)的服務(wù)

業(yè)務(wù) SRE

有了 Platform SRE 的支持，開發(fā)人員寫代碼就基本上不需要關(guān)心部署的問題了?？梢詫Ｗ⒂陂_發(fā)，使用公司開箱即用的服務(wù)。這一層的 SRE 更加貼近于業(yè)務(wù)，知道業(yè)務(wù)是怎么運(yùn)行的，請求是怎么處理的，依賴了哪些組件。如果 X 除了問題，可以有哪些降級策略。參與應(yīng)用的架構(gòu)設(shè)計(jì)，提供技術(shù)支持。

主要的工作內(nèi)容有：

1. 參與系統(tǒng)的設(shè)計(jì)。比如熔斷、降級，擴(kuò)容等策略。
2. 做壓測，了解系統(tǒng)的容量。
3. 做容量規(guī)劃。
4. 業(yè)務(wù)側(cè)的 Oncall。

對于一個(gè)專業(yè)的 SRE 來說，上述技能也不應(yīng)該有明顯的界限，比如說業(yè)務(wù) SRE 也需要掌握一些網(wǎng)絡(luò)技能，Infra SRE 也要寫一些代碼。很多工具每一個(gè)崗位的人都多少用的到，比如 Ansible/Puppet/SaltStack 這種 IT 自動(dòng)化工具，或者 Grafana/Prometheus 這種監(jiān)控工具，只有理解才能用的正確。換個(gè)角度講，對于業(yè)務(wù) SRE 來說，雖然基本上不會(huì)去管理四層以下的網(wǎng)絡(luò)，但是如果遇到網(wǎng)絡(luò)問題，能通過已有的工具和權(quán)限排查到交換機(jī)問題，去找 Infra SRE 幫忙：“請幫我看下 xx IP 到交換機(jī)是否有異常，因?yàn)?xxx 顯示的結(jié)果是 xx”，總比 “我懷疑 xx 有網(wǎng)絡(luò)問題，請幫忙排查下” 要好一些吧？

以上是工作職責(zé)的大體劃分，這個(gè)分層其實(shí)沒有什么意義，倒是可以讓讀者了解一下 SRE 都涉及哪一些工作。

下面是一些日常的工作內(nèi)容。

部署服務(wù)

部署分成兩種：

1. Day 1：將服務(wù)部署上線的那一天
2. Day 2+：服務(wù)部署之后，還會(huì)進(jìn)行很多更新，升級，配置更改，服務(wù)遷移等等

Day2+ 的工作要做很多次，Day 1 做的很少，在不斷的迭代升級之后，還能保證有一個(gè)可靠的 Day 1 操作是很難的。換句話說，我們在服務(wù)部署之后一直改來改去，還要保證這個(gè)服務(wù)在一個(gè)全新的環(huán)境能夠可靠的部署起來。部署環(huán)境的硬編碼，奇奇怪怪的 work around，都會(huì)破壞 Day 1 的可靠性。之前一家公司，擴(kuò)容一個(gè)新機(jī)房的過程簡直是噩夢，太多的奇怪配置，hardcode，導(dǎo)致踩過無數(shù)個(gè)坑才能在一個(gè)新的機(jī)房部署起來全部的服務(wù)。

Day2+ 的操作也不簡單，主要要關(guān)注穩(wěn)定性。對于重要的變更操作要設(shè)計(jì)好變更計(jì)劃，如何做到灰度測試，如果出了問題應(yīng)該如何回滾，如何保證回滾可以成功（如何測試回滾）等等。

部署的操作最好都是可以追蹤的，因?yàn)椴⒉皇撬袝?huì)引起問題的操作都會(huì)立即引起問題。比如一個(gè)操作當(dāng)時(shí)做完沒有什么問題，但是過了 1 個(gè)月，偶然的重啟或者內(nèi)存達(dá)到了某一個(gè)指標(biāo)觸發(fā)了問題。如果能記錄操作的話，我們可以回溯之前做過的變更，方便定位問題?，F(xiàn)在一般都用 git 來追蹤部署過程的變更（ gitops^[3] ）。

Oncall

Oncall 簡單來說就是要保證線上服務(wù)的正常運(yùn)行。典型的工作流程是：收到告警，檢查告警發(fā)出的原因，確認(rèn)線上服務(wù)是否有問題，定位到問題，解決問題。

收到告警并不總意味著真正的問題，也有可能告警設(shè)置的不合理。告警和監(jiān)控面板并不是一個(gè)靜態(tài)的配置，它應(yīng)該是每天都在變化的，時(shí)刻在調(diào)整的。如果發(fā)現(xiàn)沒有標(biāo)志真正線上問題的告警發(fā)了出來，就應(yīng)該修改告警規(guī)則。如果發(fā)現(xiàn)當(dāng)前的監(jiān)控?zé)o法快速定位問題，應(yīng)該調(diào)整監(jiān)控面板，添加或者刪除監(jiān)控指標(biāo)。業(yè)務(wù)在發(fā)展，請求量在變化，某些閾值也需要不斷地調(diào)整。

定位問題沒有一概而論的方法了，需要根據(jù)看到的實(shí)時(shí)，結(jié)合自己的經(jīng)驗(yàn)，然后做推測，然后使用工具驗(yàn)證自己的推測，然后確定問題的根因。

但是解決問題是可以有方法論的，叫做 SOP，標(biāo)準(zhǔn)操作流程^[4] 。即：如果出現(xiàn)了這種現(xiàn)象，那么執(zhí)行那種操作，就可以恢復(fù)業(yè)務(wù)。SOP 文檔應(yīng)該提前制定，并且驗(yàn)證其有效性。

需要注意的是上述定位問題、解決問題并沒有順序關(guān)系。一個(gè)經(jīng)常犯的錯(cuò)誤是，在出現(xiàn)故障的時(shí)候，花了很長時(shí)間定位到故障的根因，然后再修復(fù)。這樣花的時(shí)間一般會(huì)比較長。正確的做法是先根據(jù)現(xiàn)象看現(xiàn)有的 SOP 能否恢復(fù)業(yè)務(wù)。比如說當(dāng)前錯(cuò)誤只發(fā)生在某一個(gè)節(jié)點(diǎn)上，那么就直接下線這個(gè)節(jié)點(diǎn)，具體的原因后面再排查?；謴?fù)當(dāng)前的故障永遠(yuǎn)是第一要?jiǎng)?wù)。但是恢復(fù)操作也要經(jīng)過測試，比如猜測可以通過重啟解決問題的話，可以先重啟一臺做測試，而不是一次性將所有服務(wù)重啟。大部分情況是需要臨場分析的，是一個(gè)緊張又刺激的過程。

故障到底多久恢復(fù)算好？出現(xiàn)多少故障是可以容忍的？怎么標(biāo)志服務(wù)的穩(wěn)定性到底如何？我們使用 SLI/SLO 來衡量這些問題。

制定和交付 SLI/SLO

維護(hù)服務(wù)等級協(xié)議，聽起來像是一個(gè)非常簡單的事情，只要“設(shè)定一個(gè)可用率”然后去實(shí)現(xiàn)它就好了。然而現(xiàn)實(shí)的情況并不是。

比如，制定可用率的時(shí)候，并不是說我們?nèi)ァ皩?shí)現(xiàn) 4 個(gè) 9”（99.99% 的時(shí)間可用）就夠了，我們有以下問題要考慮：

1. 如何定義這個(gè)可用率？比如我們以可用率 > 99.9% 為目標(biāo)，有一個(gè)服務(wù)部署了 5 個(gè) Zone, 那么有一個(gè) Zone 掛了，其余的 Zone 是可用的，那么可用率被破壞了嗎？這個(gè)可用率是每一個(gè) Zone 的還是所有的 Zone 一起計(jì)算的？
2. 可用率計(jì)算的最小單位是什么？如果 1min 內(nèi)有 50s 沒有達(dá)到可用率，那么這一分鐘算是 down 還是 up？
3. 可用率的周期是怎么計(jì)算的？按照一個(gè)月還是一個(gè)周？一個(gè)周是最近的 7 天還是計(jì)算一個(gè)自然周？
4. 如何對 SLI 和 SLO 做監(jiān)控？
5. 如果錯(cuò)誤預(yù)算即將用完，有什么措施？比如減少發(fā)布？如果 SLI 和 SLO 沒有達(dá)到會(huì)怎么樣？

等等，如果這些問題不考慮清楚的話，那么 SLI 和 SLO 很可能就是沒有意義的。SLI/SLO 也適用于對公司內(nèi)部用戶的承諾，讓用戶對我們的服務(wù)有預(yù)期，而不能有盲目的信任。比如 Google 在 SLI/SLO 還有預(yù)算的時(shí)候，會(huì)在滿足 SLI/SLO 的時(shí)候自行對服務(wù)做一些破壞，讓用戶不要對服務(wù)有 100% 可用的錯(cuò)誤預(yù)期。SLI/SLO 也會(huì)讓 SRE 自己對當(dāng)前服務(wù)的穩(wěn)定性有更好的認(rèn)識，可以根據(jù)此調(diào)整運(yùn)維、變更、發(fā)布計(jì)劃。

故障復(fù)盤

故障復(fù)盤的唯一目的是減少故障的發(fā)生。有幾個(gè)我目前認(rèn)為不錯(cuò)的做法。

故障復(fù)盤需要有文檔記錄，包括故障發(fā)生的過程，時(shí)間線的記錄，操作的記錄，故障恢復(fù)的方法，故障根因的分析，為什么故障會(huì)發(fā)生的分析。文檔應(yīng)該隱去所有當(dāng)事人的姓名對公司的所有人公開。很多公司對故障文檔設(shè)置查看權(quán)限，我覺得沒什么道理。有些公司的故障復(fù)盤甚至 對外也是公開的^[5] 。

故障在復(fù)盤的時(shí)候應(yīng)該將當(dāng)事人的名字用代碼替代，可以營造更好的討論氛圍。

不應(yīng)該要求所有的故障復(fù)盤都產(chǎn)生 Action。之前一家的公司的故障復(fù)盤上，因?yàn)楸仨毥o領(lǐng)導(dǎo)一個(gè)“交待”，所以每次都會(huì)產(chǎn)生一些措施來預(yù)防相同的故障再次發(fā)生，比如增加審批流程之類的。這很扯，讓級別很高的領(lǐng)導(dǎo)審批他自己也看不懂的操作，只能讓領(lǐng)導(dǎo)更痛苦，也讓操作流程變得又臭又長，最后所有人都會(huì)忘記這里為什么會(huì)有一個(gè)審批，但是又沒有人敢刪掉。你刪掉，出了事情你負(fù)責(zé)。

Blame Free 文化？之前我認(rèn)為是好的。但是后來發(fā)現(xiàn)，有些不按照流程操作導(dǎo)致的問題確實(shí)多少應(yīng)該 Blame 一下，比如下線服務(wù)的時(shí)候沒有檢查還沒有 tcp 連接就直接下線了，或者操作的時(shí)候沒有做 canary 就全部操作了，這種不理智的行為導(dǎo)致的故障。但是條條框框又不應(yīng)該太多，不然活都沒法干了。

容量規(guī)劃

容量規(guī)劃是一個(gè)非常復(fù)雜的問題，甚至有一些悖論。容量要提前做好規(guī)劃，但是容量的規(guī)劃需要知道業(yè)務(wù)的擴(kuò)張速度，擴(kuò)張速度這種事情又不是提前能計(jì)劃好的。所以我一直覺得這個(gè)事情很難做，也一直沒有見過做的很好的例子。

但是至少可以對維護(hù)的系統(tǒng)建立一個(gè)模型，知道多少機(jī)器，多少資源，能容納多少容量。這樣遇到大促之類的活動(dòng)也能及時(shí)估算需要的資源數(shù)量。

用戶支持

用戶支持也是日常的一部分。包括技術(shù)咨詢，以及用戶要求的線上問題排查。

這里就需要提到文檔的重要性了。如果沒有維護(hù)好文檔，那么用戶就會(huì)一遍又一遍問相同的問題。寫文檔也是一個(gè)技術(shù)活，優(yōu)秀的需要很長時(shí)間的積累。文檔也需要經(jīng)常更新。我一般會(huì)這樣，保持這樣一種狀態(tài)：用戶可以不需要任何人就從文檔中找到他需要的所有答案。如果我發(fā)現(xiàn)用戶的問題無法從文檔中找到，或者難以找到在文檔中的什么地方，就會(huì)更新文檔，或者重新組織文檔。如果用戶的問題已經(jīng)從文檔中找到，那么就直接發(fā)文檔給他。如果用戶的問題顯然是文檔看都沒有看過（有很多人根本不看文檔的，只看文檔是誰寫的然后徑直去問這個(gè)人），就直接忽略。

優(yōu)秀的文檔應(yīng)該盡量引入少的專有名詞，少使用沒有用處的專業(yè)詞匯描述，只描述具有指導(dǎo)意義的事實(shí)，假定用戶沒有相關(guān)的背景知識，列舉使用例子，舉一些現(xiàn)實(shí)會(huì)用到的例子而不是強(qiáng)行舉例子，明確 Bad Case。等等。這其實(shí)是一個(gè)很大的話題了，這里就不展開了。

暫時(shí)就想到這一些了。下面寫一些我經(jīng)常見到的誤解，和經(jīng)常被別人問的問題。

有關(guān)做項(xiàng)目沒有專業(yè)團(tuán)隊(duì)得不到訓(xùn)練。

這方面是聽到最多的抱怨。雖然說 SRE 在工作上應(yīng)該是開發(fā)時(shí)間和運(yùn)維時(shí)間各 50%，但是真實(shí)的情況是，即使 SRE 有一些開發(fā)工作，也大部分是面向內(nèi)部用戶，面向公司內(nèi)部的開發(fā)者的。大部分項(xiàng)目是一些想法，需要去嘗試一下行不行，基本上不會(huì)有專業(yè)的設(shè)計(jì)資源，PM 資源。這種項(xiàng)目就需要 SRE 有多方面的技能，包括對產(chǎn)品的理解，清楚地知道它有什么痛點(diǎn)，最好是自己經(jīng)歷過的痛點(diǎn)，然后需要懂設(shè)計(jì)，管理好開發(fā)進(jìn)度。然而這種人非常少。其實(shí)能寫中型項(xiàng)目代碼的 SRE 就已經(jīng)非常少了。所以大部分公司內(nèi)部項(xiàng)目都會(huì)做的又難用又復(fù)雜。

即使是有專業(yè)配套 PM 和設(shè)計(jì)，甚至前端資源?；旧弦彩且粋€(gè)災(zāi)難。我也經(jīng)歷過這樣的團(tuán)隊(duì)。這種內(nèi)部項(xiàng)目對標(biāo)的不是互聯(lián)網(wǎng)項(xiàng)目，而更像是 toB 的項(xiàng)目。用戶 UI 的設(shè)計(jì)，交互邏輯，操作流程，交付周期等需要的都是另一個(gè)領(lǐng)域的知識。否則的話人越多，也只會(huì)徒增溝通成本，拖慢項(xiàng)目進(jìn)度。

回到經(jīng)常聽到的這個(gè)抱怨，說在 SRE 的團(tuán)隊(duì)沒有像開發(fā)團(tuán)隊(duì)那樣有“正規(guī)軍”，有設(shè)計(jì)和 PM，大家各司其職，后端開發(fā)只要對齊 API 然后實(shí)現(xiàn)就好了。大部分的應(yīng)屆生會(huì)有這樣的幻想，但實(shí)際上不是這樣。被搞錯(cuò)的最重要的一點(diǎn)是，學(xué)習(xí)主要是靠自己的，和別人沒有太大的關(guān)系。我覺得可能是在一個(gè)大團(tuán)隊(duì)里面，有很多人一起做一件事情，心里的懷疑和焦慮會(huì)少一點(diǎn)，人們會(huì)對這樣的工作狀態(tài)感到踏實(shí)，誤以為是“成長”，自己做所有的工作焦慮更多。

事實(shí)是，在大團(tuán)隊(duì)工作可能學(xué)到更多的溝通技能，比如和不同的人對齊不同的階段工作目標(biāo)，要想要學(xué)到其他的東西還是要靠自己。比如拿到一個(gè)設(shè)計(jì)，如果照樣子去實(shí)現(xiàn)了，其實(shí)不會(huì)學(xué)到什么東西。而要去理解為什么這么設(shè)計(jì)，為什么不那么設(shè)計(jì)。如果自己去做，思考的過程也基本是這樣的，可以怎么設(shè)計(jì)，選擇什么好。都是：思考，選擇，嘗試，經(jīng)驗(yàn)，思考……

另一個(gè)需要澄清的誤區(qū)是，模仿并不是學(xué)習(xí)。在團(tuán)隊(duì)中經(jīng)歷了一個(gè)設(shè)計(jì)，如果記住了這個(gè)設(shè)計(jì)，下次碰到類似的問題也用這個(gè)設(shè)計(jì)去解決。這也不能叫做是學(xué)習(xí)。我見過有在業(yè)務(wù)部門做過支付的 SRE 寫的代碼，在內(nèi)部系統(tǒng)中去實(shí)現(xiàn)了訂單業(yè)務(wù)的訂單、交易等概念完成一個(gè)運(yùn)維流程，甚至 Model 的名字都沒改過。拿著錘子找釘子，會(huì)讓系統(tǒng)變得更加糟糕和復(fù)雜。

總之，工作分的細(xì)并不代表工作就會(huì)更加專業(yè)。一個(gè)人身兼數(shù)職也可以在每一個(gè)方面做得很專業(yè)。重要的是不斷學(xué)習(xí)，使用正確的做事方式，向優(yōu)秀的項(xiàng)目和優(yōu)秀的開發(fā)者學(xué)習(xí)。

有關(guān)臟活累活。

每一項(xiàng)工作都會(huì)有臟活累活：學(xué)不到什么東西，做起來沒有意思?？赡苁钦硐到y(tǒng)的監(jiān)控，可能是整理現(xiàn)有的文檔，可能清理一些年久的運(yùn)維腳本，可能是需要和不同的團(tuán)隊(duì)做 一些溝通工作^[6] 等。

這是不可避免的，如果可以的話，學(xué)會(huì)從每一項(xiàng)工作中找一些偷懶的方法吧，比如用腳本處理一些工作，用更聰明的方式工作等等。

但是如果這種工作的比例太高的話，就要思考工作方式的問題了。如果陷入惡性循環(huán)，看能不能從工具和工作流程上做一些改變。如果不能的話，考慮換一份工作吧。

有關(guān)背鍋。

互相甩鍋的工作環(huán)境無疑是非常糟糕的工作環(huán)境。如果相同的團(tuán)隊(duì)、或者不同的團(tuán)隊(duì)之間需要相互勾心斗角的話，如果工作環(huán)境不允許大方承認(rèn)（SRE 無可避免地會(huì)犯一些錯(cuò)誤）自己的錯(cuò)誤，說明公司營造的氛圍有問題。比如某些公司規(guī)定，發(fā)生 P1 級別的錯(cuò)誤就必須開除一個(gè) Px 級別的員工，發(fā)生 P0 級別的錯(cuò)誤就必須開除一個(gè) Py 級別的員工一樣。如果是這種情況的話，公司實(shí)際上是在用一種懶惰地方法通過提高人的壓力來提高系統(tǒng)的穩(wěn)定性。有沒有效果不知道，但是確定的是不會(huì)有人在這種情況下工作的開心。建議換一份工作。

如何轉(zhuǎn)行？

其實(shí)難度沒有想象的高，畢竟大學(xué)里面沒有一個(gè)叫做 SRE 的專業(yè)。SRE 要求的知識也是編寫代碼、設(shè)計(jì)系統(tǒng)、了解操作系統(tǒng)和網(wǎng)絡(luò)等。所以在大學(xué)里面將本科的課程好好學(xué)好，嘗試做（并維護(hù)）一些自己的項(xiàng)目，畢業(yè)的時(shí)候基本上就滿足要求了。非科班的人要轉(zhuǎn)行的話，也可以參考大學(xué)的課程內(nèi)容去補(bǔ)足這方面的知識。

需要注意的是，培訓(xùn)班出來的做開發(fā)完成業(yè)務(wù)可能夠，但是做 SRE 遠(yuǎn)遠(yuǎn)不夠。SRE 不僅需要 make things work，還要知道背后的原理。

面試會(huì)問什么？

我覺得和后端開發(fā)的面試內(nèi)容基本上差不多。

如果是去應(yīng)聘的這個(gè)崗位所需要的一些技能，比如 K8S，監(jiān)控系統(tǒng)等，可能也會(huì)問一些領(lǐng)域內(nèi)的知識。雖說這部分工具性的東西都可以學(xué)習(xí)，但是如果人家要一個(gè)經(jīng)驗(yàn)豐富的、或者入職就能干活的，那么面試成功的機(jī)會(huì)就會(huì)小很多。當(dāng)然，也不必沮喪，這是市場的供需關(guān)系決定的，如果對方執(zhí)意要找符合特定要求的候選人，那么對方的選擇的范圍也會(huì)小很多，不必因?yàn)殄e(cuò)失了這種機(jī)會(huì)而后悔沒去學(xué)習(xí)什么工具。話又說回來，技能越多，選擇也會(huì)越多。

排查錯(cuò)誤可能是轉(zhuǎn)行做 SRE 最大的一個(gè)門檻，這個(gè)需要一些經(jīng)驗(yàn)。如果沒有經(jīng)驗(yàn)的話，就補(bǔ)足一些操作系統(tǒng)的知識，這樣遇到未知的問題也可以通過已知的知識和工具去排查。

這個(gè)倉庫是一個(gè)不錯(cuò)的面試題集錦：https://github.com/bregman-arie/devops-exercises^[7]

做 SRE 需要會(huì)寫代碼嗎？

會(huì)，而且寫代碼的要求并不會(huì)比一個(gè)專業(yè)的后端開發(fā)低。

選擇大公司還是小公司？

這屬于兩種截然不同的工作環(huán)境。小公司一般都有一個(gè)救火英雄式的人物，在公司的時(shí)間比較長，知道所有組件的部署結(jié)構(gòu)，什么都懂。跟著這種人學(xué)習(xí)會(huì)成長很快。

大公司細(xì)分領(lǐng)域很多。本文前面列出的內(nèi)容可能每一項(xiàng)在大公司中都是一個(gè)團(tuán)隊(duì)，對某個(gè)領(lǐng)域可以深入研究。

所以還是看想要做什么了。我個(gè)人比較喜歡靠譜的小公司，或者大公司中靠譜的小團(tuán)隊(duì)。

如何判斷一家公司是否靠譜？

對于 SRE 這個(gè)職位，我總結(jié)了一些判斷的技巧。比如可以判斷一下對方目前的業(yè)務(wù)和 SRE 員工的數(shù)量是否處于一個(gè)“正?！钡臓顟B(tài)，人數(shù)是否在隨著業(yè)務(wù)（機(jī)器的數(shù)量）現(xiàn)象增長？這是一個(gè)不好的跡象。是否 SRE 的數(shù)量過多？如果 SRE 人太多，有兩個(gè)可能的原因：1）某個(gè)領(lǐng)導(dǎo)為了擴(kuò)大自己的影響力在為一些“不必要的”崗位招人，這樣會(huì)導(dǎo)致人多事少，大家開始做一些奇奇怪怪的事情，發(fā)明奇奇怪怪的需求，以各種各樣的方式浪費(fèi)自己的時(shí)間來領(lǐng)公司的工資；2）這個(gè)公司的基礎(chǔ)太差，大部分工作都是需要人力運(yùn)維，導(dǎo)致基本上有多少機(jī)器就需要多少人。總之，都不是什么好事情。

一些技術(shù)比較好的公司，都沒有龐大的 SRE 隊(duì)伍，比如 Instagram, xNetflix（現(xiàn)在可能人數(shù)不少了），以及一些創(chuàng)業(yè)公司，甚至都可以沒有專門的 SRE，優(yōu)秀的 SRE 首先要是開發(fā)者，優(yōu)秀的開發(fā)者也離 SRE 不遠(yuǎn)了。一些耳熟能詳?shù)姆?wù)，比如 webarchive 這樣的數(shù)據(jù)量，其實(shí) 背后也只有幾個(gè)人在維護(hù)^[8] 。前幾年面試了國內(nèi)的一家公司，在機(jī)房遍布全球，業(yè)務(wù)已經(jīng)發(fā)展的比較龐大（上市了）的時(shí)候，SRE 團(tuán)隊(duì)也只有 10 個(gè)人。

另外我比較喜歡問的一個(gè)問題是對方關(guān)于 AIOps 怎么看。因?yàn)槲抑案懔藘赡赀@個(gè)東西，最后得到的結(jié)論是，這基本上 是個(gè)浪費(fèi)時(shí)間、欺騙上層領(lǐng)導(dǎo)的東西^[9] 。AI 這東西的不可解釋性本質(zhì)上就和運(yùn)維操作將就因果相違背的。所以經(jīng)常喜歡問面試官怎么看這個(gè)技術(shù)，基本上就可以判斷靠不靠譜。當(dāng)然了，這是我個(gè)人的職業(yè)陰影導(dǎo)致的后遺癥，只能代表個(gè)人意見。

就說這么多吧，都是一些個(gè)人理解，不一定對。寫這篇文章感覺自己好像指點(diǎn)江山一樣，其實(shí)我自己也干了才幾年而已，所以本文內(nèi)容僅供參考。如果有什么問題可以在評論提出，我能回答的話就盡量回答。

原文地址：https://www.kawabangga.com/posts/4481

參考資料