從CTO視角來看：如何建構維運/SRE能力

近期有很多文章在探討運維崗位去留的問題，我主持的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 主理人，快貓星雲創業合夥人，創業方向是穩定性保障方向，如有需求歡迎聯絡我做交流。

以上是從CTO視角來看：如何建構維運/SRE能力的詳細內容。更多資訊請關注PHP中文網其他相關文章！