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

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

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

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

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

Netflix[1] （2016 年）的模式是誰開發，誰維護。SRE 負責提供技術支持，和咨詢服務。Netflix 在全球 170 個國家有服務，Core SREs 只有 5 個人。

微軟有專門的 Game Streaming SRE[2]，負責 XBox 在線游戲的穩定性。

所以不同公司的 SRE 的內容各有偏重，取決于公司要提供什么樣的服務。

我們可以學習網絡分層的方式，將 SRE 大致的工作內容從下往上分成 3 個大類：

1. Infrastructure：主要負責最基礎的硬件設施，網絡，類似于 IaaS，做的事情可參考 DigitalOcean
2. Platform：提供中間件技術，開箱即用的一些服務，類似于 PaaS，做的事情可參考 Heroku, GCP, AWS 等
3. 業務 SRE：維護服務，應用，維護業務的正常運行

Infrastructure

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

如果有的話，工作內容也可大可小。可以從管理購買的 vps 開始，也可以從采購硬件服務器開始。

我覺得 Infrastructure SRE 的工作內容可以這樣定義：

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

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

b. NAT 服務

c. DNS 服務

d. 防火墻

e. 4 層負載均衡，7 層負載均衡

f. CDN

g. 證書管理

每一項既可以是一個很大的團隊，也可以只有一個人去對商業化的 Infra 服務。可以使用開源的產品，也可以自己研發。

Platform SRE

Infrastructure SRE 維護的是基礎設施，Platform SRE 使用他們提供的基礎設施建立軟件服務，讓公司內的開發者可以使用開箱即用的軟件服務，比如 Queue，Cache，定時任務，RPC 服務等等。

主要的工作內容有：

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

a. SCM 系統，比如自建的 Gitlab

b. CI/CD 系統

c. 鏡像系統，比如 Harbor

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

10. 一些離線計算環境，大數據的服務

業務 SRE

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

主要的工作內容有：

1. 參與系統的設計。比如熔斷、降級，擴容等策略。
2. 做壓測，了解系統的容量。
3. 做容量規劃。
4. 業務側的 Oncall。

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

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

下面是一些日常的工作內容。

部署服務

部署分成兩種：

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

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

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

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

Oncall

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

收到告警并不總意味著真正的問題，也有可能告警設置的不合理。告警和監控面板并不是一個靜態的配置，它應該是每天都在變化的，時刻在調整的。如果發現沒有標志真正線上問題的告警發了出來，就應該修改告警規則。如果發現當前的監控無法快速定位問題，應該調整監控面板，添加或者刪除監控指標。業務在發展，請求量在變化，某些閾值也需要不斷地調整。

定位問題沒有一概而論的方法了，需要根據看到的實時，結合自己的經驗，然后做推測，然后使用工具驗證自己的推測，然后確定問題的根因。

但是解決問題是可以有方法論的，叫做 SOP，標準操作流程[4]。即：如果出現了這種現象，那么執行那種操作，就可以恢復業務。SOP 文檔應該提前制定，并且驗證其有效性。

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

故障到底多久恢復算好？出現多少故障是可以容忍的？怎么標志服務的穩定性到底如何？我們使用 SLI/SLO 來衡量這些問題。

制定和交付 SLI/SLO

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

比如，制定可用率的時候，并不是說我們去“實現 4 個 9”（99.99% 的時間可用）就夠了，我們有以下問題要考慮：

1. 如何定義這個可用率？比如我們以可用率 > 99.9% 為目標，有一個服務部署了 5 個 Zone, 那么有一個 Zone 掛了，其余的 Zone 是可用的，那么可用率被破壞了嗎？這個可用率是每一個 Zone 的還是所有的 Zone 一起計算的？

2. 可用率計算的最小單位是什么？如果 1min 內有 50s 沒有達到可用率，那么這一分鐘算是 down 還是 up？

3. 可用率的周期是怎么計算的？按照一個月還是一個周？一個周是最近的 7 天還是計算一個自然周？

4. 如何對 SLI 和 SLO 做監控？

5. 如果錯誤預算即將用完，有什么措施？比如減少發布？如果 SLI 和 SLO 沒有達到會怎么樣？

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

