實戰(zhàn)剖析：13步設計出一個ITSM系統(tǒng)

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

　這是我一直想寫的內(nèi)容，本來是希望把這個項目從立項到規(guī)劃，到設計開發(fā)，到最后的實施應用的全部過程寫成一個筆記，但工程浩大，就先把我們規(guī)劃這款ITSM系統(tǒng)的想法寫出來，里面會夾雜著我對這類系統(tǒng)的深入思考。

　　這種考慮一是基于對ITIL的理解，二是對軟件實現(xiàn)的理解，三是運維管理的考量。內(nèi)容不會十分具體，因為每一個部份基本都是一個模塊，如果寫得深入，就是一個詳細的設計說明書了。下面逐步展開說明。

　　一．系統(tǒng)目標

　　系統(tǒng)目標是為了說明我們想開發(fā)一個怎樣的系統(tǒng)，想利用這個系統(tǒng)做什么，達到怎樣的目的。最簡單的是，我們想打造一個運維平臺，把我們在各個地區(qū)分布的運維服務團隊，無論屬于哪一個客戶群的，無論是屬于哪一種業(yè)務領域的（桌面、網(wǎng)絡、系統(tǒng)、軟件），都統(tǒng)一納入到一個相同的平臺上。

　　他們要基于相同的制度，基于相同的流程，基于相同的理念，用統(tǒng)一術語與方式去服務客戶。我們的一個優(yōu)勢是規(guī)模與平臺資源，但如果我們的人員與業(yè)務無法整合到一起，這種優(yōu)勢就不復存在，反而可能成為一個負面原因。因為你沒有了大船的承載能力，也沒有小船的靈活轉身能力。

　　運維服務業(yè)務有其特點，很難標準化，太容易受客戶的影響而改變流程或制度。一旦你的團隊分散、客戶多，而且地理分散，光依靠發(fā)布ISO20000的體系文件，對人員做扎實的培訓，就指望把大家的各種作業(yè)規(guī)范統(tǒng)一起來，不是說不可能，極難。運維服務數(shù)據(jù)極難分析與采集，一個顯而易見的方式就是利用軟件。

　　我們在打造自已的平臺時，概括來說，有這么幾個方面要求：

　?、僭O計要求：基于我們的運維服務業(yè)務特點，把我們的管理經(jīng)驗置入其中，同時納入ISO20000的實施所得，就是我們的服務體系。還要參考REMEDY優(yōu)缺點，這些是我們規(guī)劃設計這系統(tǒng)的基礎。

　?、诜秶螅何覀冞@個平臺要能管理所有的運維對象（各種類型的項目），同時要管理我們的運維資源（人）。運維對象可以具體到具體每一個CI及其備件，運維資源具體到每一個人的工時利用。其它像服務目錄與SLA等，都要納入管理。

　?、蹟U展要求：運維平臺可以滿足公司模式的發(fā)展需求，以及產(chǎn)品的發(fā)展，這里涉及具體的公司現(xiàn)狀，就不多作說明了。

　?、苜|量要求：在應用質量上我們要超過REMEDY，注意是應用質量，不是指功能，功能上我們無意與REMEDY去一爭長短。我們有信心只要一年實施時間，就完全可以超過REMEDY在公司的應用質量。

　　二．系統(tǒng)架構

　　我們使用的是B/S系統(tǒng)架構，這是為了方便地理分散的員工使用，也是考慮到日后全國的用戶可能會登錄系統(tǒng)進行部份作業(yè)，比如參與調查，或者開放論壇等。采用B/S的架構，負面的影響一是速度，二是界面表現(xiàn)力，但日后的升級維護比較方便，用戶登錄也很方便。是否成功，要等日后大規(guī)模應用時才能進一步驗證。

　　開發(fā)平臺是.NET2005 C#，數(shù)據(jù)庫采用ORACLE 10G。另外我們在流程中（比如事件升級、派單）做了一些郵件通知與短信通知的功能，其它技術方面，倒沒有太多值得說明的地方，也可以說技術并沒有太多的亮點。

