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

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

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

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

Netflix[1] （2016年）的模式是誰開發(fā)，誰維護。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 個大類：

1.  Infrastructure：主要負(fù)責(zé)最基礎(chǔ)的硬件設(shè)施，網(wǎng)絡(luò)，類似于 IaaS，做的事情可參考 DigitalOcean
2.  Platform：提供中間件技術(shù)，開箱即用的一些服務(wù)，類似于 PaaS，做的事情可參考 Heroku, GCP, AWS 等
   
3.  業(yè)務(wù) SRE：維護服務(wù)，應(yīng)用，維護業(yè)務(wù)的正常運行
   

Infrastructure

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

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

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

1.    負(fù)責(zé)服務(wù)器的采購，預(yù)算，CMDB 管理。要知道（能查詢到）每一臺的負(fù)責(zé)人是誰，在干什么。這個非常重要，如果做不好，會造成極大的資源浪費。
   
2.    提供可靠軟件的部署環(huán)境，一般是虛擬機，或者 bare mental。
   
3.    操作系統(tǒng)的版本統(tǒng)一維護，Linux 發(fā)行版的版本，Kernel 的版本等。
   
4.    維護機器上的基礎(chǔ)軟件，比如 NTP，監(jiān)控代理，其他的一些代理。
   
5.    提供機器的登錄方式，權(quán)限管理，命令審計。
   
6.    維護一套可觀測性的基礎(chǔ)設(shè)施，比如監(jiān)控系統(tǒng)，log 系統(tǒng)，trace 系統(tǒng)。
   
7.    維護網(wǎng)絡(luò)，大公司可能都會自己設(shè)計機房內(nèi)的網(wǎng)絡(luò)。其中包括：
   

       a. 網(wǎng)絡(luò)的連通，這個是必要的。對于上層用戶（Platform SRE）來說，交付的服務(wù)應(yīng)該是任意兩個 IP 是可以 ping 通的，即管理好 3 層以下的網(wǎng)絡(luò)。

       b. NAT 服務(wù)

       c. DNSb. 務(wù)

       d. 防火墻

       e. 4 層負(fù)載均衡，7 層負(fù)載均衡

       f. CDN

       g. 證書管理

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

Platform SRE

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

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

1.  RPC 服務(wù)：讓不同的服務(wù)可以互相發(fā)現(xiàn)并調(diào)用
2.  私有云服務(wù)
   
3.  隊列服務(wù)，比如 Kafka 或者 RabbitMQ
   
4.  分布式的 cronjob 服務(wù)
   
5.  Cache
   
6.  網(wǎng)關(guān)服務(wù)：反向代理的配置
   
7.  對象存儲：s3
   
8.  其他一些數(shù)據(jù)庫：ES，mongo 等等。一般來說，關(guān)系型數(shù)據(jù)庫會有 DBA 來運維，但是 NoSQL 或者圖數(shù)據(jù)庫一般由 SRE 維護。
   
9.  內(nèi)部的開發(fā)環(huán)境：
   

       a. SCM 系統(tǒng)，比如自建的 Gitlab

       b. CI/CD 系統(tǒng)

       c. 鏡像系統(tǒng)，比如 Harbor

       d. 其他的一些開發(fā)工具，比如分布式編譯，Sentry 錯誤管理等等

   一些離線計算環(huán)境，大數(shù)據(jù)的服務(wù)

業(yè)務(wù) SRE

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

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

1.  參與系統(tǒng)的設(shè)計。比如熔斷、降級，擴容等策略。
   
2.  做壓測，了解系統(tǒng)的容量。
   
3.  做容量規(guī)劃。
   
4.  業(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)限排查到交換機問題，去找 Infra SRE 幫忙：“請幫我看下 xx IP 到交換機是否有異常，因為 xxx 顯示的結(jié)果是 xx”，總比 “我懷疑 xx 有網(wǎng)絡(luò)問題，請幫忙排查下” 要好一些吧？

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

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

部署服務(wù)

部署分成兩種：

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

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

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

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

Oncall

Oncall 簡單來說就是要保證線上服務(wù)的正常運行。典型的工作流程是：收到告警，檢查告警發(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é)點上，那么就直接下線這個節(jié)點，具體的原因后面再排查。恢復(fù)當(dāng)前的故障永遠(yuǎn)是第一要務(wù)。但是恢復(fù)操作也要經(jīng)過測試，比如猜測可以通過重啟解決問題的話，可以先重啟一臺做測試，而不是一次性將所有服務(wù)重啟。大部分情況是需要臨場分析的，是一個緊張又刺激的過程。

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

制定和交付 SLI/SLO

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

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

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

等等，如果這些問題不考慮清楚的話，那么 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)整運維、變更、發(fā)布計劃。

故障復(fù)盤

故障復(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)該太多，不然活都沒法干了。

容量規(guī)劃

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

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

用戶支持

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

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

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

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

有關(guān)做項目沒有專業(yè)團隊得不到訓(xùn)練。

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

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

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

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

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

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

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

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

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

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

有關(guān)背鍋。

互相甩鍋的工作環(huán)境無疑是非常糟糕的工作環(huá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é)好，嘗試做（并維護）一些自己的項目，畢業(yè)的時候基本上就滿足要求了。非科班的人要轉(zhuǎn)行的話，也可以參考大學(xué)的課程內(nèi)容去補足這方面的知識。

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

面試會問什么？

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

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

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

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

做 SRE 需要會寫代碼嗎？

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

選擇大公司還是小公司？

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

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

所以還是看想要做什么了。我個人比較喜歡靠譜的小公司，或者大公司中靠譜的小團隊。

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

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

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

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

就說這么多吧，都是一些個人理解，不一定對。寫這篇文章感覺自己好像指點江山一樣，其實我自己也干了才幾年而已，所以本文內(nèi)容僅供參考。

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