雲圖集：構建雲服務提供者目錄

作為技術人員，我們都知道企業正在不斷的增加雲計算的使用。 越來越多的IT專家現在也意識到，在企業HTTP://www.aliyun.com/zixun/aggregation/14162.html">IT架構之外，更多雲應用會出現。 比如，個人業務單元會直接同協力廠商雲供應商合作，沒有直接介入IT，而實現了這種客戶關係。

結果，最可能出現的是單一的企業，出於不同的目的，和不同的雲服務提供者建立了多種關係。 這些服務提供者可能忙於實現所有的功能，從基礎架構即服務（IaaS）IT消費化（比如，災害復原、按需容量改善、虛擬測試平臺等等），到應用支援服務（PaaS），企業內部開發者可以部署應用和元件開發到外部託管的應用（SaaS） ，直接實現不同的營業單位的業務需求支援。

從營業單位的觀點來看，可能有一些預期的優勢，比如服務交付即時性，但是從技術治理的角度看，就會導致問題。 其中一項挑戰就是個人業務單元很少彼此協作，來確認他們正在從同一個供應商購買類似的服務。 從安全和法規遵從的視角來看，造成了確保每一個廠商合適的審查以及管理的挑戰，法規遵從問題則關乎敏感性資料和法規資料，只能發送給企業，而且要能以安全控制的方式來審批。

服務目錄價值

儘管一些配套齊全的企業正準備著手管理企業業務使用的多種雲服務提供者，大多數企業卻並沒有這麼做。 由於很多這種關係都涉及了存儲規定或者敏感資訊，或從業務連續性角度看，資料對於業務是關鍵的，對這些關係不施以合適的治理，就會導致潛在的安全和法規後果。 此外，因為這些關係可能出現在IT外部（多個源頭），存在邏輯負載型，因為這些關係可能並不能很好的適用于以前的治理模型。

圍繞服務提供者關係構建一個目錄，可以協助二者更好的管理潛在風險，為進一步的戰略雲計算應用計畫實施奠定基礎。 首先也是最重要的，這個目錄説明企業識別和文檔化正在使用的不同服務提供者。 這很有説明，因為服務本身不是靜態的，也不是關於他們在企業中如何使用的。 記住服務提供者，就像是組織機構一樣，會不斷改變其提供的服務，他們可能升級了安全控制，導致了宕機時間，或者成為違規的犧牲品，或者一個組織機構決定擴展使用的供應商的範圍。 為了管理這些，需要進行核心集中監督。

一個架構化服務提供者關係目錄意味著很多事情。 能夠協助企業確定每一種關係的具體擁有者，比如，誰簽訂的這項服務就來對這項用例負責。 也要説明保持與服務提供者產品更新保持一致，協助本地區域潛在的整合實現。 比如企業可以利用服務提供者來部署更多，這都要進行協商，或者對比不同產品的效果。 簡而言之，追蹤雲服務提供者關係對於企業來說，和追蹤協力廠商關係具有同樣的價值。

構建詳細目錄

在將這些結構化目錄放到一起之前，要找出大型企業中雲服務用例的全部範圍，這確實是一項額外的挑戰。 可能最簡單的方法就是找到那些維護這些歷史慣例的清單，編制出一個當前廠商關係目錄。 然而，這樣做可能只能編制出一個真個網路的子目錄。 因為很多雲服務提供者對於任何的客戶都非常易用，其產品可能只需要用信用卡交易就能支付實現，這就很難追蹤。 有一些還針對一些用例免費。

實施雲服務發現流程最好的辦法就是查詢企業內所有不同的業務、技術和支援小組，確定他們使用的用例是什麼，包括正在使用什麼服務，如何使用。

比如，如果針對企業可持續發展計畫（BCP）的商業影響分析實踐是定期管理的，收集雲服務使用的用例，對於自動化這個流程也有説明，減少了一些問題。 或者，在應用風險回顧中詢問目標問題，也有助於新計畫和業務流程的回顧。

從個體收集資料時，記住很多使用者對於「雲」是什麼並沒有概念。 比如，如果你問一個問題「你使用什麼雲服務？ 」，他們可能不理解像SalesForce這樣的工具就是雲服務，因此他們也不會提供你尋求的資料。 相反，要問一些更合適的問題，「比如哪家公司託管和管理XYZ服務？ 」如果他們不知道答案，至少你知道下一步工作的方向。

底線

在企業中將雲服務提供者目錄放在一起是一項生產性實踐，允許管理者對比他們正在審查和批准的關係，評估具體的用例類型以及物件可能要求遵守的法規環境。 此外，在先關的調查中，可靠的目錄格外有用。

(責任編輯：呂光)