SRE本質(zhì)就是一個懂運(yùn)維的資深開發(fā)
原文鏈接：https://www.kawabangga.com/posts/4481
有很多人問過我，想了解一下 SRE 這個崗位，這是個很大的話題，在這篇博客中把想到的一些介紹一下。
SRE 到底是什么？這是一個最早由 Google 提出的概念，我的理解是，用軟件解決運(yùn)維問題。標(biāo)準(zhǔn)化、自動化、可擴(kuò)展、高可用是主要的工作內(nèi)容。這個崗位被提出的時候，想解決的問題是打破開發(fā)人員想要快速迭代，與運(yùn)維人員想要保持穩(wěn)定，拒絕頻繁更新之間的矛盾。
SRE 目前對于招聘來說還是比較困難。一方面，這個崗位需要一定的經(jīng)驗，而應(yīng)屆生一般來說不會有運(yùn)維復(fù)雜軟件的經(jīng)歷；另一方面就是很多人依然以為這就是“運(yùn)維”工程師，認(rèn)為做的是一些低級重復(fù)的工作，對這個工作有排斥。最根本的，其實這個崗位尋找的要么是具有運(yùn)維經(jīng)驗的開發(fā)人員，要么是具有軟件開發(fā)技能的運(yùn)維工程師。所以比較難以找到合適的人。
在現(xiàn)實生活中，不同公司的 SRE 崗位大有不同，有一些甚至可能還是傳統(tǒng)運(yùn)維的名字換了一個崗位名稱。
比如螞蟻金服有兩種 SRE，一種是負(fù)責(zé)穩(wěn)定性的，就是大家所理解的 SRE；另一種叫做資金安全 SRE，并不負(fù)責(zé)服務(wù)正常運(yùn)行，而是負(fù)責(zé)金錢數(shù)目正確，對賬沒有錯誤，工作內(nèi)容以開發(fā)為主，主要是資金核對平臺和核對規(guī)則（沒有做過，只是個人理解）。某種意義上說，已經(jīng)不算是 SRE 而是專業(yè)領(lǐng)域的開發(fā)了。
Netflix[1]（2016年）的模式是誰開發(fā)，誰維護(hù)。SRE 負(fù)責(zé)提供技術(shù)支持，和咨詢服務(wù)。Netflix 在全球 170 個國家有服務(wù)，Core SREs 只有 5 個人。
微軟有專門的 Game Streaming SRE[2]，負(fù)責(zé) XBox 在線游戲的穩(wěn)定性。
所以不同公司的 SRE 的內(nèi)容各有偏重，取決于公司要提供什么樣的服務(wù)。
我們可以學(xué)習(xí)網(wǎng)絡(luò)分層的方式，將 SRE 大致的工作內(nèi)容從下往上分成 3 個大類：
Infrastructure：主要負(fù)責(zé)最基礎(chǔ)的硬件設(shè)施，網(wǎng)絡(luò)，類似于 IaaS，做的事情可參考 DigitalOcean
Platform：提供中間件技術(shù)，開箱即用的一些服務(wù)，類似于 PaaS，做的事情可參考 Heroku，GCP，AWS 等
業(yè)務(wù) SRE：維護(hù)服務(wù)，應(yīng)用，維護(hù)業(yè)務(wù)的正常運(yùn)行
— 1 —
Infrastructure 和 Platform SRE 其實可有可無，這些年商業(yè)化的服務(wù)其實越來越多了，比如，如果公司選擇全部在 AWS 部署自己的服務(wù)的話，那么就不需要自己建立 Datacenter，維護(hù)網(wǎng)絡(luò)之類的工作了，只需要幾個 AWS 專家即可。
如果有的話，工作內(nèi)容也可大可小。可以從管理購買的 VPS 開始，也可以從采購硬件服務(wù)器開始。
我覺得 Infrastructure SRE 的工作內(nèi)容可以這樣定義：
負(fù)責(zé)服務(wù)器的采購，預(yù)算，CMDB 管理。要知道（能查詢到）每一臺的負(fù)責(zé)人是誰，在干什么。這個非常重要，如果做不好，會造成極大的資源浪費(fèi)。
提供可靠軟件的部署環(huán)境，一般是虛擬機(jī)，或者 bare mental。
操作系統(tǒng)的版本統(tǒng)一維護(hù)，Linux 發(fā)行版的版本，Kernel 的版本等。
維護(hù)機(jī)器上的基礎(chǔ)軟件，比如 NTP，監(jiān)控代理，其他的一些代理。
提供機(jī)器的登錄方式，權(quán)限管理，命令審計。
維護(hù)一套可觀測性的基礎(chǔ)設(shè)施，比如監(jiān)控系統(tǒng)，log 系統(tǒng)，trace 系統(tǒng)。
維護(hù)網(wǎng)絡(luò)，大公司可能都會自己設(shè)計機(jī)房內(nèi)的網(wǎng)絡(luò)。其中包括：
網(wǎng)絡(luò)的連通，這個是必要的。對于上層用戶（Platform SRE）來說，交付的服務(wù)應(yīng)該是任意兩個 IP 是可以 ping 通的，即管理好 3 層以下的網(wǎng)絡(luò)。
NAT 服務(wù)
DNS 服務(wù)
防火墻
4 層負(fù)載均衡，7層負(fù)載均衡
CDN
證書管理
每一項既可以是一個很大的團(tuán)隊，也可以只有一個人去對商業(yè)化的 Infra 服務(wù)。可以使用開源的產(chǎn)品，也可以自己研發(fā)。
— 2 —
Infrastructure SRE 維護(hù)的是基礎(chǔ)設(shè)施，Platform SRE 使用他們提供的基礎(chǔ)設(shè)施建立軟件服務(wù)，讓公司內(nèi)的開發(fā)者可以使用開箱即用的軟件服務(wù)，比如 Queue、Cache、定時任務(wù)、RPC 服務(wù)等等。
主要的工作內(nèi)容有：
RPC 服務(wù)：讓不同的服務(wù)可以互相發(fā)現(xiàn)并調(diào)用
私有云服務(wù)
隊列服務(wù)，比如 Kafka 或者 RabbitMQ
分布式的 cronjob 服務(wù)
Cache
網(wǎng)關(guān)服務(wù)：反向代理的配置
對象存儲：S3
其他一些數(shù)據(jù)庫：ES，mongo 等等。一般來說，關(guān)系型數(shù)據(jù)庫會有 DBA 來運(yùn)維，但是 NoSQL 或者圖數(shù)據(jù)庫一般由 SRE 維護(hù)。
內(nèi)部的開發(fā)環(huán)境：
SCM 系統(tǒng)，比如自建的 GitLab
CI/CD 系統(tǒng)
鏡像系統(tǒng)，比如 Harbor
其他的一些開發(fā)工具，比如分布式編譯，Sentry 錯誤管理等等
一些離線計算環(huán)境，大數(shù)據(jù)的服務(wù)
— 3 —
有了 Platform SRE 的支持，開發(fā)人員寫代碼就基本上不需要關(guān)心部署的問題了。可以專注于開發(fā)，使用公司開箱即用的服務(wù)。這一層的 SRE 更加貼近于業(yè)務(wù)，知道業(yè)務(wù)是怎么運(yùn)行的，請求是怎么處理的，依賴了哪些組件。如果 X 除了問題，可以有哪些降級策略。參與應(yīng)用的架構(gòu)設(shè)計，提供技術(shù)支持。
主要的工作內(nèi)容有：
參與系統(tǒng)的設(shè)計。比如熔斷、降級，擴(kuò)容等策略。
做壓測，了解系統(tǒng)的容量。
做容量規(guī)劃。
業(yè)務(wù)側(cè)的 Oncall。
對于一個專業(yè)的 SRE 來說，上述技能也不應(yīng)該有明顯的界限，比如說業(yè)務(wù) SRE 也需要掌握一些網(wǎng)絡(luò)技能，Infra SRE 也要寫一些代碼。很多工具每一個崗位的人都多少用的到，比如 Ansible/Puppet/SaltStack 這種 IT 自動化工具，或者 Grafana/Prometheus 這種監(jiān)控工具，只有理解才能用的正確。
換個角度講，對于業(yè)務(wù) SRE 來說，雖然基本上不會去管理四層以下的網(wǎng)絡(luò)，但是如果遇到網(wǎng)絡(luò)問題，能通過已有的工具和權(quán)限排查到交換機(jī)問題，去找 Infra SRE 幫忙：“請幫我看下 xx IP 到交換機(jī)是否有異常，因為 xxx 顯示的結(jié)果是 xx”，總比 “我懷疑 xx 有網(wǎng)絡(luò)問題，請幫忙排查下” 要好一些吧？
以上是工作職責(zé)的大體劃分，這個分層其實沒有什么意義，倒是可以讓讀者了解一下 SRE 都涉及哪一些工作。
下面是一些日常的工作內(nèi)容。
— 4 —
部署分成兩種：
Day 1：將服務(wù)部署上線的那一天
Day 2+：服務(wù)部署之后，還會進(jìn)行很多更新，升級，配置更改，服務(wù)遷移等等
Day 2+ 的工作要做很多次，Day 1 做的很少，在不斷的迭代升級之后，還能保證有一個可靠的 Day 1 操作是很難的。換句話說，我們在服務(wù)部署之后一直改來改去，還要保證這個服務(wù)在一個全新的環(huán)境能夠可靠的部署起來。
部署環(huán)境的硬編碼，奇奇怪怪的 work around，都會破壞 Day 1 的可靠性。之前一家公司，擴(kuò)容一個新機(jī)房的過程簡直是噩夢，太多的奇怪配置，hardcode，導(dǎo)致踩過無數(shù)個坑才能在一個新的機(jī)房部署起來全部的服務(wù)。
Day2+ 的操作也不簡單，主要要關(guān)注穩(wěn)定性。對于重要的變更操作要設(shè)計好變更計劃，如何做到灰度測試，如果出了問題應(yīng)該如何回滾，如何保證回滾可以成功（如何測試回滾）等等。
部署的操作最好都是可以追蹤的，因為并不是所有會引起問題的操作都會立即引起問題。比如一個操作當(dāng)時做完沒有什么問題，但是過了 1 個月，偶然的重啟或者內(nèi)存達(dá)到了某一個指標(biāo)觸發(fā)了問題。如果能記錄操作的話，我們可以回溯之前做過的變更，方便定位問題。現(xiàn)在一般都用 Git 來追蹤部署過程的變更（GitOps[3]）。
— 5 —
Oncall 簡單來說就是要保證線上服務(wù)的正常運(yùn)行。典型的工作流程是：收到告警，檢查告警發(fā)出的原因，確認(rèn)線上服務(wù)是否有問題，定位到問題，解決問題。
收到告警并不總意味著真正的問題，也有可能告警設(shè)置的不合理。告警和監(jiān)控面板并不是一個靜態(tài)的配置，它應(yīng)該是每天都在變化的，時刻在調(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ù)看到的實時，結(jié)合自己的經(jīng)驗，然后做推測，然后使用工具驗證自己的推測，然后確定問題的根因。
但是解決問題是可以有方法論的，叫做 SOP（標(biāo)準(zhǔn)操作流程）[4]。即：如果出現(xiàn)了這種現(xiàn)象，那么執(zhí)行那種操作，就可以恢復(fù)業(yè)務(wù)。SOP 文檔應(yīng)該提前制定，并且驗證其有效性。
需要注意的是上述定位問題、解決問題并沒有順序關(guān)系。一個經(jīng)常犯的錯誤是，在出現(xiàn)故障的時候，花了很長時間定位到故障的根因，然后再修復(fù)。這樣花的時間一般會比較長。正確的做法是先根據(jù)現(xiàn)象看現(xiàn)有的 SOP 能否恢復(fù)業(yè)務(wù)。
比如說當(dāng)前錯誤只發(fā)生在某一個節(jié)點(diǎn)上，那么就直接下線這個節(jié)點(diǎn)，具體的原因后面再排查。恢復(fù)當(dāng)前的故障永遠(yuǎn)是第一要務(wù)。但是恢復(fù)操作也要經(jīng)過測試，比如猜測可以通過重啟解決問題的話，可以先重啟一臺做測試，而不是一次性將所有服務(wù)重啟。大部分情況是需要臨場分析的，是一個緊張又刺激的過程。
故障到底多久恢復(fù)算好？出現(xiàn)多少故障是可以容忍的？怎么標(biāo)志服務(wù)的穩(wěn)定性到底如何？我們使用 SLI/SLO 來衡量這些問題。
— 6 —
維護(hù)服務(wù)等級協(xié)議，聽起來像是一個非常簡單的事情，只要“設(shè)定一個可用率”然后去實現(xiàn)它就好了，然而現(xiàn)實的情況并不是。
比如，制定可用率的時候，并不是說我們?nèi)ァ皩崿F(xiàn)4個9”（99.99% 的時間可用）就夠了，我們有以下問題要考慮：
如何定義這個可用率？比如我們以可用率 > 99.9% 為目標(biāo)，有一個服務(wù)部署了 5 個 Zone，那么有一個 Zone 掛了，其余的 Zone 是可用的，那么可用率被破壞了嗎？這個可用率是每一個 Zone 的還是所有的 Zone 一起計算的？
可用率計算的最小單位是什么？如果 1min 內(nèi)有 50s 沒有達(dá)到可用率，那么這一分鐘算是 down 還是 up？
可用率的周期是怎么計算的？按照一個月還是一個周？一個周是最近的 7 天還是計算一個自然周？
如何對 SLI 和 SLO 做監(jiān)控？
如果錯誤預(yù)算即將用完，有什么措施？比如減少發(fā)布？如果 SLI 和 SLO 沒有達(dá)到會怎么樣？
等等，如果這些問題不考慮清楚的話，那么 SLI 和 SLO 很可能就是沒有意義的。SLI/SLO 也適用于對公司內(nèi)部用戶的承諾，讓用戶對我們的服務(wù)有預(yù)期，而不能有盲目的信任。
比如 Google 在 SLI/SLO 還有預(yù)算的時候，會在滿足 SLI/SLO 的時候自行對服務(wù)做一些破壞，讓用戶不要對服務(wù)有 100% 可用的錯誤預(yù)期。SLI/SLO 也會讓 SRE 自己對當(dāng)前服務(wù)的穩(wěn)定性有更好的認(rèn)識，可以根據(jù)此調(diào)整運(yùn)維、變更、發(fā)布計劃。
— 7 —
故障復(fù)盤的唯一目的是減少故障的發(fā)生。有幾個我目前認(rèn)為不錯的做法。
故障復(fù)盤需要有文檔記錄，包括故障發(fā)生的過程，時間線的記錄，操作的記錄，故障恢復(fù)的方法，故障根因的分析，為什么故障會發(fā)生的分析。文檔應(yīng)該隱去所有當(dāng)事人的姓名對公司的所有人公開。很多公司對故障文檔設(shè)置查看權(quán)限，我覺得沒什么道理。有些公司的故障復(fù)盤甚至對外也是公開的[5]。
故障在復(fù)盤的時候應(yīng)該將當(dāng)事人的名字用代碼替代，可以營造更好的討論氛圍。
不應(yīng)該要求所有的故障復(fù)盤都產(chǎn)生 Action。之前一家的公司的故障復(fù)盤上，因為必須給領(lǐng)導(dǎo)一個“交待”，所以每次都會產(chǎn)生一些措施來預(yù)防相同的故障再次發(fā)生，比如增加審批流程之類的。這很扯，讓級別很高的領(lǐng)導(dǎo)審批他自己也看不懂的操作，只能讓領(lǐng)導(dǎo)更痛苦，也讓操作流程變得又臭又長，最后所有人都會忘記這里為什么會有一個審批，但是又沒有人敢刪掉。你刪掉，出了事情你負(fù)責(zé)。
Blame Free 文化？之前我認(rèn)為是好的。但是后來發(fā)現(xiàn)，有些不按照流程操作導(dǎo)致的問題確實多少應(yīng)該 Blame 一下，比如下線服務(wù)的時候沒有檢查還沒有 TCP 連接就直接下線了，或者操作的時候沒有做 canary 就全部操作了，這種不理智的行為導(dǎo)致的故障。但是條條框框又不應(yīng)該太多，不然活都沒法干了。
— 8 —
容量規(guī)劃是一個非常復(fù)雜的問題，甚至有一些悖論。容量要提前做好規(guī)劃，但是容量的規(guī)劃需要知道業(yè)務(wù)的擴(kuò)張速度，擴(kuò)張速度這種事情又不是提前能計劃好的。所以我一直覺得這個事情很難做，也一直沒有見過做的很好的例子。
但是至少可以對維護(hù)的系統(tǒng)建立一個模型，知道多少機(jī)器，多少資源，能容納多少容量。這樣遇到大促之類的活動也能及時估算需要的資源數(shù)量。
— 9 —
用戶支持也是日常的一部分。包括技術(shù)咨詢，以及用戶要求的線上問題排查。
這里就需要提到文檔的重要性了。如果沒有維護(hù)好文檔，那么用戶就會一遍又一遍問相同的問題。寫文檔也是一個技術(shù)活，優(yōu)秀的需要很長時間的積累。文檔也需要經(jīng)常更新。我一般會這樣，保持這樣一種狀態(tài)：用戶可以不需要任何人就從文檔中找到他需要的所有答案。
如果我發(fā)現(xiàn)用戶的問題無法從文檔中找到，或者難以找到在文檔中的什么地方，就會更新文檔，或者重新組織文檔。如果用戶的問題已經(jīng)從文檔中找到，那么就直接發(fā)文檔給他。如果用戶的問題顯然是文檔看都沒有看過（有很多人根本不看文檔的，只看文檔是誰寫的然后徑直去問這個人），就直接忽略。
優(yōu)秀的文檔應(yīng)該盡量引入少的專有名詞，少使用沒有用處的專業(yè)詞匯描述，只描述具有指導(dǎo)意義的事實，假定用戶沒有相關(guān)的背景知識，列舉使用例子，舉一些現(xiàn)實會用到的例子而不是強(qiáng)行舉例子，明確 Bad Case。等等。這其實是一個很大的話題了，這里就不展開了。
暫時就想到這一些了。下面寫一些我經(jīng)常見到的誤解，和經(jīng)常被別人問的問題。
有關(guān)做項目沒有專業(yè)團(tuán)隊得不到訓(xùn)練
這方面是聽到最多的抱怨。雖然說 SRE 在工作上應(yīng)該是開發(fā)時間和運(yùn)維時間各 50%，但是真實的情況是，即使 SRE 有一些開發(fā)工作，也大部分是面向內(nèi)部用戶，面向公司內(nèi)部的開發(fā)者的。大部分項目是一些想法，需要去嘗試一下行不行，基本上不會有專業(yè)的設(shè)計資源，PM 資源。
這種項目就需要 SRE 有多方面的技能，包括對產(chǎn)品的理解，清楚地知道它有什么痛點(diǎn)，最好是自己經(jīng)歷過的痛點(diǎn)，然后需要懂設(shè)計，管理好開發(fā)進(jìn)度。然而這種人非常少。其實能寫中型項目代碼的 SRE 就已經(jīng)非常少了。所以大部分公司內(nèi)部項目都會做的又難用又復(fù)雜。
即使是有專業(yè)配套 PM 和設(shè)計，甚至前端資源。基本上也是一個災(zāi)難。我也經(jīng)歷過這樣的團(tuán)隊。這種內(nèi)部項目對標(biāo)的不是互聯(lián)網(wǎng)項目，而更像是 toB 的項目。用戶 UI 的設(shè)計，交互邏輯，操作流程，交付周期等需要的都是另一個領(lǐng)域的知識。否則的話人越多，也只會徒增溝通成本，拖慢項目進(jìn)度。
回到經(jīng)常聽到的這個抱怨，說在 SRE 的團(tuán)隊沒有像開發(fā)團(tuán)隊那樣有“正規(guī)軍”，有設(shè)計和 PM，大家各司其職，后端開發(fā)只要對齊 API 然后實現(xiàn)就好了。大部分的應(yīng)屆生會有這樣的幻想，但實際上不是這樣。
被搞錯的最重要的一點(diǎn)是，學(xué)習(xí)主要是靠自己的，和別人沒有太大的關(guān)系。我覺得可能是在一個大團(tuán)隊里面，有很多人一起做一件事情，心里的懷疑和焦慮會少一點(diǎn)，人們會對這樣的工作狀態(tài)感到踏實，誤以為是“成長”，自己做所有的工作焦慮更多。
事實是，在大團(tuán)隊工作可能學(xué)到更多的溝通技能，比如和不同的人對齊不同的階段工作目標(biāo)，要想要學(xué)到其他的東西還是要靠自己。比如拿到一個設(shè)計，如果照樣子去實現(xiàn)了，其實不會學(xué)到什么東西。而要去理解為什么這么設(shè)計，為什么不那么設(shè)計。如果自己去做，思考的過程也基本是這樣的，可以怎么設(shè)計，選擇什么好。都是：思考、選擇、嘗試、經(jīng)驗、思考……
另一個需要澄清的誤區(qū)是，模仿并不是學(xué)習(xí)。在團(tuán)隊中經(jīng)歷了一個設(shè)計，如果記住了這個設(shè)計，下次碰到類似的問題也用這個設(shè)計去解決。這也不能叫做是學(xué)習(xí)。我見過有在業(yè)務(wù)部門做過支付的 SRE 寫的代碼，在內(nèi)部系統(tǒng)中去實現(xiàn)了訂單業(yè)務(wù)的訂單、交易等概念完成一個運(yùn)維流程，甚至 Model 的名字都沒改過。拿著錘子找釘子，會讓系統(tǒng)變得更加糟糕和復(fù)雜。
總之，工作分的細(xì)并不代表工作就會更加專業(yè)。一個人身兼數(shù)職業(yè)可以在每一個方面做得很專業(yè)。重要的是不斷學(xué)習(xí)，使用正確的做事方式，向優(yōu)秀的項目和優(yōu)秀的開發(fā)者學(xué)習(xí)。
有關(guān)臟活累活
每一項工作都會有臟活累活：學(xué)不到什么東西，做起來沒有意思。可能是整理系統(tǒng)的監(jiān)控，可能是整理現(xiàn)有的文檔，可能清理一些年久的運(yùn)維腳本，可能是需要和不同的團(tuán)隊做一些溝通工作[6]等。
這是不可避免的，如果可以的話，學(xué)會從每一項工作中找一些偷懶的方法吧，比如用腳本處理一些工作，用更聰明的方式工作等等。
但是如果這種工作的比例太高的話，就要思考工作方式的問題了。如果陷入惡性循環(huán)，看能不能從工具和工作流程上做一些改變。如果不能的話，考慮換一份工作吧。
有關(guān)背鍋
互相甩鍋的工作環(huán)境無疑是非常糟糕的工作環(huán)境。如果相同的團(tuán)隊、或者不同的團(tuán)隊之間需要相互勾心斗角的話，如果工作環(huán)境不允許大方承認(rèn)（SRE 無可避免地會犯一些錯誤）自己的錯誤，說明公司營造的氛圍有問題。
比如某些公司規(guī)定，發(fā)生 P1 級別的錯誤就必須開除一個 Px 級別的員工，發(fā)生 P0 級別的錯誤就必須開除一個 Py 級別的員工一樣。如果是這種情況的話，公司實際上是在用一種懶惰地方法通過提高人的壓力來提高系統(tǒng)的穩(wěn)定性。有沒有效果不知道，但是確定的是不會有人在這種情況下工作的開心。建議換一份工作。
如何轉(zhuǎn)行？
其實難度沒有想象的高，畢竟大學(xué)里面沒有一個叫做 SRE 的專業(yè)。SRE 要求的知識也是編寫代碼、設(shè)計系統(tǒng)、了解操作系統(tǒng)和網(wǎng)絡(luò)等。所以在大學(xué)里面將本科的課程好好學(xué)好，嘗試做（并維護(hù)）一些自己的項目，畢業(yè)的時候基本上就滿足要求了。非科班的人要轉(zhuǎn)行的話，也可以參考大學(xué)的課程內(nèi)容去補(bǔ)足這方面的知識。
需要注意的是，培訓(xùn)班出來的做開發(fā)完成業(yè)務(wù)可能夠，但是做 SRE 遠(yuǎn)遠(yuǎn)不夠。SRE 不僅需要 make things work，還要知道背后的原理。
面試會問什么？
我覺得和后端開發(fā)的面試內(nèi)容基本上差不多。
如果是去應(yīng)聘的這個崗位所需要的一些技能，比如 Kubernetes，監(jiān)控系統(tǒng)等，可能也會問一些領(lǐng)域內(nèi)的知識。雖說這部分工具性的東西都可以學(xué)習(xí)，但是如果人家要一個經(jīng)驗豐富的、或者入職就能干活的，那么面試成功的機(jī)會就會小很多。
當(dāng)然，也不必沮喪，這是市場的供需關(guān)系決定的，如果對方執(zhí)意要找符合特定要求的候選人，那么對方的選擇的范圍也會小很多，不必因為錯失了這種機(jī)會而后悔沒去學(xué)習(xí)什么工具。話又說回來，技能越多，選擇也會越多。
排查錯誤可能是轉(zhuǎn)行做 SRE 最大的一個門檻，這個需要一些經(jīng)驗。如果沒有經(jīng)驗的話，就補(bǔ)足一些操作系統(tǒng)的知識，這樣遇到未知的問題也可以通過已知的知識和工具去排查。
這個倉庫是一個不錯的面試題集錦：https://github.com/bregman-arie/devops-exercises
做 SRE 需要會寫代碼嗎？
是的，而且寫代碼的要求并不會比一個專業(yè)的后端開發(fā)低。
選擇大公司還是小公司？
這屬于兩種截然不同的工作環(huán)境。小公司一般都有一個救火英雄式的人物，在公司的時間比較長，知道所有組件的部署結(jié)構(gòu)，什么都懂。跟著這種人學(xué)習(xí)會成長很快。
大公司細(xì)分領(lǐng)域很多。本文前面列出的內(nèi)容可能每一項在大公司中都是一個團(tuán)隊，對某個領(lǐng)域可以深入研究。
所以還是看想要做什么了。我個人比較喜歡靠譜的小公司，或者大公司中靠譜的小團(tuán)隊。
如何判斷一家公司是否靠譜？
對于 SRE 這個職位，我總結(jié)了一些判斷的技巧。
比如可以判斷一下對方目前的業(yè)務(wù)和 SRE 員工的數(shù)量是否處于一個“正常”的狀態(tài)，人數(shù)是否在隨著業(yè)務(wù)（機(jī)器的數(shù)量）現(xiàn)象增長？這是一個不好的跡象。是否 SRE 的數(shù)量過多？如果 SRE 人太多，有兩個可能的原因：
某個領(lǐng)導(dǎo)為了擴(kuò)大自己的影響力在為一些“不必要的”崗位招人，這樣會導(dǎo)致人多事少，大家開始做一些奇奇怪怪的事情，發(fā)明奇奇怪怪的需求，以各種各樣的方式浪費(fèi)自己的時間來領(lǐng)公司的工資；
這個公司的基礎(chǔ)太差，大部分工作都是需要人力運(yùn)維，導(dǎo)致基本上有多少機(jī)器就需要多少人。
總之，都不是什么好事情。
一些技術(shù)比較好的公司，都沒有龐大的 SRE 隊伍，比如 Instagram、Netflix（現(xiàn)在可能人數(shù)不少了），以及一些創(chuàng)業(yè)公司，甚至都可以沒有專門的 SRE，優(yōu)秀的 SRE 首先要是開發(fā)者，優(yōu)秀的開發(fā)者也離 SRE 不遠(yuǎn)了。一些耳熟能詳?shù)姆?wù)，比如 webarchive 這樣的數(shù)據(jù)量，其實背后也只有幾個人在維護(hù)[7]。前幾年面試了國內(nèi)的一家公司，在機(jī)房遍布全球，業(yè)務(wù)已經(jīng)發(fā)展的比較龐大（上市了）的時候，SRE 團(tuán)隊也只有 10 個人。
另外我比較喜歡問的一個問題是對方關(guān)于 AIOps 怎么看。因為我之前搞了兩年這個東西，最后得到的結(jié)論是，這基本上是個浪費(fèi)時間、欺騙上層領(lǐng)導(dǎo)的東西[8]。AI 這東西的不可解釋性本質(zhì)上就和運(yùn)維操作將就因果相違背的。
所以經(jīng)常喜歡問面試官怎么看這個技術(shù)，基本上就可以判斷靠不靠譜。當(dāng)然了，這是我個人的職業(yè)陰影導(dǎo)致的后遺癥，只能代表個人意見。
就說這么多吧，都是一些個人理解，不一定對。寫這篇文章感覺自己好像指點(diǎn)江山一樣，其實我自己也干了才幾年而已，所以本文內(nèi)容僅供參考。如果有什么問題可以在評論提出，我能回答的話就盡量回答。
相關(guān)鏈接：
https://www.youtube.com/watch?v=koGaH4ffXaU https://azure.microsoft.com/mediahandler/files/resourcefiles/devops-at-microsoft-game-streaming-sre/DevOps%20at%20Microsoft%20-%20Xbox%20game%20streaming%20SRE.pdf https://www.weave.works/technologies/gitops/ https://en.wikipedia.org/wiki/Standard_operating_procedure https://github.com/danluu/post-mortems https://www.kawabangga.com/posts/4294 https://archive.org/details/jonah-edwards-presentation https://www.kawabangga.com/posts/4145
- END -
推薦閱讀 Kubernetes 生態(tài)架構(gòu)圖 基于Nginx實現(xiàn)灰度發(fā)布與AB測試 Linux 系統(tǒng)日常巡檢腳本 K8s kubectl 常用命令總結(jié)（建議收藏） 搭建一套完整的企業(yè)級 K8s 集群（kubeadm方式）
點(diǎn)亮，服務(wù)器三年不宕機(jī)
