智能化IT運維管理平臺方案建議書

1、智能化 IT 運維管理平臺方案建議書1. 企業(yè)運維現(xiàn)狀與開展趨勢隨著企業(yè)信息化的不斷開展，運維人員需要面對越來越復(fù)雜的業(yè) 務(wù)和 越來越多樣化的用戶需求，不斷擴展的應(yīng)用需要越來越合理的模 式來保障 運維效勞能靈活便捷、平安穩(wěn)定地持續(xù)。某企業(yè)從初期的幾臺效勞器開展到龐大的數(shù)據(jù)中心， 單靠人工已 經(jīng)無 法滿足在技術(shù)、業(yè)務(wù)、管理等方面的要求，那么標(biāo)準(zhǔn)化、自動化、 架構(gòu)優(yōu) 化、過程優(yōu)化等降低運維效勞本錢的因素越來越被人們所重 視。其中，自動化開始代替人工操作在企業(yè)的運維過程中逐漸表達出 來了 強大的優(yōu)勢。運維隨著企業(yè)業(yè)務(wù)的開展，自動化作為其重要屬性之一已經(jīng)不僅 僅只 是代替人工操作，更重要的是深層探知和

2、全局分析，關(guān)注的是在 當(dāng)前條件 下如何實現(xiàn)性能與效勞最優(yōu)化，同時保障投資收益最大化。通過自動化運維能最大限度地在更少的維修時間內(nèi)實現(xiàn)運維目 標(biāo)，提 高運維效勞質(zhì)量。因此 ，對于越來越復(fù)雜的運維來說，將人工操作逐漸改變?yōu)樽詣踊芾硎且粋€重要開展趨勢。2. 企業(yè)運維存在的問題與需求某企業(yè)初期只有文件共享和郵件效勞等幾臺效勞器， 運維工作完中心全由人工操作，隨著企業(yè)的開展，新業(yè)務(wù)系統(tǒng)不斷上線企業(yè)、建設(shè)了 機房，運維工作還是以人工為主，但是這一階段增加了網(wǎng)絡(luò)管理 系統(tǒng)和環(huán) 境監(jiān)控系統(tǒng)，這兩個系統(tǒng)在一定程度上減輕了運維的工作 量，根本上實現(xiàn) 了運維的半自動化。企業(yè)在開展，運維工作量在不斷的增加，企業(yè)的運

3、維工作面臨以 下的 問題及需要解決：2.1 運維人員的工作效率與工作主動性需要提升在企業(yè)運維過程中，只有當(dāng)故障已經(jīng)發(fā)生并且造成業(yè)務(wù)影響時才 能發(fā) 現(xiàn)和著手處理，這種被動 救火不但使運維人員終日忙碌，也使 運維本身 質(zhì)量很難提高，導(dǎo)致 IT 部門和業(yè)務(wù)部門對運維效勞滿意度 都不咼。運維人員日常大局部時間和精力是處理一些簡單重復(fù)的問題，而且由于故障預(yù)警機制不完善，往往是故障發(fā)生后或報警后才會進行處理，使得運維人員的工作經(jīng)常是處于被動的狀態(tài)， 怎樣才能在故障發(fā) 生前及時 發(fā)現(xiàn)并把故障處理掉，使運維工作變被動為主動？2.2 需要建立一套高效的運維機制企業(yè)在運維管理過程中缺少自動化的運維管理模式， 沒有

