一名運維者的思考：云計算時代的自動化運維走向

發(fā)表于：2017/7/12 15:02:48??閱讀量：?[關閉]

　　關于題目“云計算時代的自動化運維”，用通俗的話講，就是應用的自動化部署。

　　第一個關鍵詞是自動化，自動化代表高速效率、低成本;第二個關鍵詞是應用部署。即，不涉及講物理基礎設施的運維(如機房基建、能源、消防、安保、布線等等)。

　　假設一個企業(yè)要做一個電商網站，典型的運維流程是這樣：

　　1. 購買硬件設備：服務器、交換機?？赡苓€有路由器、負載均衡器、防火墻，不一一窮舉了。

　　2. 在服務器上安裝操作系統(tǒng)

　　3. 在服務器上安裝配置基礎環(huán)境(數據庫、Web服務器、搜索引擎等)

　　4. 在服務器上安裝配置應用軟件(用Java、PHP開發(fā)的電商軟件)

　　5. 把硬件設備送進機房托管，開通公網訪問

　　6. 監(jiān)控運維中的業(yè)務，并做日常備份、擴容/縮容、遷移、升級

　　如果是使用公有云，則沒有第1，2，5步，直接購買公有云的虛擬機、容器、平臺服務(文件存儲、關系數據庫、內容分發(fā)等)

　　應用環(huán)境和應用軟件部署是指第3步和第4步。

　　1 操作系統(tǒng)自動化部署

　　第2步是物理祼機的部署，現(xiàn)在市面上的主流服務器，都支持IPMI管理，通電接上管理端口就可以完成BIOS設置，再輔以DHCP， TFTP， KickStart可以實現(xiàn)無人值守的自動化安裝操作系統(tǒng)。

　　目前虛擬化、私有云、公有云已經相當普及，除了一些對特殊硬件有要求的場合，和一些歷史遺留場合，其它大部分場合都可以用虛擬機，物理機上安裝的是宿主操作系統(tǒng)，應用軟件裝在虛擬機里，這樣物理祼機就只需要安裝宿主操作系統(tǒng)，需求相對簡單，沒有應用部署那么復雜。裝完之后不會經常去改動，運行穩(wěn)定。

　　2 應用部署

　　與操作系統(tǒng)部署相比，應用部署復雜性高得多，主要表現(xiàn)在：

　　· 場景繁多

　　一個小型的B2C網站，有負載均衡器、Web服務器、應用服務器、緩存服務器、搜索引擎、分布式文件系統(tǒng)、監(jiān)制中心、日志中心、VPN服務器等十多種服務器角色

　　· 依賴復雜

　　軟件包之間有依賴，服務器之間有通信依賴

　　· 配置各異

　　除標準的ini，xml， yaml， json， properties文件外，iptables， sysctl， nginx， haproxy， pptpd等都有自己獨特的配置文件格式，多達上百種。文檔描述和運維腳本編寫都有相當大的難度。

　　3 應用部署技術發(fā)展歷程

　　下面以在CentOS上安裝nginx為例，回顧一下應用部署技術的發(fā)展歷程：

　　3.1 手工安裝配置

　　這是很古老的部署方式，直到今天也被廣大小規(guī)模團隊廣泛采用。部署過程往往會產生這樣一份文檔供日后參考：

　　3.1.1 優(yōu)點

　　3.1.1.1 靈活性高

　　可以安裝任何想要的版本，啟用任何想要的模塊(包括自行開發(fā)的私有模塊)

　　3.1.1.2 學習門檻低

　　文檔是自然語言寫成，閱讀和書寫都很簡單，不需要額外學習其它技術語言。安裝配置用到的工具、命令也較少，主要是網絡下載、解壓縮、編譯、文本編輯幾種，容易掌握。

　　3.1.2 缺點

　　作為很古老的部署技術，缺點也是顯而易見的：

　　3.1.2.1 文檔不精確

