[原創(chuàng)]ITSM系統(tǒng)的建設(shè)

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

破子

這是我一直想寫的內(nèi)容，苦于沒(méi)有時(shí)間與精力，本來(lái)是希望把這個(gè)項(xiàng)目從立項(xiàng)到規(guī)劃，到設(shè)計(jì)開(kāi)發(fā)，到最后的實(shí)施應(yīng)用的全部過(guò)程寫成一個(gè)筆記，但工程浩大，有些力不從心，正好國(guó)慶節(jié)有一些時(shí)間，就先寫一部份吧。以下的內(nèi)容會(huì)一些雜，我把我們規(guī)劃這款I(lǐng)TSM系統(tǒng)的一些想法寫出來(lái)，里面會(huì)夾雜著我對(duì)這種類型系統(tǒng)的一些規(guī)劃考慮點(diǎn)，這種考慮一是基本對(duì)ITIL的理解，二是對(duì)軟件實(shí)現(xiàn)的理解，三是運(yùn)維管理的考量。內(nèi)容不會(huì)十分具體，因?yàn)槊恳粋€(gè)部份基本都是一個(gè)模塊，如果寫得深入，基本是一個(gè)詳細(xì)的設(shè)計(jì)說(shuō)明書(shū)了，這就沒(méi)有必要了。這是第一次真正的去思考規(guī)劃與設(shè)計(jì)一個(gè)系統(tǒng)，這里說(shuō)的設(shè)計(jì)可能與軟件工程的設(shè)計(jì)定義有一些區(qū)別。以前都是做軟件實(shí)施，現(xiàn)在終于有機(jī)會(huì)把在做軟件實(shí)施時(shí)的一些想法前移到設(shè)計(jì)階段，因?yàn)檫@個(gè)項(xiàng)目的規(guī)劃與實(shí)施都會(huì)是我負(fù)責(zé)，所以是把首尾相連了，這也相對(duì)可以保證規(guī)劃的思想可以比較徹底的貫徹下去?？赡艽嬖诘膯?wèn)題是，后續(xù)的一些設(shè)計(jì)過(guò)程，我沒(méi)有非常深入進(jìn)去了，這樣會(huì)導(dǎo)致一些缺失，另一方面，許多在規(guī)劃的想法是會(huì)對(duì)公司的體制與管理制度造成一定沖擊的，可能到時(shí)沒(méi)有足夠的時(shí)間與決策支持去扭轉(zhuǎn)當(dāng)前的作業(yè)現(xiàn)狀，最后就是對(duì)開(kāi)發(fā)團(tuán)隊(duì)的實(shí)現(xiàn)能力有一些擔(dān)心，一個(gè)好的想法開(kāi)發(fā)人員沒(méi)有足夠的技術(shù)能力去實(shí)現(xiàn)，這也是比較麻煩的?？偟膩?lái)說(shuō)，這項(xiàng)目要想取得我預(yù)計(jì)中的效果，非常具有挑戰(zhàn)性。一、系統(tǒng)目標(biāo)系統(tǒng)目標(biāo)是為了說(shuō)明我們想開(kāi)發(fā)一個(gè)怎樣的系統(tǒng)，想利用這個(gè)系統(tǒng)做什么，達(dá)到怎樣的目的，最簡(jiǎn)單的是，我們想打造一個(gè)運(yùn)維平臺(tái)，把我們?cè)诟鱾€(gè)地區(qū)分布的運(yùn)維服務(wù)團(tuán)隊(duì)，無(wú)論屬于哪一個(gè)客戶群的，無(wú)論是屬于哪一種業(yè)務(wù)領(lǐng)域的（桌面、網(wǎng)絡(luò)、系統(tǒng)、軟件）都統(tǒng)一納入到一個(gè)相同的平臺(tái)上作用，他們要基于相同的制度，基于相同的流程，基于相同的理念，用統(tǒng)一術(shù)語(yǔ)與方式去服務(wù)客戶，我們的一個(gè)優(yōu)勢(shì)是規(guī)模與平臺(tái)資源，但如果我們的人員與業(yè)務(wù)無(wú)法整合到一起，這種優(yōu)勢(shì)就不復(fù)存在的，反而可能成為一個(gè)負(fù)面原因，因?yàn)槟銢](méi)有了大船的承載能力，卻也沒(méi)有小船的靈活轉(zhuǎn)身能力。運(yùn)維服務(wù)業(yè)務(wù)有其特點(diǎn)，因?yàn)楹茈y標(biāo)準(zhǔn)化，同時(shí)太容易受客戶的影響而改變流程或制度了，一旦你的團(tuán)隊(duì)分散，客戶多，而且地理分散后，說(shuō)光依靠發(fā)布出ISO20000的體系文件，對(duì)人員做多么扎實(shí)的培訓(xùn)，這樣就能把大家的各種作業(yè)規(guī)范統(tǒng)一起來(lái)，不是說(shuō)不可能，極難，要花費(fèi)巨大的管理資源，同時(shí)這樣做的一個(gè)問(wèn)題是你的運(yùn)維服務(wù)數(shù)據(jù)是極難進(jìn)行分析與采集的，這時(shí)一個(gè)顯而易見(jiàn)的方式就是利用軟件。我們?cè)诖蛟熳砸训钠脚_(tái)時(shí)，概括來(lái)說(shuō)對(duì)這個(gè)平臺(tái)有這么一些幾個(gè)方面要求：設(shè)計(jì)要求要基于我們的運(yùn)維服務(wù)業(yè)務(wù)特點(diǎn)，同時(shí)把這幾年我們做管理探索與改善的經(jīng)驗(yàn)置入其中，另一個(gè)方面要把ISO20000在實(shí)施過(guò)程的所得納入實(shí)現(xiàn)，這里就是我們的服務(wù)體系了，但只是取部份流程的，主要是針對(duì)服務(wù)支持等部份的流程，還有一個(gè)方面就是要參考REMEDY優(yōu)缺點(diǎn)。這三個(gè)方面是我們規(guī)劃設(shè)計(jì)這系統(tǒng)的主要基礎(chǔ)，加上我們對(duì)遠(yuǎn)景的期望，基本上這三個(gè)方面我們都做了一些調(diào)研與整理工作。范圍要求我們所有的運(yùn)維服務(wù)業(yè)務(wù)，我們所有的運(yùn)維服務(wù)人員，以及運(yùn)維服務(wù)中的所有活動(dòng)都需要可以被管理，也可以分這么兩個(gè)層面來(lái)說(shuō)，我們這個(gè)平臺(tái)要可以管理所有的運(yùn)維對(duì)象（各種類型的項(xiàng)目），同時(shí)要管理我們的運(yùn)維資源（人），這里的運(yùn)維對(duì)象與運(yùn)維資源并不是抽象的概念，是非常具體的，運(yùn)維對(duì)象可以具體到具體每一個(gè)CI及其備件，運(yùn)維資源具體到每一個(gè)人的工時(shí)利用。其它的象服務(wù)目錄與SLA等就不用多介紹了，是必要納入管理。主線是從運(yùn)維對(duì)象與運(yùn)維資源這兒走出來(lái)的。  擴(kuò)展要求運(yùn)維平臺(tái)可以滿足公司當(dāng)前的運(yùn)模式的發(fā)展需求，以及我們現(xiàn)在的產(chǎn)品的發(fā)展，這里涉及具體的一些公司現(xiàn)狀，就不多作說(shuō)明了 質(zhì)量要求在應(yīng)用質(zhì)量上我們要超過(guò)REMEDY，注意是應(yīng)用質(zhì)量，不是指功能，功能上我們無(wú)意與REMEDY去一爭(zhēng)長(zhǎng)短，因?yàn)檫@沒(méi)有什么可能性與意義，但我們有信心只要一年實(shí)施時(shí)間，我們就完全可以超過(guò)REMEDY在公司的應(yīng)用質(zhì)量，這一點(diǎn)我的把握相當(dāng)大。二、系統(tǒng)架構(gòu)我們使用的是B/S的系統(tǒng)架構(gòu)，這是為了方便地理分散的員工使用，同時(shí)也是為了考慮到日后全國(guó)的用戶可能會(huì)登錄系統(tǒng)進(jìn)行一部份的作業(yè)，比如參與調(diào)查，或者開(kāi)放論壇等，采用B/S的架構(gòu)，負(fù)面的影響一是速度方面，二是界面表現(xiàn)力，但日后的升級(jí)維護(hù)比較方便，用戶登錄也很方便。具體是否成功，可能還要等日后大規(guī)模應(yīng)用時(shí)才能進(jìn)一步驗(yàn)證。開(kāi)發(fā)平臺(tái)是.NET2005 C#，數(shù)據(jù)庫(kù)采用ORACLE 10G。另外我們?cè)诹鞒讨校ū热缡录?jí)、派單）做了一些郵件通知與短信通知的功能，其它的在技術(shù)方面，倒好象沒(méi)有太多值得說(shuō)明的地方，也可能可以說(shuō)技術(shù)并沒(méi)有太多的亮點(diǎn)。三、流程控制在系統(tǒng)流程控制方面，當(dāng)時(shí)也有過(guò)一些爭(zhēng)議，后面由于我的堅(jiān)持，放棄了采用工作流引擎的想法，一不是希望增加項(xiàng)目復(fù)雜度，二是硬性的流程事實(shí)上是不現(xiàn)實(shí)的，因?yàn)樵谶\(yùn)維服務(wù)活動(dòng)中，單據(jù)的流轉(zhuǎn)方式很難硬性定義，加上一人擔(dān)負(fù)多個(gè)角色，去配工作流是沒(méi)有太多意義的，同時(shí)我們主要是自用，一旦運(yùn)轉(zhuǎn)起來(lái)后，去調(diào)整流程的可能性較低，那樣工作流引擎存在意義就很低了。所以我們?cè)陂_(kāi)發(fā)過(guò)程中，一旦有硬性的流程就寫死在程序中，而單據(jù)的流轉(zhuǎn)是由人確定的，可以不做限制進(jìn)行單據(jù)的轉(zhuǎn)派。這里也是以前在軟件實(shí)施一直的想法，不能指望軟件去完全實(shí)現(xiàn)一切的控制，有些的控制點(diǎn)放在系統(tǒng)之外，往往會(huì)更好更省力，軟件只是一個(gè)汽車，你想它跑得更快更好，需要有一條道路去配合在一起，這條路就是你的管理制度，許多寄望軟件實(shí)現(xiàn)的控制點(diǎn)，一旦沒(méi)有考慮清楚，最后會(huì)帶來(lái)許多麻煩，所以要有先松后緊的策略，逐步增加控制，而且是要以制度為先。四、服務(wù)臺(tái)管理事件管理與服務(wù)臺(tái)管理是不同的概念，前者是一種流程，后者是一種職能，許多人沒(méi)有搞清楚這兩者的關(guān)系，事實(shí)上事件管理的許多操作是由服務(wù)臺(tái)人員完成的，服務(wù)臺(tái)本身并不存在流程（注意這是站在ITIL流程的層面），服務(wù)臺(tái)管理本身是一個(gè)獨(dú)立的學(xué)問(wèn)，這要根據(jù)每個(gè)組織的特點(diǎn)去考慮，在我們的情況中，有幾名獨(dú)立的熱線人員作為服務(wù)窗口，對(duì)這些人員的話務(wù)管理是通過(guò)語(yǔ)音系統(tǒng)管理的，而這個(gè)語(yǔ)音系統(tǒng)與我們的ITSM系統(tǒng)是有接口的，真正的事件操作事實(shí)還是在事件管理中完成。這里特別提一下，在我們的ITSM系統(tǒng)中事實(shí)上是沒(méi)有一個(gè)服務(wù)臺(tái)管理模塊的，我相信許多人并沒(méi)有真正理解服務(wù)臺(tái)的真正含義，把熱線與服務(wù)臺(tái)劃等號(hào)是有問(wèn)題的，尤其是要IT服務(wù)領(lǐng)域，一旦你包含比較多的軟件項(xiàng)目，服務(wù)臺(tái)就一定會(huì)發(fā)生變異，如果你的服務(wù)臺(tái)人員只是起到一個(gè)轉(zhuǎn)電話與派單的作用，那事實(shí)是一個(gè)語(yǔ)音菜單的功能，這樣的服務(wù)臺(tái)設(shè)立的意義不大，多數(shù)人以為服務(wù)臺(tái)作用是單點(diǎn)受理以及快速響應(yīng)，但是這更多只是手段不是目的，服務(wù)臺(tái)并不是一定在物理上坐在一起，服務(wù)臺(tái)可以是多種多樣的，一定搞清楚服務(wù)臺(tái)的目的是什么，它為什么而存在，IT服務(wù)不同于其它的行業(yè)，當(dāng)用戶打電話到攜程與招商銀行的的服務(wù)臺(tái)時(shí)，跟用戶打電話到一個(gè)IT服務(wù)商是不一樣的，攜程與招行的服務(wù)是相當(dāng)“大眾”與“標(biāo)準(zhǔn)”的，他們的服務(wù)臺(tái)基本可以做到你電話過(guò)去時(shí)，就能真正響應(yīng)，而IT服務(wù)商的服務(wù)臺(tái)通常做不到，為什么？因?yàn)槟愕姆?wù)更具“縱深”，所以對(duì)你的服務(wù)臺(tái)提出了更高的要求，你讓幾個(gè)完全聽(tīng)不懂用戶問(wèn)題與需求所在的熱線非常快的接到用戶電話真正有用嗎？響應(yīng)的定義是什么？如果僅僅是接聽(tīng)了用戶的請(qǐng)求，而不做任何反應(yīng)，這叫響應(yīng)嗎？我讓一個(gè)電話錄音機(jī)當(dāng)熱線，這算不算響應(yīng)呢？如果你的熱線是真接轉(zhuǎn)電話給工程師，經(jīng)過(guò)熱線轉(zhuǎn)一下的意義何在？工程師仍然處于隨時(shí)待命的狀態(tài)，你的服務(wù)資源沒(méi)有任何節(jié)省，而是在浪費(fèi)，同時(shí)讓用戶重復(fù)問(wèn)題，或者讓熱線轉(zhuǎn)述問(wèn)題，造成信息缺失。當(dāng)你的服務(wù)臺(tái)沒(méi)有起到真正的服務(wù)臺(tái)作用時(shí)，你會(huì)發(fā)現(xiàn)一個(gè)有意思的現(xiàn)象，用戶會(huì)繞過(guò)你的服務(wù)臺(tái)，直接打電話到工程師哪兒了，不要說(shuō)這是用戶的問(wèn)題，這是你的問(wèn)題，你沒(méi)有把一個(gè)正確的路徑給用戶，用戶會(huì)按最有效率的路徑來(lái)走的（是不是類似我們走草坪的情形？，人們不會(huì)喜歡90度的直角小徑，會(huì)用斜線穿越草坪。好象扯遠(yuǎn)了，服務(wù)臺(tái)這一課題要展開(kāi)講是一個(gè)獨(dú)立的篇章，IT服務(wù)業(yè)的服務(wù)臺(tái)是不同于傳統(tǒng)行業(yè)的，用傳統(tǒng)行業(yè)的callcenter的做法去設(shè)立IT服務(wù)業(yè)的服務(wù)臺(tái)的做法，一般是行不通的，尤其當(dāng)你的業(yè)務(wù)領(lǐng)域復(fù)雜時(shí)，可能虛擬服務(wù)臺(tái)是一個(gè)不錯(cuò)的選擇，沒(méi)有一定的硬性標(biāo)準(zhǔn)，要根據(jù)自已實(shí)際的業(yè)務(wù)需要來(lái)，一個(gè)真正好的服務(wù)臺(tái)，是可以節(jié)省你的服務(wù)資源，而且可以更快把客戶請(qǐng)求結(jié)束掉。五、事件管理 事件管理是創(chuàng)建、處理事件的模塊，一個(gè)事件的生命周期全部會(huì)在此模塊內(nèi)，在設(shè)計(jì)時(shí)，需要考慮以下的信息    事件的類型事件管理在我們規(guī)劃中，是一個(gè)非常重要的窗口模塊，事件類型我們分為了有故障、請(qǐng)求、咨詢、新需求、投訴，基本上面向客戶的事務(wù)都會(huì)在此發(fā)起，這種類型也是為了日后的統(tǒng)計(jì)分析。事件的分類由于我們項(xiàng)目眾多，考慮到橫向統(tǒng)計(jì)的需要，我們要定義一個(gè)公用的事件分類，以便運(yùn)維管理分析，我們分了硬件、軟件、網(wǎng)絡(luò)、數(shù)據(jù)庫(kù)、接口、業(yè)務(wù)這幾個(gè)大類，日后可能會(huì)進(jìn)一步細(xì)化分類，以便做更深入的分析，但這個(gè)難度很大，需要時(shí)間的積累。事件的等級(jí)最開(kāi)始我們是希望引入優(yōu)先級(jí)（嚴(yán)重度與緊急度），但后面發(fā)現(xiàn)這樣定義非常困難，對(duì)指導(dǎo)工程師處理意義不大，還很有可能會(huì)誤導(dǎo)信息，所以最后就把事件硬切為5個(gè)等級(jí)，公司給出最粗的定義標(biāo)準(zhǔn)，然后由每個(gè)項(xiàng)目具體定義解釋，這樣每個(gè)工程師在作業(yè)時(shí)，就可以定義事件的等級(jí)，默認(rèn)情況下，等級(jí)越高的事件，是表示越嚴(yán)重，也表示要優(yōu)先處理的，雖然會(huì)相對(duì)粗放一些，但相對(duì)簡(jiǎn)單適用業(yè)務(wù)，而且我們的SLA是與此相關(guān)的。 事件的狀態(tài)事件狀態(tài)是為了表達(dá)事件單當(dāng)前的處理狀況，我們?yōu)榱藙?chuàng)建、分派中、處理中、等待中、解決、關(guān)閉。這樣可以形成看板與統(tǒng)計(jì)。 事件與CMDB的關(guān)聯(lián)一直以來(lái)說(shuō)CMDB的用處，在事件的應(yīng)用就相當(dāng)關(guān)鍵，在事件發(fā)生時(shí)，要做一個(gè)關(guān)鍵動(dòng)作，就是組件定位，需要搞清楚這個(gè)事件是發(fā)生在什么項(xiàng)目（CI）的什么地方（CI），需要事件創(chuàng)建者做出定位，然后在派單時(shí)，就會(huì)根據(jù)你的CI定位，帶出相關(guān)的責(zé)任工程師，與事件與CI的關(guān)聯(lián)，給你的運(yùn)維分析會(huì)帶許多豐富的信息，你CMDB所有的信息與事件的信息可以交叉進(jìn)行統(tǒng)計(jì)分析，比如上面說(shuō)的事件的分類有硬件，那我想知道桌面項(xiàng)目的一年中硬盤發(fā)生了多少故障呢？我想知道一年中桌面項(xiàng)目中希捷品牌的硬盤發(fā)生了多少故障呢？我想知道去年桌面項(xiàng)目中，客戶對(duì)哪一款軟件的咨詢次數(shù)最多，以便我來(lái)年準(zhǔn)備對(duì)用戶做一次操作培訓(xùn)，這些信息全部依靠事件中的組件定位，這樣的信息就可以輕而易舉的告訴你。還有你想知道去年你的軟件的哪一個(gè)功能點(diǎn)或模塊的發(fā)生的故障次數(shù)最多嗎？你想知道去年被投訴次數(shù)最多的項(xiàng)目或人是誰(shuí)嗎？這些全部可以出得來(lái)。事件與其它流程的接口事件與變更、問(wèn)題、知識(shí)庫(kù)是存在接口的，事件處理過(guò)程中可以直接發(fā)起變更申請(qǐng)，也可以發(fā)起問(wèn)題申請(qǐng)與知識(shí)庫(kù)申請(qǐng)，需要說(shuō)明的是事件與變更的接口，我們的事件是否關(guān)閉沒(méi)有硬性判斷與之關(guān)聯(lián)的變更是否終結(jié)，而是從事件單方面流出信息，并沒(méi)有把變更的處理情況與事件單關(guān)聯(lián)，讓這個(gè)流程分線程去作業(yè)處理，主要是擔(dān)心做得太死，可能導(dǎo)致事件單關(guān)閉受阻。事件的時(shí)長(zhǎng)與工作量在任何一個(gè)事件的處理時(shí)，對(duì)于時(shí)間而言，有二個(gè)概念，一個(gè)是事件的時(shí)長(zhǎng)，是指一個(gè)事件的處理周期（從8：00創(chuàng)建到12：00解決，4小時(shí)），一個(gè)是事件的花費(fèi)的資源量，即工作量（4小時(shí)的時(shí)長(zhǎng)中，工程師可能投入了2小時(shí)來(lái)處理），時(shí)長(zhǎng)是為了SLA的計(jì)算，后者是為了運(yùn)維資源的分析。統(tǒng)計(jì)分析事件報(bào)表的統(tǒng)計(jì)分析是非常豐富，可以從CMDB的角度出發(fā)，去統(tǒng)計(jì)每一個(gè)項(xiàng)目、每一個(gè)設(shè)備的事件情況，還可以從客戶的角度出發(fā)，統(tǒng)計(jì)某個(gè)客戶組織或某個(gè)客戶的事件情況，還可以運(yùn)維組織的角度出發(fā)，統(tǒng)計(jì)我們的一個(gè)服務(wù)團(tuán)隊(duì)或一個(gè)服務(wù)人員的事件情況，另外可以從事件本身的信息出發(fā)，根據(jù)事件的類型、分類、等級(jí)、狀態(tài)、來(lái)源（電話、郵件、WEB）去統(tǒng)計(jì)，還可以統(tǒng)計(jì)SLA方面的數(shù)據(jù)。  六、問(wèn)題管理問(wèn)題管理處理邏輯其實(shí)是類似事件的，它的許多信息是繼承事件，比如等級(jí)與類型等，在規(guī)劃問(wèn)題管理時(shí)，要想清楚問(wèn)題的分類等級(jí)等信息跟事件是什么關(guān)系，問(wèn)題管理的大概作業(yè)界面有哪一些，在系統(tǒng)流程上有哪幾個(gè)步驟，如何留下問(wèn)題的處理時(shí)長(zhǎng)與工作量，如保留下問(wèn)題處理的記錄信息，問(wèn)題如何發(fā)起變更，如何納入知識(shí)庫(kù)。問(wèn)題與事件在程序處理上的區(qū)別，比如問(wèn)題的創(chuàng)建后需要有一個(gè)審批的動(dòng)作，問(wèn)題不服從SLA，問(wèn)題有知名錯(cuò)誤的概念，這一部份的設(shè)計(jì)如果你的事件規(guī)劃好后，問(wèn)題管理是相對(duì)簡(jiǎn)單的，它的難不在于程序，而在于日后的應(yīng)用。問(wèn)題的統(tǒng)計(jì)報(bào)表，基本上與事件的緯度類似。七、變更管理在ITIL中變更與發(fā)布是兩個(gè)獨(dú)立的流程，在我們規(guī)劃時(shí)把這個(gè)流程與合并為一個(gè)了，發(fā)布的控制在程序中可以實(shí)現(xiàn)的控制點(diǎn)是很少的，而且它與變更是如此緊密，在我理解中，變更的實(shí)施就是發(fā)布流程，即發(fā)布可以理解為是變更的一個(gè)子流程，發(fā)布并不僅僅是針對(duì)軟件的，硬件一樣也會(huì)有發(fā)布的概念，比如將一臺(tái)新設(shè)備布署到生產(chǎn)環(huán)境中。對(duì)CMDB的控制，在業(yè)務(wù)層面全部是需要通過(guò)變更來(lái)實(shí)現(xiàn)控制的，所以CMDB精確度如何，很大程度上取決于變更的執(zhí)行情況。這里特別需要寫說(shuō)明的，我們?cè)谝?guī)劃中考慮到一點(diǎn)，如果讓CMDB的信息更新得到真正有效的控制，當(dāng)工程師在填寫變更申請(qǐng)時(shí)，在界面上就提列出變更前后的具體信息，在審批時(shí)，不光是審批變更的行為，更重要的是要審批變更的內(nèi)容，如果審批通過(guò)，執(zhí)行后，就會(huì)根據(jù)這些信息把CMDB做更新，這樣可以相對(duì)減少?zèng)]有約束的對(duì)CMDB更新的行為。變更管理為什么而存在，在業(yè)務(wù)上起到什么作用，這些我覺(jué)得很多人沒(méi)有想清楚，很多時(shí)候變成變更管理主要為目的是為了實(shí)現(xiàn)對(duì)CMDB的維護(hù)控制，這是對(duì)變更管理的曲解，這里一點(diǎn)上我也犯過(guò)這種毛病，變更的主要目的是授權(quán)與控制對(duì)基礎(chǔ)架構(gòu)或其它的服務(wù)的改變，注意這里說(shuō)的更新是指現(xiàn)實(shí)的服務(wù)或物理上的基礎(chǔ)架構(gòu)，而不是你系統(tǒng)中數(shù)據(jù)的更新，100條變更請(qǐng)求并不是最終全部會(huì)落入到CMDB的更新中，可能有5條是對(duì)SLA的變更，所以變更與CMDB不是劃等號(hào)的，當(dāng)你的工程師對(duì)具體的一些設(shè)備做維護(hù)時(shí)，事實(shí)上你已賦予他改變基礎(chǔ)架構(gòu)的權(quán)利了，如果他把生產(chǎn)環(huán)境中的CI做了改變，那他再走變更管理的意義是什么？是為了控制他對(duì)CMDB的更新嗎，這種控制反而是起到負(fù)作用了，如果無(wú)法控制別人對(duì)生產(chǎn)環(huán)境的變更行為，或者你是默認(rèn)授權(quán)的，最后給予一個(gè)通道讓他直接可以維護(hù)CMDB，比如一名桌面工程師，他在修電腦的過(guò)程中，把一臺(tái)電腦的操作系統(tǒng)升級(jí)了，這時(shí)他要走變更管理流程嗎？我的回答是不應(yīng)該，除非他不得到批準(zhǔn)就不能對(duì)操作系統(tǒng)做升級(jí)，這時(shí)變更才具有意義，不然這種控制完全負(fù)面的，如果這個(gè)工程師在修電腦的過(guò)程中，發(fā)現(xiàn)是硬盤徹底壞掉了，這時(shí)需要更換硬盤，此時(shí)有可能超出了他的權(quán)限范圍（這也需要考慮到具體業(yè)務(wù)定義），這時(shí)他不走變更流程根本無(wú)法得到硬盤，這時(shí)變更才具有一定意義，但這種情況并不是最具代表性的，這樣的業(yè)務(wù)情形最具有變更管理的代表性：要對(duì)一段網(wǎng)絡(luò)做調(diào)整，但是有可能會(huì)影響到幾個(gè)系統(tǒng)項(xiàng)目，這時(shí)需要發(fā)起變更申請(qǐng)，由涉及到的幾個(gè)項(xiàng)目負(fù)責(zé)人與網(wǎng)絡(luò)領(lǐng)域的主管一同做變更的評(píng)估，如果認(rèn)為有方法對(duì)應(yīng)，可以進(jìn)行此次變更的話，此時(shí)需要制作一個(gè)變更的實(shí)施方案，然后安排人員進(jìn)行具體的調(diào)整操作實(shí)施。實(shí)施完成，把CMDB中的信息更新。變更管理的統(tǒng)計(jì)報(bào)表，可以從發(fā)起源統(tǒng)計(jì)，可以從CMDB的角度發(fā)起統(tǒng)計(jì)，也可以從變更本身的信息進(jìn)行統(tǒng)計(jì)，比如變更的狀態(tài)、變更的分類，變更的人員等八、配置管理配置管理模塊，核心的就是CMDB，這一點(diǎn)我寫了不少這方面的文章了，就不再啰嗦多了，把配置管理的流程層面的一些點(diǎn)再說(shuō)明一下。CMDB的審計(jì)CMDB審計(jì)是需要規(guī)劃好的，應(yīng)該可以根據(jù)各種條件審計(jì)，比如根據(jù)某一類的組件，某一個(gè)項(xiàng)目的組件，還可以確定一定的數(shù)量進(jìn)行審計(jì)（隨機(jī)抽?。┮部梢詻Q定一定的比率（隨機(jī)抽?。瑢徲?jì)的目的是為了檢查CMDB的數(shù)據(jù)正確情況，找出問(wèn)題并修正。 CMDB的鎖定CI在某些情況需要進(jìn)鎖定，比如變更時(shí)，比如審計(jì)時(shí)，為什么要這樣呢，如果你對(duì)一個(gè)CI變更時(shí)，不鎖定這個(gè)CI的信息，會(huì)發(fā)生同時(shí)幾個(gè)地方對(duì)這個(gè)CI做信息更新，由于時(shí)間差，很可能把錯(cuò)誤的信息更新到CMDB中了，同時(shí)用戶在變更過(guò)程中調(diào)用CI信息的話，也會(huì)發(fā)生誤導(dǎo)，所以需要控制單線程的對(duì)CI進(jìn)行維護(hù)，在同一時(shí)間只能有一個(gè)對(duì)CI維護(hù)的動(dòng)作進(jìn)行。審計(jì)也是一樣，如果你審計(jì)開(kāi)始時(shí)，這個(gè)CI信息一直在動(dòng)態(tài)的變化，不鎖定CI的話，審計(jì)無(wú)法進(jìn)行，同時(shí)會(huì)審計(jì)出一個(gè)錯(cuò)誤的結(jié)果。配置管理的信息可以被許多模塊調(diào)用，需要規(guī)劃到CI查詢的畫(huà)面，然后置入到事件、問(wèn)題、變更、操作等模塊中，CMDB的人機(jī)界面相當(dāng)關(guān)鍵，要盡可能的方便調(diào)用、查詢、操作。九、操作管理操作管理為了處理那些非事件、問(wèn)題、變更等事務(wù)，比如機(jī)房巡檢，定期的機(jī)器清潔、檢修，操作管理可以創(chuàng)建作業(yè)，作業(yè)的來(lái)源有兩種來(lái)源，一種是直接創(chuàng)建的，比如臨時(shí)要對(duì)一臺(tái)設(shè)備做檢測(cè)，一種是根據(jù)周期性作業(yè)計(jì)劃產(chǎn)生的，比如服務(wù)器每日要檢查數(shù)據(jù)文件、表空間使用情況、JOB運(yùn)行情況、操作系統(tǒng)日志。操作管理與能力管理中的監(jiān)視計(jì)劃是存在許多聯(lián)系的。說(shuō)到操作管理，有一種東西需要特別，就是服務(wù)日歷，我覺(jué)得可能這是第一次有人清晰定義“服務(wù)日歷”這一概念，注意不是工作日歷，而是服務(wù)日歷，什么是服務(wù)日歷呢，我們想想跟客戶簽訂的運(yùn)維合同時(shí)，我們承諾客戶我們的服務(wù)是8*5或16*7，這種承諾表示在這個(gè)時(shí)間期內(nèi)，我們周期性的任務(wù)是需要與之相配的，比如我們上面說(shuō)的服務(wù)器巡檢，如果每4小時(shí)需要做一次，我們跟客戶簽的是一年的8*5的合同的話，那么我們每周要做5*2次巡檢，這個(gè)次數(shù)是事先定義好的，每個(gè)項(xiàng)目的服務(wù)日歷是可能不同的，這表示我們每一個(gè)項(xiàng)目都可能存在一個(gè)服務(wù)日歷，根據(jù)這個(gè)服務(wù)日歷，我們?cè)谙到y(tǒng)中制作出一個(gè)周期性的計(jì)劃，系統(tǒng)根據(jù)服務(wù)日歷與你的計(jì)劃內(nèi)容，每天提前生成出作業(yè)指令給工程師，計(jì)劃上還定義了標(biāo)準(zhǔn)的工時(shí)要求與作業(yè)要求，工程師每天把這樣指令做完，然后把相關(guān)的作業(yè)關(guān)閉，并留下相應(yīng)的實(shí)際工時(shí)，這就是操作管理的核心。操作管理主要功能點(diǎn)有制作計(jì)劃、創(chuàng)建作業(yè)、作業(yè)處理、作業(yè)關(guān)閉、統(tǒng)計(jì)分析，在功能界面是相對(duì)簡(jiǎn)單的，但這一個(gè)模塊還可以把除事件、問(wèn)題、變更之外的工程剩余的活動(dòng)有效管理起來(lái)，而且可以保證你的服務(wù)作業(yè)可以得到強(qiáng)制執(zhí)行，它最后可以針對(duì)每一個(gè)批量計(jì)劃做分析，分析執(zhí)得如何，花費(fèi)了多少服務(wù)資源，要注意的是操作管理與事件管理沒(méi)有做程序接口，就是說(shuō)如果工程師在巡檢時(shí)發(fā)現(xiàn)故障，需要手工在事件管理創(chuàng)建事件，而不是自動(dòng)去觸發(fā)事件。十、任務(wù)管理任務(wù)管理的本意是為了管理我們的管理資源，這可能是針對(duì)我們公司自身的運(yùn)維管理特點(diǎn)設(shè)計(jì)的，每年我們做許多管理改善的工作，我們做很多培訓(xùn)，我們開(kāi)許多的會(huì)議，我們一直想分析一下我們花在管理上的資源是多少，我們希望把這種管理工時(shí)與直接生產(chǎn)工時(shí)做一個(gè)比率分析，我相信許多公司很有興趣想知道一年下來(lái)我們花在會(huì)議上有多少工時(shí)，這是我們管理效率提升一個(gè)非常重要的基礎(chǔ)數(shù)據(jù)。在很多時(shí)候，領(lǐng)導(dǎo)安排一個(gè)任務(wù)出來(lái)，這個(gè)任務(wù)是需要各個(gè)業(yè)務(wù)主管理去解下去的，在以前最后這個(gè)任務(wù)沒(méi)有被有效的監(jiān)督與執(zhí)行，同時(shí)這個(gè)任務(wù)花了多少時(shí)間也是不清楚的，比如領(lǐng)導(dǎo)要求各個(gè)領(lǐng)域開(kāi)展員工能力提升活動(dòng)，在任務(wù)管理中，只需要部長(zhǎng)生成一個(gè)任務(wù)，然后把這個(gè)任務(wù)派給各個(gè)業(yè)務(wù)主管，任務(wù)中會(huì)標(biāo)明要求完成的時(shí)間點(diǎn)，每個(gè)業(yè)務(wù)主管會(huì)接到這個(gè)任務(wù)，會(huì)展開(kāi)作業(yè)，此時(shí)作業(yè)過(guò)程的記錄與工時(shí)會(huì)不斷的增加在這個(gè)父任務(wù)上，一直到完成審請(qǐng)關(guān)閉時(shí)，當(dāng)這個(gè)父任務(wù)每一個(gè)子任務(wù)都關(guān)閉時(shí)，父任務(wù)可以關(guān)閉，并統(tǒng)計(jì)出花費(fèi)的資源情況，任務(wù)可以多層分解，甚至可以分解到每一名員工身上，這相對(duì)可以加強(qiáng)任務(wù)的控制力度，也會(huì)某種程度控制管理人員過(guò)度的使用資源。任務(wù)管理更多是為了管理者的工作而設(shè)計(jì)的，這也是運(yùn)維服務(wù)作業(yè)中最后一塊沒(méi)有被記錄的話動(dòng)，這樣下來(lái)后，事件、問(wèn)題、變更、操作、任務(wù)就構(gòu)成了任何一個(gè)運(yùn)維服務(wù)人員，無(wú)論他是領(lǐng)導(dǎo)還是一線員工的作業(yè)平臺(tái)，只有監(jiān)視所有的活動(dòng)，你的資源使用才被全部監(jiān)視。任務(wù)管理的報(bào)表會(huì)有針對(duì)任務(wù)執(zhí)行情況的，還有橫向分析任務(wù)類型的，即哪一些任務(wù)的資源占用情況，如果數(shù)據(jù)積累足夠多時(shí)，我想這種分析展開(kāi)，會(huì)讓我們非常吃驚，運(yùn)維服務(wù)的大量資源是被無(wú)效使用的。這樣我們運(yùn)維服務(wù)管理才有改善的方向與具體指標(biāo)。十一、管理SLM某種程度上，我們的ITSM系統(tǒng)并沒(méi)有實(shí)現(xiàn)真正意義的SLM管理，系統(tǒng)中并不關(guān)心SLA制訂出來(lái)前的過(guò)程，也沒(méi)有把UC與OLA等納入其中，我們只把制訂出來(lái)的SLA設(shè)置在系統(tǒng)中，以實(shí)現(xiàn)監(jiān)控與作業(yè)。所以以下說(shuō)的是SLA的管理實(shí)現(xiàn)方式SLA在我們業(yè)務(wù)中我們分為了故障解決率與Q指標(biāo)，而EUS（客戶滿意度）是另一個(gè)緯度的數(shù)據(jù)，并不在此提列。故障解決率是指在規(guī)定時(shí)間內(nèi)完成事件處理的百分比，Q指標(biāo)是持續(xù)運(yùn)行時(shí)間。具體談一下我們的實(shí)現(xiàn)方式，前面說(shuō)的服務(wù)日歷是很重要的一個(gè)基礎(chǔ)數(shù)據(jù)，沒(méi)有它SLA的計(jì)算全部都會(huì)錯(cuò)誤的。我們把事件分成了5個(gè)等級(jí)（SLA只適用于事件處理），每一個(gè)項(xiàng)目都會(huì)針對(duì)每一個(gè)事件等級(jí)設(shè)置解決時(shí)間要求值（比如一級(jí)事件需要2小時(shí)，二級(jí)事件需要4小時(shí)，三級(jí)事件6小時(shí)，四級(jí)事件8小時(shí)，5級(jí)事件12小時(shí)），注意這里定義的時(shí)間值是與服務(wù)日歷匹配的，比如服務(wù)日歷定義是5*8是指周一至周五的8：00-12：00，14：00-18：00，這時(shí)如果一個(gè)一級(jí)事件是發(fā)生在周五的1 7：00，即便是第二周的周一的8：30解決也是沒(méi)有違反SLA的（雖然現(xiàn)實(shí)中我們會(huì)馬上處理，但在硬性的SLA的計(jì)算是如此）。另外Q指標(biāo)的定義是這樣的，每一個(gè)項(xiàng)目要定義清楚到底哪一個(gè)事件等級(jí)會(huì)納入Q指標(biāo)的計(jì)算中，比如一級(jí)、二級(jí)事件的故障時(shí)間（從事件創(chuàng)建到事件解決）會(huì)納入計(jì)算，三、四、五級(jí)的事件故障時(shí)間就不納入計(jì)算，這樣隨時(shí)可以計(jì)算你的當(dāng)前的Q指標(biāo)是多少。SLA設(shè)置完成后，就會(huì)在事件中就用，當(dāng)你把事件定位在一個(gè)項(xiàng)目時(shí)（CI），你選擇了事件等級(jí)，此時(shí)系統(tǒng)會(huì)調(diào)出事件解決的時(shí)間要求，當(dāng)你創(chuàng)建完成時(shí)，系統(tǒng)開(kāi)始倒計(jì)時(shí)。SLA的報(bào)表主要是針對(duì)故障解決率與Q指標(biāo)的，只是統(tǒng)計(jì)的緯度可能是多樣的。十二、  知識(shí)庫(kù)管理知識(shí)庫(kù)管理考慮現(xiàn)實(shí)情況，我們沒(méi)有做得太復(fù)雜，運(yùn)維服務(wù)的知識(shí)是有比較強(qiáng)的時(shí)效性的，知識(shí)更新較快，這里說(shuō)的知識(shí)是指針對(duì)故障處理方面的，并不是指針對(duì)員工的技能或知識(shí)培養(yǎng)方面，這與通常說(shuō)的KM還是有不少區(qū)別的?？紤]到運(yùn)維過(guò)程中的知識(shí)是非常具有針對(duì)性的，所以沒(méi)有把那種通用的知識(shí)納入考慮，都是以項(xiàng)目的角度出來(lái)，知識(shí)的創(chuàng)建有三個(gè)來(lái)源，一是事件生成，二是問(wèn)題生成，三是手工創(chuàng)建，為了便于查找，我們的做法是以項(xiàng)目為綱，以分類為目，以關(guān)建字為輔，即最根本的分類是項(xiàng)目，然后是根本事件問(wèn)題的分類，最后是用關(guān)鍵字，用這幾個(gè)手段進(jìn)行查找知識(shí)點(diǎn)，供工程師在處理事件時(shí)調(diào)用查看。無(wú)論知識(shí)是從事件或問(wèn)題還是手工創(chuàng)建，都會(huì)有一個(gè)審批的過(guò)程控制知識(shí)庫(kù)的更新，同時(shí)還可以設(shè)置知識(shí)有效期限，因?yàn)樵S多知識(shí)點(diǎn)或能在項(xiàng)目的特定時(shí)間內(nèi)有限（比如針對(duì)某個(gè)版本），事實(shí)上如果知識(shí)庫(kù)納入后不進(jìn)行更新維護(hù)，最后可能會(huì)誤導(dǎo)工程師，起到負(fù)作用，所以知識(shí)庫(kù)的更新與停用也是需要考慮好的。另外知識(shí)庫(kù)的創(chuàng)建可以做一些統(tǒng)計(jì)與分析，看哪一個(gè)團(tuán)隊(duì)的知識(shí)復(fù)用較多，哪一種類型的知識(shí)較多。對(duì)于知識(shí)的利用，不建議納入系統(tǒng)考慮，因?yàn)樵谲浖惺欠浅ｋy以識(shí)別知識(shí)是否被調(diào)用的，靠點(diǎn)擊意義不大，一個(gè)人打開(kāi)知識(shí)看后，可能發(fā)現(xiàn)根本不是他想要的，或者他只是借鑒看一下，這時(shí)強(qiáng)迫按鈕操作沒(méi)有意義。十三、調(diào)查管理調(diào)查管理原本是希望改變以前那種手工發(fā)郵件采集滿意度調(diào)查的做法，后面在設(shè)計(jì)時(shí)，發(fā)現(xiàn)可以對(duì)象化，做得更靈活些。所以我們?cè)谝?guī)劃時(shí)，我們是這樣考慮的，可以設(shè)計(jì)許多問(wèn)卷，這些問(wèn)卷可能是針對(duì)客戶滿意度的，也可能是為了調(diào)研我們的服務(wù)方式改進(jìn)方向的，也可能是為商業(yè)的考慮了解服務(wù)產(chǎn)品化的潛在空間的，問(wèn)卷設(shè)計(jì)好后，可以生成調(diào)查任務(wù)，這時(shí)引用調(diào)研問(wèn)卷，一個(gè)問(wèn)卷可以被無(wú)限調(diào)用，而調(diào)查的結(jié)果是針對(duì)調(diào)查任務(wù)而不是針對(duì)問(wèn)卷的。 調(diào)查可以直接發(fā)網(wǎng)址到客戶郵箱（取自客戶數(shù)據(jù)），也可以直接把問(wèn)卷發(fā)過(guò)去，如果是WEB采集數(shù)據(jù)，可以生成用戶名與密碼發(fā)到客戶郵箱，用戶登陸系統(tǒng)填寫，也可以手工回收，但WEB是省力的，因?yàn)檎{(diào)研結(jié)果由系統(tǒng)自動(dòng)生成。有一些細(xì)節(jié)地方需要考慮，比如任務(wù)的開(kāi)始與結(jié)束時(shí)間來(lái)決定問(wèn)卷填寫開(kāi)始與停止，是不是設(shè)置必填與可選，是翻頁(yè)填寫還是整頁(yè)顯示，甚至你的問(wèn)卷的答案選項(xiàng)與分值設(shè)置，還要注意調(diào)研對(duì)象散與客戶資料的集成（從某一個(gè)客戶組織選擇一定百分比）還有CMDB（針對(duì)某一個(gè)系統(tǒng)或項(xiàng)目）的接口?；旧习盐覀兇蟮哪K寫完了，一路寫下去，發(fā)現(xiàn)有些跑題了，狀態(tài)不是很好，有些大雜燴，有些地方不夠深入，也沒(méi)有真正一個(gè)ITSM系統(tǒng)每一個(gè)模塊應(yīng)該具備的元素提煉好，象一些績(jī)效點(diǎn)沒(méi)有體系的寫出來(lái)。大家湊合著看吧。有一些可惜，后續(xù)我沒(méi)有時(shí)間把每一模塊深入考慮好，加上開(kāi)發(fā)團(tuán)隊(duì)離我的期望要求有比較大的差距，沒(méi)有足夠的時(shí)間與足夠的資源，不然我很有信心做出中國(guó)最好的一款I(lǐng)TSM系統(tǒng)，但就算目前的情況，我的許多設(shè)計(jì)仍然是國(guó)內(nèi)的公司在一段時(shí)間很難企及的，這里包含許多年來(lái)各種各樣的思考，軟件的，管理的，ITIL的，對(duì)運(yùn)維業(yè)務(wù)本質(zhì)的理解。不過(guò)可能只有一家從事這種系統(tǒng)開(kāi)發(fā)的公司或個(gè)人在看到時(shí)，才能真正知道其中的價(jià)值。