2018 年接近尾聲，InfoQ 策劃了“解讀 2018”年終技術盤點系列文章，希望能夠給讀者清晰地梳理出重要技術領域在這一年來的發展和變化。本篇文章是運維領域 2018 年終盤點，分析了一些有代表性和影響力的技術，也展望了未來的發展。
過去一年的是各種新的運維技術和理念交相輝映的一年。技術和理念落地的過程中，也就是理想和現實碰撞的時候，往往具有戲劇性。有的技術破殼而出，迎來快速發展。有的則遇到了瓶頸，在艱難的爬坡。這裏僅選擇最具有代表性和影響力的技術來進行分析，作爲對過去一年的總結，也希望能夠看清楚未來運維領域的發展之路。
DevOps
運維方面最重要的技術理念就是DevOps。傳統的軟件組織將開發、質量保障和IT運營設置爲分離的部門。在分佈式和雲計算的潮流之下，這種開發模式明顯地不能滿足軟件快速迭代的需求和模式。DevOps則把他們有機的結合在一起，以更好的提高軟件交付的效率。
在DevOps潮流之下，單獨討論運維已經是沒有意義的事情了。自從DevOps理念提出之後，運維從邊緣重新回到人們的視野。DevOps所代表的打破開發、測試和運維之間的壁壘，利用技術實現自動化的理念深刻影響了運維，被證實也被廣泛接受，對提高軟件生產質量、安全、軟件發佈週期等都有非常非常明顯的推動作用，已經成爲一種不可抵擋的趨勢，對整個信息技術領域產生了深遠的影響。每一項IT技術和理念的變革，背後都會和運維技術和DevOps理念產生千絲萬縷的聯繫。
對於DevOps的理解有一個逐步深入的過程。初期人們對於DevOps常見的錯誤觀念是把DevOps認爲是一個組織、一個職位或者一套具體的解決方案，或者簡單把CI/CD當做DevOps。經過DevOps社區的不斷宣傳，大家都認識到DevOps代表一種理念和文化。在具體落地時需要根據自己公司的文化、規模等來採取不同的形式。谷歌的SRE手冊作爲一種有代表性的DevOps實踐，給出來一個非常具有指導意義的示範，是對DevOps的CAMS理念：文化（Culture）、自動化（Automation）、測量（Measurement）、共享（Sharing）最好的總結。
DevOps在開發團隊具體落地時，一般都是從CI/CD開始，通過採用一些開源軟件，解決基本的自動化問題。但是這種組裝的解決方案逐漸不能滿足更加高效的開發要求，所以轉向自己開發一些關鍵的流程和平臺。這是因爲每個公司的基礎設施和解決的問題都有其特殊性。開源雖然提供了一些關鍵的組件，但是還是需要根據自己的需求進行定製。從這個意義上講，對於致力於提供DevOps解決方案的公司既是挑戰，也是機會。其平臺一方面要具有通用性和可擴展性，又需要能夠對於不同行業的靈活的定製化的能力。
近年來，DevOps的意義也是不斷擴展。從字面上理解，DevOps主要是爲了消除開發和運維團隊之間的隔閡，讓軟件的交付和維護過程更加流暢。如今，DevOps已經擴展爲一個通用名詞，把敏捷開發、精益開發等方面的核心理念也包括進來，成爲軟件全生命週期的概念。這是因爲很多事情，例如安全、監控、部署、故障處理等問題，在軟件設計和開發的階段考慮得越全面，後面所付出的代價就越小。最新的DevSecOps成爲一種趨勢就非常明顯說明這個問題。
雖然DevOps已經被廣泛接受和認可，但是其在設計應用中的成熟度還有待進一步提高。在一份關於DevOps的調查報告中，把DevOps進化分爲三個級別，80%被調查的團隊處於中等評級，而處於高級階段和低級階段的都在10%左右。報告分析，這是因爲通過實現自動化以達到中等評級是相對比較容易，而達到高等評級則需要在文化和共享方面的努力，這相對來說更加難以掌握和實施。這也符合組織文化變革中的J型曲線。在經過了初期的效率增長之後，自動化的深化進入了瓶頸期。更進一步的效率提升需要對組織、架構進行更加深入的調整。這段期間可能還會有效率下降、故障攀升的問題。從這一方面講，實際DevOps的落地和深化還有很長的路要走。
Kubernetes & CNCF
說到DevOps，就必須提到Kubernetes和CNCF。容器技術和Kubernetes的結合，解決了自動化、標準化、配置化的問題，順應了DevOps的理念，生逢其時，所以成爲了時代的弄潮兒。由於Kubernetes背後谷歌強大技術力量的支持，容器編排技術中和Docker的競爭在2018年初毫無懸念的結束了，以Kubernetes的完勝告終。
Kubernetes解決了發佈&服務管理的問題。通過把容器、編排技術完美結合在一起，爲Cloud Native技術提供了一個良好的基礎，所以過去的一年也是CNCF快速發展的一年。CNCF的生態發展壯大，形成了一個具有壓倒優勢的開源生態。CNCF一方面成爲很多公司和廠家都急着要搭上的開源之車，一方面又打破了平臺建設的壁壘。CNCF平臺的提出，使建設跨平臺的應用成爲可能，成爲事實上的應用開發平臺的標準，極大簡化了多雲部署，也讓雲平臺的競爭到了另一個級別上。雲廠商要麼在IaaS層提高效率，要麼在SaaS層提高價值，而以前的PaaS層則成爲一個沒有商業機會的平地。Kubernetes在改變技術生態的同時也深刻影響了雲計算的商業生態。競爭需要向更深層次，和更高價值鏈維度進行。僅僅靠平臺壁壘和技術優勢來摘取商業紅利的設想成爲了泡影。
微服務和Serverless
開發人員對於效率的追求是沒有止境的。所以在DevOps的CI/CD之後，新的技術理念不斷涌現，要進一步降低運維的成本。微服務、Service Mesh、Serverless、FaaS、Lambda等新的理念和技術讓技術人員眼花繚亂。不過這些新的技術可以分爲兩類：以微服務爲代表的架構派，和以Serverless爲代表的NoOps派。
每一種新的技術和理念的提出，都是針對運維中的一些痛點而給出的解決方案。但是在落地的過程中，微服務、Service Mesh在解決一方面問題的時候，也帶來了新的挑戰。微服務減少了服務間的耦合性，讓部署更加便捷，但是同時對於架構設計和業務梳理要求更高，而對於可能的微服務爆炸的情況，如果沒有一個強大的管理系統，則運維的整體複雜性實際上是升高的。Service Mesh剛出來時，所提出的解決問題的思路確實讓人眼前一亮，通過Sidecar技術剝離所有的安全、服務發現、負載均衡等問題，讓服務開發人員只用關注業務邏輯，可以完美支持多語言。但是這個解決方案是以性能的損失爲代價的。如果要把現有業務遷移到Service Mesh的架構上，要完美保持Service Mesh的架構和理念就比較困難了。看到一些實際落地的解決方案，例如螞蟻金融的SOFAMesh，都是進行了一些折中來提高性能。
Serverless的目標是完全讓運維對開發透明，也是過去的一年中的熱門之一。在AWS的推動下，以Lambda爲代表的Serverless產品得到廣泛關注，進入雲計算的舞臺。在這個領域，技術的演化也是非常快的。對於Serverless計算來說，首先要解決安全隔離的問題。同時由於每個業務的壽命週期短，所以需要平臺技術啓動快、開銷小，能夠快速水平擴展。AWS開源的Firecracker和谷歌的gVisor技術都致力於讓Serverless計算場景下的容器安全沙箱更加精簡、安全。
FaaS是Serverless的另一個場景。一般是在某一個業務平臺上提供一個可擴展的編程環境，爲支持前端場景的多樣性提供更加快速的開發環境。很多國內的業務場景比較複雜的公司都有實踐，通過定製化的IDE環境讓開發人員專注於業務。無論哪一種Serverless場景，實際上後臺的運維工作都是不可以缺少的，只是通過自動化技術讓擴容容錯等技術對於開發人員透明。它們所面對的場景來說目前來說還是有限的，但是隨着技術的成熟，越來越多的場景可能會利用其FaaS來實現快速開發和迭代。FaaS就類似於Python等腳本語言，和Java/C++這些語言相比，以一部分的性能換來快速開發的優勢。
AIOps
AIOps利用智能化技術解決運維問題。一經提出就影響深遠。經過幾年的努力，智能化技術在一些基本的運維場景落地，例如故障預測、根因分析、智能報警燈場景上已經確實極大地提高了系統的自動化程度，但是同時也碰到了一些瓶頸。
理想和現實之間的差距是有原因的。清華大學的張鈸院士對於人工智能技術的分析可以對這個現象給出比較合理的解釋。根據張鈸院士的總結，目前的人工智能技術水平，要應用到具體場景，必須要滿足下面的五個限制：有豐富的數據或者豐富的知識、完全信息、確定性信息、靜態與結構性環境、單任務與有限領域。目前取得較大進展的圖像識別、語音識別、推薦、搜索、下棋幾個領域都滿足這幾個限制條件。深藍和AlphaGo都以下棋作爲突破口就是因爲下棋是完全符合這些條件的問題。滿足這 5 個條件的工作，總有一天會被計算機取代。這五個條件也可以我們幫助我們檢驗某個問題是否可以採用人工智能技術。
對於AIOps來說，數據豐富性和準確性是最大的限制條件。要想利用好智能算法，就必須要花很大的精力來清晰和整理數據。業界人士的估計是80%的時間花在數據上，20%的時間花在算法上。這是因爲很多系統最開始設計時，並沒有考慮智能化運維的需求和場景。關鍵信息不全，關鍵的依賴和關聯關係要通過機器學習的思路來抓取出來的話，往往是事倍功半。所以智能化的出路，還是要通過對系統的改造，在深入理解運維場景的基礎上，通過提高數據和信息的完整性、準確性來實現運維的自動化和智能化。從這個意義上講，我們需要在設計開發階段就考慮到系統智能運維的需求，方便數據積累和建立關於系統的知識。
總體來說，AIOps應該還是非常有意義的理念隨着系統的規模越來越大、複雜性越來越高，AIOps將是必然的趨勢，不過我們需要保持冷靜和客觀的態度來建設。
展望
可以預期的是，新的一年DevOps將會得到更加廣泛的接受，其含義和範圍會繼續擴大和深化。最近推出的DevSecOps就是一個例子，把安全作爲一個關鍵考慮因素放入軟件全生命週期管理之中。基於Kubernetes的生態會更加豐富多彩。CNCF的影響力會更加巨大。開放、標準化仍然是趨勢。所有人，都努力在大的生態中佔有一席之地。
Firecracker和gVisor技術非常具有象徵意義。開始是容器和容器編排技術促進了運維自動化，而現在無服務器計算又對容器技術的安全、效率提出了更高的要求，推動了容器技術方面更多的創新和變革。計算機核心技術能力直接影響到在運維效率上的競爭力。運維和計算機核心技術相互促進，相互融合，我想纔是將來技術發展的大的趨勢。DevOps正如一個硬幣的兩面，已經完全無法分割開來了。可以期待的是新的一年裏會有更多深層的技術架構上的創新，讓開發和運維更加高效智能。
每一個理論和模型、架構都有它的優勢和缺點，有其適用範圍，也有其侷限性。我們不能指望一種技術解決所有的問題。人工智能、大數據將越來越重要，但是人的創造性、主動性仍將是最寶貴的資源。《人月神話》中預言沒有可以解決一切問題的銀彈，而人工智能看來也不是我們預期的銀彈。但是通過積累對於整個系統更加完備的拓撲、依賴等更方面的信息，然後和AI技術相結合，我們還是有希望一步一步地接近我們期望達到的智能運維的目標的。
作者簡介
趙豔標（花名：燕標） 阿里巴巴資深技術專家。2015年加入阿里巴巴，現任阿里巴巴基礎設施事業部天基平臺架構師，主要從事大規模集羣和應用運維、運維數倉、智能化和安全生產方面的研發工作，着力於建設面向未來的智能化運維體系。之前曾在微軟公司的必應搜索、Office、SQL Server等部門工作多年。