首頁 > 運維 > 安全 > 從CTO視角來看:如何建構維運/SRE能力

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

WBOY
發布: 2023-06-09 12:37:08
轉載
846 人瀏覽過

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


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


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


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

關於標題

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

關於維運/SRE團隊

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

從哪裡獲取維運/SRE能力

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

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

自建團隊

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

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

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

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

第三方供應商

透過第三方供應商取得維運能力,是另一個路子,供應商的交付物顯然也包括兩個部分:產品 服務。產品分為開源、閉源兩種類型,有哪些考慮點呢?

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

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

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

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

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

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

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

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

這張圖其實已經很能說明問題了,我再稍微囉嗦一下:

  • 可靠的基礎環境和元件:業務程式要運行,需要基礎網路、硬體、作業系統、資料庫、中介軟體等,需要這些環境和元件穩定可靠
  • 快速安全變更的能力:快速變更的能力,大家很容易理解,作為研發人員,寫了一個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視角來看:如何建構維運/SRE能力

#故障開始之前降發生

事前的預防和風控,有很多的工作。例如:制定告警完備性標準並對各個業務線做量化評估;制定定位原則和流程以及故障定級定責的標準;提前梳理各個業務的核心功能和服務模組的對應關係,建立全局穩定性視圖或者作戰室,方便快速揪出故障模組或介面;對架構做最佳化;梳理故障計畫並定期演練保鮮,也就是混沌工程那攤事;等等等等。

這裡有些事情是需要業務研發來搞定的,例如架構優化,剩下的事情,我的建議是:讓維運團隊來牽頭,研發配合。例如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中文網其他相關文章!

相關標籤:
來源:51cto.com
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板