　　三．流程控制

　　在系統(tǒng)流程控制方面，放棄了采用工作流引擎的想法，一是不希望增加項目復雜度，二是硬性的流程事實上不現(xiàn)實。因為在運維服務活動中，單據(jù)的流轉方式很難硬性定義，加上一人擔負多個角色，去配工作流沒有太多意義；同時我們主要是自用，運轉起來后，去調整流程的可能性較低，那樣工作流引擎存在意義就很低了。

　　所以我們在開發(fā)過程中，一旦有硬性的流程就寫死在程序中，而單據(jù)的流轉是由人確定的，可以不做限制進行單據(jù)的轉派。不能指望軟件去實現(xiàn)一切控制，有些控制點放在系統(tǒng)之外，往往會更好更省力。

　　軟件只是一個汽車，你想它跑得更快更好，需要有一條道路去配合在一起，這條路就是你的管理制度。許多寄望軟件實現(xiàn)的控制點，一旦沒有考慮清楚，最后會帶來許多麻煩。所以要有先松后緊的策略，逐步增加控制，而且要以制度為先。

六．問題管理

　　問題管理處理邏輯其實是類似事件的，它的許多信息是繼承事件，比如等級與類型等。在規(guī)劃問題管理時，要想清楚問題的分類等級等信息跟事件是什么關系，問題管理的大概作業(yè)界面有哪一些，在系統(tǒng)流程上有哪幾個步驟，如何留下問題的處理時長與工作量等等。

　　還要想清楚問題與事件在程序處理上的區(qū)別，比如問題的創(chuàng)建后需要有一個審批的動作，問題不服從SLA，問題有知名錯誤的概念，這一部份的設計如果你的事件規(guī)劃好后，問題管理是相對簡單的，它的難不在于程序，而在于日后的應用。

　　問題的統(tǒng)計報表，基本上與事件的緯度類似。

　　七．變更管理

　　在ITIL中，變更與發(fā)布是兩個獨立的流程，我們把這個流程合并為一個。發(fā)布的控制在程序中可以實現(xiàn)的控制點是很少的，而且它與變更是如此緊密。在我理解中，變更的實施就是發(fā)布流程，即發(fā)布可以理解為是變更的一個子流程。發(fā)布不僅僅是針對軟件的，硬件一樣也會有發(fā)布的概念，比如將一臺新設備布署到生產(chǎn)環(huán)境中。

　　對CMDB的控制，在業(yè)務層面全部需要通過變更來實現(xiàn)，CMDB精確度如何，很大程度上取決于變更的執(zhí)行情況。我們考慮到一點，如果讓CMDB的信息更新得到有效控制，當工程師在填寫變更申請時，在界面上就提列出變更前后的具體信息；審批時，不光是審批變更的行為，更重要的是要審批變更的內(nèi)容；如果審批通過，執(zhí)行后，根據(jù)這些信息把CMDB做更新。這樣可以相對減少沒有約束的對CMDB更新的行為。

　　變更管理為什么而存在，在業(yè)務上起到什么作用？這些我覺得很多人沒有想清楚，很多時候變成變更管理，主要目的是為了實現(xiàn)對CMDB的維護控制，這是對變更管理的曲解。這點上我也犯過這種毛病。

　　變更的主要目的是授權與控制對基礎架構或其它服務的改變，這里說的更新是指現(xiàn)實的服務或物理上的基礎架構，而不是系統(tǒng)中數(shù)據(jù)的更新。100條變更請求并不會都落入到CMDB的更新中，可能有5條是對SLA的變更，所以變更與CMDB不是劃等號的。

　　當你的工程師對具體設備做維護時，事實上你已賦予他改變基礎架構的權利了，如果他把生產(chǎn)環(huán)境中的CI做了改變，那他再走變更管理的意義是什么？是為了控制他對CMDB的更新嗎，這種控制反而起到負作用；如果無法控制別人對生產(chǎn)環(huán)境的變更行為，或者你是默認授權的，最后給予一個通道讓他直接維護CMDB，比如一名桌面工程師，在修電腦的過程中，把一臺電腦的操作系統(tǒng)升級了，這時他要走變更管理流程嗎？

