運維十年回顧:當前很多新技術的本質都是在解決運維問題

传奇霸业腾讯版微端 www.jogex.icu 為促進社區發展,運維派尋求戰略合作、贊助、投資,請聯系微信:helloywp

2008 年到 2019 年這 10 年多的時間里爆發了很多重要的技術和技術浪潮,運維技術也在這十年間發展到了深水區。隨著云計算技術的普及以及容器技術的興起,運維效率大大提升,運維平臺得以將運維人員從繁重的人工操作中解救出來;而人工智能的發展也使得 AIOps 成為可能,讓運維人員能夠先用戶發現故障,更好得保障業務運行。

此文系 QCon 十周年特別策劃《技術十年》系列文章,在技術發展 10 年這個特殊的時間節點上,我們邀請了蘑菇街技術總監趙成來談談他在過去十年間的感受。一起回顧一下運維行業十年來的發展變化和趨勢,以及這中間的演進邏輯,以期給更多的運維同行一個參考。

很高興能在 QCon 10 年之際接到邀請,寫一寫運維行業發展的這十年,非常感謝 InfoQ 社區的邀請和信任。

在我正式寫文章之前,我仔細回顧了一下我個人經歷的運維的過程,也去翻了很多其他公司公開能看到一些分享材料,也找很多業界的同事做了交流,讓他們也一起回憶一下過往的經歷,因為十年很長,還是有很多東西值得回味和探討。

最終,我總結出 5 個結論,也是規律,分享給大家,期望帶給各位讀者和所在的企業一些思考和啟發:

  • 第一,運維行業的發展,是有規律可循的,是一個逐步演進的過程。這也說明,其實我們有很多經驗可以向先行者們學習。
  • 第二,運維行業的發展,不是孤立的,它與業界的整個技術趨勢發展是相輔相成的。這就要求,關注運維的同時,我們也要關注整個技術趨勢和背景。
  • 第三,運維行業真正高速地發展,真正地被重視,其實就在最近 5、6 年。運維這個行業還很年輕,仍有非常大的發展空間。
  • 第四,運維行業當前的痛點,本質上更多的是企業層面的痛點,而不是運維個體的痛點。所以,要嘗試自上而下的解決問題,而不是自下而上。
  • 第五,未來,一定是云計算的時代,未來已來,只是分布不均。所以,云計算時代下的運維轉型升級,將是一個非常明確的方向。

如果用一張圖表示這 10 年運維發展的過程,下圖再合適不過:

接下來,我們分過去、現在和未來三部分來分享一下我對運維發展過程及未來趨勢的理解。

過去(2009-2013):人工運維

第一個階段,人工作坊階段,也就是我們遇到的所有運維問題,基本靠人工操作完成。這種情況下,系統規模不大,遇到的問題相對簡單,大多集中在硬件、網絡和系統層面,所以有一定操作系統或網絡維護經驗的人就可以搞定。

這種場景下的運維,也就是我們常說的 SA,系統管理員,而且一般身兼多職,人數也不太多。

第二個階段,腳本工具階段,一般絕大多數企業都會很快從第一階段過渡到第二階段,因為上一階段的大量重復繁瑣的操作,完全可以轉化為腳本來實現,而不是每次都去敲一堆類似的命令。

早期的 SA 主要以各種 shell 為主,所以很多 SA 如果會 shell 編寫一些批處理腳本,就會很有競爭力了。再往后,我們大家所熟知的 Perl、Ruby、Python 等動態語言也被廣泛應用于腳本工具的實現,特別是一些邏輯和場景相對復雜的自動化實現。

第三個階段,流程和工具階段,當我們把一些復雜的操作封裝成一個個的腳本后,效率確實會提升很多,但是我們所面對的業務場景和體量也在變得更復雜。比如,對于運維同學,以前就是負責安裝和配置一下操作系統,如果是幾十臺或百臺的規模,腳本批量執行完全可以搞定。

