本文是互聯網專欄《高效運維最佳實踐》的第05篇文字，由蕭田國原創並授權“高效運維”公眾號轉發。本文未經作者授權，謝絕轉載。
前言
這些年來，大家都在談運維自動化。但是否也會困惑於“只見樹木、不見森林”？或者說，做了幾年的運維自動化，但依然不能確定還有哪些工作沒做？還有，怎樣更優雅的實施運維自動化？
另外，運維自動化是萬能的么？有哪些潛在問題？想了解5月底某網站大故障的獨家剖析？且聽本文分解~
本文實際上包括兩部分，關於運維自動化的一些觀點（前3部分）和運維自動化的痛點（第4部分）。如果已是運維自動化的專業人士，可以跳過前面內容，直接鑒賞第4部分——運維自動化之殤。
依慣例放上目錄，請享用：
什么是運維自動化？
運維自動化的三個階段
怎么做運維自動化？
運維自動化之殤
好吧我們正式開始。
1. 什么是運維自動化？
有人從實用性的角度來表述運維自動化，就是把運維日常需要登錄機器的操作，完全Web化，以后只需要點一下鼠標就搞定。然后，和監控結合，就有自動擴縮容，自動告警分析，自動故障發現，自動流量切換。
這種說法正確么？實際上，Web化只是最基礎的工作（而且這更多是運維自助化），我們不能將Web化和運維自動化畫上等號。
在了解運維自動化之前，讓我們回到起點，先看看什么是運維。運維應包括如下：
環境定義：開發環境、測試環境、類生產環境、生產環境等；
部署：能夠將部署包有效的部署到不同的環境；
監控：能夠監控部署后的系統和應用；
告警響應：出現問題時的響應和處理機制；
性能優化：系統各個服務如Nginx、Java、PHP、DB或網絡等的優化
SLA保障：通常要和業務相關部門討論確定
所以，運維自動化，應該包括上述這些內容。我們結合起來，略舉幾例：
1）環境定義自動化：
很多公司采用的是數據中心+虛擬機，團隊需要某種環境的時候，必須要走流程申請，申請就意味着和不同部門打交道，挨個部門進行層層審批，很浪費時間。
所以環境/基礎設施能否自動化很重要，負責開發、管理基礎設施的部門，一定要提供方便的接口，幫助其他團隊能自動創建資源。
2）部署自動化：
這部分的進化過程大抵如此：Scripts -> Auto tools -> Cloud -> Container，略作說明如下：
-
最早的部署方式，都是ssh到目標機器上，下載部署包，拷貝到指定的位置，重啟服務。如果應用頻繁升級，操作人員就會很痛苦，所以就想辦法自動化。於是大家來寫Shell腳本，自動化部署過程。雖然，Shell腳本好用，但是讀起來代碼量大，不好維護。
-
隨着工具的發展，客戶的部署腳本遷移到了Chef/Puppet，使用起來方便，而且容易維護。
-
再往后有了私有雲，公有雲，部署方式又發生變化，這時候面對的層次不一樣，部署包也不一樣，以前的war包，rpm包，現在到了IaaS層，都變成了image，雖然部署簡單了，但考慮的問題更多了，怎么管理image，怎么用好image，怎么更快的scale？都是問題。
-
現在，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，企業信息化架構創始人怎么說的：
只有擁有大量原子模型時，才可能大規模重用和組裝。也就是在你得到訂單之前你就應該在倉庫里擁有東西，這樣你才能做到大規模客戶定制和按訂單生產。
復合件的數量是無限的，原子件的數量是有限的；原子件可用於一個以上的實施。
這可以作為我們的指導思想。我們來看一下騰訊游戲基於此的最佳實踐。
騰訊游戲在底層設計並封裝很多原子件，這些原子件可被多次調用。例如原子件“DB容量管理”就應用到復合件“數據決策自動縮擴容”、“運營活動自動開關”等。
4. 運維自動化之殤
運維自動化是我們的必經之路，那么，一定就是解決所有問題的靈丹妙葯么？可能不盡然哦。潛在問題包括如下：
1）忽略權限和基線
運維自動化平台通常由DevOps開發（例如Python + Shell），更多的是以實現功能為主，可能對賬號權限或服務器操作權限，未做特殊限制，這樣問題就來了，例如：
是否針對運維自動化平台的服務器賬號做了特殊限制，使得這個賬號只能操作指定目錄，只能重啟Nginx、不能重啟PHP？
是否做了超限檢查？例如，對部分特殊請求如“rm -Rf”或超高數值調整做了二次過濾？
是否做了關鍵操作的雙保險？例如，數據庫合並類的危險操作，增加了一個檢查人審核機制？
另外，運維自動化發布平台是否保存有程序基線，並有一鍵恢復功能？
大公司的業務系統，運行十多年，開發人員你來我往數以千計，而發布平台每次僅更新部分代碼（類似縫縫補補）。這樣的后果是，可能根本沒有人有一套完整的業務系統代碼。
如果執行任意系統命令+缺乏基線，兩者兼備，剛好又有人觸發了執行操作，那么災難性的后果就會突然來臨。
畢竟，對於歷史悠久的大型業務系統而言，老代碼往往沒人敢動，而且嚴重SOA化，從零重建的難度之大，也許需要幾十個小時。而又因為這種極端情況下，很難形成一個強一致性的版本，所以重建成功往往只是災難的開始，之后就是開發、客服和DBA陷入長期的疲於奔命之中。
2）缺乏安全機制
運維自動化平台一般由非專業開發人員實施，而且是給內部人員使用，主觀上容易忽略代碼安全和系統安全。
“上帝節點”是安全災難的起點。
之前沒有運維自動化，小米加步槍的時代，上千台服務器相對獨立，還有各種堡壘機、動態令牌或私鑰登錄服務器等安全措施，想一個命令刪除大批量服務器的程序，還真不容易實現。
運維自動化平台已然是“上帝節點”，天然的實現了連接到大批量服務器（甚至可能直接是root權限）。這樣，為廣大的黑客朋友帶來了無限想象空間。
有朋友可能會說，我放在公司內網了非常安全。其實，現在黑客可以很容易的掃描到內網所有域名，識別到疑似運維自動化平台的域名，然后用常規或非常規手段入侵，然后就“一鍋端”了。例如：
你的運維自動化平台是基於通用框架如Django么。一個常識是，越是流行的框架，已知漏洞、甚至0day漏洞越多哦。
3）忽略專業性
運維自動化越是充分的公司，隱藏的風險就越大。
即使一個再優秀的運維自動化平台，也不能解決所有運維問題。所以，如果忽略了對人員專業能力的培養，那么在某些需要人工操作的場景（例如機房遷移這類重大調試），問題就會報復性的反彈和爆發。
一次專業的調試，體現在對調試時長和調試效果的掌控上。調試時長必須可接受、並可控。
例如一次跨機房遷移，停業務10小時甚至以上，是很難被接受的；停業務10分鍾以下，則是很令人愉快的。但這個的專業化要求很多，包括如充分的演練、更多的任務前置，保證只有必須的操作在調試期間進行。
可控性主要體現在調試節奏的把握，例如是否有快速可操作的回滾措施，保證如果預計調試不能如期完成，能提前預警並快速切回之前的系統狀態。
當有重大調試需求時，突然發現中級運維人員沒那么多了，初級運維人員缺少專業化鍛煉和練手機會，“手生”，主管不敢用之；高級運維人員都已“金盆洗手”多年，自己不敢上手。
4）自得和忽略人文關懷
運維自動化平台上線后，運維人員可能會產生一種主觀的優越感，並嚴重阻礙后續工作的開展。以前是開發追着運維打，運維往往疲於奔命，心力憔悴。現在神器在手，容易“多年的媳婦熬成婆”。。。
其實運維自動化只是解決了運維部分工作效率的問題，遠沒有解決運維的全部問題，外部門對運維的不滿，可能濤聲依舊，例如經常容易犯的“老板着個臉，說話直接不拐彎；需求老不及時完成，完不成也不說”等等。
運維自動化越是充分的公司，高層管理者（技術VP或CTO）可能產生一種錯覺，運維人員是否可以靠邊站了？甚至誇張些說，是否可以“卸磨殺驢”了？這種意識層的錯覺或者說自我心理暗示，會導致各種多米諾骨牌式的效應。
如果高層忽略人為關懷，在某些極端情況下，運維自動化平台的高權限人員，可能“有意”利用上述提及的平台缺陷，進行極具破壞性的事情。。然后災難性的后果，可能長時間難以補救。
結語
運維自動化的價值在於，將運維從繁瑣的、例行、容易發生人為事故的工作中脫離出來，做更有價值的業務運維和服務運維。
所以，從這個角度來看，運維自動化既不是起點，也不是終點。運維自動化不是萬能的，我們需要看清楚它的位置。
運維自動化，終歸只是一個高級工具而已。運維的價值最終是要體現在業務上的：
體現的方式就是運維服務化，所以運維自動化（智能化）最終都要為運維的服務化服務。所以如何構建你的自動化系統最終要看你所支撐的業務需要什么樣的服務。
所以，在做之前一定要弄清楚我們的目標，不要為了做而做，如果這樣，結果就只能是呵呵了。
說明
本文與其說是我編著，還不如說是高效運維系列微信群朋友們集體智慧的結晶。其中第1部分“什么是運維自動化”，主要來自王磊@thoughtworks的觀點；第2部分“運維自動化的三個階段”，主要來自劉棲銅@騰訊游戲的觀點，另外張冠宇@大眾點評及其他專家群友對本文的形成亦有重要貢獻。Tim Yang老師再次不辭辛苦的審閱本文，在此一並謝過。