從CTO視角來看：如何搭建運(yùn)維/SRE能力

近期有很多文章在探討運(yùn)維崗位去留的問題，我主持的SRETalk公眾號(hào)里也發(fā)了多個(gè)運(yùn)維總監(jiān)的觀點(diǎn)，個(gè)人也和行業(yè)內(nèi)挺多人做了交流，有些許小小的想法，記錄下來，供各位CTO/CIO參考，作為運(yùn)維/SRE的你如果覺得迷茫，也推薦你仔細(xì)讀一下本文。

我自認(rèn)為這是一個(gè)深度的思考了，可能枯燥，但對(duì)擇業(yè)和團(tuán)隊(duì)搭建都會(huì)有些幫助。本文歡迎有理有據(jù)的討論，不歡迎杠精，另外，很多事情其實(shí)也沒有非黑即白，文章內(nèi)容對(duì)你有些啟發(fā)，對(duì)CXO們的決策帶來新的思考，那就是極好的。

另外，SRETalk的運(yùn)維總監(jiān)采訪還會(huì)繼續(xù)，還會(huì)有更多不同的觀點(diǎn)持續(xù)輸出，供大家參考，而我的觀點(diǎn)，不一定對(duì)，也是僅供參考哈。

關(guān)于標(biāo)題

首先說一下標(biāo)題，《如何搭建運(yùn)維/SRE能力》，這里我沒有寫搭建團(tuán)隊(duì)，而是搭建能力，因?yàn)橛行┠繕?biāo)的達(dá)成未必一定需要自建團(tuán)隊(duì)，從成本、結(jié)果可預(yù)見性、長(zhǎng)期投入維護(hù)的角度來看，需要慎重決策，決策錯(cuò)了，未來將是一地雞毛，這個(gè)后文再展開。

關(guān)于運(yùn)維/SRE團(tuán)隊(duì)

另外一點(diǎn)也要提前澄清，文中提到的運(yùn)維/SRE團(tuán)隊(duì)都是為業(yè)務(wù)服務(wù)的，業(yè)務(wù)的成功是第一要?jiǎng)?wù)。有些運(yùn)維團(tuán)隊(duì)做了一些產(chǎn)品在對(duì)外商業(yè)化輸出，本身成了一條業(yè)務(wù)，這個(gè)另當(dāng)別論，而且，以我在老東家的經(jīng)驗(yàn)來看，運(yùn)維/SRE團(tuán)隊(duì)這樣的做法（對(duì)外商業(yè)化輸出）不可取，尤其是在一個(gè)沒有ToB基因、沒有相應(yīng)的ToB組織建設(shè)的公司。

從哪里獲取運(yùn)維/SRE能力

既然一切都是為了業(yè)務(wù)成功（不考慮業(yè)務(wù)，只考慮自己能否晉升能否忽悠老板的另當(dāng)別論），我們就重點(diǎn)來看業(yè)務(wù)需要哪些運(yùn)維能力（后文詳細(xì)講解），需要從哪里獲取這些運(yùn)維能力，典型的獲取方式有三種。

自建團(tuán)隊(duì)

首先是通過自建團(tuán)隊(duì)提供相關(guān)能力，這個(gè)方式大家最為熟悉，自建的團(tuán)隊(duì)對(duì)業(yè)務(wù)的交付物通常包括兩部分：產(chǎn)品+服務(wù)。先說產(chǎn)品：