4、明確的 運維 人員角色定義和責(zé)任劃分，使到問題出現(xiàn)后很難快速、準(zhǔn)確地找 到根本原 因，無法及時地找到相應(yīng)的人員進行修復(fù)和處理?；蛘呤窃趩栴}找到后缺乏流程化的故障處理機制， 而在處理問題 時不 但欠缺標(biāo)準(zhǔn)化的解決方案，也缺乏全面的跟蹤記錄，企業(yè)需要建 立一套高效的運維管理制度為運維工作提供方向和依據(jù)。2.3 缺乏高效的運維技術(shù)工具隨著信息化建設(shè)的深入，企業(yè)業(yè)務(wù)系統(tǒng)日趨復(fù)雜，各種各樣的網(wǎng) 絡(luò)設(shè) 備、效勞器、存儲設(shè)備、業(yè)務(wù)系統(tǒng)等讓運維人員難以沉著應(yīng)對， 即使加班 加點地維護、部署、管理也經(jīng)常會因設(shè)備出現(xiàn)故障而導(dǎo)致業(yè) 務(wù)的中斷，嚴(yán) 重影響企業(yè)的正常運轉(zhuǎn)。出現(xiàn)這些問題局部原因是企業(yè)缺乏事件監(jiān)控和診斷工具

5、等運維 技術(shù)工 具，因為在沒有高效的技術(shù)工具的支持下故障事件很難得到主 動、快速處 理。3. 業(yè)務(wù)流程標(biāo)準(zhǔn)化與健全運維管理制度3.1 實現(xiàn)業(yè)務(wù)流程標(biāo)準(zhǔn)化，為自動化運維打好根底 標(biāo)準(zhǔn)化是自動化運維的根底，想要實現(xiàn)標(biāo)準(zhǔn)化，首先識別各個運 維對象，然后我們?nèi)粘Ｗ龅乃羞\維工作都應(yīng)該是針對這些對象的運 維。如果運維操作脫離了對象，那就沒有任何意義。同樣，沒有理清 楚對象，運維自然不得章法。例如擴容，首先確定是效勞器的擴容， 還是應(yīng)用 的擴容，還是其它對象的擴容。你會發(fā)現(xiàn)，對象不同，擴容這個場景所實施的動作是完全不一樣 的。如果把效勞器的擴容套用到應(yīng)用的擴容上去， 必然會導(dǎo)致流程錯 亂。 同時對于對象理

6、解上的不一致，也會增加無謂的溝通本錢，造成 運維效率 低下。這種情況下的自動化運維不但不能提升效率， 還會越 自動越混亂。器的對像效勞器、交換機、機柜等硬件；識別這些物理對像的屬性，效勞 序列號、ip地址、廠商等信息;識別這些對像之間的關(guān)系，效勞器所在的機柜、接入哪個交換機 的哪 個接口了等信息。效勞器物理根底設(shè)施的標(biāo)準(zhǔn)化如下列圖 其它設(shè)備的標(biāo)準(zhǔn) 化以此類推：庫的表、視圖、存儲過程的標(biāo)準(zhǔn)化，表的字段名、值，索引等，表和視圖之間的關(guān)聯(lián)關(guān)系等。第三步是流程標(biāo)準(zhǔn)化，如備份、軟件升級、殺毒，新業(yè)務(wù)上線等流程的標(biāo)準(zhǔn)化，下列圖是現(xiàn)在的運維流程:手工操作診斷祝堪升咸川isfr 運行Th、騰本前端運維人扇杳閱

