2008 年到 2019 年這 10 年多的時間裏爆發了很多重要的技術和技術浪潮，運維技術也在這十年間發展到了深水區。隨着雲計算技術的普及以及容器技術的興起，運維效率大大提升，運維平臺得以將運維人員從繁重的人工操作中解救出來；而人工智能的發展也使得 AIOps 成爲可能，讓運維人員能夠先用戶發現故障，更好得保障業務運行。
此文系 QCon 十週年特別策劃《技術十年》系列文章，在技術發展 10 年這個特殊的時間節點上，我們邀請了蘑菇街技術總監趙成來談談他在過去十年間的感受。一起回顧一下運維行業十年來的發展變化和趨勢，以及這中間的演進邏輯，以期給更多的運維同行一個參考。本系列還有移動、大數據和雲計算領域的回顧文章。訪問 QCon 北京 2019官網日程，瞭解最新技術趨勢與實踐。
很高興能在QCon 10年之際接到邀請，寫一寫運維行業發展的這十年，非常感謝InfoQ社區的邀請和信任。
在我正式寫文章之前，我仔細回顧了一下我個人經歷的運維的過程，也去翻了很多其他公司公開能看到一些分享材料，也找很多業界的同事做了交流，讓他們也一起回憶一下過往的經歷，因爲十年很長，還是有很多東西值得回味和探討。
最終，我總結出5個結論，也是規律，分享給大家，期望帶給各位讀者和所在的企業一些思考和啓發：
- 第一，運維行業的發展，是有規律可循的，是一個逐步演進的過程。這也說明，其實我們有很多經驗可以向先行者們學習。
- 第二，運維行業的發展，不是孤立的，它與業界的整個技術趨勢發展是相輔相成的。這就要求，關注運維的同時，我們也要關注整個技術趨勢和背景。
- 第三，運維行業真正高速地發展，真正地被重視，其實就在最近5、6年。運維這個行業還很年輕，仍有非常大的發展空間。
- 第四，運維行業當前的痛點，本質上更多的是企業層面的痛點，而不是運維個體的痛點。所以，要嘗試自上而下的解決問題，而不是自下而上。
5 第五，未來，一定是雲計算的時代，未來已來，只是分佈不均。所以，雲計算時代下的運維轉型升級，將是一個非常明確的方向。
如果用一張圖表示這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領域。
相關文章
雲計算十年回顧（上）：風雨兼程
雲計算十年回顧（下）：勢不可擋
最新一屆的 QCon 即將於 5 月 6-10 日在北京國際會議召開。除了涵蓋架構、移動、運維、安全、大數據等經典方向以外，QCon 還策劃了智慧零售、用戶增長、Chaos Engineering 等新興方向的話題，超 150 位技術大咖將分享最值得參考的技術實踐案例。訪問 QCon 北京 2019 查看大會日程，收穫技術成長。