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

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

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

在云計(jì)算和 DevOps 的雙重壓力下，運(yùn)維的未來會(huì)何去何從？

1. 云時(shí)代的運(yùn)維是怎么樣的？

沖浪是一個(gè)非常刺激的極限運(yùn)動(dòng)。相比海浪的力量，沖浪者的個(gè)體力量是渺小的，每一次沖浪都是一次冒險(xiǎn)。但智慧并且勇敢的沖浪者會(huì)仔細(xì)觀察海浪的方向并調(diào)整沖浪板與海浪方向一致，當(dāng)海浪抵達(dá)時(shí)，沖浪者會(huì)站起來，在海浪的沖擊下急速前進(jìn)，享受浪尖上的快感。

沖浪者很清楚，自己成功的關(guān)鍵在于找準(zhǔn)海浪的方向。我們技術(shù)人員也一樣，只有保持對新技術(shù)的敏感性，并及時(shí)調(diào)整自己，才能借助浪潮的力量快速進(jìn)步。

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

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

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

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

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

云時(shí)代運(yùn)維面臨的挑戰(zhàn)

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

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

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

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

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

第二，云服務(wù)發(fā)出的消息、日志、事件等難以有效處理。如果運(yùn)維人員每天收到幾千條短信或者郵件，一定是無法及時(shí)處理的，只能無腦忽略。但是又不能設(shè)置郵件規(guī)則將它們?nèi)咳拥嚼淅铮驗(yàn)闀?huì)擔(dān)心漏掉重要的通知，比如服務(wù)器宕機(jī)的通知。

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

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

2. 如何調(diào)整才能適應(yīng)云時(shí)代的運(yùn)維？SRE 可能是答案

如前面所說，企業(yè)上云之后，仍然有大量的運(yùn)維需求。但此時(shí)的運(yùn)維，卻又與傳統(tǒng)的運(yùn)維截然不同。企業(yè)應(yīng)該如何進(jìn)行結(jié)構(gòu)調(diào)整以適應(yīng)上云后的新形勢呢？

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

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

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

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

如何才能升級(jí)成為 SRE 呢？這三點(diǎn)建議可能對你會(huì)有所幫助：

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

3. 自動(dòng)化一切是云時(shí)代運(yùn)維的首要任務(wù)

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

監(jiān)控自動(dòng)化

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

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

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

橫向看：事件、日志、指標(biāo)和告警

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

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

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

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

縱向看：底層基礎(chǔ)設(shè)施和上層應(yīng)用

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

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

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

監(jiān)控的“控”

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

運(yùn)維操作代碼化

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

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

這時(shí)，有經(jīng)驗(yàn)的程序員可能會(huì)說：“我可以引入消息隊(duì)列服務(wù)，進(jìn)而利用多進(jìn)程 Event Consumer 來分布式的消費(fèi)，從而避免單點(diǎn)故障。”

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

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

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

......

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

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

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

在運(yùn)維語言方面，腳本化的語言成為了主流，比如 YAML，JSON 等，在遇到復(fù)雜的邏輯的時(shí)候，可以借助 Python、Shell，而 C、C++ 之類的語言，運(yùn)維人員用起來就有點(diǎn)沉重了。

開源的運(yùn)維平臺(tái)，我們可以選擇 Ansible、Puppet、SaltStack 等等。以 Ansible 為例，其核心賣點(diǎn)之一是“Agentless”，運(yùn)維人員安裝 Ansible 之后，可以直接基于 SSH，編寫 YAML 格式的 Playbook，做 Linux 集群的管。另外，各個(gè)主流云廠商也為 Ansible 編寫插件，因此運(yùn)維人員可以用 Ansible 管理云上的運(yùn)維動(dòng)作。值得注意的是，云服務(wù)商也會(huì)提供原生的運(yùn)維平臺(tái)，比如阿里云提供的運(yùn)維編排服務(wù) Operation Orchestration Service，簡稱 OOS），AWS 提供的 System Manager Automation 服務(wù)，或者 Azure Automation 服務(wù)。

基礎(chǔ)設(shè)施代碼化

云基礎(chǔ)設(shè)施包括云服務(wù)器、云存儲(chǔ)、DNS、CDN 等，而傳統(tǒng)的云基礎(chǔ)設(shè)施管理總是面臨著各種各樣的難題，例如咨詢審批流程長、響應(yīng)不及時(shí)，手工安裝和配置速度比較慢、難以版本化，易出錯(cuò)、遺漏配置項(xiàng)等等。

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

基礎(chǔ)設(shè)施代碼化后，會(huì)給我們帶來什么樣實(shí)際的好處呢？

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

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

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

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

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

4. 云時(shí)代運(yùn)維的未來發(fā)展

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

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

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