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

申請免費試用、咨詢電話：400-8352-114

破子

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