運維自動化之殤 | 高效運維最佳實踐05

本文是互聯網專欄《高效運維最佳實踐》的第05篇文字，由蕭田國原創並受權「高效運維」公衆號轉發。本文未經做者受權，謝絕轉載。

前言

這些年來，你們都在談運維自動化。可是否也會困惑於「只見樹木、不見森林」？或者說，作了幾年的運維自動化，但依然不能肯定還有哪些工做沒作？還有，怎樣更優雅的實施運維自動化？

另外，運維自動化是萬能的麼？有哪些潛在問題？想了解5月底某網站大故障的獨家剖析？且聽本文分解~

本文實際上包括兩部分，關於運維自動化的一些觀點（前3部分）和運維自動化的痛點（第4部分）。若是已經是運維自動化的專業人士，能夠跳過前面內容，直接鑑賞第4部分——運維自動化之殤。

依慣例放上目錄，請享用：

1. 什麼是運維自動化？

2. 運維自動化的三個階段

3. 怎麼作運維自動化？

4. 運維自動化之殤

好吧咱們正式開始。

1. 什麼是運維自動化？

有人從實用性的角度來表述運維自動化，就是把運維平常須要登陸機器的操做，徹底Web化，之後只須要點一下鼠標就搞定。而後，和監控結合，就有自動擴縮容，自動告警分析，自動故障發現，自動流量切換。

這種說法正確麼？實際上，Web化只是最基礎的工做（並且這更可能是運維自助化），咱們不能將Web化和運維自動化畫上等號。

在瞭解運維自動化以前，讓咱們回到起點，先看看什麼是運維。運維應包括以下：

環境定義：開發環境、測試環境、類生產環境、生產環境等；

部署：可以將部署包有效的部署到不一樣的環境；

監控：可以監控部署後的系統和應用；

告警響應：出現問題時的響應和處理機制；

性能優化：系統各個服務如Nginx、Java、PHP、DB或網絡等的優化

SLA保障：一般要和業務相關部門討論肯定

因此，運維自動化，應該包括上述這些內容。咱們結合起來，略舉幾例：

1）環境定義自動化：

不少公司採用的是數據中心+虛擬機，團隊須要某種環境的時候，必需要走流程申請，申請就意味着和不一樣部門打交道，挨個部門進行層層審批，很浪費時間。

因此環境/基礎設施可否自動化很重要，負責開發、管理基礎設施的部門，必定要提供方便的接口，幫助其餘團隊能自動建立資源。

2）部署自動化：

這部分的進化過程大抵如此：Scripts -> Auto tools -> Cloud -> Container，略做說明以下：

1. 最先的部署方式，都是ssh到目標機器上，下載部署包，拷貝到指定的位置，重啓服務。若是應用頻繁升級，操做人員就會很痛苦，因此就想辦法自動化。因而你們來寫Shell腳本，自動化部署過程。雖然，Shell腳本好用，可是讀起來代碼量大，很差維護。

2. 隨着工具的發展，客戶的部署腳本遷移到了Chef/Puppet，使用起來方便，並且容易維護。

3. 再日後有了私有云，公有云，部署方式又發生變化，這時候面對的層次不同，部署包也不同，之前的war包，rpm包，如今到了IaaS層，都變成了image，雖然部署簡單了，但考慮的問題更多了，怎麼管理image，怎麼用好image，怎麼更快的scale？都是問題。

4. 如今，Container來了，部署在Image的基礎上，又變化了，部署自動化如今解決的已經不只僅是部署自己了，還包括怎麼能更快scale，更容易管理artifact，更容易屏蔽底層的不一樣。

3）監控自動化：

如今通常都用Zabbix作問題發現，但得考慮作告警歸併，以解決特殊狀況下告警氾濫的問題，例如機房斷網形成的批量服務器報警。

監控自動化是運維自動化的起點之一，這個又包括了部分故障恢復的自動化，即故障自愈。後者又每每藉助於故障樹等機制，至少對諸如503錯誤，可經過自動重啓應用服務器程序來恢復。

2. 運維自動化的三個階段

站得高，因此看得更遠。也許咱們還在給一個小的業務環節搭建運維自動化，但從更高層次瞭解運維自動化的各個階段，不無裨益。

1）操做自動化：

這個層次的特徵是，把運維一系列的手工執行的操做，用腳本或工具簡單串起來。最簡單的例子就是，把多個Shell腳本串在一塊兒執行實現某個特定的操做目的。

誠如前文所說，這個層次的自動化只部分解決了運維手工執行的問題，但一旦操做的條件發生了變化，可能Shell腳本也得變，運維的壓力仍是很大，並且容易出錯。管理的服務器越多，出錯的機率越大得多。

2）場景自動化：

這個層次的特徵是，工具會根據外部環境判斷如何運行，而這些判斷條件是事先運維定義好的。此層次的運維繫統須要各種環境數據來作爲判斷條件，同時還要可以變化操做行爲（好比不一樣的執行步驟）。