　　我的回答是不應該，除非他不得到批準就不能對操作系統(tǒng)做升級，這時變更才具有意義，不然這種控制是完全負面的。如果這個工程師在修電腦的過程中，發(fā)現(xiàn)硬盤徹底壞掉了，需要更換硬盤，可能超出了他的權限范圍（這也需要考慮到具體業(yè)務定義），這時他不走變更流程根本無法得到硬盤，變更才具有一定意義。

　　但上述情況并不是最具代表性的，這樣的業(yè)務情形最具有變更管理的代表性：要對一段網(wǎng)絡做調整，但可能會影響到幾個系統(tǒng)項目，這時需要發(fā)起變更申請，由涉及到的幾個項目負責人與網(wǎng)絡領域的主管一同做變更的評估。如果認為有方法對應，可以進行此次變更的話，需要制作一個變更的實施方案，安排人員實施調整操作。實施完成，把CMDB中的信息更新。

　　變更管理的統(tǒng)計報表，可以從發(fā)起源統(tǒng)計，可以從CMDB的角度發(fā)起統(tǒng)計，也可以從變更本身的信息進行統(tǒng)計，比如變更的狀態(tài)、變更的分類、變更的人員等。

　　八．配置管理

　　配置管理模塊，核心的就是CMDB，這一點我就不再毒品啰嗦了，把配置管理的流程層面的一些點再說明一下。

　　CMDB的審計：CMDB審計是需要規(guī)劃好的，應該可以根據(jù)各種條件審計，比如根據(jù)某一類的組件，某一個項目的組件，還可以確定一定的數(shù)量進行審計（隨機抽取），也可以決定一定的比率（隨機抽?。?。審計的目的是為了檢查CMDB的數(shù)據(jù)正確情況，找出問題并修正。

　　CMDB的鎖定：CI在某些情況需要進鎖定，比如變更時，比如審計時。為什么要這樣呢？如果你對一個CI變更時，不鎖定這個CI的信息，會發(fā)生幾個地方同時對這個CI做信息更新，由于時間差，很可能把錯誤信息更新到CMDB中了；同時用戶在變更過程中調用CI信息的話，也會發(fā)生誤導。所以需要控制單線程對CI進行維護，在同一時間只能有一個對CI維護的動作進行。審計也是一樣，如果你審計開始時，這個CI信息一直在動態(tài)變化，不鎖定CI的話，審計無法進行，同時會審計出一個錯誤的結果。

　　配置管理的信息可以被許多模塊調用，需要規(guī)劃到CI查詢的畫面，然后置入到事件、問題、變更、操作等模塊中。CMDB的人機界面相當關鍵，要盡可能方便調用、查詢、操作。

九．操作管理

　　操作管理為了處理那些非事件、問題、變更等事務，比如機房巡檢、定期的機器清潔、檢修。操作管理可以創(chuàng)建作業(yè)，作業(yè)的來源有兩種來源。一種是直接創(chuàng)建的，比如臨時要對一臺設備做檢測；一種是根據(jù)周期性作業(yè)計劃產(chǎn)生的，比如服務器每日要檢查數(shù)據(jù)文件、表空間使用情況、JOB運行情況、操作系統(tǒng)日志。操作管理與能力管理中的監(jiān)視計劃存在許多聯(lián)系。

　　操作管理有一種東西需要特別，就是服務日歷。什么是服務日歷呢，跟客戶簽訂運維合同時，我們承諾我們的服務是8*5或16*7，這種承諾表示在這個時間期內(nèi)，我們周期性的任務是與之相配的。比如我們上面說的服務器巡檢，如果每4小時需要做一次，我們跟客戶簽的是一年8*5的合同的話，那么我們每周要做5*2次巡檢，這個次數(shù)是事先定義好的。