　　由于文檔是自然語言寫的，是寫給運維工程師閱讀的，而不是給機器執(zhí)行的。文檔寫的是什么，跟機器上實際執(zhí)行的是什么，并不是100%一致的，需要人肉轉換。在長期版本變更、人員更替中極容易出現(xiàn)疏漏。當然，可以從行政管理上解決這類隱患。很多大公司都喜歡搞流程，用測試審核流程來督促人少犯錯。然而，只要是這個文檔是給人看而不是給機器執(zhí)行的，這個文檔就會一直面臨筆誤、表達不精確、更新不及時等隱患，要用流程來徹底杜絕這些隱患，成本很高。

　　3.1.2.2 效率低

　　上述5個步驟都是串行的，須做完一步才能進行下一步。第1步和第3步是比較耗時的，若網速不快，或者編譯時間太長，運維工程師會浪費時間等待。

　　另一方面，若有多臺機器需要執(zhí)行同樣的部署操作，也無法減少重復性操作。

　　3.2 自動化部署：shell腳本

　　若服務器稍有規(guī)模的團隊里，上述手工部署就成了一個大問題。

　　人肉閱讀的文檔急需轉換成機器執(zhí)行的代碼。最早也是廣泛運用的自動化部署技術便是shell腳本。以bash為例，上述5步寫成bash shell就像這樣(示例代碼，未經測試)：

　　直接運行這個腳本，就可以自動安裝配置好nginx了。

　　相比手工部署，使用shell腳本的缺點只有兩點：一是寫代碼需要一定學習門檻。二是維護的技術難度會略高。

　　3.2.1 優(yōu)點

　　3.2.1.1 精確

　　由于shell腳本是給機器執(zhí)行的，shell腳本自身就是一份精確的可執(zhí)行的文檔，所以，不存在筆誤、表達不精確、更新不及時的問題。

　　3.2.1.2 效率高

　　運維工程師只要把腳本啟動起來就可以做別的工作了。

　　3.2.2 bash的缺點

　　Bash是幾乎所有l(wèi)inux發(fā)行版內置的，環(huán)境兼容性好，簡潔易學。但它卻不是運維編程的終極之選。具體來說有兩大缺點：

　　3.2.2.1 缺少高級語言特性

　　Bash不是一門高級編程語言，和Perl/Python/Ruby/PHP這些同樣可以用作shell編程的語言相比，缺少很多高級語言特性，而這些特性在運維部署工作中會用到。

　　3.2.2.1 工具鏈不豐富

　　由于不支持OOP，因此沒有完整的單元測試框架。

　　開發(fā)框架、缺陷分析、性能分析工具也幾乎是一片空白。IDE支持雖有(JetBrains公司IntelliJ就有bash shell插件)，但功能不多。

　　3.3 自動化部署：運維DSL

　　得益于虛擬化和公有云的快速普及，效高質量地完成應用部署不再是大公司專有的需求，也成了中小企業(yè)的剛需，前面分析過了，bash shell不能勝任大規(guī)模的、復雜的應用部署，自動化運維編程語言DSL(Domain Specific Language)被發(fā)明出來，puppet， chef，ansible， saltstack是其中杰出的代表。

　　4 自動化運維技術發(fā)展趨勢展望

　　4.1 部署工作代碼化

　　無論是使用bash / python shell，還是使用puppet、chef等DSL，都可以完成代碼化這個過程。把手工操作變成代碼。

　　使用代碼自動化部署應用環(huán)境和應用，才能保證無論在辦公室測試環(huán)境，還是在機房生產環(huán)境，每次運行這個部署代碼，都能得到相同的結果。這是一切自動化部署的基礎。

　　4.2 運維代碼版本化

　　運維代碼要和Java，PHP等應用代碼一樣，納入SVN、GIT代碼倉庫，執(zhí)行嚴格的開發(fā)-測試-上線-回滾流程。

　　這樣便可利用svn/git的成熟SCM功能，用于這樣一些場景：

　　4.2.1 新建分支

　　運維代碼由1.0升級到2.0，增加了緩存層。則可以從1.0復制出一個分支出來，命名為2.0，然后再在2.0的基礎上修改。

　　4.2.2 差異比較