• 如果產(chǎn)品需求是通用需求，產(chǎn)品大概率是直接使用的開源項(xiàng)目。需要考慮開源項(xiàng)目的持久性（開源項(xiàng)目研發(fā)人員是否有商業(yè)公司做收入上的支持，個(gè)人開源項(xiàng)目大都會(huì)死在沒有收入上）、活躍性（項(xiàng)目是否已經(jīng)多年未更新？提的issue、pr是否及時(shí)處理？通常一周內(nèi)處理就可以看做是活躍的）、生態(tài)繁榮性（是否有很多人參與做貢獻(xiàn)？很多公司投入使用？）
• 開源項(xiàng)目是否要二次開發(fā)？如果二次開發(fā)的代碼可以merge回主干，通常意味著二次開發(fā)的代碼具有通用性，得到了開源項(xiàng)目團(tuán)隊(duì)的認(rèn)可。如果無法merge回主干，后面的維護(hù)就是麻煩事了，尤其是人才變動(dòng)之后，一地雞毛。基于開源項(xiàng)目的API做一些膠水代碼，和內(nèi)部系統(tǒng)做整合，通常是可以的，畢竟沒有改造開源代碼，后面開源項(xiàng)目升級(jí)還是可以跟得上的
• 當(dāng)然也有不用開源完全自研的（只是使用一些開源的lib庫(kù)，核心產(chǎn)品邏輯自研），這種要慎重，如果開源社區(qū)沒有相關(guān)的產(chǎn)品，那只能自研，但是自研之后就要考慮長(zhǎng)期維護(hù)的問題，研發(fā)人員通常喜歡做從0到1的事情，后面收益小了，無法晉升漲薪，就容易變動(dòng)。而運(yùn)維這個(gè)賽道，開源社區(qū)的產(chǎn)品琳瑯滿目，需要自研的產(chǎn)品可能屈指可數(shù)，三思。

其次就是服務(wù)，這里所謂的服務(wù)，說的是向業(yè)務(wù)側(cè)輸出的專家經(jīng)驗(yàn)。比如自建團(tuán)隊(duì)做了一款監(jiān)控產(chǎn)品，這個(gè)團(tuán)隊(duì)需要給公司內(nèi)部的“客戶”輸出監(jiān)控的最佳實(shí)踐、監(jiān)控產(chǎn)品出問題的時(shí)候需要這個(gè)團(tuán)隊(duì)快速解決。其實(shí)，公司內(nèi)部的中后臺(tái)團(tuán)隊(duì)需要有很強(qiáng)的服務(wù)意識(shí)，同時(shí)還得了解行業(yè)最佳實(shí)踐，否則，就容易被業(yè)務(wù)牽著鼻子走，走出了和行業(yè)最佳實(shí)踐背道而馳的路子，后面，就都是問題了。

服務(wù)的核心，是靠人（當(dāng)然，能把最佳實(shí)踐固化到產(chǎn)品里，那自然是極好的），作為管理者，要想讓這個(gè)團(tuán)隊(duì)輸出好的服務(wù)，就需要考慮很多人的問題，比如：能否招到相關(guān)的人才、能否留住相關(guān)的人才（發(fā)展空間、薪資等）、自建團(tuán)隊(duì)每個(gè)方向至少兩個(gè)人互備，成本是否可以接得住。

第三方供應(yīng)商

通過第三方供應(yīng)商來獲取運(yùn)維能力，是另一個(gè)路子，供應(yīng)商的交付物顯然也包括兩部分：產(chǎn)品+服務(wù)。產(chǎn)品分為開源、閉源兩種類型，有哪些考量點(diǎn)呢？

• 開源的產(chǎn)品通常會(huì)有更多的用戶、更多的場(chǎng)景來打磨，但是一些長(zhǎng)尾需求，通常不開源，至于原因么，要么是開源團(tuán)隊(duì)把這些長(zhǎng)尾需求作為收費(fèi)項(xiàng)，要么就是開源團(tuán)隊(duì)覺得這些長(zhǎng)尾需求不夠通用，不值得放到產(chǎn)品里。
• 閉源的產(chǎn)品，通常受眾小，沒有太多的開源用戶幫助打磨產(chǎn)品，就需要經(jīng)過較長(zhǎng)時(shí)間的商業(yè)化客戶打磨，或者，閉源產(chǎn)品的供應(yīng)商有很強(qiáng)大的質(zhì)量管理體系，對(duì)產(chǎn)品有完備的測(cè)試，這就需要找那些家大業(yè)大的供應(yīng)商了，而且，測(cè)試人員和終端用戶畢竟是兩類人群，商業(yè)客戶的打磨是不可或缺的，只是，如果供應(yīng)商有強(qiáng)大的質(zhì)量保障團(tuán)隊(duì)，會(huì)讓這個(gè)打磨過程變得短一些。
• 不管是開源還是閉源，供應(yīng)商都是帶著產(chǎn)品來的，作為甲方可以直接測(cè)試，來看產(chǎn)品匹配度，很快就可以得到反饋，而自建團(tuán)隊(duì)來做的話，可能需要幾個(gè)月甚至一兩年的時(shí)間來開發(fā)，業(yè)務(wù)可能等不起，開發(fā)完了之后產(chǎn)品是否真的符合預(yù)期，又有很多因素決定，結(jié)果具有不可預(yù)見性。

