隨著企業業務飛速發展，越來越多的系統和應用會同時進行上線和測試，運維部門會面臨大量的IT資源申請需求來保障開發測試部門的工作得以順利進行。而且隨著現有系統面臨用戶量劇增、過時硬件支撐能力出現瓶頸、開發架構的變更等多種因素挑戰，也會出現大面積申請IT資源的情況發生。因此企業內部IT資源的申請可以說是運維人員面臨的普通常見而又繁瑣耗時的基礎工作。

從非運維人員視角簡單看，應對IT資源的申請無非是提供個機器，安裝個系統、配置個參數、預裝點軟件，耗點時間罷了，如果企業自動化運維做的到位，可能運維人員在資源申請系統頁面拖拖拽拽就搞定了。大部分時間成本都耗在了填寫資源申請表格、走資源申請流程、溝通資源細節上面。但實際情況真的如普通用戶想得那么簡單嗎？

佛曰：三生，即生存、生活和生命。凡世間萬事萬物需歷三世磨煉、改造、升華，而至純至臻，止于至善。企業中IT資源的申請之路也是一個不斷的經歷痛苦、改進、優化的發展旅程，讓我們扒一扒圖化資源申請之三生三世那點事兒，看看能從中得到什么啟示。

圖化資源申請之前世，即生存之世

在企業內部申請資源傳統的方式是要填寫一份符合企業標準化的資源申請表格。里面的信息大概包括使用申請資源用于哪個系統、申請幾臺機器或虛擬機、機器或虛擬機的配置情況（CPU多少？內存多少？磁盤空間多少？網絡如何？）、機器上安裝什么樣的操作系統、操作系統版本如何、預裝什么軟件環境、申請人是誰、所屬部門是什么、申請日期、聯絡電話等等，如果緊急還要標注環境到位的期限（一般只要申請資源都會說急用，越快越好）。如下表所示：

前世之困惑

這種枯燥乏味的表格式的資源需求在企業中比比皆是，可想而知，當運維人員看到包含密密麻麻的文字信息的表格時，內心會有多少個南美羊駝在奔跑啊。**這種傳統方式的資源需求表格不僅缺乏直觀識別、認知周期冗長，而且無法判斷申請的資源之間內在關系如何、所屬系統如何、是否存在先后順序等等。**無疑造成了在交付資源的過程中出現反復和錯誤，既浪費了時間成本也影響了交付質量。

同時，**傳統方式的資源申請也給企業用戶帶來了另一個挑戰：即申請的資源需求可復用性差。**客戶申請的資源往往有相同的特征，例如申請中間件集群環境，每個AppServer除了IP、主機名信息不同，其他如硬件資源、操作系統情況、中間件環境等信息都一樣，但往往由于客戶的內部規范需要重復填寫表單，或申請時間不同而反復填寫相同的表單信息。還有一種情況是申請一個通用的組件資源，如Web服務器資源，每次填寫的內容可能除了項目名稱或部門不同，其他信息也大部分雷同。因此這種申請資源中重復性的勞力工作也是我們常遇到的困惑。申請人員也不僅一次抱怨能否進行模版化、復用化的變革，從而提高工作效能，避免浪費大家寶貴的工作時間。

有困惑就會有思考，有思考就會有創新，部分經歷資源申請前世痛苦的客戶已經走在了今生不斷探索、不斷變革的資源申請之路。

圖化資源申請之今生，即生活之世

經歷了傳統資源申請的種種挑戰和痛苦，一部分IT標準化成熟的企業開始思考一個問題：有沒有新的方式或者手段來改變這種資源申請過程中遇到的各種挑戰呢？**據科學家統計，在向人類大腦傳送信息的三百萬條神經纖維中，視覺神經纖維占了二百萬條，視覺是人類感受外界事物、獲取信息的重要的感官。具有很強的模式識別能力，對可視符號的識別和感知速度，比對數字或文本快多個數量級，且大量的數據信息處理發生在潛意識階段，所以視覺是獲取信息的重要通道。而視圖是人眼處理可視化符號常用的方式，人類思考的過程，就是建立思維視圖的過程。**所以，如果在資源申請的過程中采用以視圖為中心、以視圖為數據基礎的情況下，是否能夠給我們帶來一些變化和創新呢？令人高興的是有企業已經在使用這種資源申請方式并取得了很大成效，歸納下來今生資源申請之路我們可以分為兩步來走。

1

先將資源申請需求畫出來

