運維是從 IT 誕生之初就一直存在的重要角色，在 IT 類企業(yè)中，尤其是互聯(lián)網(wǎng)企業(yè)，運維、開發(fā)和測試被稱為是驅動技術進步的三駕馬車。而金融、政府、醫(yī)藥、教育、制造、運輸?shù)绕渌袠I(yè)，為了進行數(shù)字化轉型，也紛紛建立了自己的或大或小的數(shù)據(jù)中心，并為了維持這些 IT 系統(tǒng)的正常運轉，設立了大量的運維崗位。可以說，信息技術已經(jīng)并且正在改變我們身邊的一切行業(yè)，而只要有 IT 系統(tǒng)的地方，就有運維同學的身影和貢獻。

但最近幾年，云時代的到來，讓很多運維同學倍感焦慮，“云計算是未來”得到了大多數(shù)人的認同。2019 年 Q1，公有云 IaaS 市場同比增長 74%。越來越多的企業(yè)，開始把自己線下的數(shù)據(jù)中心和機房搬遷上公有云。而一旦企業(yè)放棄了自建的 IT 基礎設施，甚至把員工的辦公電腦都搬到了云上（桌面云），由公有云廠商提供服務，那么企業(yè)是否還需要這么多運維人員呢？

與此同時，DevOps 思潮席卷全球，大家紛紛嘗試“組織機構變革”，打破開發(fā) - 測試 - 運維之間的邊界，由開發(fā)人員來直接負責自動化的測試和運維工作。更進一步，從 DevOps 進化出了 AI Ops 甚至 No Ops，人工智能開始在運維領域顯露身手。而云計算與 DevOps 正好是天生一對。云是 DevOps 最好的平臺，而 DevOps 是云上的最佳實踐。

在云計算和 DevOps 的雙重壓力下，運維的未來會何去何從？

1. 云時代的運維是怎么樣的？

沖浪是一個非常刺激的極限運動。相比海浪的力量，沖浪者的個體力量是渺小的，每一次沖浪都是一次冒險。但智慧并且勇敢的沖浪者會仔細觀察海浪的方向并調整沖浪板與海浪方向一致，當海浪抵達時，沖浪者會站起來，在海浪的沖擊下急速前進，享受浪尖上的快感。

沖浪者很清楚，自己成功的關鍵在于找準海浪的方向。我們技術人員也一樣，只有保持對新技術的敏感性，并及時調整自己，才能借助浪潮的力量快速進步。

給大家講一個真實的故事。2009 年，阿里云剛剛成立的第二年，時任淘寶技術總架構師行癲（現(xiàn)任阿里云總裁）宣布淘寶網(wǎng)將拋棄 Oracle，轉投云上的自研數(shù)據(jù)庫。獲知此消息后，八十多個 Oracle DBA 把當時的 DBA 負責人后羿堵在會議室里，“如果上邊鐵了心要干，兄弟們的前途在哪里？”還好，技術人是講理的，一場惡斗轉化成了幾十個工程師坐在會議室促膝談心。既然上云是戰(zhàn)略，為何不順勢而為？就這樣，一群 Oracle DBA，開始親手拆毀自己安身立命的系統(tǒng)。2013 年 7 月，淘寶最后一個 Oracle 數(shù)據(jù)庫下線。時至今日，整個阿里集團，所有的核心業(yè)務 100% 跑在公共云上。

是啊，既然上云勢不可擋，我們何不順勢而為，看看云上運維是什么樣子的？

首先，云上運維和傳統(tǒng)的運維，操作的目標是不一樣的。傳統(tǒng)的運維人員，需要能夠熟練的手動操作來自眾多廠家的計算、網(wǎng)絡、存儲等硬件設備，而云上的運維人員完全接觸不到物理設備，取而代之的是云上的虛擬資源，例如云服務器，云盤，虛擬交換機等。云廠商將對資源的操作全部抽象成了軟件定義的 API 接口，并用統(tǒng)一風格的 SDK、命令行進行封裝，提供給運維人員使用。云廠商提供的圖形化的運維控制臺，也不過是 API 的封裝而已。