　　若要了解1.0和2.0的運維架構到底發(fā)生了什么變化，執(zhí)行svn和git的diff即可查看每一行代碼的變化。

　　4.2.3 歷史歸檔

　　1.0版穩(wěn)定運行了半年，升級到2.0版本，此時1.0版凍結寫請求，歸檔留存。2.0上線運行一段時間，發(fā)現(xiàn)穩(wěn)定性不夠?？梢詮臍w檔中找出1.0版本的部署代碼，回滾到1.0版本。

　　4.3 測試環(huán)境高保真

　　很多公司的測試和生產環(huán)境存在操作系統(tǒng)不一致、軟件版本不一致、配置項不一致的情況。這種不規(guī)范的運維有兩大后果：一是bug在測試環(huán)境未能測出，導致線上故障;二是線上出現(xiàn)異常時，測試環(huán)境不能復現(xiàn)。

　　一個應用至少有兩種環(huán)境：測試環(huán)境、生產環(huán)境。大一點的公司還會分成：開發(fā)環(huán)境、功能測試環(huán)境、性能測試環(huán)境、預發(fā)環(huán)境、生產環(huán)境。這么多的環(huán)境的自動化部署代碼，原則上應該是90%以上都相同，只有少數地方不一樣。

　　4.4 自動化測試

　　使用代碼自動化部署完之后，服務器是否立即可用，需要測試驗證。自動化測試能讓整個運維過程更加高時效。

　　在應用開發(fā)領域，自動化測試、單元測試已經非常普及了，運維開發(fā)也可以做一些類似的自動化驗收測試工作：

　　4.4.1 終端應用測試

　　模擬一個客戶端訪問剛剛部署好的服務，例如：驗證其RESTfulAPI是否得到預期的結果。

　　優(yōu)點是，很接近實際用戶，若此測試通過，則說明裝軟件、改配置、啟服務各項工作都正確。缺點是，若測試不通過，不能立即定位出哪里出錯了。定位問題需借助下面更底層的測試。

　　4.4.2 四層網絡測試

　　使用nmap之類的工具檢測目標端口是否正常響應(包括防火墻是否放行)

　　4.4.3 本機測試

　　· 用yum，apt檢測包是否安裝

　　· 用service status檢測守護進程是否正常支持

　　· 用ps檢測進程是否正在運行

　　· 用ls檢測文件是否存在

　　· 用grep檢查配置薦是否設置成了指定的值

　　自動化測試用例覆蓋足夠全方面，我們便有可能實現(xiàn)一臺機器從祼機到上線服務全部自動化完成，無人值守。若沒有自動化測試，應用部署完成之后，仍然需要人工驗證是否滿足上線服務的要求。

　　4.5 工作流

　　運維代碼從開發(fā)到上線發(fā)揮作用，也應該和應用代碼一樣遵循下面的工作流：

　　這個流程圖只展示了基本的要求：部署到生產環(huán)境前須經過測試環(huán)境驗證。更復雜的還有代碼reivew、性能測試環(huán)境驗證、漏洞掃描環(huán)境驗證、預發(fā)環(huán)境驗證，生產環(huán)境分批發(fā)布等環(huán)節(jié)。

　　很多公司的現(xiàn)狀是運維工程師開兩個ssh終端，一條命令，先在本地環(huán)境跑一下看看效果，成功就拿到線上去跑了。更有甚者，不經過本地驗證直接到線上操作了。這主要是因為運維工作沒有充分代碼化，運維代碼沒入svn、git倉庫。

　　4.6 圖形化界面和IDE

　　運維領域一直都缺少通用的、高時效的圖形界面和IDE。這大約有兩個原因：

　　一是需求不強勁。運維編程的復雜度畢竟比應用編程簡單好幾個數量級。運維日常工作也沒有代碼化，還有大量的人工操作，所以，運維代碼通常像冰糖葫蘆一樣，一個個腳本雖然串在一起，但大都是個獨立的個體，沒有那么強的代碼組織結構。