7、手工開啟、更蘇工單事件告警(x.升級X手工操作診斷&椽更自動化運維是基于流程化的框架，將事件與 IT流程相關(guān)聯(lián)，一 旦被 監(jiān)控系統(tǒng)發(fā)現(xiàn)性能超標(biāo)，超過預(yù)先配置的閥值或宕機，就會觸發(fā) 相關(guān)事件 以及事先定義好的流程，可自動啟動故障響應(yīng)和恢復(fù)機制。自動化工作平臺還可幫助運維人員完成日常的重復(fù)性工作， 提高 運 維效率，下列圖是實現(xiàn)自動化運維的流程圖：運維的自動化能夠預(yù)測故障、在故障發(fā)生前能夠報警，讓運維人 員把 故障消除在發(fā)生前，將所產(chǎn)生損失減到最低。由過去的手工執(zhí)行 轉(zhuǎn)為自動 化操作，從而減少乃至消除運維中的延遲，實現(xiàn) 零延時的運維。3.2建立完整、全面的運維管理制度，為自動化運維的實現(xiàn)保

8、駕護航運維制度的建立包括環(huán)境管理、資產(chǎn)管理、介質(zhì)管理、設(shè)備管理、監(jiān)控管理、管理、系統(tǒng)平安管理、惡意代碼防范管理、密碼管理、變更管理、備份與恢復(fù)管理、平安事件處置，應(yīng)急預(yù)案管理等制度。1. 運維管理制度是衡量運維工作的一把尺子， 完善的管理制度能 有 效的提升運維工作效率，日常工作以管理制度為依據(jù)，按規(guī)定的要 求和規(guī) 定的流程操作既快速又準(zhǔn)確；2. 全面的運維管理制度能在問題和故障還沒有出現(xiàn)， 沒有造成損 失前保障;就被及時的發(fā)現(xiàn)，從而問題得到有效的處理，業(yè)務(wù)連續(xù)性得到了3. 運維管理制度為運維工作提供了標(biāo)準(zhǔn)化的解決方案， 使運維人 員在 處理問題時有章可循快速找到問題的根本原因，把問題對業(yè)務(wù)造

9、 成的損失 降到最低；4. 運維管理制度是為業(yè)務(wù)效勞的，業(yè)務(wù)是不斷開展的，運維管理 制度 要跟得上業(yè)務(wù)的不斷開展實現(xiàn)管理制度的創(chuàng)新。4. 自動化運維技術(shù)路線選型4.1 自動化運維概述自動化運維范圍包括安裝自動化、部署自動化、監(jiān)控自動化、發(fā) 布自 動化、升級自動化、平安管控自動化、優(yōu)化自動化、數(shù)據(jù)備份自 動化等。自動化運維系統(tǒng)包括商用自動化運維系統(tǒng)、開源自動化運維系 統(tǒng)，自 建研發(fā)自動化運維系統(tǒng)。商業(yè)的運維系統(tǒng)在功能上要全面一些， 效勞支持上能好一些，更 新與 升級有保障，采購本錢較高，對運維人員的技術(shù)要求相對較低。開源運維系統(tǒng)更靈活一些，效勞支持需要運維人員自身多投入一 些時 間和精力，更新與

10、升級更個性化一些，相對本錢較低。自建自動 化運維系 統(tǒng)對人員的技術(shù)要求最高， 本錢也不低，但是當(dāng)企業(yè)開展到 一定規(guī)模后自 建的運維系統(tǒng)才能更適合企業(yè)對于自動化運維的要求。4.2 開源運維工具的應(yīng)用場景與優(yōu)勢1Puppet 是一個開源的軟件自動化配置和部署工具，它使用簡單 且 功能強大，很多大型 IT 公司均在使用 puppet 對集群中的軟件進 行管理和 部署。優(yōu)缺點分析：優(yōu)點是 Web 界面生成處理報表、資源清單、實時 節(jié)點管理， push 命令可即刻觸發(fā)變更；缺點是相對其他工具較復(fù)雜、 需學(xué)習(xí) Puppet 的 DSL 或 Ruby ，安 裝 過程缺少錯誤校驗和生成錯誤報表。2) Salt

11、Stack 是一種全新的根底設(shè)施管理方式， 部署輕松，在幾分 鐘 內(nèi)可以運行起來，擴展性好，很容易管理上萬臺效勞器，速度夠快， 效勞 器之間秒級通訊。優(yōu)缺點分析：優(yōu)點是可以使用簡單的配置模塊或復(fù)雜的腳本，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ā)、備管