但是,再往后,運維還要負責軟件的頻繁發布,每周要多次,甚至是每天都會有,這是由業務特點決定的,特別是互聯網類型的業務,與原來傳統的每個月、甚至幾個月發布一次的場景要求完全不一樣了。而且隨著用戶體量的增加,服務器數量可能已經到了幾百上千臺,而且部署的業務也不盡相同,所以單純靠腳本執行,已經完全不能滿足要求。

這時候,就要面臨更加復雜化的場景實現,比如做一次業務部署,運維同學可能要安裝服務器,做系統配置變更,安裝軟件包、啟停進程,然后再負載均衡上配置服務等等。這時,就需要有一個流程將一個個的腳本功能串聯起來,同時還要有一些腳本執行結果校驗及判斷的過程。

所以,這就對流程和工具平臺有了更大的訴求。同時,在一些 IT 化比較早的行業,如電信運營商和金融行業,由于對變更過程的嚴格控制,這就需要更加科學和規范的管理措施,所以會引入 ITIL 這樣 IT 服務管理體系,對整個 IT 系統及其變更進行管控。

其實,第一到第三階段,在 2009 年到 2013 年期間仍是絕大部分公司主流的運維模式。如果能夠做到工具化,或者有一些工具化平臺,那應該算是比較先進的運維模式了。

現在 (2014-2019):自動化運維

但是,對于一些大廠,步伐會更快一些。2013-2014 年,就已經有國內大廠進入到了第四個階段,運維已經體系化,完全的自動化。

直到目前為止,從筆者交流和了解到的實際情況看,絕大多數企業基本都在第四階段的建設過程中,所以我們把 2014-2019 這個階段定義為現在。

到了這個階段,就凸顯出幾個明顯的特點,也是我們上面提到的其中幾個規律,我們分別說一下。

第一,國內的運維行業的爆發,運維崗位真正地被重視,其實就是近 4、5 年左右的事情,也就是 2014 開始到現在。

為什么這么講?其實我只要關注下,運維行業有自己垂直的技術大會,類似 QCon 以及 ArchSummit 這樣的頂級技術峰會,開始專門設置運維專題,基本就是在 14 年左右開始的。這個現象說明,運維的技術復雜度已經上升到了一定程度,各大企業也開始意識到運維對于企業的效率、穩定和成本有著決定性作用,對運維的訴求和要求也越來越高。

從這個角度講,新興的運維行業其實才算是剛剛起步,未來仍然會有很大的潛力和空間。

第二,運維的發展不是孤立的,它與整個技術趨勢發展是相輔相成的。

大廠之所以在這方面會走在前列,一方面是因為業務復雜度和體量所決定,另一方面,是因為這樣的場景倒逼著整個業務和技術架構發生了很大的變化。比如我們現在早已耳熟能詳的服務化和各類分布式技術,就是在這種場景下倒逼著技術體系演進出來的。

也正是在這樣新的技術體系下,運維所面臨的場景復雜度也急劇上升,原有的運維技能如操作系統維護、系統配置、腳本編寫已經完全滿足不了要求。同時,由于軟件系統復雜度的提升,也需要運維投入更多的精力去關注業務軟件架構和應用服務上。

所以,這種場景下,我們所熟知的 DevOps,SRE、PE、應用運維、技術運營這些新的名字、崗位或理念,開始如雨后春筍般浮現出來。

其實這里很多概念早在 10 多年前就已經出現了。比如 SRE 最早是在 2003 由 Google 提出;DevOps 理念的影子在 2007 年左右就開始浮現出來,2009 年的 DevOpsDays 大會上正式提出了這種叫法;而像 PE 這樣的角色,最早是在 Yahoo! 設置的。

這些優秀的運維或者穩定性的理念,在國內興起前,其實已經在國外被廣泛實踐了很多年。究其原因,還是因為國外的技術發展是超前于國內的,比如 Google 在分布式領域的“三駕馬車”,直接開創了一個新的技術時代,讓業界有機會充分實踐分布式的技術。

