1.企業運維現狀與發展趨勢
随着企業資訊化的不斷發展，運維人員需要面對越來越複雜的業務和越來越多樣化的使用者需求，不斷擴充的應用需要越來越合理的模式來保障運維服務能靈活便捷、安全穩定地持續。某企業從初期的幾台伺服器發展到龐大的資料中心，單靠人工已經無法滿足在技術、業務、管理等方面的要求，那麼标準化、自動化、架構優化、過程優化等降低運維服務成本的因素越來越被人們所重視。其中，自動化開始代替人工操作在企業的運維過程中逐漸展現出來了強大的優勢。
運維随着企業業務的發展，自動化作為其重要屬性之一已經不僅僅隻是代替人工操作，更重要的是深層探知和全局分析，關注的是在目前條件下如何實作性能與服務最優化，同時保障投資收益最大化。通過自動化運維能最大限度地在更少的維修時間内實作運維目标，提高運維服務品質。是以, 對于越來越複雜的運維來說，将人工操作逐漸改變為自動化管理是一個重要發展趨勢。
2.企業運維存在的問題與需求
某企業初期隻有檔案共享和郵件服務等幾台伺服器，運維工作完全由人工操作，随着企業的發展，新業務系統不斷上線企業建設了中心機房，運維工作還是以人工為主，但是這一階段增加了網絡管理系統和環境監控系統，這兩個系統在一定程度上減輕了運維的工作量，基本上實作了運維的半自動化。企業在發展，運維工作量在不斷的增加，企業的運維工作面臨以下的問題及需要解決：
2.1運維人員的工作效率與工作主動性需要提升
在企業運維過程中，隻有當故障已經發生并且造成業務影響時才能發現和着手處理，這種被動“救火”不但使運維人員終日忙碌，也使運維本身品質很難提高，導緻IT部門和業務部門對運維服務滿意度都不高。運維人員日常大部分時間和精力是處理一些簡單重複的問題，而且由于故障預警機制不完善，往往是故障發生後或報警後才會進行處理，使得運維人員的工作經常是處于被動的狀态，怎樣才能在故障發生前及時發現并把故障處理掉，使運維工作變被動為主動？
2.2需要建立一套高效的運維機制
企業在運維管理過程中缺少自動化的運維管理模式，沒有明确的運維人員角色定義和責任劃分，使到問題出現後很難快速、準确地找到根本原因，無法及時地找到相應的人員進行修複和處理，或者是在問題找到後缺乏流程化的故障處理機制，而在處理問題時不但欠缺規範化的解決方案，也缺乏全面的跟蹤記錄，企業需要建立一套高效的運維管理制度為運維工作提供方向和依據。
2.3缺乏高效的運維技術工具
随着資訊化建設的深入，企業業務系統日趨複雜，各種各樣的網絡裝置、伺服器、儲存設備、業務系統等讓運維人員難以從容應對，即使加班加點地維護、部署、管理也經常會因裝置出現故障而導緻業務的中斷，嚴重影響企業的正常運轉。出現這些問題部分原因是企業缺乏事件監控和診斷工具等運維技術工具，因為在沒有高效的技術工具的支援下故障事件很難得到主動、快速處理。
3.業務流程标準化與健全運維管理制度
3.1實作業務流程标準化，為自動化運維打好基礎
标準化是自動化運維的基礎，想要實作标準化，首先識别各個運維對象，然後我們日常做的所有運維工作都應該是針對這些對象的運維。如果運維操作脫離了對象，那就沒有任何意義。同樣，沒有理清楚對象，運維自然不得章法。例如擴容，首先确定是伺服器的擴容，還是應用的擴容，還是其它對象的擴容。你會發現，對象不同，擴容這個場景所實施的動作是完全不一樣的。如果把伺服器的擴容套用到應用的擴容上去，必然會導緻流程錯亂。同時對于對象了解上的不一緻，也會增加無謂的溝通成本，造成運維效率低下。這種情況下的自動化運維不但不能提升效率，還會越自動越混亂。
實作标準化的第一步是實體基礎設施的标準化，例如，識别實體對像伺服器、交換機、機櫃等硬體；識别這些實體對像的屬性，伺服器的序列号、ip位址、廠商等資訊；識别這些對像之間的關系，伺服器所在的機櫃、接入哪個交換機的哪個接口了等資訊。伺服器實體基礎設施的标準化如下圖（其它裝置的标準化以此類推）：
第二步是應用的标準化，應用服務、中間件，資料庫等；例如，資料庫的表、視圖、存儲過程的标準化，表的字段名、值，索引等，表和視圖之間的關聯關系等。
第三步是流程标準化，如備份、軟體更新、殺毒，新業務上線等流程的标準化，下圖是現在的運維流程：
運維的自動化能夠預測故障、在故障發生前能夠報警，讓運維人員把故障消除在發生前，将所産生損失減到最低。由過去的手工執行轉為自動化操作，進而減少乃至消除運維中的延遲，實作“零延時”的運維。
3.2建立完整、全面的運維管理制度，為自動化運維的實作保駕護航
運維制度的建立包括環境管理、資産管理、媒體管理、裝置管理、監控管理、網絡安全管理、系統安全管理、惡意代碼防範管理、密碼管理、變更管理、備份與恢複管理、安全事件處置，應急預案管理等制度。
1)運維管理制度是衡量運維工作的一把尺子，完善的管理制度能有效的提升運維工作效率，日常工作以管理制度為依據，按規定的要求和規定的流程操作既快速又準确；
2)全面的運維管理制度能在問題和故障還沒有出現沒有造成損失前就被及時的發現，進而問題得到有效的處理，業務連續性得到了保障；
3)運維管理制度為運維工作提供了規範化的解決方案，使運維人員在處理問題時有章可循快速找到問題的根本原因，把問題對業務造成的損失降到最低；
4)運維管理制度是為業務服務的，業務是不斷發展的，運維管理制度要跟得上業務的不斷發展實作管理制度的創新。
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适用于批量作業系統配置、批量程式的部署、批量運作指令等。
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服務的備份節點并複制主master節點的key到備節點：
預設的master的private key是在目錄：/etc/salt/pki/master. 将該目錄下的master.pem拷貝到備master節點的同一位置，對master的public key檔案master.pub做同樣的操作，啟用備master節點，在備節點接受key。
3、重新開機minions：配置完成後，minion将會對主master和備master進行核對，并且兩個master都對minion有操作權限。
注：minion可以自動檢測失敗的master，并且嘗試重連到一個更快的master，将minion端的參數master_alive_interval 設定為true，即可開啟該功能。
4、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資源和資産的詳細資訊，為企業的決策提供了有力的支撐；
通過建設自動化運維平台提高了運維工作效率，以前有很多需要人工參與處理的故障和事件，現在絕大部分由運維平台自動按預定的規則進行處理，在運維響應時間上有了很大的提升；
通過建設自動化運維平台發現潛在的問題，降低了故障率，運維人員再也不是以前的“救火”隊員了，一些潛在的問題在萌芽階段就被發現和處理了，避免了故障造成的業務中斷；
通過建設自動化運維平台有利于故障的快速恢複，通過對以往時間點配置的儲存建立配置基準快照，然後根據出現故障前後的配置基準的比對快速的發現故障的線索和根源，及時找到故障處理辦法恢複系統運作。