12、節(jié)點不需要 安裝 代理軟件、有 Web 管理界面、安裝運行簡單；缺點是對 windows 備管節(jié)點需要加強、執(zhí)行效率相對較低。下列圖是 Puppet 、 Saltstack Ansible 這三款運維工具處理能力與處 理效率的比照：各種運維工具只是用于幫助人員進行運維的，每種工具都有其使 用的優(yōu)勢領(lǐng)域， Puppet 適用于軟件自動化配置和部署；SaltStack 適用于根底設(shè)施管理，在幾分鐘內(nèi)可運行起來，很容 易管理 上萬臺效勞器，速度夠快；Ansible 適用于批量操作系統(tǒng)配置、 批量程序的部署、 批量運行 命令等； 下面是兩個常用的開源監(jiān)控系統(tǒng)：1) Nagios 是一款免費的開源 IT

13、 根底設(shè)施監(jiān)控系統(tǒng)，其功能強大 , 靈 活性強，能有效監(jiān)控 Windows 、 Linux 、 VMware 和 Unix 主機 狀態(tài)，交換 機、路由器等網(wǎng)絡(luò)設(shè)備的網(wǎng)絡(luò)設(shè)置等。一旦主機或效勞狀態(tài)出現(xiàn)異常時，會發(fā)出郵件或報警第一時間通 知 IT 運維人員，在狀態(tài)恢復(fù)后發(fā)出正常的郵件或短信通知。優(yōu)缺點分析：優(yōu)點是配置靈活、監(jiān)控工程很多、自動日志滾動、 支持冗余方式主機監(jiān)控、報警設(shè)置多樣性。缺點是事件控制臺功能較弱、無法查看歷史數(shù)據(jù)、插件易用性不 好。2) Zabbix 是一個基于 WEB 界面的提供分布式系統(tǒng)監(jiān)視以及網(wǎng) 絡(luò)監(jiān) 視功能的企業(yè)級的開源解決方案。用于監(jiān)控網(wǎng)絡(luò)上的效勞器或效勞以及其他網(wǎng)絡(luò)設(shè)

14、備狀態(tài)的網(wǎng)絡(luò) 管理系 統(tǒng)，后臺基于 C, 前臺由 PHP 編寫，可與多種數(shù)據(jù)庫搭配使 用，提供各種 實時報警機制。優(yōu)缺點分析：優(yōu)點是企業(yè)級開源、功能強大、入門容易、數(shù)據(jù)可 以圖 形的方式呈現(xiàn)、提供多種 API 接口，可定制化開發(fā)。缺點是深層次需求開發(fā)難度較大、 報警設(shè)置復(fù)雜、 缺少數(shù)據(jù)匯總 功能、 數(shù)據(jù)報表需要二次開發(fā)。Nagios 適用于 IT 根底設(shè)施的監(jiān)控系統(tǒng)，其功能強大，靈活性強， 能 有效監(jiān)控各種操作系統(tǒng)的主機、交換路由設(shè)備等；Zabbix 提供分布式系統(tǒng)監(jiān)視以及網(wǎng)絡(luò)監(jiān)視功能，用于監(jiān)控網(wǎng)絡(luò)上 的服 務(wù)器，效勞以及其他網(wǎng)絡(luò)設(shè)備狀態(tài)的網(wǎng)絡(luò)管理系統(tǒng)。以上這五種工具都是開源的，運維人員可以根

15、據(jù)企業(yè)的規(guī)模、業(yè) 務(wù)需 要、所要實現(xiàn)的運維功能等要求使用多種工具組合，發(fā)揮運維與 監(jiān)控工具 各自的優(yōu)勢。工具的使用需要人工的干預(yù)和決策， 工具不能完全代替全部運維 工作。 還需要結(jié)合實際業(yè)務(wù)邏輯和業(yè)務(wù)場景， 把工具與業(yè)務(wù)融合到一 起。例如， 按業(yè)務(wù)要求對工具進行二次開發(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ā)的方式