即用畫圖的方式將使用者要申請的資源以組件的顆粒度表達出來，下面是一個制造業用戶的資源申請視圖的局部展示。

通過上面局部視圖的展示，我們通過可視化的方式可以直觀的認知如下信息：

機器信息

客戶要申請2臺機器，共3臺虛擬機。1個虛擬機用于webserver，宿主在單獨1臺機器（企業規范一個方框表示single System），2個虛擬機用于JBoss（企業規范2個圓圈表示集群模式），共享1臺硬件機器（都在紅色區域內）。后臺交付部門可以清晰的從宏觀上知道申請者對機器數量的要求。

層次信息

上圖左側中可以看出物理機器——虛擬機——操作系統——Web Server層次信息。右側則可以看出物理機器——虛擬機——操作系統——JBoss集群——WebService和FileVault模塊這種層次信息。運維人員能夠直觀的了解每個申請資源都包含那些CI項，以及他們的層次關系，提前思考CI的分類、CI之間的關系，為將來在CMDB中如何建立數據打下基礎。

訪問信息

我們可看到webserver會通過網絡https方式訪問JBoss組件，這種直觀連線式的表達能讓客戶清晰的知道組件之間的訪問順序、訪問方向和訪問關系信息。

CI配置信息

通過進一步單擊每個組件，會看到類似CI配置的代碼信息。

通過上述描述，我們可以得出一個結論：采用視圖可視化的方式開展資源申請業務，不僅能夠讓使用者和資源提供者都在統一的視圖視角范圍內對交付內容有清晰和直觀的認知，而且擺脫了傳統數據表格模式的乏味枯燥困擾，降低了使用者對IT行業知識的認知門檻，提高了溝通的效率和客戶體驗。

2

便捷的資源申請畫圖

能夠將資源申請情況用畫圖的方式呈現出來只是基礎的功能。下圖是制造業客戶的一個資源申請視圖的全貌。

從圖上可以直觀感受到如此多的組件，如此復雜的關系連線以及如此豐富的圖標樣式。把這些視圖元素完整無誤的畫出來是非常耗時的，而且需要畫圖者需要極大的耐心和細心的。我們可以分析出圖中某些組件組合方式是經常遇到，或重復使用的，例如下圖中的組件包：

這是一個簡單而且常用的申請資源情況，就是提供客戶1臺包含SuSE操作系統的機器，可能未來用于安裝業務客戶端、也可能只是個前置Web服務機器。無論如何這類申請的資源模式在企業中十分常見，如果每次都從零開始畫圖，難免體驗過于低級。隨著企業規范越來越完善，可復用的資源組件可能越來越復雜，越來越多，這類需求的呼聲也會不斷增加。

因此，視圖平臺要提供一種能力將常用組件整合在一起，形成一個可復用、可管理、可維護的資源包，這種資源包的制作和維護完全由客戶根據企業規范和資源申請的需求自定義、自操作、自管理。資源包可以看成是視圖的重要組成部分，除了可視化的內容顯示，還包括了CI配置信息代碼、CI關系數據代碼等基本元素。從而降低資源申請者畫圖的時間，提高畫圖的效率。

今生之挑戰

從生存到生活，其實是解決了企業資源申請基本的“活著”的問題，也可以理解成相對“活的好些”的要求，其實離“活的瀟灑”還是有一定距離的，因為我們還面臨著如下的挑戰：

1、資源申請進度的不透明化：往往客戶提交了資源申請表格之后就只有等待，等待資源申請表格的流程走完、等待運維人員交付環境、等待后臺人員根據建立好的資源生成CMDB中的配置信息。這個過程往往對于前臺客戶并不完全透明，造成了更多的前后臺溝通成本，也影響了后續工作的部署進度。

**2、配置關系信息無法自動同步生成：**在一個CMDB系統比較完備的企業，配置信息的關系在資源生成之后需要客戶手工梳理和輸入組件之間的關系信息。因此后臺運維人員需要花費時間和提交資源申請人員理解消化和反復溝通各個配置信息之間的關系情況，從而在CMDB中建立準確而符合企業規范的CI關系數據。這不僅會出現由于溝通信息衰減而導致數據錯誤，而且會隨著系統的不斷變更帶來大量的反復工作，增加了運維工作的復雜度和工作強度。

企業的CMDB數據的重要性和消費性還停留在理論上，如何將數據和視圖進行整合、聯動、升華，實現CMDB生產工具圖形化、場景化、眾創化才是我們的終極目標。