其次，云上運維是高度簡化的。傳統(tǒng)的運維，需要學習來自眾多“大廠”的認證，例如，網(wǎng)絡運維要學思科的認證，數(shù)據(jù)庫運維要學 Oracle 的認證，系統(tǒng)運維要學 IBM 的認證，等等。而在云上，虛擬專有網(wǎng)絡產(chǎn)品將網(wǎng)絡設備的管理和運維變得統(tǒng)一和簡單，云上數(shù)據(jù)庫產(chǎn)品實現(xiàn)了智能化的數(shù)據(jù)庫管理，云服務器實現(xiàn)了動態(tài)的擴縮容和熱遷移，這些都大幅降低了運維操作的門檻。云上的運維人員不再需要感知底層基礎設施的細節(jié)，更不需要考取高難度的認證。即使是創(chuàng)業(yè)階段的小企業(yè)也可以擁有和大企業(yè)同等的運維能力。

但是運維簡化，并不意味著運維的重要性降低，相反，在云上，運維變得比以前更加重要了。

云時代運維面臨的挑戰(zhàn)

為什么在云時代，運維變得更重要了呢？主要有兩個原因，一是云上運維的范疇比以往擴大了，二是云上企業(yè)對于穩(wěn)定性的要求更高了。

從范疇上看，云上運維包含了從藍圖規(guī)劃，到上云交付，再到云上管理的全過程。如果我們具體到流程和階段，包括了設計選型、資源交付、系統(tǒng)交付、運維調優(yōu)、擴縮容、資源運營、備份容災，安全 & 審計等等。

從穩(wěn)定性方面看，通常云廠商只負責基礎設施的穩(wěn)定，上層應用仍由企業(yè)開發(fā)人員自主開發(fā)，同時云上應用本身的穩(wěn)定性也由企業(yè)自己的運維人員負責。如果具體來說的話，企業(yè)運維人員需要負責持續(xù)發(fā)布過程中的藍綠發(fā)布、灰度發(fā)布、分批發(fā)布、自動回滾等的實現(xiàn)，以及應用層的監(jiān)控、事件告警體系的建設。另外，云上基礎設施的穩(wěn)定性不能單純依靠云廠商，也需要企業(yè)運維人員的相互配合。例如阿里云的云服務器單臺實例的可用性達到 99.975%，但仍然存在著萬分之 2.5 的不可用時間。企業(yè)的云運維人員可以采用監(jiān)控、負載均衡、多機熱備、兩地三中心等常用的高可用設計，在不是百分百可靠的基礎設施上，搭建百分百可靠的應用。

具體來說，云上運維主要面臨著以下挑戰(zhàn)：

首先，運維排查問題的難度增加了。由于云上“黑盒子”的存在，當故障突然發(fā)生時，運維人員往往只能看到服務出現(xiàn)異常了，很難快速判定問題出在哪里？是云服務商的基礎設施出問題了，還是我自己的代碼出 bug 了？...... 甚至就算排查出是云服務商某個服務的問題，部分運維人員也只能打電話給客服尋求幫助，而從客服得到的回復往往難以令人滿意，從而耽誤了故障恢復時間。

第二，云服務發(fā)出的消息、日志、事件等難以有效處理。如果運維人員每天收到幾千條短信或者郵件，一定是無法及時處理的，只能無腦忽略。但是又不能設置郵件規(guī)則將它們全部扔到垃圾箱里，因為會擔心漏掉重要的通知，比如服務器宕機的通知。

第三，資源的膨脹帶來了管理的復雜性。所有的資源都是軟件概念，對于一個大企業(yè)來說，這些資源可能分布在全球的十幾個 region，分散在幾十個云產(chǎn)品的控制臺，服務于幾百種不同的負載或者在線服務。更可怕的是，這些資源一直在變化。如何有效的跟蹤、審計、創(chuàng)建、釋放并保證無浪費？

第四，云產(chǎn)品的頻繁升級帶來了運維的頻繁被動變化。云產(chǎn)品的選擇非常多，實例類型紛繁復雜，包括預付費、后付費、預留實例券，什么性能突發(fā)型、計算型、通用型、GPU 實例、專有宿主機、裸金屬實例，容器服務、Kubernetes 或者 Swarm、彈性容器實例，等等。更要命的是，這些云產(chǎn)品還在不停地發(fā)布升級，如何選擇適合自己的產(chǎn)品？新功能如何才能幫助到業(yè)務？...... 盲目追隨云廠商的腳步不是良策。

2. 如何調整才能適應云時代的運維？SRE 可能是答案

如前面所說，企業(yè)上云之后，仍然有大量的運維需求。但此時的運維，卻又與傳統(tǒng)的運維截然不同。企業(yè)應該如何進行結構調整以適應上云后的新形勢呢？

