運維是從IT誕生之初就一直存在的重要角色，在IT類企業中，尤其是互聯網企業，運維、開發和測試被稱爲是驅動技術進步的三駕馬車。而金融、政府、醫藥、教育、製造、運輸等其它行業，爲了進行數字化轉型，也紛紛建立了自己的或大或小的數據中心，併爲了維持這些IT系統的正常運轉，設立了大量的運維崗位。可以說，信息技術已經並且正在改變我們身邊的一切行業，而只要有IT系統的地方，就有運維同學的身影和貢獻。
但最近幾年，雲時代的到來，讓很多運維同學倍感焦慮，“雲計算是未來”得到了大多數人的認同。2019年Q1，公有云IaaS市場同比增長74%。越來越多的企業，開始把自己線下的數據中心和機房搬遷上公有云。而一旦企業放棄了自建的IT基礎設施，甚至把員工的辦公電腦都搬到了雲上（桌面雲），由公有云廠商提供服務，那麼企業是否還需要這麼多運維人員呢？
與此同時，DevOps思潮席捲全球，大家紛紛嘗試“組織機構變革”，打破開發-測試-運維之間的邊界，由開發人員來直接負責自動化的測試和運維工作。更進一步，從DevOps進化出了AI Ops甚至No Ops，人工智能開始在運維領域顯露身手。而云計算與DevOps正好是天生一對。雲是DevOps最好的平臺，而DevOps是雲上的最佳實踐。
在雲計算和DevOps的雙重壓力下，運維的未來會何去何從？
雲時代的運維是怎麼樣的？
衝浪是一個非常刺激的極限運動。相比海浪的力量，衝浪者的個體力量是渺小的，每一次衝浪都是一次冒險。但智慧並且勇敢的衝浪者會仔細觀察海浪的方向並調整衝浪板與海浪方向一致，當海浪抵達時，衝浪者會站起來，在海浪的衝擊下急速前進，享受浪尖上的快感。
衝浪者很清楚，自己成功的關鍵在於找準海浪的方向。我們技術人員也一樣，只有保持對新技術的敏感性，並及時調整自己，才能藉助浪潮的力量快速進步。
給大家講一個真實的故事。2009年，阿里雲剛剛成立的第二年，時任淘寶技術總架構師行癲（現任阿里雲總裁）宣佈淘寶網將拋棄Oracle，轉投雲上的自研數據庫。獲知此消息後，八十多個Oracle DBA把當時的DBA負責人後羿堵在會議室裏，“如果上邊鐵了心要幹，兄弟們的前途在哪裏？”還好，技術人是講理的，一場惡鬥轉化成了幾十個工程師坐在會議室促膝談心。既然上雲是戰略，爲何不順勢而爲？就這樣，一羣 Oracle DBA，開始親手拆毀自己安身立命的系統。2013年7月，淘寶最後一個Oracle數據庫下線。時至今日，整個阿里集團，所有的核心業務100%跑在公共雲上。
是啊，既然上雲勢不可擋，我們何不順勢而爲，看看雲上運維是什麼樣子的？
首先，雲上運維和傳統的運維，操作的目標是不一樣的。傳統的運維人員，需要能夠熟練的手動操作來自衆多廠家的計算、網絡、存儲等硬件設備，而云上的運維人員完全接觸不到物理設備，取而代之的是雲上的虛擬資源，例如雲服務器，雲盤，虛擬交換機等。雲廠商將對資源的操作全部抽象成了軟件定義的API接口，並用統一風格的SDK、命令行進行封裝，提供給運維人員使用。雲廠商提供的圖形化的運維控制檯，也不過是API的封裝而已。
其次，雲上運維是高度簡化的。傳統的運維，需要學習來自衆多“大廠”的認證，例如，網絡運維要學思科的認證，數據庫運維要學Oracle的認證，系統運維要學IBM的認證，等等。而在雲上，虛擬專有網絡產品將網絡設備的管理和運維變得統一和簡單，雲上數據庫產品實現了智能化的數據庫管理，雲服務器實現了動態的擴縮容和熱遷移，這些都大幅降低了運維操作的門檻。雲上的運維人員不再需要感知底層基礎設施的細節，更不需要考取高難度的認證。即使是創業階段的小企業也可以擁有和大企業同等的運維能力。
但是運維簡化，並不意味着運維的重要性降低，相反，在雲上，運維變得比以前更加重要了。
雲時代運維面臨的挑戰
爲什麼在雲時代，運維變得更重要了呢？主要有兩個原因，一是雲上運維的範疇比以往擴大了，二是雲上企業對於穩定性的要求更高了。
從範疇上看，雲上運維包含了從藍圖規劃，到上雲交付，再到雲上管理的全過程。如果我們具體到流程和階段，包括了設計選型、資源交付、系統交付、運維調優、擴縮容、資源運營、備份容災，安全&審計等等。
從穩定性方面看，通常雲廠商只負責基礎設施的穩定，上層應用仍由企業開發人員自主開發，同時雲上應用本身的穩定性也由企業自己的運維人員負責。如果具體來說的話，企業運維人員需要負責持續發佈過程中的藍綠髮布、灰度發佈、分批發布、自動回滾等的實現，以及應用層的監控、事件告警體系的建設。另外，雲上基礎設施的穩定性不能單純依靠雲廠商，也需要企業運維人員的相互配合。例如阿里雲的雲服務器單臺實例的可用性達到99.975%，但仍然存在着萬分之2.5的不可用時間。企業的雲運維人員可以採用監控、負載均衡、多機熱備、兩地三中心等常用的高可用設計，在不是百分百可靠的基礎設施上，搭建百分百可靠的應用。
具體來說，雲上運維主要面臨着以下挑戰：
首先，運維排查問題的難度增加了。由於雲上“黑盒子”的存在，當故障突然發生時，運維人員往往只能看到服務出現異常了，很難快速判定問題出在哪裏？是雲服務商的基礎設施出問題了，還是我自己的代碼出bug了？…甚至就算排查出是雲服務商某個服務的問題，部分運維人員也只能打電話給客服尋求幫助，而從客服得到的回覆往往難以令人滿意，從而耽誤了故障恢復時間。
第二，雲服務發出的消息、日誌、事件等難以有效處理。如果運維人員每天收到幾千條短信或者郵件，一定是無法及時處理的，只能無腦忽略。但是又不能設置郵件規則將它們全部扔到垃圾箱裏，因爲會擔心漏掉重要的通知，比如服務器宕機的通知。
第三，資源的膨脹帶來了管理的複雜性。所有的資源都是軟件概念，對於一個大企業來說，這些資源可能分佈在全球的十幾個region，分散在幾十個雲產品的控制檯，服務於幾百種不同的負載或者在線服務。更可怕的是，這些資源一直在變化。如何有效的跟蹤、審計、創建、釋放並保證無浪費？
第四，雲產品的頻繁升級帶來了運維的頻繁被動變化。雲產品的選擇非常多，實例類型紛繁複雜，包括預付費、後付費、預留實例券，什麼性能突發型、計算型、通用型、GPU實例、專有宿主機、裸金屬實例，容器服務、Kubernetes或者Swarm、彈性容器實例，等等。更要命的是，這些雲產品還在不停地發佈升級，如何選擇適合自己的產品？新功能如何才能幫助到業務？…盲目追隨雲廠商的腳步不是良策。
如何調整才能適應雲時代的運維？SRE可能是答案
如前面所說，企業上雲之後，仍然有大量的運維需求。但此時的運維，卻又與傳統的運維截然不同。企業應該如何進行結構調整以適應上雲後的新形勢呢？
DevOps是現在提到的很火的概念，DevOps實踐的整個生命週期是從計劃-》編碼-》構建-》測試-》發佈-》部署-》操作-》監控，再回到計劃，是一個循環。其中發佈、部署、操作和監控（下圖的黃色部分）是屬於運維領域的。
DevOps 實踐打破了開發和運維之間的壁壘，開發人員可以直接負責運維。雲上的運維已經和軟件開發融爲一體，強調高度的自動化，沉澱了一系列的運維工具和運維平臺，並朝着AIOps和NoOps的方向持續演進。
而反過來，運維人員如果能掌握開發技能，結合自動化工具的使用，是否能夠做的更好呢？答案是肯定的。運維人員可以轉型升級爲兼具開發技能和運維技能的站點穩定性工程師（SRE）。Google最早推出了SRE這一概念，並使得SRE部門成爲其承擔運維職責的一個研發部門。越來越多的上雲後的企業，開始把自己的運維部門改造升級爲SRE部門。
SRE聽上去很美，但真正要做到並不容易。以阿里云爲例，早年阿里雲也走過人肉運維的痛苦階段，儘管運維工程師7*24輪班on call待命，但客戶仍然投訴不斷，系統問題不斷。後來，阿里雲團隊開始建設穩定性，通過監控報警將故障的平均發現時間從1小時縮短到10秒鐘，同時藉助AI預測算法，在某些情況下可以在故障發生前，提前預警並採取行動。現在阿里雲每年發佈上千次變更，難免會出現變更導致的故障和異常，但是SRE團隊藍綠髮布、灰度發佈、分批發布、自動回滾、熱遷移等技術，實現了發佈全過程無人值守。
如何才能升級成爲SRE呢？這三點建議可能對你會有所幫助：
- 一是學習DevOps的實踐，熟練掌握至少一種編程技能（比如Python、Go、Java等），從思想和技術上，保持工程師的先進性；
- 二是學習雲廠商提供的各種自動化運維工具，並靈活運用，嘗試幫助自己企業搭建高效率的自動化運維平臺；
- 三是積極參與開源和雲廠商的生態建設，伴隨運維生態一起成長，如果能產生出運維平臺級的解決方案產品，廣泛應用於整個行業，那麼個人價值和商業價值都會得到體現。
自動化一切是雲時代運維的首要任務
要想實現雲上運維的順利升級，首要任務就是”自動化一切“，如果列出Top3，應該是：監控自動化、運維操作代碼化、基礎設施代碼化。
監控自動化
先來看監控，包括了“監”和“控”兩個方面。
監控的“監”
“監”，從橫向劃分，包含了事件（Event），日誌（Log），指標（Metric），告警（Alarm）四個維度；從縱向劃分，分爲底層基礎設施的“監”和上層應用的“監”。
橫向看：事件、日誌、指標和告警
什麼是事件？對於雲服務商來言，事件其實是資源的變化，每一次資源的變化，都是一個事件。例如雲服務器的每一次狀態變化都是一個事件，包括開機中（starting），運行中（running），關機中（stopping），已停止（stopped）。
什麼是日誌？日誌是客戶行爲和雲服務內部行爲的過程記錄，包含時間、操作者、內容、級別等要素。每一條事件，都可以轉化成相應的日誌，記錄到日誌服務裏。因此，日誌的範圍，比事件更大。日誌服務所提供的，不僅僅是日誌的記錄，更重要的是日誌的聚合和檢索能力。例如，運維人員可以隨時查看某一個資源在過去某一個時間段的歷史記錄。
什麼是指標？指標是資源運行時的內部屬性數據，最典型的指標就是linux裏面top命令所顯示的數據，包括CPU、內存、IO數據等。這些數據不屬於事件，也沒有記錄下來作爲日誌的必要，但仍然是很重要的實時數據，是運維人員需要關心的系統健康指標數據，如果一切健康，就可以忽略。
什麼是告警？告警可以認爲是嚴重級別的事件，是需要立即採取人工或者自動化動作的事件。運維人員可以根據指標設定閾值來觸發一個告警，也可以在事件和日誌的基礎上設定報警規則，觸發告警。
縱向看：底層基礎設施和上層應用
底層基礎設施的“監”，需要由雲服務商來提供基礎數據，雲廠商的監控往往會提供針對基礎設施的事件、日誌、指標、告警，運維人員可以很方便的配置和接入。
上層應用的“監”，可選擇的產品就很多了，例如阿里雲的應用實時監控服務ARMS提供了針對上層應用層的事件、日誌、指標、告警，用戶也可以選擇開源的prometheus或者zabbix來自建。
基礎設施和上層應用之間的邊界並不是絕對的，其實我們需要的往往是從下到上的全監控。
監控的“控”
“監”的目的，是爲了“控”，這裏的控，具體指的是對事件和告警的處理。以短信，電話，郵件等方式通知給聯繫人，是最簡單直接的處理方式，但這種方式顯然容易被人忽略，而且延時很大。因此，SRE應該實現自動化的事件處理。
運維操作代碼化
如何實現自動化的事件處理呢？程序員可能會自然想到自己寫一個Event Consumer程序，從雲監控拉事件，然後調用資源的API進行處理。這個做法看上去很容易，但是具體實現真的這麼容易嗎？
首先，對於運維自動化平臺來說，可靠性非常重要，如果Event Consumer只有一個單點，那麼一旦出現故障宕機，就無法再處理系統事件。
這時，有經驗的程序員可能會說：“我可以引入消息隊列服務，進而利用多進程 Event Consumer來分佈式的消費，從而避免單點故障。”
當然，這是個解決方法，但是還會有一個問題，沒有任何一個分佈式的消息服務，可以實現既不重複也不遺漏消息，我們只能選擇不遺漏消息，而接受可重複的消息。但重複消息可能導致重複操作，這不能被運維人員接受。那麼，怎麼去重呢？我們只能引入分佈式的KV數據庫，比如Redis，根據EventID和原子的Redis操作（比如incr）來作爲消息去重的工具。
另外，一個事件的處理僅僅是調用一個API嗎？不一定的，你可能需要對多個資源進行多個API調用，這些調用之間彼此有依賴關係，有些甚至必須串行。爲了保證多個操作的事務性，即要麼全部成功，要麼全部失敗（需要回滾操作），這時就需要一個分佈式工作流引擎。
什麼？你還需要定時的任務？那麼，只能再引入分佈式的定時任務框架了。
…
這樣一看，是不是越來越複雜？實現一個高可靠、分佈式架構的運維平臺，顯然不是一件容易的事情。何況，運維開發與普通軟件開發不同，快速開發是第一位的，因爲運維開發的需求變化更頻繁，開發週期更短，人力也更爲緊張。若沒有平臺的支持，單純靠運維人員自己從頭搭建一個自動化運維繫統，並保證高效穩定持續運行，難度和投入都很大。
爲了保證生產系統的穩定，創造了一個運維繫統，那麼，誰又來保證這個運維繫統的穩定呢？這是一個悖論。
如何輕鬆實現“運維操作代碼化”呢？兩個建議，一是選擇一個可以快速開發的簡潔的運維語言，二是選擇一個可靠的事件驅動的運維平臺，而不是自己從頭造輪子。
在運維語言方面，腳本化的語言成爲了主流，比如YAML，JSON等，在遇到複雜的邏輯的時候，可以藉助Python、Shell，而C、C++之類的語言，運維人員用起來就有點沉重了。
開源的運維平臺，我們可以選擇Ansible、Puppet、SaltStack等等。以 Ansible 爲例，其核心賣點之一是“Agentless”，運維人員安裝Ansible之後，可以直接基於SSH，編寫YAML格式的Playbook，做Linux集羣的管。另外，各個主流雲廠商也爲Ansible編寫插件，因此運維人員可以用Ansible管理雲上的運維動作。值得注意的是，雲服務商也會提供原生的運維平臺，比如阿里雲提供的運維編排服務Operation Orchestration Service，簡稱OOS），AWS提供的System Manager Automation服務，或者Azure Automation服務。
基礎設施代碼化
雲基礎設施包括雲服務器、雲存儲、DNS、CDN等，而傳統的雲基礎設施管理總是面臨着各種各樣的難題，例如諮詢審批流程長、響應不及時，手工安裝和配置速度比較慢、難以版本化，易出錯、遺漏配置項等等。
爲了規避這些問題，我們提出了“基礎設施代碼化”，它指的是用代碼的方式管理基礎設施，並且維護管理它的全生命週期，包括審計的要求。代碼成爲了審計很好的記錄，代碼變更也可以追溯到人、項目組，解決了變本、追溯和變更歷史的問題。
基礎設施代碼化後，會給我們帶來什麼樣實際的好處呢？
我們舉一個例子，假設在阿里雲上搭建一個經典的三層在線服務：前面是SLB負載均衡，中間是若干臺ECS作爲一個服務集羣，後面再掛接一套RDS數據庫。同時，我們爲這三層各自創建了一個VPC，通過安全組設置安全規則。
在業務初期你可能只需要兩臺ECS，但很快會擴大到3臺、4臺。這時應該怎麼辦呢？比較直接的辦法是在阿里雲控制檯操作，今天創建一臺，明天再創建一臺。
但這種方法明顯是比較笨拙的，我們能不能使用“基礎設施代碼化”的方法呢？當然可以。我們把資源，定義在文本文件裏，做成配置項，保存到雲上。比如有一個配置項叫做ServersAmount，代表服務器數量。我們把這個配置項從3改成5，ECS數量就自動從3臺增加到了5臺。再把ServersAmount從3改成2，會自動釋放其中一臺ECS。 代碼，或者說配置，是有變更歷史記錄的。代碼也是可以很清晰地被審查的。代碼還可以很容易的被複制。
怎麼實現“基礎設施代碼化”呢？最關鍵的是需要一個平臺，如果選擇從頭開發，那就不再是造輪子了，而是在造輪船了。
那麼什麼樣的平臺是值得選擇的呢？開源的Terraform是個不錯的選擇，它得到了各個主流雲廠商的官方支持，用戶可以直接使用。不過，Terraform要求運維人員自己準備服務器來配置安裝，還要自己維護這個平臺。另外，雲廠商也提供了開箱即用的雲服務，例如阿里雲提供的資源編排服務（ROS）。
雲時代運維的未來發展
正如前文所述，雲時代的運維工作正從手動操作過渡到代碼開發，只不過這些用於運維的代碼，形式不拘一格，可以是配置文件，可以是YAML或者JSON模板，也可以是傳統的Javascript/Python/Go等代碼。那麼，未來，雲時代的運維會怎麼發展呢？
在我看來，雲時代的運維發展其實很大程度上取決於雲上應用和基礎設施的變化。我們可以大膽分析和預測，未來雲時代的運維將會是這樣的：
1、目前主流的雲上應用架構是自建API網關+微服務+分佈式RPC+消息隊列等，這種架構需要的雲上基礎設施是負載均衡+雲服務器+虛擬專用網絡+雲關係數據庫等，其運維方式如前面介紹的。
2、未來幾年比較確定的趨勢是雲上應用開發會越來越多的使用Reactive響應式(反應式)編程，全異步、事件驅動，對應的基礎設施則會容器化，隱藏掉服務器這一層，這預示着運維工作會越來越多的圍繞容器編排，比如Kubernetes展開。
3、中遠期的未來，函數計算這種Serverless的開發模式將會流行起來，對應的基礎設施則會簡化到連容器都看不見了。用戶不再爲基礎設施而付費，而是爲實際的計算次數付費。雲服務商會利用機器學習等手段，來保證函數計算所需的基礎設施是高可靠的和高度靈活的。到時，運維人員已經不需要關心資源的編排了，但是函數內業務的監控和運維動作的自動化還是需要的。
4、更長遠的未來，雲計算，邊緣計算，本地計算，可能會統一到一起，不再區分“線上”和“線下”，取而代之的是一種無處不在，但又不被人感知的計算力。具體來說，應用開發者寫完代碼，保存起來，就完成了業務的更新。“基礎設施”和“資源”這兩個概念，將徹底消失，只留下數據本身，包括靜態數據（代碼+配置）以及動態運行時數據。而運維，並不會消失，但會從面向資源的運維，變成面向數據的運維。