[運維] 第二篇：數據中心運維IT運維項目建設之我見

      運維項目千千萬，今天重點講一下IT服務管理的項目，也是在過去幾年各個企業數據中心都在建設的東東：ITIL、綜合監控和運維自動化。先看ITIL邏輯架構圖：

         這是根據ITIL最佳實踐理論和企業運維實際結合的ITIL邏輯架構圖。最底層是基礎架構管理層，在架構管理層運維人員通過人肉或工具對IT環境進行管理。綜合監控平臺的建設基本上在這一層，綜合監控平臺的目標是“全監控和全覆蓋”（關心綜合監控的朋友可以看我其他的監控帖子）。監控的核心是什麼？綜合監控管理平臺。通過綜合監控管理平臺，將IT環境中的各個管理工具產生的事件信息進行統一採集和處理，重要的告警事件將發送到IT服務流程平臺上，進入事件管理或者工單管理流程中進行處理。需要通過基礎架構管理層往上送的數據還有性能數據和配置信息。CPU利用率這類的性能數據可以做ITIL中的容量管理，配置信息可以送到配置管理模塊中，成爲CMDB數據源的一部分。說到這裏，基本上還是技術層面的事情，在往上就是服務管理層，這更偏重於管理方面。在服務管理層，根據ITIL最佳實踐，或者ISO20000的要求，通常建設事件管理（服務檯屬於事件管理一部分）、問題管理、變更管理、發佈管理、配置管理等。最上層是統一展現層。看到統一展現層，大家會發現缺少服務管理層相關的模塊。這裏面原因有兩個，一個是這張圖是我08年時做的，有點老；另一個原因是我在實際的客戶現場，通常看見的是監控和流程是兩個界面，並不互相統一。但是兩個界面是不是就意味着沒有關聯嗎？不是！兩個的關聯更多的是體現在後臺和其他方面：
1 單點登錄
2 事件在監控平臺和流程平臺中的運轉應該是一個閉環。也就是事件觸發工單，當工單解決後關閉，那在監控平臺上的事件也應該被關閉。
3 監控數據的流轉，主要是告警事件、性能數據和配置信息。
4 運維大屏全面展示業務的運行狀態和工單處理情況。
        圖上還缺少運維自動化，當時業務高速建設時期已基本結束，開始進入運維建設時期，運維自動化還沒有進入主題，所以就沒有畫。再看一張全的圖：

          這是2010年做的運維建設架構圖，那時建行開始建設運維自動化項目，選型搞的沸沸揚揚，IBM、BMC、HP全力出擊，測試進行幾輪，逐輪淘汰，在業界影響很大，更多的運維人員瞭解到原來運維自動化工具能給我們的運維帶來這麼大方便和價值！在那之後，光大銀行、中信銀行、招商銀行等都開始建設自己的運維自動化平臺，當然各自選型都不一樣。國產運維自動化廠商也走上舞臺，更接地氣、更靈活的特點也使得他們的產品進入實際項目落地的階段。理想、神碼、宇信易誠等都各自在自己的視野內開疆拓土！例如神碼和宇信在券商的舞臺上你死我活，這就不多說了。
         下面談談我對運維項目落地的一些理念。首先是一句話“看大做小，分步實現”。什麼意思呢？做事先看全局，看清楚後在落子，落得時候小心翼翼，一步一步的實現自己的規劃，有一張圖，大家可以借鑑一下：

          客戶想實施運維項目時，通常有一個困惑，我到底是先做監控，還是先做流程，或者兩者都做。根據我的實際經營，這幾種都可以，都有成功的經營，也都有失敗的案例。這不是廢話嗎？還真不是！企業在運維項目落地之前先要搞清楚自己企業的實際情況，再結合預期要實現的目標、項目成本等，制定自己企業落地的路線圖，以及近期、中期和遠期目標。比如我企業監控已經做了一些了，但還不夠全面，那就可以做監控；我企業服務流程已經有了一些在運行，只是不夠成體系，那就可以做流程；再或者我企業近期希望可以將運維能力和水平體現出來，那就可以做ISO20000和ISO27001等，不一而足，沒有一定之規。但是不管那條路，都有一些基本原則要遵守：
1 可以先考察同類型企業運維建設情況，所謂取經
2 細緻瞭解自身運維實際情況，選定可行的項目範圍和目標，所謂知彼知己
3 選擇有豐富實施經驗和實施人員的公司協助企業建設運維項目，所謂知彼
4 發動更多的人蔘與到項目中，尤其是領導，有領導的支持，可以事半功倍，所謂上級支持
        咱們這篇文章只是大致聊聊，真正的故事要比講這些經驗有趣的多，好玩的多！以後有機會再聊！