DevOps 是現(xiàn)在提到的很火的概念，DevOps 實踐的整個生命周期是從計劃 -》編碼 -》構建 -》測試 -》發(fā)布 -》部署 -》操作 -》監(jiān)控，再回到計劃，是一個循環(huán)。其中發(fā)布、部署、操作和監(jiān)控（下圖的黃色部分）是屬于運維領域的。

DevOps 實踐打破了開發(fā)和運維之間的壁壘，開發(fā)人員可以直接負責運維。云上的運維已經(jīng)和軟件開發(fā)融為一體，強調高度的自動化，沉淀了一系列的運維工具和運維平臺，并朝著 AIOps 和 NoOps 的方向持續(xù)演進。

而反過來，運維人員如果能掌握開發(fā)技能，結合自動化工具的使用，是否能夠做的更好呢？答案是肯定的。運維人員可以轉型升級為兼具開發(fā)技能和運維技能的站點穩(wěn)定性工程師（SRE）。Google 最早推出了 SRE 這一概念，并使得 SRE 部門成為其承擔運維職責的一個研發(fā)部門。越來越多的上云后的企業(yè)，開始把自己的運維部門改造升級為 SRE 部門。

SRE 聽上去很美，但真正要做到并不容易。以阿里云為例，早年阿里云也走過人肉運維的痛苦階段，盡管運維工程師 7*24 輪班 on call 待命，但客戶仍然投訴不斷，系統(tǒng)問題不斷。后來，阿里云團隊開始建設穩(wěn)定性，通過監(jiān)控報警將故障的平均發(fā)現(xiàn)時間從 1 小時縮短到 10 秒鐘，同時借助 AI 預測算法，在某些情況下可以在故障發(fā)生前，提前預警并采取行動。現(xiàn)在阿里云每年發(fā)布上千次變更，難免會出現(xiàn)變更導致的故障和異常，但是 SRE 團隊藍綠發(fā)布、灰度發(fā)布、分批發(fā)布、自動回滾、熱遷移等技術，實現(xiàn)了發(fā)布全過程無人值守。

如何才能升級成為 SRE 呢？這三點建議可能對你會有所幫助：

• 一是學習 DevOps 的實踐，熟練掌握至少一種編程技能（比如 Python、Go、Java 等），從思想和技術上，保持工程師的先進性；
• 二是學習云廠商提供的各種自動化運維工具，并靈活運用，嘗試幫助自己企業(yè)搭建高效率的自動化運維平臺；
• 三是積極參與開源和云廠商的生態(tài)建設，伴隨運維生態(tài)一起成長，如果能產(chǎn)生出運維平臺級的解決方案產(chǎn)品，廣泛應用于整個行業(yè)，那么個人價值和商業(yè)價值都會得到體現(xiàn)。

3. 自動化一切是云時代運維的首要任務

要想實現(xiàn)云上運維的順利升級，首要任務就是”自動化一切“，如果列出 Top3，應該是：監(jiān)控自動化、運維操作代碼化、基礎設施代碼化。

監(jiān)控自動化

先來看監(jiān)控，包括了“監(jiān)”和“控”兩個方面。

監(jiān)控的“監(jiān)”

“監(jiān)”，從橫向劃分，包含了事件（Event），日志（Log），指標（Metric），告警（Alarm）四個維度；從縱向劃分，分為底層基礎設施的“監(jiān)”和上層應用的“監(jiān)”。

橫向看：事件、日志、指標和告警

什么是事件？對于云服務商來言，事件其實是資源的變化，每一次資源的變化，都是一個事件。例如云服務器的每一次狀態(tài)變化都是一個事件，包括開機中（starting），運行中（running），關機中（stopping），已停止（stopped）。

什么是日志？日志是客戶行為和云服務內部行為的過程記錄，包含時間、操作者、內容、級別等要素。每一條事件，都可以轉化成相應的日志，記錄到日志服務里。因此，日志的范圍，比事件更大。日志服務所提供的，不僅僅是日志的記錄，更重要的是日志的聚合和檢索能力。例如，運維人員可以隨時查看某一個資源在過去某一個時間段的歷史記錄。

什么是指標？指標是資源運行時的內部屬性數(shù)據(jù)，最典型的指標就是 linux 里面 top 命令所顯示的數(shù)據(jù)，包括 CPU、內存、IO 數(shù)據(jù)等。這些數(shù)據(jù)不屬于事件，也沒有記錄下來作為日志的必要，但仍然是很重要的實時數(shù)據(jù)，是運維人員需要關心的系統(tǒng)健康指標數(shù)據(jù)，如果一切健康，就可以忽略。