所以，此層次的運維繫統須要跟不少其餘系統對接（好比對接了配置系統、網管系統等），最好還要有流程引擎；

3）智能化：

此層次的運維繫統具有數據核心（大數據存儲，全部運營中的數據都會按關聯關係集中存儲），具有根據數據本身分析和判斷、並自我決策和執行的能力。

在此層次，運維的主要工做是爲系統增添分析策略、運營和維護此智能運維繫統，以及在系統執行的關鍵節點上介入作人工判斷；

3. 怎麼作運維自動化？

不少運維同仁實施運維自動化時，謀求設計一個完備的系統，來自動化完成幾乎全部運維工做——但與此同時，又每每被其複雜程度所困惑、躊躇不前。在咱們思考怎麼作運維自動化以前，咱們需認識到的是：

「企業的架構不是設計出來的，是演變而來的。」

這能夠近似做爲指導思想。這也代表，除非是成熟的大公司，不然不要一開始想着我怎麼作個大一統的自動化平臺，而後千辛萬苦找公司要到資源，而後大半年不出成果（而後績效還得了個C）。

1）先解決痛點

若是登陸服務器部署更新程序很是頻繁、常常爲此起夜或因響應不及時常被業務投訴，那就先作Web部署自助化（例如Jenkins + Ansible）。至於說是否基於CMDB，反而不過重要，特別是若是業務系統並沒那麼大，服務器變更也沒那麼頻繁的話。

平常工做中，對常見問題進行分類和梳理，能作成工具的就工具化，能程序化操做的，就避免人爲干預。

這樣各類工具愈來愈多，小工具組裝起來，發揮更大的效能。對於複雜的自動化任務需求，也能夠用多個小的、單一功能的模塊，組合起來完成複雜的操做，相似於先造零件，再拼裝（後文再詳細介紹）。

2）選擇正確的階段

運維自動化通常沿襲這樣的階段：

手動支撐 => 線上標準規範化 => 運維工具化 => 平臺自助化/自動化。

選擇適合本身當前業務發展階段的運維自動化方式，很重要哦，不要圖謀一口吃成胖子，呵呵。

也有人說，運維自動化平臺就是一個任務執行系統，若是確保準確執行是整個系統的核心所在。

因此，標準化是運維自動化的前提，如Ngnix/JAVA/PHP/MySQL這些常見服務的應用初始化流程、部署更新流程等，得提早固化下來；另外同理，業務流程和操做順序也不能亂來。

另外，對於大中型運維自動化平臺而言，CMDB和配置系統依然不可或缺。

CMDB即配置管理數據庫，通常用於統一管理IT數據、服務器數據資產等。CMDB數據的準確性和權威性，關係到運維自動化是否走在正確的路上——畢竟系統不是人，沒法加入感性判斷，只能基於冰冷的數據進行觸發式處理。

須要注意的是，解決痛點和標準化/CMDB不是矛盾互斥的：

解決痛點而搭建的運維自助部署平臺，和基於標準化/CMDB而部署的高大上運維自動化平臺，能夠共存。畢竟前者實施起來快，後者建設週期長。

3）原子件 & 複合件

上好佳的運維自動化平臺須要融入一些架構設計的思想。這裏最重要的就是原子件和複合件的設計，咱們先看一下Zachman，企業信息化架構創始人怎麼說的：

1. 只有擁有大量原子模型時，纔可能大規模重用和組裝。也就是在你獲得訂單以前你就應該在倉庫裏擁有東西，這樣你才能作到大規模客戶定製和按訂單生產。

2. 複合件的數量是無限的，原子件的數量是有限的；原子件可用於一個以上的實施。

這能夠做爲咱們的指導思想。咱們來看一下騰訊遊戲基於此的最佳實踐。

騰訊遊戲在底層設計並封裝不少原子件，這些原子件可被屢次調用。例如原子件「DB容量管理」就應用到複合件「數據決策自動縮擴容」、「運營活動自動開關」等。

4. 運維自動化之殤

運維自動化是咱們的必經之路，那麼，必定就是解決全部問題的靈丹妙藥麼？可能不盡然哦。潛在問題包括以下：

1）忽略權限和基線

運維自動化平臺一般由DevOps開發（例如Python + Shell），更多的是以實現功能爲主，可能對帳號權限或服務器操做權限，未作特殊限制，這樣問題就來了，例如：

1. 是否針對運維自動化平臺的服務器帳號作了特殊限制，使得這個帳號只能操做指定目錄，只能重啓Nginx、不能重啓PHP？

2. 是否作了超限檢查？例如，對部分特殊請求如「rm -Rf」或超高數值調整作了二次過濾？

3. 是否作了關鍵操做的雙保險？例如，數據庫合併類的危險操做，增長了一個檢查人審覈機制？

另外，運維自動化發佈平臺是否保存有程序基線，並有一鍵恢復功能？

大公司的業務系統，運行十多年，開發人員你來我往數以千計，而發佈平臺每次僅更新部分代碼（相似縫縫補補）。這樣的後果是，可能根本沒有人有一套完整的業務系統代碼。

