早在20世紀90年代，國外IDC（數據中心）已經引入ITIL進行“軟升級”。目前，國內一批意識和思路領先的規模較大的IDC已經嘗試引入ITIL，在不斷的探索中打造全新理念的IDC。
2006年上半年新一輪互聯網投資熱潮，拉動IDC業務快速回升。據預測，2006年中國IDC業務有望突破20億元，並以30%的增長率高速發展。尤其是，隨着短信、語音、視頻、3G、電子商務以及外包業務的發展，IDC增值服務將迅速發展。未來IDC市場的競爭焦點就在於如何爲企業提供優質的個性化增值服務。
增值業務的快速發展，必將挑戰IDC傳統以託管服務爲核心的運作管理模式。目前 IDC業務收入仍以基礎託管服務爲主，其比重高達88.4%。在以託管服務爲核心的業務模式下，用戶普遍關心的問題仍然是網絡帶寬和網絡穩定性。只要網絡 基礎設施足夠穩定、提供足夠帶寬、能夠快速訪問，那麼用戶就會比較滿意。
但是，增值服務不僅要求IDC具備良好的網絡基礎設施，還要求IDC具有較高的 運維管理水平，比如以客戶爲中心的服務流程、自動化的運維平臺、高超服務技能的運維人員等。面臨新一輪競爭環境，IDC必須未雨綢繆，全面啓動升級戰。未 來誰能夠贏得客戶的滿意，那麼誰將贏得市場。
早在20世紀90年代，國外IDC已經引入ITIL進行“軟升級”。目前，國內 一批意識和思路領先的規模較大的IDC已經嘗試引入ITIL，在不斷的探索中打造全新理念的IDC。但是如何打贏這場“升級戰”？如何與競爭對手區隔開來 呢？讓我們先看看目前IDC運維工作所面臨的困惑。
傳統模式的困惑
相比國外具有成熟運作模式的IDC，目前國內IDC的運行管理主要存在四個困惑（見下表）。
第一、運維人員技能不足。大多數IDC是在幾十個運維人員的規模，很多人的處理能力不夠，往往一個人就能做的事情卻需要幾個人才能完成，人員數量總是減不下來，誤操作也比較多。
舉例來說，某IDC在UPS（不間斷電源）方面需要更換電源的一個模塊，由於操作人 員沒有充分準備好變更計劃，只簡單向部門領導報告一下就去做了，當天導致UPS不能正常工作，IDC的一些重要客戶發生宕機故障，又因爲處理緊急情況的能 力和技能不足，宕機一個小時之後才解決故障，影響客戶正常業務運作，最後按照合同賠給客戶一大筆錢。
國外IDC運維人員的技能都比較高，保守來算，國外一個運維人員所做的工作在國內可能至少需要兩個人才能完成。
第二、以業務爲核心的運維流程已不能滿足需要。從IDC市場發展趨勢來看，未來競爭的焦點是在同質化情況下怎麼做得精細化，怎樣時刻考慮客戶感受，從客戶角度制定管理流程和策略。
長期以來，國內IDC的運維流程以業務爲核心，主要去支持業務，沒有特別在意客戶感受。很多IDC的運維流程完全跟着業務走，什麼樣的業務流程就有什麼樣的運維流程，很多類似事情也是不同流程。
比如，代維服務有一個運維流程；數據存儲也有自己的運維流程。每項業務的運維流程都是按照業務的開通、合同修改等步驟而設，業務開通需要填一個單子，業務修改又是一個不同的單子，業務撤銷也是一個不同的單子。
在這種情況下，當面對同一個客戶的不同業務需求時，由於不同業務分散在不同的運維流程裏，IDC無法快速有效地給予客戶反饋和支持，客戶會感到等待時間特別長、服務效率比較低。
另外，由於運維服務沒有量化，比如明確規定多長時間響應客戶？多長時間處理完某個業務？中間哪個環節需要和客戶溝通，並通知客戶進展情況；因此很多時候客戶會感受到不被尊重或者沒有得到關心，從而感覺到不滿意。
因流程而引發的另一個問題是許多IDC的故障分級特別簡單、含糊，某些IDC甚至都沒有故障記錄，只是通過客戶的電子郵件進行處理，處理完之後給客戶回封電子郵件就行了，這也不便於進行分析統計，對故障進行分類，發現故障原因何在。
儘管IDC提供一個比較穩定的環境，但由於沒有做好這些細節，很多客戶會感覺不滿 意，因此，國內IDC需要從客戶角度來梳理運維流程，提升客戶滿意度。ITIL提供一套規範的流程，可以改變傳統以業務爲核心的運維流程。舉個例子，業務 的開通和修改，差別不是特別大，現在它們都提供不同的記錄單子，ITIL會把二者的運維流程進行整合和簡化，提高效率。
第三、自動化能力較弱。自動化體現在很多方面，不僅是流程自動化，還包括對資源信息的監控和管理。目前國內IDC自動化能力比較弱，在資源的分配、供給和調度方面，尚處在自動化初級階段，大多采用一些網管監控、資源庫等工具，這也導致運維的效率低，人員數量無法減下來。
一些監控信息的查詢或者展現方面不是太理想，比如從管理層的視角展現出他們想關注的 監控信息。另外，由於資源信息不準確，比如IP地址、網端、機架、機房等IDC提供業務所需要的重要資源，缺少自動化查詢和統計手段，目前大多數IDC只 是用Excel記錄或者放在數據庫裏，這樣運行半年之後，就開始斷網或發生故障，其原因就是沒有去採集和維護某些信息。
國外數據中心的自動化做得相當好。比如，當用戶需要在服務器安裝新軟件時，國內IDC操作人員需要拿着安裝盤去現場安裝；而國外IDC會提供一些自動化工具或自助服務功能，請用戶按照說明自動完成。
再舉一例，用戶把服務器託 管在IDC租用帶寬，可能會很關心流量問題，經常想了解一下每個月使用了多少流量，流量分佈情況怎麼樣。對於這種簡單的請求，國內IDC一般會在系統裏出 一個報表，再傳真給客戶，這些都是人力浪費；國外IDC一般請用戶直接在網站上訪問他們實時出具的報表，或者查詢他們想要的信息。
IDC的ITIL特色
不同行業、不同企業都需要結合自身特點來實施ITIL，IDC也不例外。相比其他行業來說，IDC的ITIL實施具有四個與衆不同的特點（見下表）。
首先需要結合eTOM模型來實施。eTOM是電信業務參考模型。大多數IDC的業務運作模式參考eTOM而建，運維管理體系、運維人員也都來自電信企業，因此，IDC實施ITIL不能脫離IDC實際情況，要結合eTOM來做。
其次，儘管ITIL的核心是十大流程管理，但是，在流程梳理時需要緊密結合IDC已 經形成的日常運維流程來實施。IDC在託管服務方面已經具備非常成熟的運作模式，也形成了很多運維管理流程和規範。比如，運維人員出入室流程（類似機房的 出入管理，但要複雜一些），設備的搬進搬出流程，業務的開通、修改和撤銷等，這些都是目前IDC日常運維中核心的、經常需要執行的流程。
在引入ITIL時，IDC不能完全照搬ITIL十大流程，必須對日常運維流程進行梳理之後，靈活地和ITIL結合起來。比如，在引入ITIL之後，人員出入室流程可能需要單獨列爲一個服務流程，因爲這是IDC經常要處理的事情，以便於用戶去IDC維護他們自己的服務器，或者來IDC參觀等。
再舉例來說，在ITIL流程設計中，一個變更管理流程需要體現出開通業務、修改業務 等不同情況的處理方式。而業務開通、修改和撤銷是IDC日常工作的主要內容，已經形成一套操作習慣和認識，如果簡簡單單地用ITIL的變更管理流程來代替 這些操作，就會很難推進下去。相反，要讓員工感覺到雖然增加了一個變更管理流程，但是以前的操作習慣沒有太大變化，而不是不知道從哪下手。
實際上，IDC實施ITIL流程最關鍵的是對已有獨立的業務流程進行梳理和整 合，重點抓住流程的操作步驟和控制環節，但又不會太大地改變原來的操作習慣。比如人員出入和設備的搬入搬出都可以放在服務請求管理流程裏，在這個流程裏， 只要能體現出來“在不同人員出入的情況下，不同設備搬入搬出的情況下，相應地需要審批哪些內容，哪些需要密碼確認”，就可以了。
舉例來說，IDC業務開通要做8件事情：準備電源、IP地 址、上架，通知用戶開通了業務、驗證等。如果一般企業實施ITIL變更管理流程，就不會考慮這8件事情，只會考慮是否提交變更請求，有沒有人做變更的復 查，並進行相應的風險審批，評估之後安排時間就可以去做變更，做完了之後再審查一下。
但是，IDC可能不會接受這種變更流程，因爲如果按照這種流程去做，他會覺得業 務的開通、修改比較模糊化。因此，這些具體的操作步驟，建議放在變更管理流程裏不同的模板中來做。也就是說，只有一個變更管理流程，但是在這個流程中，業 務開通要做8件事情都可以直接看到，也可以一步步去操作。這樣，運維人員就不覺得難以把握，或者是效率低了。
總之，IDC整個運維流程會遵循ITIL流程，但是不會改變原來操作的方便性，而且會更加規範，比如，以前風險評估可能只要寫在一張紙上就完了，現在需要實時記錄。
第三，強化資源管理。IDC的核心業務就是出租資源，因此必須管理好資源。否則，資 源不準確或出了問題，就會影響業務發展。IDC的資源管理與ITIL配置管理非常相似，但配置管理對資源的控制相對比較嚴格。實際上，大多數IDC資源管 理做得不到位，最大的原因是有些信息的自動化採集和更新沒有做到位；另外，IDC對資源的控制力度也非常弱。
比如，對於業務變化和設備變化，IDC缺乏強制措施去要求運維人員更新資源庫；大概每半年IDC會花費很多時間和精力從頭到尾梳理一遍資源庫，否則如果有新客戶申請某些業務，IDC就無法準確回答有多少資源可用。
因此，在資源管理方面有兩點建議：要有自動化資源採集工具，也要有一套資源分析和優化機制。
第四，關注組織架構設計。現在很多IDC的組織架構是比較傳統的企業組織結構，比如按照不同技術領域劃分爲不同部門，各個部門之間的溝通和協調方面不夠順暢。
ITIL所提供的組織架構是把人員劃分爲一線、二線、三線；一線人員記錄服務的呼 叫，並處理簡單故障；二線人員處理一線解決不了的問題；三線人員解決難度較大的問題。另外，ITIL還針對不同流程設置相應的流程經理，去推動每個流程的 實現。這種方式可以提高處理故障的效率，而且使相同數量人員的服務能力極大提高。
但是，需要注意的是，如果IDC完全按照ITIL來設計組織架構肯定有難度，因爲很難找到合適的流程經理來承擔這樣的事情。因爲流程要執行得好，主要不是靠執行人，而是靠流程經理不斷優化流程。
在當前的實踐中，建議IDC在初期可以建立跨職能部門的團隊。他們負責兩方面事情， 一是協調不同流程執行的問題；二是在解決問題的時候負責整個故障的分配和處理。他們一起對某個問題進行分析和處理，問題出來之後，先到這個團隊進行分析和 處理，然後再由相應技術部門做後續的故障處理。引入這種方式的目的是讓運維人員迅速反應，這在人員意識和技能還不能滿足要求時，不失爲一種過渡方法。
IDC實施ITIL三階段
對於IDC來說，實施ITIL主要分三個階段（見下表）。
第一階段是建立清晰的服務目錄、服務水平協議和IT財務管理流程。
服務目錄是IDC在運維服務方面能夠提供哪些產品，或者是提供哪些具體的服務，這些 產品或服務最終會涉及到基礎設施，比如帶寬、機架、防火牆、殺毒服務能力等。服務水平協議是針對不同的服務產品，能夠提供什麼樣的服務能力，比如80%的 客戶滿意度、多長時間內響應故障等。
服務目錄、服務水平協議是回答“IDC能提供什麼樣的服務”；IT財務管理流程是回答“這些服務是怎麼收費的”。
實際上，國內IDC已經具備以上兩個方面內容，但是不夠規範和細緻。比如他們在服務水平協議中承諾的服務條款比較隨意，有時候爲了能夠拿下這個項目，就承諾許多，但實際能力可能又做不到。因此，服務水平協議方面還應該借鑑ITIL的思路，儘量做到科學化。
大多數IDC的IT財務管理流程比較簡單，因爲現在主要是託管業務，按照流量收費或者包月就可以了。對於不同客戶怎麼收費的問題，還沒有細化。
而未來增值業務的計費就比較複雜和多樣化，比如怎麼對不同用戶收費，收費原則怎麼定，怎麼分攤等問題必須精細化，因此，財務方面的分攤和計費辦法就會更加複雜。在這方面，必須將技術手段與合理的計費方法結合起來，參照ITIL的框架進行實施。
第二階段是完善監控和服務支持體系。目前很多IDC都建設了監控體系，能夠採集到需要的數據，也能監控到整個網絡的故障，這方面基本上沒有太大問題。
但是，從ITIL角度來看，IDC在運維監控方面仍有待完善，比如需要建立事件管理、問題管理、變更管理，並完善資源庫，使後臺的維護工作與IDC日常運營工作緊密結合起來。
在完成前兩個階段的工作後，IDC基本上已經能夠良好運轉，同時也能夠讓客戶獲得一個比較滿意的服務和體驗。
第三階段是從IDC長期發展的角度來看，重點需要進行可用性管理和容量管理。在這方面，國內IDC可以借鑑一下國外IDC的好的實踐經驗。比如，一些資源動態分配、調度的能力，要儘量實現自動化，儘量減少執行煩雜的手工操作；安裝一些軟件時，不要每次都重新去裝，通過自動化的安裝和調度來降低可能出現的誤操作等。