這里,我想表達的一個觀點是,這些理念在國內真正的落地,還是因為有實際的場景驅動。業務體量和復雜度到了那個程度,技術體系必然會找朝著分布式的方向發展。而配套的,必然會有 SRE、DevOps 以及 PE 這樣相輔相成的體系出現。

國內大廠有機會提前走到這一步,從絕大部分公司發展的過程看,也必然會遵循這樣的規律,只是早跟晚,快跟慢的問題。這里的決定性因素其實是業務復雜度和體量所決定的。

目前很多企業和公司之所以能走到運維的第四階段,其實很大程度上也是因為廣泛采用分布式技術,引入了服務化和各類分布式組件,在這種情況下,業務架構越來越清晰,對應的對運維的訴求和要求也就逐步提升了上來。

典型的技術和發展特點:

從技術角度,我們關注下這 4、5 年來技術的發展,說兩個最典型的:

一個是容器技術,以及以容器為核心的編排系統,現在基本是以 K8S 為標準了。

首先,Docker 的創始人 Solomon 其實是運維出身,并不是做開發的。當時他的想法也很簡單,就是希望能夠屏蔽一些跟應用無關的底層細節,Run any application,anywhere,提升部署和發布的效率。

后來一經推出,大受關注,特別是在 14 年左右,可謂是大紅大紫,且圍繞著容器的一整套生態也在逐步成長起來。到目前為止基于容器和 K8S 的基礎平臺,已經成為 PaaS 體系建設的標準,如果哪項技術不適配 K8S,那基本是沒有發展空間的,也基本不會被認可。

從運維的角度看,容器解決的最大的問題就是運維的問題,特別是運維的效率問題。從目前業界的實踐來看,容器確實發揮了極大的作用。

現在更為極致的一種理念是無服務器技術,也就是我們熟知的 Serverless,也叫函數服務器。這種理念極致的地方在于,以后純粹就是 NoOps 的時代,開發寫完代碼直接部署發布到云上,完全不用考慮服務器和資源的問題。這種場景無疑是將整個迭代周期壓縮到了極致,理想狀態下,讓整個技術團隊無需考慮運維的事情。

但是,實際場景下,新技術發展仍需要一定周期和周邊配套體系完善。同時,新技術能夠發展完善,也需要找到適合自己發揮的業務場景,有時新技術出現并不是要為了完全替代早期的技術。

簡單總結一下,我們會發現,當前非常多的新技術和新趨勢的產生,從本質上都是在解決運維問題,未來也一定是這樣一個趨勢。

從最佳時間角度,到了這個階段,從我個人認為,現在業界運維問題,更多的是企業層面的運維問題,而不是個體運維的問題。這一點跟開發者社區特別強調個人能力極為不同,很多運維的問題解決不了,有時候很大程度上是受限于企業體制、組織架構、文化等方面的非技術層面的因素,而不單純是個人能力所能解決的。

所以,要解決企業的運維問題,有時是需要自上而下的推進,整個技術團隊共同執行落地才可以。從運維的角度單方面發起,是不會有效果的。

未來(2019-Future):智能運維和云計算

關于智能運維

智能運維或 AIOps,我之所以把它定位在未來階段,主要是我認為目前能在這個領域有成果的,還是集中在大廠。對于絕大多數企業來說,特別是中小企業,時機仍然未到。

從 AI 的角度,AIOps 有三個方面的充要條件:機器學習算法、計算能力如 GPU、海量數據。

從上面三個條件看,也就不難理解,為什么 AIOps 做的比較超前的都是國內外的大廠,因為有技術實力、有足夠的資源和數據,最關鍵的是有足夠復雜和變態的業務場景以及運維場景,在倒逼著 Ops 往這個方向上走。

但是,對于一家企業來說,實施 AIOps 最重要的前提條件是數據,海量數據。目前來說,能夠具備這個條件的只有大廠,因為只有大廠有這個業務和資源體量,能夠產生海量數據。

同時,對于 AIOps 來說, 還有很重要的一個前提條件,那就是高度完善的運維自動化,也就是 Ops 的部分。自動化都沒做好前,AIOps 是沒有任何意義的,千萬不要本末倒置。