什么是告警？告警可以認為是嚴重級別的事件，是需要立即采取人工或者自動化動作的事件。運維人員可以根據(jù)指標設定閾值來觸發(fā)一個告警，也可以在事件和日志的基礎上設定報警規(guī)則，觸發(fā)告警。

縱向看：底層基礎設施和上層應用

底層基礎設施的“監(jiān)”，需要由云服務商來提供基礎數(shù)據(jù)，云廠商的監(jiān)控往往會提供針對基礎設施的事件、日志、指標、告警，運維人員可以很方便的配置和接入。

上層應用的“監(jiān)”，可選擇的產(chǎn)品就很多了，例如阿里云的應用實時監(jiān)控服務 ARMS 提供了針對上層應用層的事件、日志、指標、告警，用戶也可以選擇開源的 prometheus 或者 zabbix 來自建。

基礎設施和上層應用之間的邊界并不是絕對的，其實我們需要的往往是從下到上的全監(jiān)控。

監(jiān)控的“控”

“監(jiān)”的目的，是為了“控”，這里的控，具體指的是對事件和告警的處理。以短信，電話，郵件等方式通知給聯(lián)系人，是最簡單直接的處理方式，但這種方式顯然容易被人忽略，而且延時很大。因此，SRE 應該實現(xiàn)自動化的事件處理。

運維操作代碼化

如何實現(xiàn)自動化的事件處理呢？程序員可能會自然想到自己寫一個 Event Consumer 程序，從云監(jiān)控拉事件，然后調用資源的 API 進行處理。這個做法看上去很容易，但是具體實現(xiàn)真的這么容易嗎？

首先，對于運維自動化平臺來說，可靠性非常重要，如果 Event Consumer 只有一個單點，那么一旦出現(xiàn)故障宕機，就無法再處理系統(tǒng)事件。

這時，有經(jīng)驗的程序員可能會說：“我可以引入消息隊列服務，進而利用多進程 Event Consumer 來分布式的消費，從而避免單點故障。”

當然，這是個解決方法，但是還會有一個問題，沒有任何一個分布式的消息服務，可以實現(xiàn)既不重復也不遺漏消息，我們只能選擇不遺漏消息，而接受可重復的消息。但重復消息可能導致重復操作，這不能被運維人員接受。那么，怎么去重呢？我們只能引入分布式的 KV 數(shù)據(jù)庫，比如 Redis，根據(jù) EventID 和原子的 Redis 操作（比如 incr）來作為消息去重的工具。

另外，一個事件的處理僅僅是調用一個 API 嗎？不一定的，你可能需要對多個資源進行多個 API 調用，這些調用之間彼此有依賴關系，有些甚至必須串行。為了保證多個操作的事務性，即要么全部成功，要么全部失敗（需要回滾操作），這時就需要一個分布式工作流引擎。

什么？你還需要定時的任務？那么，只能再引入分布式的定時任務框架了。

......

這樣一看，是不是越來越復雜？實現(xiàn)一個高可靠、分布式架構的運維平臺，顯然不是一件容易的事情。何況，運維開發(fā)與普通軟件開發(fā)不同，快速開發(fā)是第一位的，因為運維開發(fā)的需求變化更頻繁，開發(fā)周期更短，人力也更為緊張。若沒有平臺的支持，單純靠運維人員自己從頭搭建一個自動化運維系統(tǒng)，并保證高效穩(wěn)定持續(xù)運行，難度和投入都很大。

為了保證生產(chǎn)系統(tǒng)的穩(wěn)定，創(chuàng)造了一個運維系統(tǒng)，那么，誰又來保證這個運維系統(tǒng)的穩(wěn)定呢？這是一個悖論。

如何輕松實現(xiàn)“運維操作代碼化”呢？兩個建議，一是選擇一個可以快速開發(fā)的簡潔的運維語言，二是選擇一個可靠的事件驅動的運維平臺，而不是自己從頭造輪子。

在運維語言方面，腳本化的語言成為了主流，比如 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 等，而傳統(tǒng)的云基礎設施管理總是面臨著各種各樣的難題，例如咨詢審批流程長、響應不及時，手工安裝和配置速度比較慢、難以版本化，易出錯、遺漏配置項等等。