故障復盤

故障復盤的唯一目的是減少故障的發生。有幾個我目前認為不錯的做法。

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

故障在復盤的時候應該將當事人的名字用代碼替代，可以營造更好的討論氛圍。

不應該要求所有的故障復盤都產生 Action。之前一家的公司的故障復盤上，因為必須給領導一個“交待”，所以每次都會產生一些措施來預防相同的故障再次發生，比如增加審批流程之類的。這很扯，讓級別很高的領導審批他自己也看不懂的操作，只能讓領導更痛苦，也讓操作流程變得又臭又長，最后所有人都會忘記這里為什么會有一個審批，但是又沒有人敢刪掉。你刪掉，出了事情你負責。

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

容量規劃

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

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

用戶支持

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

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

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

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

有關做項目沒有專業團隊得不到訓練。

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

即使是有專業配套 PM 和設計，甚至前端資源。基本上也是一個災難。我也經歷過這樣的團隊。這種內部項目對標的不是互聯網項目，而更像是 toB 的項目。用戶 UI 的設計，交互邏輯，操作流程，交付周期等需要的都是另一個領域的知識。否則的話人越多，也只會徒增溝通成本，拖慢項目進度。

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

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

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

總之，工作分的細并不代表工作就會更加專業。一個人身兼數職業可以在每一個方面做得很專業。重要的是不斷學習，使用正確的做事方式，向優秀的項目和優秀的開發者學習。

有關臟活累活。

每一項工作都會有臟活累活：學不到什么東西，做起來沒有意思。可能是整理系統的監控，可能是整理現有的文檔，可能清理一些年久的運維腳本，可能是需要和不同的團隊做一些溝通工作[6]等。

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

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

有關背鍋。

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

如何轉行？

其實難度沒有想象的高，畢竟大學里面沒有一個叫做 SRE 的專業。SRE 要求的知識也是編寫代碼、設計系統、了解操作系統和網絡等。所以在大學里面將本科的課程好好學好，嘗試做（并維護）一些自己的項目，畢業的時候基本上就滿足要求了。非科班的人要轉行的話，也可以參考大學的課程內容去補足這方面的知識。

需要注意的是，培訓班出來的做開發完成業務可能夠，但是做 SRE 遠遠不夠。SRE 不僅需要 make things work，還要知道背后的原理。

面試會問什么？

我覺得和后端開發的面試內容基本上差不多。

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

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

做 SRE 需要會寫代碼嗎？

會，而且寫代碼的要求并不會比一個專業的后端開發低。

選擇大公司還是小公司？

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

大公司細分領域很多。本文前面列出的內容可能每一項在大公司中都是一個團隊，對某個領域可以深入研究。

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

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

對于 SRE 這個職位，我總結了一些判斷的技巧。比如可以判斷一下對方目前的業務和 SRE 員工的數量是否處于一個“正常”的狀態，人數是否在隨著業務（機器的數量）現象增長？這是一個不好的跡象。是否 SRE 的數量過多？如果 SRE 人太多，有兩個可能的原因：1）某個領導為了擴大自己的影響力在為一些“不必要的”崗位招人，這樣會導致人多事少，大家開始做一些奇奇怪怪的事情，發明奇奇怪怪的需求，以各種各樣的方式浪費自己的時間來領公司的工資；2）這個公司的基礎太差，大部分工作都是需要人力運維，導致基本上有多少機器就需要多少人。總之，都不是什么好事情。

一些技術比較好的公司，都沒有龐大的 SRE 隊伍，比如 Instagram, Netflix（現在可能人數不少了），以及一些創業公司，甚至都可以沒有專門的 SRE，優秀的 SRE 首先要是開發者，優秀的開發者也離 SRE 不遠了。一些耳熟能詳的服務，比如 webarchive 這樣的數據量，其實背后也只有幾個人在維護[7]。前幾年面試了國內的一家公司，在機房遍布全球，業務已經發展的比較龐大（上市了）的時候，SRE 團隊也只有 10 個人。

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

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

原文鏈接：https://mp.weixin.qq.com/s/dzo9LgIRJI3bfY3Ty8D7rQ