　　二是運維社區(qū)極客氛圍濃重。就連應用編程領域也只有Java、.NET等語言的用戶比較偏愛IDE。在PHP、Python、Perl社區(qū)，vim黨、emacs黨、sublime text黨、notepad++黨各領風騷。這些黨派崇拜的編輯器不同，但有一個共同信仰：不依賴IDE寫代碼是一個優(yōu)秀程序員的必備素質。

　　關于這個問題，我是這樣認為的，有高科技能提升編程生活質量，為什么不用用?即使puppet、chef把運維編程體驗做到這么好了，我仍然期待運維業(yè)界涌現(xiàn)一批Eclipse、AdobeFlash這樣的圖形界面、IDE。讓IDE的高效易用和運維的命令行操作相得益彰。

　　4.7 運維代碼分治

　　運維界有一句祖訓：沒有折騰，就沒有故障。

　　但為了快速響應業(yè)務需求和提高資源利用率，運維又不得不頻繁折騰。有沒有什么辦法能打破“折騰越多、故障越多”的魔咒?有，分而治之。

　　分治，就是把風險高的和風險低的分開、重要性高的和不高的分開、簡單的和復雜的分開、頻繁變動的和不頻繁的分開。應用編程領域，大家積極探索和實踐的各種架構、框架、模式，歸根到底都在做兩件事：封裝復雜度、隔離變化。

　　運維架構層的分治，在業(yè)界已經非常普遍了，比如應用服務器和數據庫服務器分離、交易數據庫和用戶數據庫分離;生產環(huán)境和測試環(huán)境隔絕。

　　4.7.1 配置項和邏輯代碼分開

　　其實業(yè)界早就在這么做了，puppet的hiera和saltstack的pillar都是做這個用的。

　　有些運維變更，可能只改變了配置項的值，而并沒改變運維代碼里的業(yè)務邏輯、流程控制。如果只改配置文件，不改運維腳本。發(fā)布風險就低了很多，起碼不會導致語法錯誤。

　　4.7.2 會變動的配置項獨立

　　就像應用開發(fā)領域里的模板引擎一樣，把配置文件寫成模板，模板中包含變量，運維工具或者運維平臺解析模板內容，把變量替換成真實的值。

　　4.7.3 服務發(fā)現(xiàn)

　　將會變動的配置項獨立出來動態(tài)維護，還可以實現(xiàn)服務發(fā)現(xiàn)。以haproxy + etcd + confd為例：

　　confd就是一個模板引擎，類似Java里有Velocity和Python里的jinja。不同之處是：confd還有自動輪詢etcd的能力。使用confd解析和管理haproxy的配置文件，摘錄如下：

　　跟原生的haproxy配置文件不同，最后三行是confd模板。

　　etcd是一個KV存儲，類似memcached，不同之處是etcd生來就是分布式的，自帶高可用和負載均衡的基因，同時還有HTTPRESTful API，存取方便。使用etcd存儲后端服務器列表。

　　當后端有一臺nginx服務啟動的時候，調etcd的api把這臺機器的ip地址寫入etcd上的列表。confd輪詢etcd時查到這臺新加入的機器，便會自己把它加進haproxy的backend server里。

　　這樣便實現(xiàn)了負載均衡集群自動化擴容，下線一臺nginx機器亦同此理，先調etcd的api刪除某臺機器，過一分鐘在這臺nginx上檢測不到流量了再把它下線。

　　擴容過程中沒有修改haproxy的配置，也沒有部署haproxy。只是調用了etcd的RESTfulAPI，這個風險就比修改haproxy配置文件再部署上線小多了。

　　4.8 整合基礎設施API

　　所有的公有云廠商都提供了HTTPOpenAPI，包括國外的aws、azure、gce和國內的阿里云、Ucloud、青云。

　　市場占有率排名靠前的虛擬化軟件商也都有HTTPOpenAPI，包括：VMware、Hyper-V、XenServer、OpenStack。

　　因此技術上有可能把基礎設施提供商的API整合進來，實現(xiàn)虛擬機創(chuàng)建、啟動、安裝操作系統(tǒng)、聯(lián)網、執(zhí)行命令、關機、銷毀全生命周期的自動化。