為了規(guī)避這些問題，我們提出了“基礎設施代碼化”，它指的是用代碼的方式管理基礎設施，并且維護管理它的全生命周期，包括審計的要求。代碼成為了審計很好的記錄，代碼變更也可以追溯到人、項目組，解決了變本、追溯和變更歷史的問題。

基礎設施代碼化后，會給我們帶來什么樣實際的好處呢？

我們舉一個例子，假設在阿里云上搭建一個經(jīng)典的三層在線服務：前面是 SLB 負載均衡，中間是若干臺 ECS 作為一個服務集群，后面再掛接一套 RDS 數(shù)據(jù)庫。同時，我們?yōu)檫@三層各自創(chuàng)建了一個 VPC，通過安全組設置安全規(guī)則。

在業(yè)務初期你可能只需要兩臺 ECS，但很快會擴大到 3 臺、4 臺。這時應該怎么辦呢？比較直接的辦法是在阿里云控制臺操作，今天創(chuàng)建一臺，明天再創(chuàng)建一臺。

但這種方法明顯是比較笨拙的，我們能不能使用“基礎設施代碼化”的方法呢？當然可以。我們把資源，定義在文本文件里，做成配置項，保存到云上。比如有一個配置項叫做 ServersAmount，代表服務器數(shù)量。我們把這個配置項從 3 改成 5，ECS 數(shù)量就自動從 3 臺增加到了 5 臺。再把 ServersAmount 從 3 改成 2，會自動釋放其中一臺 ECS。代碼，或者說配置，是有變更歷史記錄的。代碼也是可以很清晰地被審查的。代碼還可以很容易的被復制。

怎么實現(xiàn)“基礎設施代碼化”呢？最關鍵的是需要一個平臺，如果選擇從頭開發(fā)，那就不再是造輪子了，而是在造輪船了。

那么什么樣的平臺是值得選擇的呢？開源的 Terraform 是個不錯的選擇，它得到了各個主流云廠商的官方支持，用戶可以直接使用。不過，Terraform 要求運維人員自己準備服務器來配置安裝，還要自己維護這個平臺。另外，云廠商也提供了開箱即用的云服務，例如阿里云提供的資源編排服務（ROS）。

4. 云時代運維的未來發(fā)展

正如前文所述，云時代的運維工作正從手動操作過渡到代碼開發(fā)，只不過這些用于運維的代碼，形式不拘一格，可以是配置文件，可以是 YAML 或者 JSON 模板，也可以是傳統(tǒng)的 Javascript/Python/Go 等代碼。那么，未來，云時代的運維會怎么發(fā)展呢？

在我看來，云時代的運維發(fā)展其實很大程度上取決于云上應用和基礎設施的變化。我們可以大膽分析和預測，未來云時代的運維將會是這樣的：

• 目前主流的云上應用架構是自建 API 網(wǎng)關 + 微服務 + 分布式 RPC+ 消息隊列等，這種架構需要的云上基礎設施是負載均衡 + 云服務器 + 虛擬專用網(wǎng)絡 + 云關系數(shù)據(jù)庫等，其運維方式如前面介紹的。
• 未來幾年比較確定的趨勢是云上應用開發(fā)會越來越多的使用 Reactive 響應式 (反應式) 編程，全異步、事件驅動，對應的基礎設施則會容器化，隱藏掉服務器這一層，這預示著運維工作會越來越多的圍繞容器編排，比如 Kubernetes 展開。
• 中遠期的未來，函數(shù)計算這種 Serverless 的開發(fā)模式將會流行起來，對應的基礎設施則會簡化到連容器都看不見了。用戶不再為基礎設施而付費，而是為實際的計算次數(shù)付費。云服務商會利用機器學習等手段，來保證函數(shù)計算所需的基礎設施是高可靠的和高度靈活的。到時，運維人員已經(jīng)不需要關心資源的編排了，但是函數(shù)內業(yè)務的監(jiān)控和運維動作的自動化還是需要的。
• 更長遠的未來，云計算，邊緣計算，本地計算，可能會統(tǒng)一到一起，不再區(qū)分“線上”和“線下”，取而代之的是一種無處不在，但又不被人感知的計算力。具體來說，應用開發(fā)者寫完代碼，保存起來，就完成了業(yè)務的更新。“基礎設施”和“資源”這兩個概念，將徹底消失，只留下數(shù)據(jù)本身，包括靜態(tài)數(shù)據(jù)（代碼 + 配置）以及動態(tài)運行時數(shù)據(jù)。而運維，并不會消失，但會從面向資源的運維，變成面向數(shù)據(jù)的運維。