知識星球來自：talkwithtrend（微訊號：talkwithtrend）
1.企業運維現狀與發展趨勢
隨著企業資訊化的不斷發展，運維人員需要面對越來越複雜的業務和越來越多樣化的使用者需求，不斷擴充套件的應用需要越來越合理的樣式來保障運維服務能靈活便捷、安全穩定地持續。某企業從初期的幾臺伺服器發展到龐大的資料中心，單靠人工已經無法滿足在技術、業務、管理等方面的要求，那麼標準化、自動化、架構最佳化、過程最佳化等降低運維服務成本的因素越來越被人們所重視。其中，自動化開始代替人工操作在企業的運維過程中逐漸體現出來了強大的優勢。
運維隨著企業業務的發展，自動化作為其重要屬性之一已經不僅僅只是代替人工操作，更重要的是深層探知和全域性分析，關註的是在當前條件下如何實現效能與服務最最佳化，同時保障投資收益最大化。透過自動化運維能最大限度地在更少的維修時間內實現運維標的，提高運維服務質量。因此, 對於越來越複雜的運維來說，將人工操作逐漸改變為自動化管理是一個重要發展趨勢。
2.企業運維存在的問題與需求
某企業初期只有檔案共享和郵件服務等幾臺伺服器，運維工作完全由人工操作，隨著企業的發展，新業務系統不斷上線企業建設了中心機房，運維工作還是以人工為主，但是這一階段增加了網路管理系統和環境監控系統，這兩個系統在一定程度上減輕了運維的工作量，基本上實現了運維的半自動化。企業在發展，運維工作量在不斷的增加，企業的運維工作面臨以下的問題及需要解決：
2.1運維人員的工作效率與工作主動性需要提升
在企業運維過程中，只有當故障已經發生並且造成業務影響時才能發現和著手處理，這種被動“救火”不但使運維人員終日忙碌，也使運維本身質量很難提高，導致IT部門和業務部門對運維服務滿意度都不高。運維人員日常大部分時間和精力是處理一些簡單重覆的問題，而且由於故障預警機制不完善，往往是故障發生後或報警後才會進行處理，使得運維人員的工作經常是處於被動的狀態，怎樣才能在故障發生前及時發現並把故障處理掉，使運維工作變被動為主動？
2.2需要建立一套高效的運維機制
企業在運維管理過程中缺少自動化的運維管理樣式，沒有明確的運維人員角色定義和責任劃分，使到問題出現後很難快速、準確地找到根本原因，無法及時地找到相應的人員進行修複和處理，或者是在問題找到後缺乏流程化的故障處理機制，而在處理問題時不但欠缺規範化的解決方案，也缺乏全面的跟蹤記錄，企業需要建立一套高效的運維管理制度為運維工作提供方向和依據。
2.3缺乏高效的運維技術工具
隨著資訊化建設的深入，企業業務系統日趨複雜，各種各樣的網路裝置、伺服器、儲存裝置、業務系統等讓運維人員難以從容應對，即使加班加點地維護、部署、管理也經常會因裝置出現故障而導致業務的中斷，嚴重影響企業的正常運轉。出現這些問題部分原因是企業缺乏事件監控和診斷工具等運維技術工具，因為在沒有高效的技術工具的支援下故障事件很難得到主動、快速處理。
3.業務流程標準化與健全運維管理制度
3.1實現業務流程標準化，為自動化運維打好基礎
標準化是自動化運維的基礎，想要實現標準化，首先識別各個運維物件，然後我們日常做的所有運維工作都應該是針對這些物件的運維。如果運維操作脫離了物件，那就沒有任何意義。同樣，沒有理清楚物件，運維自然不得章法。例如擴容，首先確定是伺服器的擴容，還是應用的擴容，還是其它物件的擴容。你會發現，物件不同，擴容這個場景所實施的動作是完全不一樣的。如果把伺服器的擴容套用到應用的擴容上去，必然會導致流程錯亂。同時對於物件理解上的不一致，也會增加無謂的溝通成本，造成運維效率低下。這種情況下的自動化運維不但不能提升效率，還會越自動越混亂。
實現標準化的第一步是物理基礎設施的標準化，例如，識別物理對像伺服器、交換機、機櫃等硬體；識別這些物理對像的屬性，伺服器的序列號、ip地址、廠商等資訊；識別這些對像之間的關係，伺服器所在的機櫃、接入哪個交換機的哪個介面了等資訊。伺服器物理基礎設施的標準化如下圖（其它裝置的標準化以此類推）：
第二步是應用的標準化，應用服務、中介軟體，資料庫等；例如，資料庫的表、檢視、儲存過程的標準化，表的欄位名、值，索引等，表和檢視之間的關聯關係等。
第三步是流程標準化，如備份、軟體升級、防毒，新業務上線等流程的標準化，下圖是現在的運維流程：
自動化運維是基於流程化的框架，將事件與IT流程相關聯，一旦被監控系統發現效能超標，超過預先配置的閥值或宕機，就會觸發相關事件以及事先定義好的流程，可自動啟動故障響應和恢復機制。自動化工作平臺還可幫助運維人員完成日常的重覆性工作，提高運維效率，下圖是實現自動化運維的流程圖：
運維的自動化能夠預測故障、在故障發生前能夠報警，讓運維人員把故障消除在發生前，將所產生損失減到最低。由過去的手工執行轉為自動化操作，從而減少乃至消除運維中的延遲，實現“零延時”的運維。
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適用於批次作業系統配置、批次程式的部署、批次執行命令等。
下麵是兩個常用的開源監控系統：
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等。
3、建立一個master服務的備份節點並複製主master節點的key到備節點：
預設的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資源和資產的詳細資訊，為企業的決策提供了有力的支撐；
透過建設自動化運維平臺提高了運維工作效率，以前有很多需要人工參與處理的故障和事件，現在絕大部分由運維平臺自動按預定的規則進行處理，在運維響應時間上有了很大的提升；
透過建設自動化運維平臺發現潛在的問題，降低了故障率，運維人員再也不是以前的“救火”隊員了，一些潛在的問題在萌芽階段就被髮現和處理了，避免了故障造成的業務中斷；
透過建設自動化運維平臺有利於故障的快速恢復，透過對以往時間點配置的儲存建立配置基準快照，然後根據出現故障前後的配置基準的比對快速的發現故障的線索和根源，及時找到故障處理辦法恢復系統執行。
聶奎甲：十餘年工作經驗，主要參與政府、電力、國土等行業的系統整合專案，包括主機儲存、oracle資料庫，精通計算機網路與安全。
●編號228，輸入編號直達本文
●輸入m獲取文章目錄
Linux學習
更多推薦《18個技術類微信公眾號》
涵蓋：程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。
