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

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

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

關于標題

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

關于運維/SRE團隊

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

從哪里獲取運維/SRE能力

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

自建團隊

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

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

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

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

第三方供應商

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

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

其次是服務，供應商相比自建的團隊，通常會有優勢。原因如下：

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

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

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

業務需要哪些技術支撐能力

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

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

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

各個能力如何獲取

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

可靠的基礎環境和組件

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

關于擇業：對于系統運維工程師、網絡運維工程師，看起來并不是個好消息，云的出現確實搶占了一部分這類崗位的空間，沒辦法，時代的車輪滾滾向前，大家都是歷史的塵埃。

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

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

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

快速安全變更的能力

業務研發最常做的變更是二進制、配置的變更，當然，還有對基礎環境以及組件的變更需求。

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

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

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

生產環境的變更，和測試環境、聯調環境的變更還不太一樣，生產環境對穩定性要求比較苛刻，測試環境、聯調環境則相對沒有太高的要求。所謂的CI/CD的系統，大都是針對測試環境、聯調環境的，能夠對生產環境做到CD的公司，屈指可數。

劃重點：測試、聯調環境的CI/CD系統，更多的是為研發效率提速；生產環境的變更系統，更多的是確保穩定性、落地規范制度的。公司前期體量小，靠規章制度就夠了，后面就需要規章制度+變更平臺協同發力了。

這個規范制度誰來定？變更平臺誰來開發？

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

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

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

另外就是基礎組件和環境的變更，典型的比如MySQL表結構、Nginx配置、DNS、VIP等等，這類變更可以內化到組件管控平臺里，讓組件能力提供方提供變更入口和管控能力。

可靠性保障能力

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

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

故障開始之前降發生

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

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

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

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

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

故障開始之后降影響

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

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

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

最佳實踐

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

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

上面的四個支撐能力，業務側應該如何獲取，CTO應該如何統籌，各團隊應該如何配合，大致就說這么多。下面我們再做兩個小結。

小結1：CTO如何幫助業務線獲取這些支撐能力？

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

另外補充一點FinOps的話題，FinOps也是一個橫向能力，是否也要交由SRE來做呢？這個倒是未必。就讓業務自閉環我覺得也挺好的，業務自己要負責盈虧，IT支出是支出大頭，業務的GM理應是很上心的，CEO把營收凈利相關的KPI壓給業務GM，業務GM可以自閉環做好折中的。

小結2：運維/SRE擇業建議

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

本文作者

秦曉輝，Open-Falcon、Nightingale 創業研發，極客時間《??運維監控系統實戰筆記???》作者，公眾號 SRETalk 主理人，快貓星云創業合伙人，創業方向是穩定性保障方向，如有需求歡迎??聯系我做交流??。