其次是服務(wù)，供應(yīng)商相比自建的團(tuán)隊(duì)，通常會(huì)有優(yōu)勢(shì)。原因如下：

• 因?yàn)楣?yīng)商見識(shí)了更多的客戶場(chǎng)景，而ToB公司，長(zhǎng)期的行業(yè)Know-How的積累，是這個(gè)公司的核心競(jìng)爭(zhēng)力，供應(yīng)商會(huì)不斷的從優(yōu)秀客戶那里汲取經(jīng)驗(yàn)，反哺給那些不那么先進(jìn)的客戶，良性循環(huán)，多方共贏。
• 也是因?yàn)楣?yīng)商見識(shí)了更多的場(chǎng)景，可以對(duì)產(chǎn)品做更好的抽象，可以讓產(chǎn)品更通用，更像一個(gè)產(chǎn)品，而自建團(tuán)隊(duì)做的產(chǎn)品，通常更偏工具，無意冒犯，我說的是通常。
• 供應(yīng)商之所以在運(yùn)維這個(gè)賽道創(chuàng)業(yè)，大概率是在這個(gè)賽道有些建樹的，相比自建團(tuán)隊(duì)，供應(yīng)商的頂層認(rèn)知通常會(huì)好一些，你真的去招人的時(shí)候就會(huì)發(fā)現(xiàn)了，最牛逼的那群人，要么創(chuàng)業(yè)了，要么太貴了，要么不愿意來。

另外說一下成本問題，供應(yīng)商的收費(fèi)大概率是比自己招人（前提是招到合適的人）來的劃算，否則的話，商業(yè)邏輯不成立。這個(gè)道理顯而易見不再贅述。

從第三方供應(yīng)商這里獲取運(yùn)維能力，看起來是碾壓自建團(tuán)隊(duì)的，所以，后面的文章還用讀么？其實(shí)也不盡然，對(duì)于某個(gè)運(yùn)維能力，到底更看重的是產(chǎn)品能力，還是服務(wù)能力，你最需要的是產(chǎn)品能力還是服務(wù)能力，需要 case by case 的看，后文，我會(huì)從業(yè)務(wù)側(cè)需要的各個(gè)方面的運(yùn)維能力分別拆解。

業(yè)務(wù)需要哪些技術(shù)支撐能力

運(yùn)維本質(zhì)是一類技術(shù)支撐能力，跟基礎(chǔ)架構(gòu)團(tuán)隊(duì)很像，有些活放到運(yùn)維團(tuán)隊(duì)是可以的，放到基礎(chǔ)架構(gòu)團(tuán)隊(duì)問題也不大，甚至有些公司直接把這類人放到業(yè)務(wù)研發(fā)團(tuán)隊(duì)，我們暫且不管分工的問題，先來梳理一下業(yè)務(wù)需要什么樣的技術(shù)支撐能力。

這個(gè)圖其實(shí)已經(jīng)很能說明問題了，我再稍微啰嗦一下：

• 可靠的基礎(chǔ)環(huán)境和組件：業(yè)務(wù)程序要運(yùn)行，需要基礎(chǔ)網(wǎng)絡(luò)、硬件、操作系統(tǒng)、數(shù)據(jù)庫(kù)、中間件等，需要這些環(huán)境和組件穩(wěn)定可靠
• 快速安全變更的能力：快速變更的能力，大家很容易理解，作為研發(fā)人員，寫了一個(gè)feature或者做了個(gè)bugfix，肯定很想快速交付，但是變更很容易導(dǎo)致故障，變更需要受控，需要盡量確保安全
• 可靠性保障能力：軟件部署到生產(chǎn)環(huán)境之后，可能會(huì)遇到各類問題，如何能夠提前做好風(fēng)險(xiǎn)量化，如何能快速發(fā)現(xiàn)問題、定位問題、快速止損，這可能是業(yè)務(wù)側(cè)對(duì)運(yùn)維側(cè)最重要的訴求了
• 最佳實(shí)踐：業(yè)務(wù)依賴很多基礎(chǔ)支撐能力，這些能力用的如何？是不是業(yè)界最佳實(shí)踐？是不是公司內(nèi)其他大部分業(yè)務(wù)的最佳實(shí)踐？需要基礎(chǔ)支撐團(tuán)隊(duì)反哺給業(yè)務(wù)