　　每個項目的服務日歷可能不同，這表示每個項目都可能存在一個服務日歷。根據(jù)這個服務日歷，我們在系統(tǒng)中制作出一個周期性的計劃，系統(tǒng)根據(jù)服務日歷與計劃內(nèi)容，每天提前生成出作業(yè)指令給工程師。計劃上還定義了標準的工時要求與作業(yè)要求，工程師每天把這樣指令做完，然后把相關的作業(yè)關閉，并留下相應的實際工時，這就是操作管理的核心。

　　操作管理主要功能點有制作計劃、創(chuàng)建作業(yè)、作業(yè)處理、作業(yè)關閉、統(tǒng)計分析，功能界面是相對簡單的，但這個模塊可以把除事件、問題、變更之外的工程剩余活動有效管理起來，而且可以保證你的服務作業(yè)得到強制執(zhí)行。它可以針對每一個批量計劃做分析，分析執(zhí)行如何，花費了多少服務資源。要注意的是操作管理與事件管理沒有做程序接口，就是說如果工程師在巡檢時發(fā)現(xiàn)故障，需要手工在事件管理創(chuàng)建事件，而不是自動去觸發(fā)事件。

　　十．任務管理

　　任務管理的本意是為了管理我們的管理資源，這是針對我們公司自身的運維管理特點設計的。每年我們做許多管理改善的工作，做很多培訓，開許多會議，我們一直想分析一下花在管理上的資源是多少，希望把管理工時與直接生產(chǎn)工時做一個比率分析。這是管理效率提升的非常重要的基礎數(shù)據(jù)。

　　比如領導要求各個領域開展員工能力提升活動，在任務管理中，只需要部長生成一個任務，派給各個業(yè)務主管，任務中標明要求完成的時間點；每個業(yè)務主管接到這個任務，展開作業(yè)，作業(yè)過程的記錄與工時會不斷增加在這個父任務上，一直到完成審請關閉時；當每一個子任務都關閉時，父任務可以關閉，統(tǒng)計出花費的資源情況，任務可以多層分解，甚至可以分解到每一名員工身上。這可以加強任務的控制力度，也會控制管理人員過度使用資源。

　　任務管理更多是為了管理者的工作而設計的，這也是運維服務作業(yè)中最后一塊沒有被記錄的話動。這樣下來后，事件、問題、變更、操作、任務就構成了任何一個運維服務人員，無論他是領導還是一線員工的作業(yè)平臺，只有監(jiān)視所有的活動，其資源使用才被全部監(jiān)視。

　　任務管理的報表有針對任務執(zhí)行情況的，還有橫向分析任務類型的，即任務的資源占用情況。如果數(shù)據(jù)積累足夠多時，這種分析展開，會讓我們非常吃驚，因為運維服務的大量資源是被無效使用的。這樣運維服務管理才有改善的方向與具體指標。

　　十一．SLM管理

　　某種程度上，我們的ITSM系統(tǒng)并沒有實現(xiàn)真正意義的SLM管理，系統(tǒng)中并不關心SLA制訂出來前的過程，也沒有把UC與OLA等納入其中，我們只把制訂出來的SLA設置在系統(tǒng)中，以實現(xiàn)監(jiān)控與作業(yè)。所以以下說的是SLA的管理實現(xiàn)方式。

　　SLA在我們業(yè)務中分為故障解決率與Q指標，EUS（客戶滿意度）是另一個緯度的數(shù)據(jù)，不在此列。故障解決率是指在規(guī)定時間內(nèi)完成事件處理的百分比，Q指標是持續(xù)運行時間。

　　具體談一下我們的實現(xiàn)方式。前面說的服務日歷是很重要的一個基礎數(shù)據(jù)，沒有它，SLA的計算全部會錯。我們把事件分成了5個等級（SLA只適用于事件處理），每一個項目都會針對每一個事件等級設置解決時間要求值（比如一級事件需要2小時，二級事件需要4小時，三級事件6小時，四級事件8小時，5級事件12小時）。

　　這里定義的時間值是與服務日歷匹配的，比如服務日歷定義5*8是指周一至周五的8：00-12：00，14：00-18：00。如果一個一級事件發(fā)生在周五的1 7：00，即便是第二周周一的8：30解決，也沒有違反SLA（雖然現(xiàn)實中我們會馬上處理，但SLA計算是如此）。