16、進行認證管理。salt 我們選擇了 0.16.0 版，該版中參加了 multi-masterr 特性，在 這 種架構(gòu)下所有的 minion 將連接到所有配置的 master 上去。當(dāng)一個 master 出現(xiàn)故障可以使用其余的 master 繼續(xù)提供效勞， 不會 影響我們的正常使用， saltstack 架構(gòu)如下列圖：Saltstack 在企業(yè)中的部署步驟： 1 、確定 saltstack 軟件依賴關(guān)系 是 否滿足要求： saltstack 要求 python 的版本大于 2.6 或小于 3.0 ，還 需要檢查以下的庫，包括 msgpack-pythor 、 yaml 、 jinja2 、 ma

17、rkupsafe apache-libcloud 、 requests 等。2、安裝 master 和 minions : 我這里效勞器的操作系統(tǒng)是 centos 的， 安裝命令如下：Wget :/dow nl .no arc h.rpmyum in stall salt-masteryum in stall salt-mi nio n注 : 安裝成功，顯示 Complete 。3、創(chuàng)立一個 master 效勞的備份節(jié)點并復(fù)制主 master 節(jié)點的 key 到備節(jié)點：Master:-saltmaster1.cccxht -saltmaster2.cccxht 默認的 master 的 pri

18、vate key 是在 目錄： /etc/salt/pki/master.將該目錄下的 master.pem 拷貝到備 master 節(jié)點的同一位置，對 master 的 public key 文件 master.pub 做同樣的操作，啟用備 master節(jié)點，在備節(jié)點接受 key4、重啟 minions: 配置完成后， minion 將會對主 master 禾口備 master 進行核對，并且兩個 master 都對 minion 有操作權(quán)限。注： minion 可以自動檢測失敗的 master, 并且嘗試重連到一個更快的 master, 將 minion 端的參數(shù)master_alive_

19、interval 設(shè)置為 true ，即可開啟該功能。5、saltstack 狀態(tài)文件的編寫， saltstack 上線后，運維工作從復(fù)雜 的重復(fù)的效勞器部署和配置工作轉(zhuǎn)移到 saltstack 狀態(tài)文件的編寫和 維護，狀態(tài)文件的編寫要考慮模塊化和通用性， 在大批量部署之前要 經(jīng)過測試，沒有問題后再部署，以下是一些經(jīng)常用到的測試命令：1) 查詢網(wǎng)絡(luò)連接情況一是否能連接到客戶端rootce ntos sal t# salt '*' test.p in glocalhost:Trueserver.cccxht :True 2 查詢網(wǎng)卡 iprootce ntos /# salt &

20、#39;localhost' n etwork.i nterfaceslocalhost:ethO:hwaddr:08:00:27:59:a9:8dinet:192.168.151.255 -label: ethO-netmask: (3) 查詢磁盤空間rootce ntos tmp# salt 'localhost' disk.usagelocalhost: /: 1K-blocks: 28423128 available: 21572236 capacity: 25% filesystem: /dev/mapper/vg_ce ntos-lv_root used:5

21、406132還有很多經(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è)務(wù) 自動擴展；Saltstack 可以與 CMDB 相結(jié)合實現(xiàn)運維平臺化、自動化和智能 化。5?自動化運維方案設(shè)計5.1 自動化運維規(guī)劃圖提到自動化運維就不能不說 ITIL, ITIL 即信息技術(shù)根底架構(gòu)庫(In formati o

22、n Tech no logy In frastructure Library) ，主要適用于 IT 效勞 管 理( ITSM ) 。ITIL 為企業(yè)的 IT 效勞管理實踐提供了一個客觀、嚴(yán)謹、可量化 的標(biāo)準(zhǔn)和標(biāo)準(zhǔn)ITIL 已經(jīng)成為了 IT 效勞管理的國際標(biāo)準(zhǔn)，而 CMDB 配置管理數(shù) 據(jù) 庫Con figuration Ma nageme nt Database 那么是實現(xiàn) ITIL 最重要的 內(nèi) 容。隨著企業(yè)的開展，對于運維要求越來越高，使用現(xiàn)有的開源工具已經(jīng)不能滿足企業(yè)對于運維的要求， 根據(jù)企業(yè)業(yè)務(wù)的開展與對運維的要求建設(shè)統(tǒng)一的運維管理平臺成為了企業(yè)迫切的需求。自動化運維平臺的建設(shè)以 IT

