證券行業(yè)也需要IT服務管理

　　從傳統(tǒng)概念講，機房建設，網絡建設，大型存儲建設，從新的技術來說，虛擬化，自動化，包括開源，包括數(shù)據(jù)安全，網絡安全，很多方面的元素可以去談，這都是我們金融行業(yè)，如證券行業(yè)整個數(shù)據(jù)中心運維當中必不可少的。ISO9001認證

　　原來做Mainframe的時代，我們?yōu)槭裁磳?a href="/news/ITfwywbzzqyj_3982.html">證券IT服務管理需求并不是很強？不需要協(xié)調太多的人，也不需要設計太多流程，也不需要面臨太多的溝通的環(huán)節(jié)。幾個系統(tǒng)管理員管兩臺大型機，溝通環(huán)節(jié)少，緊湊高效，所以IT服務管理需求并不強烈。但是當公司在2001年引進新一代集裝箱系統(tǒng)之后，變成了四五百臺機器，大量的NT機和小型機。我們學過IBM大機人都知道，在大機年代，所有的系統(tǒng)error，你只要能熟讀手冊，當然那些原版的白皮書排氣來很多的ErrorCode都是可以查得到的，但是當我們引進開放式系統(tǒng)，很多復雜的問題，涉及到網絡，主機，數(shù)據(jù)庫，甚至應用，很難定位其根本原因，而且隨著團隊的專業(yè)化分工，很多問題的溝通成本加大，沒有高效管理流程，一大堆問題就出現(xiàn)了。我本人在這方面特別有感受，這也是我今天主要想和大家分享的，ITIL在企業(yè)管理如何定位，ITIL在企業(yè)里如何落地。進入運維的數(shù)據(jù)中心，可以感覺到在用原來的管理理念去管理數(shù)據(jù)中心是不行的，為什么？ISO14000認證

　　剛才我其實已經簡單的概括了一下我們實施的背景，其實沒有2001年證券數(shù)據(jù)中心大集中，IT服務管理的流程和理念也許至今還是會離我們很遙遠，因此我個人認為，任何管理的改變和措施的實施都是要有一個背景，也就是一個推動力去推動。那當時我們面臨一個什么樣的挑戰(zhàn)呢?原來其實我們的IT系統(tǒng)是一個分布式的架構，在上海我們只要管到在上海遠洋這塊的業(yè)務就OK了，但是公司2000年做戰(zhàn)略調整，實現(xiàn)集裝箱及系統(tǒng)數(shù)據(jù)大集中以后，我們全球差不多400多個網點要集中來訪問我們位于上海外高橋保稅區(qū)內的全球數(shù)據(jù)中心，通過專線和VPN連進來差不多170多個網點，應當說中遠是國內企業(yè)海外布點最廣的公司。因此，我們面臨第一大挑戰(zhàn)是全球性。

　　第二大挑戰(zhàn)是復雜性，大家可以看到，我們的應用是非常復雜的，根據(jù)麥肯錫06年的報告，集裝箱行業(yè)的數(shù)據(jù)中心系統(tǒng)是最為復雜的系統(tǒng)，所以在我們整個系統(tǒng)里面，差不多大大小小有50多套系統(tǒng)互相交集，相當復雜。因此，動任何一個系統(tǒng)，就有可能影響到其他系統(tǒng)，可謂牽一發(fā)動全身，集裝箱系統(tǒng)非常復雜，但是高性能的要求和我們銀行，金融行業(yè)是沒法比的，集裝箱行業(yè)整個價值鏈特別長，他整個數(shù)據(jù)交易鏈條非常長，這就導致業(yè)務對系統(tǒng)的依賴程度特別高，對系統(tǒng)每個環(huán)節(jié)的可用性要求也非常高。當然，從單個交易的高可用性要求，我們無法和金融及證券交易所相比。此外，我們各種數(shù)據(jù)庫IT團隊和IT管理面臨很大挑戰(zhàn)，我們感覺應付不過來。都有，這其實當時不是我們定的，因為我們引進其他行業(yè)公司的應用軟件一起打包引入的。同時，我們還有龐大的開發(fā)測試環(huán)境，預生產環(huán)境，災備中心。

　　由于我們實施數(shù)據(jù)中心大集中，過程當中遭遇來自于各方面的阻力，包括對于新系統(tǒng)地servicecal就像雪花一樣飛來，無論是應用的，還是網絡的，還是數(shù)據(jù)的，還是用戶使用方法的。如果沒有好的IT支持和服務管理流程，我們根本無法有效的支持用戶和前瞻性的發(fā)現(xiàn)系統(tǒng)問題。于是2000年開始，我們就踏上了IT服務管理的實踐道路。

　　在ISO20000其實是蠻多的，因為這兩年隨著我們各大企業(yè)用戶成熟度和提高，2002年談ISO20000，在2000年的時候，其實還是很早的，那個時候和其他用戶同行做交流，幾乎提不到這個概念，是比較早的，大家看到這個模型，這是當時惠普ITIL模型，最早是給我們做咨詢顧問，我們也是引進了一套產品，作為整個IT服務管理體系的工具平臺。

