云原生、DevOps、ChatGPT,真能“殺死”運維?
原創本文訪談部分源自快貓星云創始人來煒此前訪談分享。6月16日-17日·北京,由來煒出品的《可觀測性技術與實踐》專題將在WOT全球技術創新大會期間呈現。來自美團、快貓星云、格睿時代...的眾多技術大咖們將帶來:美團可觀測性平臺:Raptor建設與實踐、幫一千個微服務落地SLO、面向故障處理的可觀測性體系建設、云原生時序數據庫的挑戰和架構設計等精彩分享。
點擊閱讀原文可了解活動詳情,或掃描下方二維碼了解WOT更多精彩主題。WOT大會九折期即將結束,現在購票優惠多多。
一、運維行業沒有消亡
Q:有些運維老炮反映公司對運維的價值所知甚少,您是怎么給公司講清楚運維價值的?
來煒:把工作的價值,如何通俗易懂的給公司管理層講清楚,并取得理解和支持,是所有中后臺技術團隊普遍面臨的難題,否則失業分分鐘的事情,運維工作的價值講清楚更是難上加難。
從我的朋友圈來看,時不時就會看到勸運維下崗/轉行的帖子:比如瑞典馬工的《是時候讓運維集體下崗了》,振聾發聵,開篇就提到:明人不說暗話:在云原生和DevOps成熟的今天,運維作為一個崗位和團隊已經完成了歷史任務,應該退出舞臺了。
再比如帶我入行的井老板,用心良苦的勸導:隨著科技的發展,時代的變化,一個崗位的消亡是很正常的事情,及時做好調整和規劃才是思考的重心。
但是,運維這個崗位以及背后的運維人,從來都是一次次站在要被淘汰的邊緣徘徊,又一次次倔強的起死回生,柳暗花明。他們往往樂于自嘲、主動擁抱危機、敢于求變。回想下,近十年來,云計算也好、云原生也罷、DevOps 也算、SRE 也行,所有這些 IT 的大變革,都是嘗試在不斷優化和改進“大運維”這個領域。運維這個行業沒有消亡,反而是不斷進化,生發出了新的內涵。
這說明了什么?說明運維很重要,說明運維也很難!但是如何把這個價值說清楚,我們要從站位、目標設定、投入產出比上來分別著手分析。
二、運維人:要堅定地和業務站在一起
Q:您覺得運維工作最重要的幾個目標是什么?您是怎么落地這些目標的?運維的價值如何更好的得到體現?
來煒:聚焦經典的運維領域,最主要的幾個工作職責是:
(1)代碼發布和交付(delivery),做好最后一公里的價值交付;
(2)提升架構的可伸縮性(scalability)并付諸實施;
(3)保障系統的穩定性(reliability)并不斷改善;
(4)在滿足前三項目標的同時,不斷優化并降低系統的運行成本(finops)。
如果你發現自己的工作,并不是圍繞著以上范疇展開,那么有兩種可能,你不是運維或者你的工作超綱了!
明確了工作范疇,說大點就是明確了運維的使命之后,設定目標就相對容易些了,比如:
(1)針對代碼發布和交付,可以簡單的用發布次數來度量;
(2)針對系統的伸縮性,可以用擴容的時效性來度量;
(3)針對穩定性,我們可以通過觀察核心功能的不可用時長來度量;
(4)針對系統運行成本,我們可以計算到每完成一筆核心交易所花費的資源成本和人力成本來表示和追蹤。
關于如何體現運維的價值,首先我們運維人要轉變的是態度和立場:堅定地和業務站在一起,爭取共背業務目標。我舉個例子,HR部門,也是屬于公司內部后臺的不能再后臺的部門了,但是我所接觸過的優秀的HR中,不管是recruiter、還是hrbp,從來都是把自己當作業務部門的一份子,把業務部門的目標當作自己的目標。當立場一致,大家都是自己人的時候,價值就好說了。
其次,價值這個事情,永遠都是和“成本投入”相對應的。你如果組建了一個很大的運維團隊,人力成本在公司很顯眼,那么你就很容易成為老板眼中的“重點關注對象”,也會受到業務方更苛刻的挑戰。正所謂,楚人無罪懷璧其罪。客觀上來講,運維團隊的資源投入,一定是要和業務收入相匹配的,過高過低都是不健康的,不利于團隊發展的。所以,“運維的價值創造”最后會落到運維效率的競爭上來。
最后,關于價值,定量和定性的描述都得有。譬如和行業水平的定量對比,來自公司內業務部門滿意度調查的定量數據。也要有比如對公司戰略項目支撐中的“存在感”這些定性數據。
三、ChatGPT或將代替初級運維崗位
Q:ChatGPT這樣的AI能力您覺得未來是否有可能解決運維行業的問題?
來煒:首先我們看看,ChatGPT的核心優勢是什么?ChatGPT,在知識的豐富度、自然語言理解能力(以及上下文理解)、內容生成能力方面,有著代際的革新。然后,我們再分析下運維行業的核心問題是什么,是缺少領域知識嗎?是交互效率低嗎?是內容輸出難嗎?
以上都不是,運維行業所處理的問題,本質上還是一個系統性的工程問題,是為了解決IT系統價值快速交付的問題、解決伸縮性的問題、解決穩定性的問題,是不斷提高系統運行維護性價比的問題。
目前來看,云計算、微服務對于運維行業的改變來的要更實質性一些。ChatGPT能有效改善運維行業知識沉淀的問題,或許會很快代替一些初級的運維架構師崗位。
四、《可觀測性技術與實踐》專題精彩內容
1.美團可觀測性平臺:Raptor建設與實踐
美團技術專家任天:Raptor作為美團可觀測性平臺,不僅融合了前端監控、基礎設施監控、應用層監控,同時也給業務提供指標、鏈路、部分日志監控能力,讓業務能夠無死角的觀測到系統;在耗時檢測方面,涵蓋了業務端到端耗時、后端整體耗時、中間件耗時等,滿足業務各階段的可觀測訴求。作為可觀測系統,Raptor每日承載著PB級監控流量,百萬的告警策略,覆蓋前后端的觀測能力,給業務提供及時有效的觀測和預警,為業務保駕護航。
本次分享,主要從Raptor整體視角出發,介紹美團可觀測體系的建設之路以及應用實踐、從監控系統Cat到可觀測系統Raptor的演進過程。以及如何支撐美團PB級監控數據,滿足業務低延遲、高可用、低成本的訴求。最后針對當前面臨新的訴求和挑戰,討論Raptor下一步的工作重點和方向。
2.面向故障處理的可觀測性體系建設
快貓星云COO秦曉輝:服務穩定性保障是一個系統性的工程,建設一個完善的可觀測性體系,是穩定性保障的基礎,而穩定性保障也是可觀測性體系服務的最重要的場景。然而目前企業內部普遍面臨著一個痛點,雖然各種觀測數據都有了,但在故障發現、故障定位上仍然存在發現慢,定位難,協同難等問題,在穩定性保障上技術團隊經常處于被動。很多企業可能已經不缺少數據,但缺少的是將數據價值在穩定性保障領域發揮出來的產品、方法和最佳實踐。
快貓星云團隊總結了解決企業可觀測系統落地問題的三大要素:數據、平臺、場景。假如把建設一套面向穩定性保障的可觀測系統比喻為做一道好菜,那數據就是食材,平臺就是炊具,場景就是廚藝。
3.云原生時序數據庫的挑戰和架構設計
格睿時代技術副總裁馮家純:隨著企業上云和云原生基礎服務的發展,作為需要存儲和處理海量傳感器數據的時序數據庫也需要往云原生架構遷移。在這一過程中面臨諸多挑戰:面向彈性設計的 ServerlessDB 架構;海量規模的時序數據在高并發讀寫下的可用性和穩定性挑戰;時序數據特有的高基數問題和數據壓縮問題;存算分離架構帶來的性能挑戰;混合時序和分析負載帶來的算力隔離和調度問題。
我們在實現 GreptimeDB 這個分布式、云原生的時序數據庫過程中,直面這些挑戰,并將在本次分享中給出我們的設計選擇和背后的思考。
以上精彩內容都將在6月16日-17日·北京的WOT全球技術創新大會期間呈現。