我的理解,AI 和 Ops 要解決的還是兩個層面的問題??梢岳啾鵲餃?,AI 相當于人的大腦,我們手腳和軀干是執行系統,大腦負責決策判斷,手腳軀干負責完成大腦下發的動作指令。對應到運維上面,AI 要解決的是怎么快速發現問題和判斷根因,而問題一旦找到,就需要靠我們高度完善的自動化體系去執行對應的運維操作,比如容量不夠就擴容、流量過大就應該觸發限流和降級等等。

最后,AIOps 的發展一定是一個長期演進的過程。AI 是 Ops 的有力補充,進一步降低運維的工作強度和壓力,但是 AIOps 一定建設在高度自動化和完善的運維體系之上的,是一個演進的過程,不會是一個跳躍性的過程,也不會產生一個完全顛覆性的 AIOps 模式,將現有的 Ops 體系替代掉。

云計算:未來已來,勢不可擋

其實仔細關注下技術趨勢的發展,我們會發現,現在很火的一些概念,比如 Serverless、FaaS、邊緣計算、彈性計算、云原生、IoT 等,甚至是我們耳熟能詳的 Docker 容器、K8S、機器學習、AI 等等,基本都跟云計算相關。很多都是在云計算這個趨勢下衍生出來的新技術,而且又因為云計算提供的基礎設施,相互之間又有緊密的聯系。

說地嚴格一點,這些技術只有在云上,甚至是公有云上才會發揮作用和價值。脫離了云計算,這些技術沒有任何意義。因為,云計算帶來的最大的好處就是“按需索取”,也就是我們說的彈性,進而帶來成本上的最優化。如果我們自己機房里還維護著上千臺設備,都是我們自己的成本,說實話,再彈性也沒多大意義,因為不解決實際的成本問題。

再就是,到了機器學習領域,特點是周期性地需要大量 CPU 和 GPU 資源,并不是持續需要,所以如果還是延續老的思路自己采購,這個成本就大了去了,對于一般企業根本不現實??鑾矣惺焙蚧掛悸親試叢誆煌蚍植嫉奈侍?,比如邊緣計算,一個普通企業搞一個機房還可以,但是要管理和維護很多機房,就不太現實了。

所以不難理解,未來的技術趨勢,一定是跟云計算相關的。這個是大勢,不可逆。

因此從個人成長的角度,我覺得,如果想要更好的發展、更大的空間,就朝著云計算這個行業走,做跟這個行業相關的崗位。一些崗位參考,比如,公有云平臺的運維,至少在規模和體量上足夠大,挑戰也足夠大,還能接觸到很多新技術。其他由云計算衍生出來的解決方案架構師、技術運營、CRE 這樣的崗位也都是不錯的選擇。

對于企業來說,盡快擁抱云計算,將更多的精力放到自己的核心業務能力上,通過云的能力,為自身的業務帶來更多可能性,或許是一個更好的選擇。

寫在最后

這些年經歷下來,特別是近幾年,最大的感受就是變化之快,讓人目不暇接。新事物、新技術、新產品、新平臺層出不窮,有時不知從何下手。

面對這樣充滿了不確定性的場景,運維人員,包括其他技術人員,唯一能做的就是堅持學習,擁抱變化,腳踏實地的解決問題。對于個人要不斷提升能力,對于企業要審時度勢,選擇好未來的技術方向,我想未來一定會更有挑戰,更有樂趣,也必將更加精彩。


作者簡介:

趙成,資深 DevOps 和運維專家,現任蘑菇街平臺技術總監,騰訊云 TVP,極客時間運維專欄作家,多屆 ArchSummit 運維專題明星講師和優秀出品人,SRECon19 Asia/Pacific Speaker,個人專注于云計算、SRE 和 AIOps 領域。

網友評論comments

發表評論

電子郵件地址不會被公開。 必填項已用*標注

暫無評論

Copyright ? 2012-2019 www.jogex.icu - 運維派 - 粵ICP備14090526號-3
掃二維碼
掃二維碼
返回頂部