　　很多咨詢廠商都會講到，我整個IT服務管理歷程是怎么樣的？應該沒有最好的，只有最適合你的，最適應你的才是最好的。我覺得這應當是黃金法則。包括我和交通銀行，金融的、證券他們交流也是，他們在說什么是最適合你企業(yè)的，那就是看每個階段我們希望解決的最關鍵矛盾是什么，因為資源是有限的，想全上，但是你有那么多資源嗎？所以要根據(jù)企業(yè)的自身情況，去解決你最關注的問題。當然，在規(guī)劃上如果有條件可以整體規(guī)劃，分布實施。

　　在2001年到2002年，在IT服務管理里面，我們做了Incidentmanagement-故障管理流程和ServiceDesk—服務請求流程（ITIL10個模塊中的2個）。前面說過，2001年我們開始做大集中，大集中要解決的問題就是收編，新的應用面臨著很大的問題，一個就是客戶化的問題，還有就是用戶對系統(tǒng)不熟悉，培訓不夠，對系統(tǒng)抵觸情緒很強烈，不愿意用你的系統(tǒng)，報出一堆問題，在建立這兩個流程之前，各種問題像球一樣互相傳來傳去，沒有人統(tǒng)一跟蹤，分析，往往一個問題導致的多種現(xiàn)象，分在一堆人手上處理，大家還不知道就是一個問題。因此，當時的狀態(tài)是沒有一個統(tǒng)一系統(tǒng)進行管理，沒有統(tǒng)一團隊進行管理，沒有統(tǒng)一的溝通渠道，沒有統(tǒng)一的記錄平臺，沒有責任人，沒有響應要求和解決要求，沒有上報機制，沒有跟蹤機制，沒有相應的績效考核，沒有相應的統(tǒng)計報表，也沒有一線二線處理的知識庫等等。而我們后來建了這套體系流程，配備了相應的組織架構，推廣了有效的工具，問題得到大幅的緩解。我們相繼在北美、亞太、歐洲建了一個區(qū)域支持中心對問題進行一線處理，處理不了的問題升級到我們一個集中的24*7HELPDESK，HELPDESK解決不了，再派發(fā)到二線支持，包括業(yè)務和IT。這套系統(tǒng)現(xiàn)在對于各位同行來說可能好像很普通，大多數(shù)數(shù)據(jù)中心都這么做了，可是在2001年、2002年的時候，還是很先進的。這兩個流程的上線為我們的系統(tǒng)大集中做出了不可磨滅的貢獻。

　　我們進行ITIL服務管理的第二個階段是實施變更管理，也是我作為一名ITIL_master最為關注和認為控制數(shù)據(jù)中心風險最為重要的流程之一，另外一個是發(fā)布管理，稍后可以再講。

　　變更管理，我不知道各個企業(yè)是不是已經上了。即使上了，有沒有用的很好？這個差別還是很大的，其實變更管理我們在之前并沒有重視。直到2003年，我們公司發(fā)生了解次到現(xiàn)在想起來都非常驚心動魄的“雙10事件”，那次正好是特地選在國慶期間做一個存儲改造“從DAS到SAN”的改造，后來發(fā)現(xiàn)我們那臺核心主服務器不知道什么原因不能正常啟動，我們想主服務不工作問題不大，按照應急預案，我們備用服務器2個小時就能完成接管，可是災難的事情發(fā)生了，我們切換過去之后，雖然設備能夠啟動，但是應用根本起不來。原來，原來半年來在主服務器做的那么多變更，在備用服務器上都沒有實施，或者實施后沒有經過驗證。由于沒有變更管理流程，所有變更沒有統(tǒng)一的記錄，審核和批復，不管影響多大的變更，TEAM負責人同意就可以實施，不管是否影響到其它部件或者應用，由于沒有變更管理，那臺可憐的備用服務器成了擺設。由于沒有變更，系統(tǒng)的問題不知道是什么原因造成的。CIO不能接受這個事實，所謂養(yǎng)兵千日，用兵一時卻用不上，當時我們做運維的壓力非常大。那次的事故后來整整影響了我們2天，才最終把問題找出來。那次以后，我們CIO明確要求，我們拿出整改方案。我們運維團隊在整個事件當中深受教育，隨即啟動了變更管理流程，對數(shù)據(jù)中心所有對生產環(huán)境的操作進行嚴格的控制和記錄。建立的方法，是先細后粗。即先把所有在數(shù)據(jù)中心可能做的變更全部列出來，大撒網，然后再經過討論進行分類，哪些是重大變更，較大變更，日常變更，一般變更，還有哪些情況下允許緊急變更。變更的分類是根據(jù)其可能對系統(tǒng)產生的影響，而不是技術實施的難度。即使技術實施非常簡單，可能產生的潛在風險很大，我們也應當把它列為重大變更。我們還成立了變更管理委員會，委員會的最高領導是我們的CIO，負責對重大變更的批復。變更流程做起來以后，大大減少了由于誤操作，或溝通問題，或變更沖突，主備系統(tǒng)不一致等導致的系統(tǒng)可用性風險，同時，每周要做的所有變更每個干系人都會提前知道。

本頁關鍵詞：證券行業(yè)也需要IT服務管理