實(shí)戰(zhàn)剖析：13步設(shè)計(jì)出一個(gè)ITSM系統(tǒng)

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

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

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

　　一．系統(tǒng)目標(biāo)

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

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

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

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

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

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

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

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

　　二．系統(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)用時(shí)才能進(jìn)一步驗(yàn)證。

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

　　三．流程控制

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

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

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

六．問題管理

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

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

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

　　七．變更管理

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

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

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

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

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

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

　　但上述情況并不是最具代表性的，這樣的業(yè)務(wù)情形最具有變更管理的代表性：要對一段網(wǎng)絡(luò)做調(diào)整，但可能會影響到幾個(gè)系統(tǒng)項(xiàng)目，這時(shí)需要發(fā)起變更申請，由涉及到的幾個(gè)項(xiàng)目負(fù)責(zé)人與網(wǎng)絡(luò)領(lǐng)域的主管一同做變更的評估。如果認(rèn)為有方法對應(yīng)，可以進(jìn)行此次變更的話，需要制作一個(gè)變更的實(shí)施方案，安排人員實(shí)施調(diào)整操作。實(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)再說明一下。

　　CMDB的審計(jì)：CMDB審計(jì)是需要規(guī)劃好的，應(yīng)該可以根據(jù)各種條件審計(jì)，比如根據(jù)某一類的組件，某一個(gè)項(xiàng)目的組件，還可以確定一定的數(shù)量進(jìn)行審計(jì)（隨機(jī)抽?。部梢詻Q定一定的比率（隨機(jī)抽?。?。審計(jì)的目的是為了檢查CMDB的數(shù)據(jù)正確情況，找出問題并修正。

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

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

九．操作管理

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

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

　　每個(gè)項(xiàng)目的服務(wù)日歷可能不同，這表示每個(gè)項(xiàng)目都可能存在一個(gè)服務(wù)日歷。根據(jù)這個(gè)服務(wù)日歷，我們在系統(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ì)分析，功能界面是相對簡單的，但這個(gè)模塊可以把除事件、問題、變更之外的工程剩余活動有效管理起來，而且可以保證你的服務(wù)作業(yè)得到強(qiáng)制執(zhí)行。它可以針對每一個(gè)批量計(jì)劃做分析，分析執(zhí)行如何，花費(fèi)了多少服務(wù)資源。要注意的是操作管理與事件管理沒有做程序接口，就是說如果工程師在巡檢時(shí)發(fā)現(xiàn)故障，需要手工在事件管理創(chuàng)建事件，而不是自動去觸發(fā)事件。

　　十．任務(wù)管理

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

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

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

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

　　十一．SLM管理

　　某種程度上，我們的ITSM系統(tǒng)并沒有實(shí)現(xiàn)真正意義的SLM管理，系統(tǒng)中并不關(guān)心SLA制訂出來前的過程，也沒有把UC與OLA等納入其中，我們只把制訂出來的SLA設(shè)置在系統(tǒng)中，以實(shí)現(xiàn)監(jiān)控與作業(yè)。所以以下說的是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)方式。前面說的服務(wù)日歷是很重要的一個(gè)基礎(chǔ)數(shù)據(jù)，沒有它，SLA的計(jì)算全部會錯(cuò)。我們把事件分成了5個(gè)等級（SLA只適用于事件處理），每一個(gè)項(xiàng)目都會針對每一個(gè)事件等級設(shè)置解決時(shí)間要求值（比如一級事件需要2小時(shí)，二級事件需要4小時(shí)，三級事件6小時(shí)，四級事件8小時(shí)，5級事件12小時(shí)）。

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

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

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

十二．知識庫管理

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

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

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

　　十三．調(diào)查管理

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

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

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

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

來源：IT168