各個(gè)能力如何獲取

上面談及的四個(gè)能力，應(yīng)該如何獲取？下面我們就掰開了揉碎了講一講。

可靠的基礎(chǔ)環(huán)境和組件

首先說基礎(chǔ)硬件環(huán)境，顯然有兩種選擇，上云 or 自建，如果是政策有要求必須自己折騰，那沒有辦法，以政策為準(zhǔn)。如果可以自行選擇，現(xiàn)在這個(gè)時(shí)代，大概率是上云更合適，除非公司體量很大，機(jī)器量很大，自建才可能有優(yōu)勢(shì)。注意，我這里說的是才可能，算成本的時(shí)候切記要把人力成本算上，別只算了硬件的成本。

關(guān)于擇業(yè)：對(duì)于系統(tǒng)運(yùn)維工程師、網(wǎng)絡(luò)運(yùn)維工程師，看起來并不是個(gè)好消息，云的出現(xiàn)確實(shí)搶占了一部分這類崗位的空間，沒辦法，時(shí)代的車輪滾滾向前，大家都是歷史的塵埃。

再說組件，比如mysql、redis、mongodb、kafka、elasticsearch、nginx、kubernetes等等，顯然有3種選擇，使用云上paas產(chǎn)品 or 自己折騰 or 自己出硬件+供應(yīng)商出方案和服務(wù)。針對(duì)每種選擇，我們分別做一下點(diǎn)評(píng)：

• 云上PaaS產(chǎn)品：如果規(guī)模不大，沒有相關(guān)人才儲(chǔ)備，使用云上PaaS產(chǎn)品，是比較合適的，可以快速把能力建設(shè)起來，選擇使用云上PaaS產(chǎn)品的甲方，通常已經(jīng)使用了云上的虛擬機(jī)、Kubernetes類的Runtime環(huán)境，順帶采買PaaS類的產(chǎn)品，也比較絲滑，不需要再跟新的供應(yīng)商做對(duì)接。
• 自己折騰：如果某個(gè)組件規(guī)模很大，或許是有自建的必要性的，比如Kafka，自己折騰，招2個(gè)人一主一備，水平還可以，出了問題能兜底，在北京的話每年大概100萬的成本，得多大的規(guī)模才能從硬件和組件上省出這些錢呢？當(dāng)然，也可以招聘一些低成本的運(yùn)維工程師（劃重點(diǎn)，這里可能需要運(yùn)維工程師，但是職級(jí)不高），能解決日常問題，高階問題解不了，高階問題可以求助外部供應(yīng)商的專家服務(wù)。
• 自己出硬件+供應(yīng)商出方案和服務(wù)：第三方供應(yīng)商相比云廠商的PaaS產(chǎn)品，通常性價(jià)比更高，響應(yīng)更快，但是組件如此之多，每個(gè)供應(yīng)商大概率只能搞定有限的幾款，作為甲方，可能要同時(shí)跟多個(gè)供應(yīng)商打交道，略微麻煩。對(duì)于需要跨云協(xié)同的產(chǎn)品，比如統(tǒng)一監(jiān)控、故障定位、FinOps相關(guān)的產(chǎn)品，如果公司用了多家云或是混合云架構(gòu)，大概率是第三方供應(yīng)商更為合適。

關(guān)于擇業(yè)：各組件的資深老炮，第一選擇是去云廠商工作或創(chuàng)業(yè)輸出經(jīng)驗(yàn)，第二選擇去自建組件的大廠，普通中小廠，很難有高薪資，畢竟第三方的專家服務(wù)性價(jià)比不低。

快速安全變更的能力

業(yè)務(wù)研發(fā)最常做的變更是二進(jìn)制、配置的變更，當(dāng)然，還有對(duì)基礎(chǔ)環(huán)境以及組件的變更需求。

我們先說二進(jìn)制、配置的變更，怎么做才能又快又安全的迭代呢？可以分階段，公司還比較小的時(shí)候，不用太關(guān)注工具的建設(shè)，只需要定好規(guī)范和流程即可。規(guī)范方面比如：部署在哪個(gè)賬號(hào)下，哪個(gè)目錄下，日志怎么放，進(jìn)程怎么托管，任何變更必須能夠可回滾等等，流程方面比如：變更通報(bào)機(jī)制、多模塊協(xié)同上線機(jī)制、無法回滾的需要有審批機(jī)制等等。