23、IL 標(biāo)準(zhǔn)為依據(jù)，按照先底層后高層的原那么先建設(shè)效勞工具區(qū)域的各個運維子系統(tǒng)，各個運維子系統(tǒng)通過 API 的方 式對上層提供效勞，最后不同的業(yè)務(wù)平臺去調(diào)用這些效勞接口即可， 運維平臺的各個 層面建設(shè)要全面符合管理制度的要求。5.2 自動化運維平臺模塊設(shè)計自動化運維平臺以 ITIL 標(biāo)準(zhǔn)為依據(jù)在此標(biāo)準(zhǔn)上開發(fā)的，第一階 段已 經(jīng)做到了業(yè)務(wù)流程的標(biāo)準(zhǔn)化， 現(xiàn)階段從事件管理子系統(tǒng)開始逐漸 完善各個 子系統(tǒng)，把各種配置當(dāng)作效勞來看待。CMDB 也可以理解成統(tǒng)一的元數(shù)據(jù)庫，比方說機房信息、效勞 器信 息、人員信息、效勞信息、業(yè)務(wù)信息以及他們之間的物理和業(yè)務(wù) 拓撲關(guān)系上層的所有系統(tǒng)都應(yīng)該關(guān)聯(lián)到 CMDB ，

24、以 CMDB 為中心，變更 后的數(shù)據(jù)信息必須實時反應(yīng)到 CMDB 中，各個運維子系統(tǒng)才能看到 最新的數(shù)據(jù)信息，確保其他系統(tǒng)能同步這份變更，以到達統(tǒng)一同步的 目的。 因此把 CMDB 系統(tǒng)當(dāng)作運維的核心系統(tǒng)來對待，有利于后續(xù)各 個系 統(tǒng)之間的互通。以下是局部模塊的設(shè)計要求：事件管理：負責(zé)記錄、歸類和安排專家處理事故并監(jiān)督整個處理 過 程直至事故得到解決和終止。事件管理的目的是在盡可能最小地影響客戶和用戶業(yè)務(wù)的情況下使 IT 系統(tǒng)恢復(fù)到 SLA 效勞級別協(xié)議 ( Service-Level Agreement) 所 定義 的效勞級別；問題與日志管理：通過調(diào)查和分析 IT 根底架構(gòu)的薄弱環(huán)節(jié)、查 明

25、事 故產(chǎn)生的原因，并制定解決事故的方案和防止事故再次發(fā)生的措 施，將由 于問題和事故對業(yè)務(wù)產(chǎn)生的負面影響減小到最低的效勞管理 流程。在問題管理這局部要做好問題處理過程的日志的功能， 對于問題的處理提供查詢的功能，可以追蹤問題以防止類似問題再次發(fā)生。變更管理：在最短的時間窗口內(nèi)完成根底架構(gòu)或效勞的變更而對 其 進行控制的效勞管理流程。的可行變更管理的目標(biāo)是確保在變更實施過程中使用標(biāo)準(zhǔn)的方法和步 驟， 盡快地實施變更， 以將由變更所導(dǎo)致的業(yè)務(wù)中斷對業(yè)務(wù)的影響減 小到最低 可行性管理：通過分析用戶和業(yè)務(wù)系統(tǒng)的可行性需求并據(jù)以優(yōu)化 和 設(shè)計 IT 根底架構(gòu)的可行性，從而確保以合理的本錢滿足不斷增長 性需求的管理流程?？尚行怨芾硎且粋€前瞻性的管理流程， 它通過對業(yè)務(wù)和用戶可行 性 需求的定位，使得 IT 效勞的設(shè)計建立在真實需求的根底上，從而 防止 IT 效勞運作中采用了過度的可行性級別， 節(jié)約了 IT 效勞的運作 本錢。突發(fā)事件：分析業(yè)