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

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

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

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

首先說一下標(biāo)題，《如何搭建運維/SRE能力》，這里我沒有寫搭建團隊，而是搭建能力，因為有些目標(biāo)的達成未必一定需要自建團隊，從成本、結(jié)果可預(yù)見性、長期投入維護的角度來看，需要慎重決策，決策錯了，未來將是一地雞毛，這個后文再展開。

關(guān)于運維/SRE團隊

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

從哪里獲取運維/SRE能力

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

自建團隊

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

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

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

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

第三方供應(yīng)商

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

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

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

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

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

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

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

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

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

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

各個能力如何獲取

上面談及的四個能力，應(yīng)該如何獲?。肯旅嫖覀兙完_了揉碎了講一講。

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

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

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

再說組件，比如MySQL、Redis、MongoDB、Kafka、ElasticSearch、Nginx、Kubernetes等等，顯然有3種選擇，使用云上PaaS產(chǎn)品 or 自己折騰 or 自己出硬件+供應(yīng)商出方案和服務(wù)。針對每種選擇，我們分別做一下點評：

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

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

快速安全變更的能力

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

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

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

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

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

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

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

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

變更平臺的開發(fā)，由運維團隊來開發(fā)相對比較合適，后文還會介紹一些其他的平臺，成立一個專門的運維團隊（這里我說的運維和SRE沒有區(qū)別，你也可以管這個團隊叫SRE團隊）是合適的。變更平臺因為要落地公司的規(guī)范，外采的情況比較少，公司大到一定規(guī)模之后，基于開源的東西自研、攢，是個大概率的選擇。

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

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

可靠性保障能力

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

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

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

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

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

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

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

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

故障開始之后降影響

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

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

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

最佳實踐

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

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

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

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

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

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

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

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

本文作者

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