然后，需要有歷史變更的量化數(shù)據(jù)，比如某個(gè)團(tuán)隊(duì)最近一個(gè)季度有多少次變更，回滾率如何，故障率如何，各個(gè)團(tuán)隊(duì)有個(gè)對(duì)比，做的不好的團(tuán)隊(duì)就會(huì)在下個(gè)季度好好改善的。

當(dāng)公司繼續(xù)變大，就可以投入人力做變更類的平臺(tái)，把規(guī)范制度落實(shí)到平臺(tái)上，產(chǎn)出量化數(shù)據(jù)，因?yàn)椴煌墓厩闆r各異，在傳統(tǒng)的物理機(jī)虛擬機(jī)時(shí)代，很少看到有商業(yè)化的變更系統(tǒng)。當(dāng)然，Kubernetes起來之后，屏蔽掉了底層的很多差異，基于Kubernetes做變更平臺(tái)通用性強(qiáng)了很多，開始有相關(guān)的產(chǎn)品出來。

生產(chǎn)環(huán)境的變更，和測(cè)試環(huán)境、聯(lián)調(diào)環(huán)境的變更還不太一樣，生產(chǎn)環(huán)境對(duì)穩(wěn)定性要求比較苛刻，測(cè)試環(huán)境、聯(lián)調(diào)環(huán)境則相對(duì)沒有太高的要求。所謂的CI/CD的系統(tǒng)，大都是針對(duì)測(cè)試環(huán)境、聯(lián)調(diào)環(huán)境的，能夠?qū)ιa(chǎn)環(huán)境做到CD的公司，屈指可數(shù)。

劃重點(diǎn)：測(cè)試、聯(lián)調(diào)環(huán)境的CI/CD系統(tǒng)，更多的是為研發(fā)效率提速；生產(chǎn)環(huán)境的變更系統(tǒng)，更多的是確保穩(wěn)定性、落地規(guī)范制度的。公司前期體量小，靠規(guī)章制度就夠了，后面就需要規(guī)章制度+變更平臺(tái)協(xié)同發(fā)力了。

這個(gè)規(guī)范制度誰來定？變更平臺(tái)誰來開發(fā)？

規(guī)范的制定其實(shí)偏前期，可能運(yùn)維團(tuán)隊(duì)都還沒有的時(shí)候規(guī)范就已經(jīng)有了，所以，大概率是CTO以及下轄的Core團(tuán)隊(duì)來制定就好了。如果之前沒有制定過，運(yùn)維總監(jiān)（運(yùn)維總監(jiān)上場(chǎng)了）可以牽頭制定，CTO下轄的Core團(tuán)隊(duì)來評(píng)審（大家有參與度），最終CTO拍板（自頂向下）發(fā)布，大家執(zhí)行。

變更平臺(tái)的開發(fā)，由運(yùn)維團(tuán)隊(duì)來開發(fā)相對(duì)比較合適，后文還會(huì)介紹一些其他的平臺(tái)，成立一個(gè)專門的運(yùn)維團(tuán)隊(duì)（這里我說的運(yùn)維和SRE沒有區(qū)別，你也可以管這個(gè)團(tuán)隊(duì)叫SRE團(tuán)隊(duì)）是合適的。變更平臺(tái)因?yàn)橐涞毓镜囊?guī)范，外采的情況比較少，公司大到一定規(guī)模之后，基于開源的東西自研、攢，是個(gè)大概率的選擇。

關(guān)于擇業(yè)：變更管理是企業(yè)中的重要一環(huán)，同時(shí)服務(wù)于穩(wěn)定性體系。這是一個(gè)典型的devops崗位，天花板大概在P7+的水平（純屬個(gè)人看法，僅供參考）。

另外就是基礎(chǔ)組件和環(huán)境的變更，典型的比如MySQL表結(jié)構(gòu)、Nginx配置、DNS、VIP等等，這類變更可以內(nèi)化到組件管控平臺(tái)里，讓組件能力提供方提供變更入口和管控能力。

可靠性保障能力