　　另外Q指標的定義是這樣的，每一個項目要定義清楚到底哪一個事件等級會納入Q指標的計算中，比如一級、二級事件的故障時間（從事件創(chuàng)建到事件解決）會納入計算，三、四、五級的事件故障時間就不納入計算，這樣隨時可以計算你當前的Q指標是多少。

　　SLA設置完成后，就會在事件中就用。當你把事件定位在一個項目時（CI），你選擇了事件等級，此時系統(tǒng)會調出事件解決的時間要求；當你創(chuàng)建完成時，系統(tǒng)開始倒計時。SLA的報表主要是針對故障解決率與Q指標的，只是統(tǒng)計的緯度是多樣的。

十二．知識庫管理

　　知識庫管理考慮現(xiàn)實情況，我們沒有做得太復雜，運維服務的知識有較強的時效性，更新較快。這里說的知識是針對故障處理方面的，并不是指員工的技能或知識培養(yǎng)方面，這與通常說的KM有不少區(qū)別。

　　運維過程中的知識非常具有針對性，所以沒有把通用的知識納入考慮，都是從項目的角度提出來。知識的創(chuàng)建有三個來源，事件生成、問題生成、手工創(chuàng)建。為了便于查找，我們的做法是以項目為綱，以分類為目，以關建字為輔，即最根本的分類是項目，然后是根本事件問題的分類，最后是用關鍵字，用這幾個手段查找知識點，供工程師處理事件時調用查看。

　　無論知識是從事件或問題或手工創(chuàng)建，都會有一個審批的過程控制知識庫的更新，還可以設置知識有效期限。另外，知識庫的創(chuàng)建可以做一些統(tǒng)計與分析，看哪一個團隊的知識復用較多，哪一種類型的知識較多。對于知識的利用，不建議納入系統(tǒng)考慮，因為在軟件中難以識別，靠點擊意義不大。一個人打開知識看后，可能發(fā)現(xiàn)根本不是他想要的，或者他只是借鑒看一下，這時強迫按鈕操作沒有意義。

　　十三．調查管理

　　調查管理原本是希望改變以前手工發(fā)郵件采集滿意度調查的做法，設計時，發(fā)現(xiàn)可以對象化，做得更靈活些。我們是這樣考慮的：可以設計許多問卷，可能是針對客戶滿意度的，可能是為了調研我們的服務方式改進方向的，也可能是為了解服務產(chǎn)品化的潛在空間的。問卷設計好后，可以生成調查任務，一個問卷可以被無限調用，而調查結果是針對調查任務而不是針對問卷的。

　　調查可以直接發(fā)網(wǎng)址到客戶郵箱（取自客戶數(shù)據(jù)），也可以直接把問卷發(fā)過去。如果是WEB采集數(shù)據(jù)，可以生成用戶名與密碼發(fā)到客戶郵箱，用戶登陸系統(tǒng)填寫，也可以手工回收。但WEB是省力的，因為調研結果由系統(tǒng)自動生成。

　　有一些細節(jié)需要考慮，比如任務的開始與結束時間決定問卷填寫開始與停止，是不是設置必填與可選，是翻頁填寫還是整頁顯示，甚至問卷的答案選項與分值設置，還要注意調研對象散與客戶資料的集成（從某一個客戶組織選擇一定百分比），還有CMDB（針對某一個系統(tǒng)或項目）的接口。

　　基本上把我們大的模塊寫完了，有些大雜燴，有些地方不夠深入，也沒有把一個ITSM系統(tǒng)每一個模塊應該具備的元素提煉好，象一些績效點沒有成體系寫出來。但上述許多設計仍然是國內(nèi)公司一段時間內(nèi)較難企及的，這里包含許多年來各種各樣的思考，軟件的、管理的、ITIL的，對運維業(yè)務本質的理解。從事這種系統(tǒng)開發(fā)的公司或個人能知道其中的價值。

來源：IT168