　　和應用部署腳本不同，調用云廠商的API不能由DSL腳本完成，用bash shell來做也非常不方便。應該用PHP、Java之類的應用編程語言寫一個應用來做。

　　至此，虛擬機和操作系統(tǒng)初始化、應用環(huán)境部署、應用軟件部署全部都實現(xiàn)了自動化，便可以從零創(chuàng)建一臺可上線服務的機器。

　　4.9 跨廠商跨城市故障轉移

　　實現(xiàn)了部署工作代碼化和基礎設施API整合之后，便可以自由地跨廠商、跨城市遷移：在不同的機房維持兩份相同的數據，每分鐘同步。當基礎設施發(fā)生重大故障難以在短時間內恢復時，可以迅速在另外一個有數據的機房將整套應用自動化部署起來。

　　4.10 彈性伸縮

　　幾乎每一個給人類訪問的網站，其服務器資源利用率都是存在明顯峰谷的：

　　· 有的尖峰是一年出現(xiàn)一次，典型的例子是阿里的雙十一。每年11月11日，電商狂歡。大賣家的進銷存系統(tǒng)、淘寶生態(tài)鏈上的SaaS服務商(如在線打印快遞單、發(fā)送短信券碼、物流跟蹤)的系統(tǒng)壓力也跟著猛漲1-2個數量級。他們投資擴容的硬件設備，只有這一天才能充分利用，平時利用率極低。

　　· 有的尖峰是一天出現(xiàn)一次或者多次，比如唯品會、聚劃算的10點秒殺。基本每一個電商都一天多波次的秒殺、搶購。

　　· 更普遍的是白天高峰、凌晨到清晨低谷。

　　自動化運維(包括自動購買分配虛擬機、自動部署應用環(huán)境、自動部署應用軟件、自動測試)使按需調度計算資源成為了可能。實時的彈性伸縮，意味著每天、甚至每分鐘都在做擴容、縮容，這須要靠自動化運維實現(xiàn)。

　　4.10.1 公有云上的按需采購

　　主流的公有云計費粒度都已經細到小時(aws、阿里云、Ucloud)，有的做到了按分鐘(azure、gce)，甚至還有按秒計費的(青云)。

　　對出現(xiàn)頻率較低、計劃中的尖峰，人工干預，提前做好擴容和縮容預案，以雙十一為例，人工設定好11月10日購買一批按小時計費的機器(不是包年包月)，到了11月15日釋放這些機器，廠商會停止計費。

　　對出現(xiàn)頻率高的尖峰，運維平臺智能調度，比如每5秒采樣系統(tǒng)資源利用率，達到指定的擴容閾值就自動買機器并自動化部署、測試、上線服務，低于指定的回收閾值就自動下線服務器、通知廠商停止計費。這種適用于部署上線時間極短的服務，特別是無狀態(tài)、無用戶數據的應用服務器。若需要較長的預熱時間(如數據庫、緩存、搜索引擎)，則需要提前擴容，這就要根據歷史性能曲線做智能預測了。

　　按需購買對公有云廠商也有積極意義：

　　· 從宏觀角度講，用多少買多少，杜絕浪費，提升了全球公有云資源池中的資源利用率，任何提升資源利用率的事情都是有積極正面的。

　　· 從經濟角度講，公有云按小時售賣的機器單價比包年的貴，如果兩種售賣方式都能100%把機器賣出去，按小時計費的總收入更高。

　　· 目前有的公有云廠商已經出現(xiàn)部分機房物理資源售罄的情況。如果提供實時服務(如電商、支付、新聞、社交)的客戶都按需采購，就有可能在閑時把資源釋放出來給實時性要求不高的客戶(如離線大數據處理、動畫渲染)使用。

　　4.10.2 私有云的業(yè)務間調配

　　已經投資購置大量硬件的企業(yè)，可以在不同內部業(yè)務之間調度，比如白天把大多數機器用來為消費者提供服務，晚上縮減承擔消費者請求的機器規(guī)模，釋放出來的計算資源用來做大數據處理。