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