圖化資源申請之未來，即生命之世

古人云：前世之債，今生來償，終其一生思考以謀未來之福祉。從生活到生命，區別在于一個是我們生于其間的現實世界，一個是我們心向往之的理想國度。對于企業內部IT資源申請的來世，可能沒有我們遙望的那么久遠，因為變革已經發生，即使是潘多拉的魔盒也沒有將希望完全泯滅，讓我們來感受一下資源申請美好的未來。

1

通過視圖讓資源申請進度可視化

通過視圖來表示資源申請的情況還不是我們的目標。在申請者提交資源視圖之后，他們的關注點已經轉移到了資源申請的進度如何，客戶希望對申請資源的到位情況能夠實時掌握，從而有計劃、有目標的開展下一步的工作。請看下圖：

從上圖中我們可以直觀的感受到申請資源的進度情況。左邊的Client組件仍然是灰顯狀態，說明資源還未到位；中間的WebServer資源的機器和虛擬機已經ok，因為視圖中顯示高亮狀態，但虛擬機中的操作系統和WebServer平臺軟件還在部署中，因此狀態為灰顯；而右邊的AppServer組件無論是硬件級別、操作系統級別還是平臺軟件級別都是高亮狀態，說明申請需要的資源已經完全到位，用戶可以開展下一步的測試或部署應用工作。

實現上述資源進度可視化功能是離不開企業的CMDB核心配置庫的。還記得我們在畫圖中要對每個CI配置信息進行輸入嗎？這就為我們能夠通過視圖進行資源申請進度跟蹤埋下了伏筆。在使用者申請資源畫圖中，會根據需求在代碼段中填寫相應分類組件的部分配置信息。當運維部門在交付資源的時候會參考并補充完整這部分CI配置信息，待資源交付成功后會手工或自動化的在企業核心CMDB中生成CI的配置數據。這些配置數據會定時回傳給視圖管理平臺。當用戶通過視圖查看進度的時候，視圖管理平臺會自動根據視圖中組件信息和回傳的CI數據進行匹配，從而選擇灰顯或高亮組件來呈現資源交付進度。這種方式不僅在資源申請過程中實現了數圖結合，數圖互動，也擴大了企業CMDB的使用價值和自動化進程改革。

2

CI關系數據自動生成和回寫

以往我們CI關系數據需要客戶進行梳理和建立，但采用視圖方式之后，由于在資源申請的時候申請人會完善CI關系代碼信息，CI關系也只有開發、業務和申請人這類角色工作人員清楚，后臺交付人員對CI關系信息不敏感。如果交付人員建立CI關系數據也需要和前端溝通和確認，十分麻煩而且也容易造成理解誤區。以此我們把CI關系數據的梳理和建立放在了視圖管理平臺中，由申請人或有權限修改視圖的業務人員進行梳理并確認。當視圖中所有資源交付成功后，即灰顯狀態都成為高亮狀態時，視圖管理平臺根據視圖中的CI關系代碼信息自動建立CI關系數據，之后將這些關系數據回寫到CMDB核心庫中。到此為止客戶申請資源的業務流程形成了一個閉環，視圖在資源申請的過程中，扮演著直觀顯示資源情況、描述資源CI信息、生成CI關系數據并回傳，校驗視圖中組件資源申請進度的角色。

3

視圖的資源變更擴展能力

在申請資源交付給使用者后，資源有可能發生變更和淘汰，我們還需要視圖的一些擴展能力予以支撐。

• 客戶由于架構改變，或機器替換的時候，CMDB中的數據發生改變，這些改變的數據會同步回視圖管理平臺。當客戶瀏覽視圖的同時，這些變化的數據會以視圖可視化的方式提醒客戶，幫助客戶校驗、修改和完善資源申請視圖。

• 數據校驗和修改后，視管理平臺提供視圖的版本管理功能，記錄由于數據改變而帶來的視圖變化痕跡信息，用于日后申請者進行歷史查詢。

這樣，通過視圖的方式提供給企業一個資源申請全生命周期的可視化管理能力，幫助企業更好、更快、更敏捷的進行資源申請業務的開展。

未來的生命之路所以美好而令人期待，就是因為“未來”這個字眼就意味著無限的可能性，我們完全有理由相信通過視圖手段實現業務需求這種理念，會在企業IT發展上帶來更多的奇跡、更好的明天。優锘的DMV可視化平臺了解客戶的前世之痛、今生之憾和未來之夢，攜手我們，讓我們一起和未來赴約。