IT維運管理IT維運管理- 從現有環境到雲端服務
雲端服務雖是一個新觀念，其實它是由主機代管(host computing)、刀鋒伺服器、網路、虛擬化、自動化(automation)及服務目錄(service catalog)等現有技術建構而成。它的挑戰是：如何在「維持服務水平、縮短提供服務的前置作業時間」並同時達到「降低成本」等雲端服務所標榜的目標。但各位細想：這些目標何嘗不是多年來我們對IT營運管理所追求的。
這幾年，BMC (註一)因應虛擬化及資料中心自動化潮流推出server 及network automation 工具並獲得Cisco認可並將前者內建在其伺服器一起出貨(註二)。去年，它成功地結合其BSM(Business Service Management)管理平台和Amazon EC2 雲端服務使得EC2的使用者可經由BSM以同一標準控管其私有雲端服務(private cloud)及EC2 (註三)。本文即和各位分享BMC在虛擬化管理、資料中心自動化及雲端服務領域耕耘的心得及建議，就如上述，它對現有的IT環境也適用。
建議一：你可將私有雲端服務(無論貴公司是否要建立)所訴求的「虛擬化」、「自動化」及「服務目錄」視為現有的IT環境努力的目標。
「虛擬化」在節能省電及透過虛擬機(virtual machine)所帶來的便利性已是大家耳熟能詳，在此就不再贅述。
「自動化」主要是著眼於將日常一些固定、一般、重覆性的工作(例如OS、DB、AP server等制式軟體安裝)自動化，使得MIS可在最短時間內提供業務所需的運算資源以利公司業務推展。(誠然「虛擬化」可協助這方面，但有些服務仍需實體機所提供的運算能力)。
「自動化」另一個重點是：針對系統/服務上線後，相關的軟體、網路及儲存設備之組態變更、軟體升級及補丁(patch)等管理工作，如何透過工具以「系統化」的方式進行；它包含應有的流程(變更申請、同意)及標準作業程序。前者除了以電子表單落實之外，諸如密碼變更、帳號申請、增加硬碟空間等日常的需求申請，BMC建議提供「服務目錄」給使用者點選，這類需求應可由服務台(service desk)同仁或啟動後續相關(自動)流程來滿足。
至於標準作業程序，因為是以工具代替人工進行這些變更並留下變更軌跡，其落實的遵循度及事後稽核的能力則可顯著提升；萬一有問題時，則可透過比對變更前後版本的差異，縮短問題查找的時間。Cisco將其自家網路設備搭配它認證過的刀鋒伺服器、EMC儲存設備、VMware虛擬化軟體及BMC自動化管理軟體即是上述這些理念的具體實現(詳見註二)。
落實「自動化」的關鍵在於指揮家(orchestrator)，就如同交響樂團的指揮家，如圖一所示，它有條不紊串起一個資訊服務相關流程及工具。反之，如圖二所示，對使用者而言，MIS就會如迷宮，對使用者及服務提供者而言都事倍功半。
資訊中心重要的資產「人」因為上述自動化的協助，使得他們有更多的時間去做更有創意、開發新業務所需要的資訊支援系統的工作。
建議二：建立一個正確、即時記載資料中心相關軟硬體設備組態的系統
就如同製造業仰賴ERP系統詳實記載原物料、半成品、成品數量及成本，對於資料中心相關軟硬體設備的組態，我們也需要一個系統來管理，這包含資料庫及相關的管理軟體，這個資料庫就是CMDB (configuration management database)。
數年來，已有一些CMDB實作的例子，有成功也有失敗而以後者居多；BMC分析其失敗原因，主要可歸納成幾點。
(一) 在組態變更後，並沒即時更新CMDB而導致其正確性與日漸減，漸漸也沒人用，一個逆向循環於焉開始，跳脫它的關鍵在於相關變更動作和CMDB的整合。如圖三所示，除了資產管理之外，其它諸如變更、組態、事故/問題管理等除了在事前要查詢此資料庫以了解當時的組態，更重要是在變更後要能將最新組態「自動」更新到資料庫。在此要特別強調「自動」更新這點，以往由於缺乏環繞資料庫而整合的工具，工具各自為政並夾雜人工更新動作而導致維護CMDB資料正確性窒礙難行。
上述「指揮家」是實際「自動」更新到資料庫的關鍵人物。
(二) CMDB不只是資產清單，它還必須記載資產之間的關係，例如網路銀行系統是由哪些伺服器、儲存設備、路由器、應用伺服器及應用軟體組成? 各組成元件的組態、版本是什麼? 有了這些資訊，事故發生時(例如伺服器-A 異常)，才能判斷那些業務被影響，從而訂定優先處理順序。
再者如圖四所示，資料中心在CMDB導入之前應已有幾份各別記載相關資產的資料庫或文件，CMDB的聯邦(federate)機制就極為重要；透過它，CMDB就如圖書館的查書目錄，它扮演仲介的角色而不需將這些現有資料都併入CMDB，這對CMDB未來擴充性及實用性都助益良多。CMDB該做的是：以業務(例如網路銀行)的觀點分析歸納相關資產的關係，作為確保IT提供的服務合乎業務的需求的重要基石。BMC提供的Atrium (大廳) CMDB即能達到上述目標的最佳選擇，值得你參考。
建議三：能精確追蹤及預測所提供的服務的成本
「追踨」這個面向是指我們必須知道，從業務需求的觀點，它使用到多少運算資源(CPU、儲存空間、支援人力及WAN頻寬等)。對公共雲端服務(public cloud)提供業者而言，據此才能向客戶收費(若是依使用量收費的客戶)；對現有IT環境而言，若貴單位實施內部收費，則是內部收費的依據。無論是對內或外部客戶收費，如何以最短時間提供出所需的運算資源及降低維運成本是極為關鍵；對雲端服務提供者而言，它更是獲利的核心競爭力。
「預測」這個面向則泛指根據過往使用記錄，以業務需求觀點，來判斷目前它使用的運算資源是否趨於飽和並參酌最新科技趨勢，幫它規劃未來所需的運算資源規格。
要做好「追踨」及「預測」，上述「自動化」的機制及CMDB的建置之重要性就很明顯。
建議四：根據業務需求，提供不同「服務水平」等級的服務
對公共雲端服務提供者而言，這是必備的；對現有IT環境而言，無論是否有內部收費，它可協助訂定事故處理及資源配置的優先順序，並確保客戶滿意度可被衡量。很明顯地，若缺乏上述「自動化」、CMDB、「追踨」及「預測」機制，我們要憑藉什麼去制定不同服務水平等級?
上述其實就是「IT治理」的範疇，其精髓在於：透過機制、流程及適切的工具輔助來治理IT、設定衡量標準並從中分析、歸納出待改進的地方進而訂定改善對策；如此，我們就能愈來愈好。否則，若連問題都不知道，更遑論如何改善。
最後，就如台北都會區的捷運系統是分段建設、通車，上述四個建議可分階段達成；若規劃妥善，每一個階段的完成，我們即可享受其帶來的效益。
註一：叡揚在1992年即代理BMC主機(Mainframe)相關管理工具及開放系統的Patrol（系統監控）、SQL BackTrack（資料庫復原）、Control-M （批次作業）等管理工具
註二：Cisco UCS : http://media.cms.bmc.com/documents/bmc_cisco_announce_unified_computing_system.pdf
註三：Amazon EC2 : http://www.bmc.com/news/press-releases/2009/BMC-Software-Leverages-Amazon-Web-Services.html