若是執行任意系統命令+缺少基線，二者兼備，恰好又有人觸發了執行操做，那麼災難性的後果就會忽然來臨。

畢竟，對於歷史悠久的大型業務系統而言，老代碼每每沒人敢動，並且嚴重SOA化，從零重建的難度之大，也許須要幾十個小時。而又由於這種極端狀況下，很難造成一個強一致性的版本，因此重建成功每每只是災難的開始，以後就是開發、客服和DBA陷入長期的疲於奔命之中。

2）缺少安全機制

運維自動化平臺通常由非專業開發人員實施，並且是給內部人員使用，主觀上容易忽略代碼安全和系統安全。

「上帝節點」是安全災難的起點。

以前沒有運維自動化，小米加步槍的時代，上千臺服務器相對獨立，還有各類堡壘機、動態令牌或私鑰登陸服務器等安全措施，想一個命令刪除大批量服務器的程序，還真不容易實現。

運維自動化平臺已然是「上帝節點」，自然的實現了鏈接到大批量服務器（甚至可能直接是root權限）。這樣，爲廣大的黑客朋友帶來了無限想象空間。

有朋友可能會說，我放在公司內網了很是安全。其實，如今黑客能夠很容易的掃描到內網全部域名，識別到疑似運維自動化平臺的域名，而後用常規或很是規手段入侵，而後就「一鍋端」了。例如：

你的運維自動化平臺是基於通用框架如Django麼。一個常識是，越是流行的框架，已知漏洞、甚至0day漏洞越多哦。

3）忽略專業性

運維自動化越是充分的公司，隱藏的風險就越大。

即便一個再優秀的運維自動化平臺，也不能解決全部運維問題。因此，若是忽略了對人員專業能力的培養，那麼在某些須要人工操做的場景（例如機房遷移這類重大調試），問題就會報復性的反彈和爆發。

一次專業的調試，體如今對調試時長和調試效果的掌控上。調試時長必須可接受、並可控。

例如一次跨機房遷移，停業務10小時甚至以上，是很難被接受的；停業務10分鐘如下，則是很使人愉快的。但這個的專業化要求不少，包括如充分的演練、更多的任務前置，保證只有必須的操做在調試期間進行。

可控性主要體如今調試節奏的把握，例如是否有快速可操做的回滾措施，保證若是預計調試不能如期完成，能提早預警並快速切回以前的系統狀態。

當有重大調試需求時，忽然發現中級運維人員沒那麼多了，初級運維人員缺乏專業化鍛鍊和練手機會，「手生」，主管不敢用之；高級運維人員都已「金盆洗手」多年，本身不敢上手。

4）自得和忽略人文關懷

運維自動化平臺上線後，運維人員可能會產生一種主觀的優越感，並嚴重阻礙後續工做的開展。之前是開發追着運維打，運維每每疲於奔命，心力憔悴。如今神器在手，容易「多年的媳婦熬成婆」。。。

其實運維自動化只是解決了運維部分工做效率的問題，遠沒有解決運維的所有問題，外部門對運維的不滿，可能濤聲依舊，例如常常容易犯的「老闆着個臉，說話直接不拐彎；需求老不及時完成，完不成也不說」等等。

運維自動化越是充分的公司，高層管理者（技術VP或CTO）可能產生一種錯覺，運維人員是否能夠靠邊站了？甚至誇張些說，是否能夠「卸磨殺驢」了？這種意識層的錯覺或者說自我心理暗示，會致使各類多米諾骨牌式的效應。

若是高層忽略人爲關懷，在某些極端狀況下，運維自動化平臺的高權限人員，可能「有意」利用上述說起的平臺缺陷，進行極具破壞性的事情。。而後災難性的後果，可能長時間難以補救。

結語

運維自動化的價值在於，將運維從繁瑣的、例行、容易發生人爲事故的工做中脫離出來，作更有價值的業務運維和服務運維。

因此，從這個角度來看，運維自動化既不是起點，也不是終點。運維自動化不是萬能的，咱們須要看清楚它的位置。

運維自動化，終歸只是一個高級工具而已。運維的價值最終是要體如今業務上的：

體現的方式就是運維服務化，因此運維自動化（智能化）最終都要爲運維的服務化服務。因此如何構建你的自動化系統最終要看你所支撐的業務須要什麼樣的服務。

因此，在作以前必定要弄清楚咱們的目標，不要爲了作而作，若是這樣，結果就只能是呵呵了。

說明

本文與其說是我編著，還不如說是高效運維繫列微信羣朋友們集體智慧的結晶。其中第1部分「什麼是運維自動化」，主要來自王磊@thoughtworks的觀點；第2部分「運維自動化的三個階段」，主要來自劉棲銅@騰訊遊戲的觀點，另外張冠宇@大衆點評及其餘專家羣友對本文的造成亦有重要貢獻。Tim Yang老師再次任勞任怨的審閱本文，在此一併謝過。