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