這個(gè)能力非常重要，SRE就是Site Reliability Engineering的縮寫，即站點(diǎn)可靠性工程。從CTO的角度，軟件部署到生產(chǎn)環(huán)境，后續(xù)可能會(huì)有各種問題發(fā)生，希望能有一套工程體系來保障可靠性。這是一個(gè)巨大的話題，本文不會(huì)事無巨細(xì)，只是理清楚哪些事哪些人來負(fù)責(zé)即可。

所謂的可靠性，就是與故障做斗爭(zhēng)的過程，所以，我們還是來看故障的生命周期，從生命周期的各個(gè)環(huán)節(jié)著手，把故障打趴下，甚至直接把它扼殺在搖籃之中。

故障開始之前降發(fā)生

事前的預(yù)防和風(fēng)控，有很多的工作。比如：制定告警完備性標(biāo)準(zhǔn)并對(duì)各個(gè)業(yè)務(wù)線做量化評(píng)估；制定定位原則和流程以及故障定級(jí)定責(zé)的標(biāo)準(zhǔn)；提前梳理各個(gè)業(yè)務(wù)的核心功能和服務(wù)模塊的對(duì)應(yīng)關(guān)系，建立全局穩(wěn)定性視圖或者作戰(zhàn)室，便于快速揪出故障模塊或接口；對(duì)架構(gòu)做優(yōu)化；梳理故障預(yù)案并定期演練保鮮，也就是混沌工程那攤事；等等等等。

這里有些事情是需要業(yè)務(wù)研發(fā)來搞定的，比如架構(gòu)優(yōu)化，剩下的事情，我的建議是：讓運(yùn)維團(tuán)隊(duì)來牽頭，研發(fā)配合。比如CTO下轄的Core團(tuán)隊(duì)大概率既有運(yùn)維一號(hào)位也有各個(gè)業(yè)務(wù)的技術(shù)一號(hào)位，名義上要CTO拍板，授權(quán)運(yùn)維一號(hào)位來牽頭，各個(gè)業(yè)務(wù)的研發(fā)一號(hào)位來配合，當(dāng)然了，實(shí)際操刀的時(shí)候，運(yùn)維一號(hào)位可能是找了一個(gè)得力干將來實(shí)操，各個(gè)業(yè)務(wù)線可能也是有技術(shù)一號(hào)位依仗的人來做接口人配合。

除了架構(gòu)優(yōu)化之外，其他這些事情都是橫向的事情，是可以有一些方法論和最佳實(shí)踐的，把大家拉通，有利于共享這些方法論和最佳實(shí)踐。當(dāng)然，有些人會(huì)有疑問：我們能否直接在研發(fā)團(tuán)隊(duì)找個(gè)人來組成這么一個(gè)穩(wěn)定性的虛擬組織，共同推進(jìn)這個(gè)事情呢？其實(shí)也可以嘗試。不過會(huì)有這么幾點(diǎn)問題：

• 每個(gè)業(yè)務(wù)線通常只有這么一兩個(gè)接口人，人少活多，這個(gè)人大概率很難兼顧業(yè)務(wù)代碼開發(fā)和穩(wěn)定性工作，如果這個(gè)人全職做穩(wěn)定性了，其實(shí)就相當(dāng)于SRE了
• 如果是SRE，和業(yè)務(wù)研發(fā)人員的考核體系其實(shí)是不同的，KPI怎么定？而且這個(gè)人可能也沒有很好的歸屬感
• 如果這個(gè)人同時(shí)兼顧兩個(gè)事情：穩(wěn)定性、業(yè)務(wù)研發(fā)，可能會(huì)引發(fā)人的惰性，穩(wěn)定性工作遇到問題的時(shí)候，天然的就會(huì)想去干點(diǎn)業(yè)務(wù)研發(fā)的活，業(yè)務(wù)研發(fā)遇到問題的時(shí)候，又想偷懶去干穩(wěn)定性的活

劃重點(diǎn)：事前的預(yù)防和風(fēng)控，請(qǐng)各位CXO找運(yùn)維總監(jiān)要結(jié)果，但是必須給予極大的配合，從上往下推。對(duì)于搞定這攤事的SRE工程師角色，看起來是需要非常專業(yè)的高級(jí)別人士，工作5年以內(nèi)大概率認(rèn)知跟不上，或許，從資深研發(fā)團(tuán)隊(duì)招SRE是一個(gè)不錯(cuò)的選擇，各位CXO可以嘗試下。

