[[435670]]

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

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

SRE 目前對(duì)于招聘來(lái)說(shuō)還是比較困難。一方面，這個(gè)崗位需要一定的經(jīng)驗(yàn)，而應(yīng)屆生一般來(lái)說(shuō)不會(huì)有運(yùn)維復(fù)雜軟件的經(jīng)歷；另一方面就是很多人依然以為這就是“運(yùn)維”工程師，認(rèn)為做的是一些低級(jí)重復(fù)的工作，對(duì)這個(gè)工作有排斥。最根本的，其實(shí)這個(gè)崗位尋找的要么是具有運(yùn)維經(jīng)驗(yàn)的開(kāi)發(fā)人員，要么是具有軟件開(kāi)發(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ù)目正確，對(duì)賬沒(méi)有錯(cuò)誤，工作內(nèi)容以開(kāi)發(fā)為主，主要是資金核對(duì)平臺(tái)和核對(duì)規(guī)則（沒(méi)有做過(guò)，只是個(gè)人理解）。某種意義上說(shuō)，已經(jīng)不算是 SRE 而是專業(yè)領(lǐng)域的開(kāi)發(fā)了。

Netflix[1] （2016 年）的模式是誰(shuí)開(kāi)發(fā)，誰(shuí)維護(hù)。SRE 負(fù)責(zé)提供技術(shù)支持，和咨詢服務(wù)。Netflix 在全球 170 個(gè)國(guó)家有服務(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ù)，開(kāi)箱即用的一些服務(wù)，類似于 PaaS，做的事情可參考 Heroku, GCP, AWS 等
3.  業(yè)務(wù) SRE：維護(hù)服務(wù)，應(yīng)用，維護(hù)業(yè)務(wù)的正常運(yùn)行

Infrastructure

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

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

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

1.  負(fù)責(zé)服務(wù)器的采購(gòu)，預(yù)算，CMDB 管理。要知道（能查詢到）每一臺(tái)的負(fù)責(zé)人是誰(shuí)，在干什么。這個(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ù)一套可觀測(cè)性的基礎(chǔ)設(shè)施，比如監(jiān)控系統(tǒng)，log 系統(tǒng)，trace 系統(tǒng)。
7.  維護(hù)網(wǎng)絡(luò)，大公司可能都會(huì)自己設(shè)計(jì)機(jī)房?jī)?nèi)的網(wǎng)絡(luò)。其中包括：

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

              b.  NAT 服務(wù)

              c.  DNS 服務(wù)

              d.  防火墻

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

              f.  CDN

              g.  證書(shū)管理

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

Platform SRE

Infrastructure SRE 維護(hù)的是基礎(chǔ)設(shè)施，Platform SRE 使用他們提供的基礎(chǔ)設(shè)施建立軟件服務(wù)，讓公司內(nèi)的開(kāi)發(fā)者可以使用開(kāi)箱即用的軟件服務(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.  對(duì)象存儲(chǔ)：s3
8.  其他一些數(shù)據(jù)庫(kù)：ES，mongo 等等。一般來(lái)說(shuō)，關(guān)系型數(shù)據(jù)庫(kù)會(huì)有 DBA 來(lái)運(yùn)維，但是 NoSQL 或者圖數(shù)據(jù)庫(kù)一般由 SRE 維護(hù)。
9.  內(nèi)部的開(kāi)發(fā)環(huán)境：

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

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

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

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

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

業(yè)務(wù) SRE

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

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

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

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

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

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

部署服務(wù)

部署分成兩種：

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

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

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

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

Oncall

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

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

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

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

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

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

制定和交付 SLI/SLO

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

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

    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 沒(méi)有達(dá)到可用率，那么這一分鐘算是 down 還是 up？

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

    4.  如何對(duì) SLI 和 SLO 做監(jiān)控？

    5.  如果錯(cuò)誤預(yù)算即將用完，有什么措施？比如減少發(fā)布？如果 SLI 和 SLO 沒(méi)有達(dá)到會(huì)怎么樣？

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

故障復(fù)盤

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

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

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

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

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

容量規(guī)劃

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

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

用戶支持

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

有關(guān)背鍋。

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

如何轉(zhuǎn)行？

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

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

面試會(huì)問(wèn)什么？

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

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

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

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

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

選擇大公司還是小公司？

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

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

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

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

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

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

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

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