企業(yè)級自動化運維 與發(fā)展趨勢
隨著企業(yè)信息化的不斷發(fā)展，運維人員需要面對越來越復雜的業(yè)務和越來越多樣化的用戶需求，不斷擴展的應用需要越來越合理的模式來保障運維服務能靈活便捷、安全穩(wěn)定地持續(xù)。
某企業(yè)從初期的幾臺服務器發(fā)展到龐大的數(shù)據(jù)中心，單靠人工已經(jīng)無法滿足在技術、業(yè)務、管理等方面的要求，那么標準化、自動化、架構(gòu)優(yōu)化、過程優(yōu)化等降低運維服務成本的因素越來越被人們所重視。
其中，自動化開始代替人工操作在企業(yè)的運維過程中逐漸體現(xiàn)出來了強大的優(yōu)勢。
運維隨著企業(yè)業(yè)務的發(fā)展，自動化作為其重要屬性之一已經(jīng)不僅僅只是代替人工操作，更重要的是深層探知和全局分析，關注的是在當前條件下如何實現(xiàn)性能與服務最優(yōu)化，同時保障投資收益最大化。通過自動化運維能最大限度地在更少的維修時間內(nèi)實現(xiàn)運維目標，提高運維服務質(zhì)量。因此, 對于越來越復雜的運維來說，將人工操作逐漸改變?yōu)樽詣踊芾硎且粋€重要發(fā)展趨勢。
2. 企業(yè)級自動化運維 在的問題與需求
某企業(yè)初期只有文件共享和郵件服務等幾臺服務器，運維工作完全由人工操作，隨著企業(yè)的發(fā)展，新業(yè)務系統(tǒng)不斷上線企業(yè)、建設了中心機房，運維工作還是以人工為主，但是這一階段增加了網(wǎng)絡管理系統(tǒng)和環(huán)境監(jiān)控系統(tǒng)，這兩個系統(tǒng)在一定程度上減輕了運維的工作量，基本上實現(xiàn)了運維的半自動化。
企業(yè)在發(fā)展，運維工作量在不斷的增加，企業(yè)的運維工作面臨以下的問題及需要解決：
2.1 運維人員的工作效率與工作主動性需要提升
在企業(yè)運維過程中，只有當故障已經(jīng)發(fā)生并且造成業(yè)務影響時才能發(fā)現(xiàn)和著手處理，這種被動“救火”不但使運維人員終日忙碌，也使運維本身質(zhì)量很難提高，導致 IT 部門和業(yè)務部門對運維服務滿意度都不高。
運維人員日常大部分時間和精力是處理一些簡單重復的問題，而且由于故障預警機制不完善，往往是故障發(fā)生后或報警后才會進行處理，使得運維人員的工作經(jīng)常是處于被動的狀態(tài)，怎樣才能在故障發(fā)生前及時發(fā)現(xiàn)并把故障處理掉，使運維工作變被動為主動？
2.2 需要建立一套高效的運維機制
企業(yè)在運維管理過程中缺少自動化的運維管理模式，沒有明確的運維人員角色定義和責任劃分，使到問題出現(xiàn)后很難快速、準確地找到根本原因，無法及時地找到相應的人員進行修復和處理。
或者是在問題找到后缺乏流程化的故障處理機制，而在處理問題時不但欠缺規(guī)范化的解決方案，也缺乏全面的跟蹤記錄，企業(yè)需要建立一套高效的運維管理制度為運維工作提供方向和依據(jù)。
2.3 缺乏高效的運維技術工具
隨著信息化建設的深入，企業(yè)業(yè)務系統(tǒng)日趨復雜，各種各樣的網(wǎng)絡設備、服務器、存儲設備、業(yè)務系統(tǒng)等讓運維人員難以從容應對，即使加班加點地維護、部署、管理也經(jīng)常會因設備出現(xiàn)故障而導致業(yè)務的中斷，嚴重影響企業(yè)的正常運轉(zhuǎn)。
出現(xiàn)這些問題部分原因是企業(yè)缺乏事件監(jiān)控和診斷工具等運維技術工具，因為在沒有高效的技術工具的支持下故障事件很難得到主動、快速處理。
3. 業(yè)務流程標準化與健全運維管理制度
3.1 實現(xiàn)業(yè)務流程標準化，為自動化運維打好基礎
標準化是自動化運維的基礎，想要實現(xiàn)標準化，首先識別各個運維對象，然后我們?nèi)粘Ｗ龅乃羞\維工作都應該是針對這些對象的運維。
如果運維操作脫離了對象，那就沒有任何意義。同樣，沒有理清楚對象，運維自然不得章法。例如擴容，首先確定是服務器的擴容，還是應用的擴容，還是其它對象的擴容。
你會發(fā)現(xiàn)，對象不同，擴容這個場景所實施的動作是完全不一樣的。
如果把服務器的擴容套用到應用的擴容上去，必然會導致流程錯亂。同時對于對象理解上的不一致，也會增加無謂的溝通成本，造成運維效率低下。
這種情況下的自動化運維不但不能提升效率，還會越自動越混亂。
實現(xiàn)標準化的第一步是物理基礎設施的標準化，例如，識別物理對像服務器、交換機、機柜等硬件；識別這些物理對像的屬性，服務器的序列號、ip地址、廠商等信息；
識別這些對像之間的關系，服務器所在的機柜、接入哪個交換機的哪個接口了等信息。
服務器物理基礎設施的標準化如下圖（其它設備的標準化以此類推）：
第二步是應用的標準化，應用服務、中間件，數(shù)據(jù)庫等；例如，數(shù)據(jù)庫的表、視圖、存儲過程的標準化，表的字段名、值，索引等，表和視圖之間的關聯(lián)關系等。
第三步是流程標準化，如備份、軟件升級、殺毒，新業(yè)務上線等流程的標準化，下圖是現(xiàn)在的運維流程：
企業(yè)級自動化運維 是基于流程化的框架，將事件與IT流程相關聯(lián)，一旦被監(jiān)控系統(tǒng)發(fā)現(xiàn)性能超標，超過預先配置的閥值或宕機，就會觸發(fā)相關事件以及事先定義好的流程，可自動啟動故障響應和恢復機制。
自動化工作平臺還可幫助運維人員完成日常的重復性工作，提高運維效率，下圖是實現(xiàn)自動化運維的流程圖：
運維的自動化能夠預測故障、在故障發(fā)生前能夠報警，讓運維人員把故障消除在發(fā)生前，將所產(chǎn)生損失減到最低。由過去的手工執(zhí)行轉(zhuǎn)為自動化操作，從而減少乃至消除運維中的延遲，實現(xiàn)“零延時”的運維。
3.2 建立完整、全面的運維管理制度，為自動化運維的實現(xiàn)保駕護航
運維制度的建立包括環(huán)境管理、資產(chǎn)管理、介質(zhì)管理、設備管理、監(jiān)控管理、網(wǎng)絡安全管理、系統(tǒng)安全管理、惡意代碼防范管理、密碼管理、變更管理、備份與恢復管理、安全事件處置，應急預案管理等制度。
- 運維管理制度是衡量運維工作的一把尺子，完善的管理制度能有效的提升運維工作效率，日常工作以管理制度為依據(jù)，按規(guī)定的要求和規(guī)定的流程操作既快速又準確；
- 全面的運維管理制度能在問題和故障還沒有出現(xiàn)，沒有造成損失前就被及時的發(fā)現(xiàn)，從而問題得到有效的處理，業(yè)務連續(xù)性得到了保障；
- 運維管理制度為運維工作提供了規(guī)范化的解決方案，使運維人員在處理問題時有章可循快速找到問題的根本原因，把問題對業(yè)務造成的損失降到最低；
- 運維管理制度是為業(yè)務服務的，業(yè)務是不斷發(fā)展的，運維管理制度要跟得上業(yè)務的不斷發(fā)展實現(xiàn)管理制度的創(chuàng)新。
4. 自動化運維技術路線選型
4.1 自動化運維概述
自動化運維范圍包括安裝自動化、部署自動化、監(jiān)控自動化、發(fā)布自動化、升級自動化、安全管控自動化、優(yōu)化自動化、數(shù)據(jù)備份自動化等。
自動化運維系統(tǒng)包括商用自動化運維系統(tǒng)、開源自動化運維系統(tǒng)，自建（研發(fā)）自動化運維系統(tǒng)。
商業(yè)的運維系統(tǒng)在功能上要全面一些，服務支持上能好一些，更新與升級有保障，采購成本較高，對運維人員的技術要求相對較低。
開源運維系統(tǒng)更靈活一些，服務支持需要運維人員自身多投入一些時間和精力，更新與升級更個性化一些，相對成本較低。
自建自動化運維系統(tǒng)對人員的技術要求最高，成本也不低，但是當企業(yè)發(fā)展到一定規(guī)模后自建的運維系統(tǒng)才能更適合企業(yè)對于自動化運維的要求。
4.2 開源運維工具的應用場景與優(yōu)勢
1) Puppet是一個開源的軟件自動化配置和部署工具，它使用簡單且功能強大，很多大型IT公司均在使用 puppet 對集群中的軟件進行管理和部署。
優(yōu)缺點分析：優(yōu)點是Web界面生成處理報表、資源清單、實時節(jié)點管理，push命令可即刻觸發(fā)變更；
缺點是相對其他工具較復雜、需學習Puppet的DSL或Ruby，安裝過程缺少錯誤校驗和生成錯誤報表。
2) SaltStack是一種全新的基礎設施管理方式，部署輕松，在幾分鐘內(nèi)可以運行起來，擴展性好，很容易管理上萬臺服務器，速度夠快，服務器之間秒級通訊。
優(yōu)缺點分析：優(yōu)點是可以使用簡單的配置模塊或復雜的腳本，Web界面可以看到運行和監(jiān)控的工作狀態(tài)、事件日志，擴展能力極強；
缺點是缺少生成深度報告的能力。
3) Ansible是新出現(xiàn)的運維工具是基于Python研發(fā)的綜合了眾多老牌運維工具的優(yōu)點實現(xiàn)了批量操作系統(tǒng)配置、批量程序的部署、批量運行命令等功能。
在進行大規(guī)模部署時，手工配置服務器環(huán)境是不現(xiàn)實的，這時必須借助于自動化部署工具。
優(yōu)缺點分析：優(yōu)點是模塊可以用任何語言開發(fā)、備管節(jié)點不需要安裝代理軟件、有Web管理界面、安裝運行簡單；
缺點是對windows備管節(jié)點需要加強、執(zhí)行效率相對較低。
下圖是Puppet、Saltstack、Ansible這三款運維工具處理能力與處理效率的對比：
各種運維工具只是用于幫助人員進行運維的，每種工具都有其使用的優(yōu)勢領域，Puppet 適用于軟件自動化配置和部署；
SaltStack 適用于基礎設施管理，在幾分鐘內(nèi)可運行起來，很容易管理上萬臺服務器，速度夠快；
Ansible 適用于批量操作系統(tǒng)配置、批量程序的部署、批量運行命令等；
下面是兩個常用的開源監(jiān)控系統(tǒng)：
1）Nagios是一款免費的開源IT基礎設施監(jiān)控系統(tǒng)，其功能強大，靈活性強，能有效監(jiān)控 Windows 、Linux、VMware 和 Unix 主機狀態(tài)，交換機、路由器等網(wǎng)絡設備的網(wǎng)絡設置等。
一旦主機或服務狀態(tài)出現(xiàn)異常時，會發(fā)出郵件或短信報警第一時間通知 IT 運維人員，在狀態(tài)恢復后發(fā)出正常的郵件或短信通知。
優(yōu)缺點分析：優(yōu)點是配置靈活、監(jiān)控項目很多、自動日志滾動、支持冗余方式主機監(jiān)控、報警設置多樣性。
缺點是事件控制臺功能較弱、無法查看歷史數(shù)據(jù)、插件易用性不好。
2）Zabbix 是一個基于WEB界面的提供分布式系統(tǒng)監(jiān)視以及網(wǎng)絡監(jiān)視功能的企業(yè)級的開源解決方案。
用于監(jiān)控網(wǎng)絡上的服務器或服務以及其他網(wǎng)絡設備狀態(tài)的網(wǎng)絡管理系統(tǒng)，后臺基于C，前臺由PHP編寫，可與多種數(shù)據(jù)庫搭配使用，提供各種實時報警機制。
優(yōu)缺點分析：優(yōu)點是企業(yè)級開源、功能強大、入門容易、數(shù)據(jù)可以圖形的方式呈現(xiàn)、提供多種API接口，可定制化開發(fā)。
缺點是深層次需求開發(fā)難度較大、報警設置復雜、缺少數(shù)據(jù)匯總功能、數(shù)據(jù)報表需要二次開發(fā)。
Nagios 適用于IT基礎設施的監(jiān)控系統(tǒng)，其功能強大，靈活性強，能有效監(jiān)控各種操作系統(tǒng)的主機、交換路由設備等；
Zabbix提供分布式系統(tǒng)監(jiān)視以及網(wǎng)絡監(jiān)視功能，用于監(jiān)控網(wǎng)絡上的服務器，服務以及其他網(wǎng)絡設備狀態(tài)的網(wǎng)絡管理系統(tǒng)。
以上這五種工具都是開源的，運維人員可以根據(jù)企業(yè)的規(guī)模、業(yè)務需要、所要實現(xiàn)的運維功能等要求使用多種工具組合，發(fā)揮運維與監(jiān)控工具各自的優(yōu)勢。
工具的使用需要人工的干預和決策，工具不能完全代替全部運維工作。還需要結(jié)合實際業(yè)務邏輯和業(yè)務場景，把工具與業(yè)務融合到一起。例如，按業(yè)務要求對工具進行二次開發(fā)，更好的發(fā)揮運維與監(jiān)控工具的優(yōu)勢，提升運維人員工作效率。
4.3 Saltstack 實現(xiàn)服務器部署的自動化
Saltstack 在企業(yè)中實現(xiàn)服務器部署的自動化運維，saltstack 是基于 python 開發(fā)的一套 C/S 架構(gòu)配置管理工具，它的底層使用 zeroMQ 消息隊列pub/sub方式通信，使用SSL證書簽發(fā)的方式進行認證管理。
salt我們選擇了0.16.0版，該版中加入了multi-masterr 特性，在這種架構(gòu)下所有的 minion 將連接到所有配置的master上去。
當一個master出現(xiàn)故障可以使用其余的master繼續(xù)提供服務，不會影響我們的正常使用，saltstack架構(gòu)如下圖：
Saltstack在企業(yè)中的部署步驟： 1、確定saltstack軟件依賴關系是否滿足要求：saltstack要求python的版本大于2.6或小于3.0，還需要檢查以下的庫，包括 msgpack-python、yaml、jinja2、markupsafe、apache-libcloud、requests等。
2、安裝 master 和 minions：我這里服務器的操作系統(tǒng)是centos的，安裝命令如下：
Wget http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpmyum install salt-masteryum install salt-minion注：安裝成功，顯示Complete。
3、創(chuàng)建一個 master 服務的備份節(jié)點并復制主 master 節(jié)點的 key 到備節(jié)點：
Master:-saltmaster1.cccxht.com-saltmaster2.cccxht.com
默認的master的private key是在目錄：
/etc/salt/pki/master.
將該目錄下的 master.pem 拷貝到備 master 節(jié)點的同一位置，對 master 的public key 文件 master.pub 做同樣的操作，啟用備master節(jié)點，在備節(jié)點接受key。
4、重啟minions：配置完成后，minion將會對主master和備master進行核對，并且兩個master都對minion有操作權限。
注：minion可以自動檢測失敗的master，并且嘗試重連到一個更快的master，將minion端的參數(shù)master_alive_interval 設置為true，即可開啟該功能。
5、saltstack 狀態(tài)文件的編寫，saltstack上線后，運維工作從復雜的重復的服務器部署和配置工作轉(zhuǎn)移到saltstack狀態(tài)文件的編寫和維護，狀態(tài)文件的編寫要考慮模塊化和通用性，在大批量部署之前要經(jīng)過測試，沒有問題后再部署，以下是一些經(jīng)常用到的測試命令：
（1）查詢網(wǎng)絡連接情況—是否能連接到客戶端
（2）查詢網(wǎng)卡ip
（3）查詢磁盤空間
還有很多經(jīng)常用到的命令在此就不一一列舉了，Saltstack 可以實現(xiàn)云計算與數(shù)據(jù)中心架構(gòu)編排，Saltstack可以由 zabbix 監(jiān)控事件調(diào)用。
通過Saltstack的 salt-cloud 實現(xiàn)對 docker 和 openstack 等云平臺的支持，配合 saltstack 的mine 實時發(fā)現(xiàn)功能就可以實現(xiàn)各種云平臺業(yè)務自動擴展；
Saltstack可以與CMDB相結(jié)合實現(xiàn)運維平臺化、自動化和智能化。
5.自動化運維方案設計
5.1自動化運維規(guī)劃圖
提到自動化運維就不能不說ITIL，ITIL即信息技術基礎架構(gòu)庫(Information Technology Infrastructure Library)，主要適用于IT服務管理（ITSM）。
ITIL為企業(yè)的IT服務管理實踐提供了一個客觀、嚴謹、可量化的標準和規(guī)范。
ITIL已經(jīng)成為了IT服務管理的國際標準，而CMDB配置管理數(shù)據(jù)庫（Configuration Management Database）則是實現(xiàn)ITIL最重要的內(nèi)容。
隨著企業(yè)的發(fā)展，對于運維要求越來越高，使用現(xiàn)有的開源工具已經(jīng)不能滿足企業(yè)對于運維的要求，根據(jù)企業(yè)業(yè)務的發(fā)展與對運維的要求建設統(tǒng)一的運維管理平臺成為了企業(yè)迫切的需求。
下面是企業(yè)自動化運維總體規(guī)劃圖：
自動化運維平臺的建設以ITIL標準為依據(jù)，按照先底層后高層的原則先建設服務工具區(qū)域的各個運維子系統(tǒng)，各個運維子系統(tǒng)通過API的方式對上層提供服務，
最后不同的業(yè)務平臺去調(diào)用這些服務接口即可，運維平臺的各個層面建設要全面符合管理制度的要求。
5.2 自動化運維平臺模塊設計
自動化運維平臺以ITIL標準為依據(jù)在此規(guī)范上開發(fā)的，第一階段已經(jīng)做到了業(yè)務流程的標準化，現(xiàn)階段從事件管理子系統(tǒng)開始逐漸完善各個子系統(tǒng)，把各種配置當作服務來看待。
CMDB也可以理解成統(tǒng)一的元數(shù)據(jù)庫，比如說機房信息、服務器信息、人員信息、服務信息、業(yè)務信息以及他們之間的物理和業(yè)務拓撲關系等。
上層的所有系統(tǒng)都應該關聯(lián)到CMDB，以CMDB為中心，變更后的數(shù)據(jù)信息必須實時反饋到CMDB中，各個運維子系統(tǒng)才能看到最新的數(shù)據(jù)信息，確保其他系統(tǒng)能同步這份變更，以達到統(tǒng)一同步的目的。
因此把CMDB系統(tǒng)當作運維的核心系統(tǒng)來對待，有利于后續(xù)各個系統(tǒng)之間的互通。以下是部分模塊的設計要求：
事件管理：負責記錄、歸類和安排專家處理事故并監(jiān)督整個處理過程直至事故得到解決和終止。
事件管理的目的是在盡可能最小地影響客戶和用戶業(yè)務的情況下使IT系統(tǒng)恢復到SLA服務級別協(xié)議（Service-Level Agreement）所定義的服務級別；
問題與日志管理：通過調(diào)查和分析 IT 基礎架構(gòu)的薄弱環(huán)節(jié)、查明事故產(chǎn)生的原因，并制定解決事故的方案和防止事故再次發(fā)生的措施，將由于問題和事故對業(yè)務產(chǎn)生的負面影響減小到最低的服務管理流程。
在問題管理這部分要做好問題處理過程的日志的功能，對于問題的處理提供查詢的功能，可以追蹤問題以防止類似問題再次發(fā)生。
變更管理：在最短的時間窗口內(nèi)完成基礎架構(gòu)或服務的變更而對其進行控制的服務管理流程。
變更管理的目標是確保在變更實施過程中使用標準的方法和步驟，盡快地實施變更，以將由變更所導致的業(yè)務中斷對業(yè)務的影響減小到最低。
可行性管理：通過分析用戶和業(yè)務系統(tǒng)的可行性需求并據(jù)以優(yōu)化和設計IT基礎架構(gòu)的可行性，從而確保以合理的成本滿足不斷增長的可行性需求的管理流程。
可行性管理是一個前瞻性的管理流程，它通過對業(yè)務和用戶可行性需求的定位，使得IT服務的設計建立在真實需求的基礎上，從而避免IT服務運作中采用了過度的可行性級別，節(jié)約了IT服務的運作成本。
突發(fā)事件：分析業(yè)務系統(tǒng)的運行狀況和已經(jīng)發(fā)生過的問題日志，掌握系統(tǒng)常規(guī)問題發(fā)生的根源、對于突發(fā)事件做到規(guī)范化的處理流程。
及時發(fā)現(xiàn)、及時解決，強化監(jiān)控監(jiān)管、技術、備件備品、應急措施、方案、策略等相結(jié)合的辦法避免和及時的解決突發(fā)事件。
自動化運維平臺是面向業(yè)務的調(diào)度平臺，平臺以業(yè)務為導向協(xié)調(diào)各個子系統(tǒng)，指揮底層各個子系為它服務。
自動化運維平臺的建設是一個循序漸進的過程，根據(jù)業(yè)務和運維的需要不斷的測試和改進才能從根本上改變運維現(xiàn)狀，提升運維工作效率，最終實現(xiàn)自動化運維。
6. 企業(yè)自動化運維方案總結(jié)
企業(yè)的運維工作經(jīng)歷了從最開始的全部人工操作，到后來的大部分人工操作少部分自動化，到現(xiàn)在的自動化運維的過程。
在沒有建設運維平臺之前，一個新業(yè)務上線，需要做很多操作，例如DNS變更、LVS變更、OS初始化、自動化測試、持續(xù)部署、持續(xù)反饋、監(jiān)控、業(yè)務調(diào)用關系配置等等。
現(xiàn)在新業(yè)務上線只需要簡單的配置，剩余的工作由平臺協(xié)調(diào)自動完成上線。
使用自動化運維平臺后用戶滿意度從33%上升到95%，同時期IT費用營收占比從4%下降到2.4%。
通過建設自動化運維平臺實現(xiàn)了對業(yè)務流程的有效梳理，有效的了解現(xiàn)有的IT資源、運行狀況、可靠性與可用性，使企業(yè)從全局掌握IT資源和資產(chǎn)的詳細信息，為企業(yè)的決策提供了有力的支撐；
通過建設自動化運維平臺提高了運維工作效率，以前有很多需要人工參與處理的故障和事件，現(xiàn)在絕大部分由運維平臺自動按預定的規(guī)則進行處理，在運維響應時間上有了很大的提升；
通過建設自動化運維平臺發(fā)現(xiàn)潛在的問題，降低了故障率，運維人員再也不是以前的“救火”隊員了，一些潛在的問題在萌芽階段就被發(fā)現(xiàn)和處理了，避免了故障造成的業(yè)務中斷；
通過建設自動化運維平臺有利于故障的快速恢復，通過對以往時間點配置的保存建立配置基準快照，然后根據(jù)出現(xiàn)故障前后的配置基準的比對快速的發(fā)現(xiàn)故障的線索和根源，及時找到故障處理辦法恢復系統(tǒng)運行。
相關案例：