故障開始之后降影響

一旦故障發(fā)生，我們的首要目標(biāo)就變成降影響了。相關(guān)團(tuán)隊(duì)立馬協(xié)作起來，快速定位直接原因、快速止損，事后再慢慢排查根因即可。這里會(huì)涉及如下一些工作內(nèi)容：

• 定義故障：通常，業(yè)務(wù)的指標(biāo)出現(xiàn)問題就代表故障開始了，比如訂單量下跌、叫車呼叫量下跌、支付量下跌，老板會(huì)尤為關(guān)注這類指標(biāo)；而某個(gè)機(jī)器的CPU飆高或者磁盤用滿，可能只是團(tuán)隊(duì)內(nèi)部消化的問題，甚至K8s類的系統(tǒng)自動(dòng)漂移解決，通常對(duì)客戶主流程沒有影響，老板是不關(guān)注的。為了不至于草木皆兵，我們就需要區(qū)分故障和問題的定義，不同的業(yè)務(wù)線指標(biāo)不同，但是總體方法論是一樣的。
• 響應(yīng)故障：故障告警接收人是給業(yè)務(wù)研發(fā)？還是SRE？還是OnCall中心？不同的公司做法差異巨大，我個(gè)人的想法是：直接發(fā)給有能力處理的人！沒有非黑即白，不同的告警不同的處理機(jī)制，比如基礎(chǔ)網(wǎng)絡(luò)有問題，顯然是要發(fā)給網(wǎng)工，某個(gè)業(yè)務(wù)有問題，發(fā)給對(duì)應(yīng)的運(yùn)維和研發(fā)，盡量不要在中間再轉(zhuǎn)一次，發(fā)給張三，張三處理不了去聯(lián)系李四，就浪費(fèi)時(shí)間了，故障處理應(yīng)該爭(zhēng)分奪秒。
• 快速定位：一套行之有效的故障定位系統(tǒng)，是大殺器。故障定位系統(tǒng)通常是基于可觀測(cè)性數(shù)據(jù)構(gòu)建的，可以看做是駕駛艙級(jí)別的產(chǎn)品。可觀測(cè)性數(shù)據(jù)是海量的，如果不經(jīng)過梳理利用，這些海量的數(shù)據(jù)無法變成有價(jià)值的信息。從定位的角度來看，通常需要的是：可觀測(cè)性體系+故障定位+持續(xù)運(yùn)營(yíng)，這里要展開的話內(nèi)容就太多了，如想詳細(xì)探討可以聯(lián)系我，什么？不知道怎么聯(lián)系？SRETalk公眾號(hào)，了解一下。
• 快速止損：止損要快，就要有完備的預(yù)案，每次故障復(fù)盤的時(shí)候，建議CTO、運(yùn)維總監(jiān)關(guān)注預(yù)案有效率，就是說，這個(gè)故障是否是利用一個(gè)既有的預(yù)案來止損的，還是現(xiàn)攢的解決方案。如果是現(xiàn)攢的，說明你們的預(yù)案不夠完備啊。

OK，上面洋洋灑灑一片，回歸問題，針對(duì)這塊工作內(nèi)容，CTO找誰要結(jié)果？我的建議是：SRE團(tuán)隊(duì)（文中多次出現(xiàn)運(yùn)維、SRE字眼，在本文中基本都代表一個(gè)意思，這里的運(yùn)維不止是Operations）。顯然SRE無法搞定所有的故障，應(yīng)該說大部分故障都得借助其他團(tuán)隊(duì)的人，但是CTO總不能一會(huì)找A團(tuán)隊(duì)一會(huì)找B團(tuán)隊(duì)吧。所以，SRE要攜CTO的尚方寶劍，牽頭整體的穩(wěn)定性建設(shè)，各個(gè)業(yè)務(wù)需要出接口人極力配合，所謂的穩(wěn)定性建設(shè)，包括事前的預(yù)防風(fēng)控、事中的統(tǒng)籌協(xié)同、事后的復(fù)盤推進(jìn)，這也是SRE對(duì)公司的最大價(jià)值。

最佳實(shí)踐

這個(gè)內(nèi)容很多，比如用什么機(jī)型套餐比較合適，用什么組網(wǎng)方式比較合適，用哪些組件公司具有更好的掌控力、可以得到更好的支持（不管是內(nèi)部團(tuán)隊(duì)還是借助第三方供應(yīng)商），公司推薦甚至要求的編程語言、框架是什么，業(yè)界推薦的接入層方案是什么？變更方案是什么？可觀測(cè)性怎么做？等等等等。

不可否認(rèn)，牛逼的業(yè)務(wù)研發(fā)團(tuán)隊(duì)，這些實(shí)踐方式是門清的，但是同樣不可否認(rèn)，業(yè)務(wù)線多了之后，水平是良莠不齊的，水平差的團(tuán)隊(duì)勢(shì)必需要教練角色的人，總不能啥事都去找CTO吧，SRE團(tuán)隊(duì)作為一個(gè)橫向的技術(shù)團(tuán)隊(duì)，特別適合負(fù)責(zé)這攤事。但是顯然，這是一個(gè)高端職位，新瓜蛋子干不來，招聘高階人士做業(yè)務(wù)BP是推進(jìn)技術(shù)棧趨于統(tǒng)一的有效手段，如果CTO用不好這個(gè)抓手，技術(shù)體系會(huì)百花齊放，后面則是各種治理困局。

上面的四個(gè)支撐能力，業(yè)務(wù)側(cè)應(yīng)該如何獲取，CTO應(yīng)該如何統(tǒng)籌，各團(tuán)隊(duì)?wèi)?yīng)該如何配合，大致就說這么多。下面我們?cè)僮鰞蓚€(gè)小結(jié)。

小結(jié)1：CTO如何幫助業(yè)務(wù)線獲取這些支撐能力？

顯然，CTO不需要親力親為，但CTO要做好把關(guān)，CTO要頒發(fā)政策，是全軍統(tǒng)帥。橫向的工作落給SRE團(tuán)隊(duì)，各團(tuán)隊(duì)出接口人極力配合，大概率是個(gè)最佳實(shí)踐。如果把橫向的工作目標(biāo)完全打散到業(yè)務(wù)團(tuán)隊(duì)自閉環(huán)，就無法享受到橫向團(tuán)隊(duì)帶來的經(jīng)驗(yàn)傳播能力。而且，屁股決定腦袋，不在其位不謀其政，各個(gè)業(yè)務(wù)自己容易有小九九，中心的橫向組織也是一個(gè)削藩機(jī)制，抱歉這個(gè)詞用的重了，本意是好的，你要自己體會(huì)啦。

另外補(bǔ)充一點(diǎn)FinOps的話題，F(xiàn)inOps也是一個(gè)橫向能力，是否也要交由SRE來做呢？這個(gè)倒是未必。就讓業(yè)務(wù)自閉環(huán)我覺得也挺好的，業(yè)務(wù)自己要負(fù)責(zé)盈虧，IT支出是支出大頭，業(yè)務(wù)的GM理應(yīng)是很上心的，CEO把營(yíng)收凈利相關(guān)的KPI壓給業(yè)務(wù)GM，業(yè)務(wù)GM可以自閉環(huán)做好折中的。

小結(jié)2：運(yùn)維/SRE擇業(yè)建議

如果沒有太高的職級(jí)和薪資期望，做一些相對(duì)基礎(chǔ)的Operations工作也是可以的，10年內(nèi)這個(gè)崗位大概率不會(huì)消亡。如果對(duì)職級(jí)和薪資有更高期望，先深扎某個(gè)細(xì)分領(lǐng)域，做到行業(yè)專家，是一條行之有效的路徑。再之后，則講究多個(gè)技術(shù)方向的融會(huì)貫通了，又要往廣度發(fā)展。再之后，創(chuàng)業(yè)或者高管。

本文作者

秦曉輝，Open-Falcon、Nightingale 創(chuàng)業(yè)研發(fā)，極客時(shí)間《??運(yùn)維監(jiān)控系統(tǒng)實(shí)戰(zhàn)筆記???》作者，公眾號(hào) SRETalk 主理人，快貓星云創(chuàng)業(yè)合伙人，創(chuàng)業(yè)方向是穩(wěn)定性保障方向，如有需求歡迎??運(yùn)維監(jiān)控系統(tǒng)實(shí)戰(zhàn)筆記??。