作為技術人員，我們都知道企業(yè)正在不斷的增加云計算的使用。越來越多的IT專家現(xiàn)在也意識到，在企業(yè)IT架構之外，更多云應用會出現(xiàn)。比如，個人業(yè)務單元會直接同第三方云提供商合作，沒有直接介入IT，而實現(xiàn)了這種客戶關系。

結果，最可能出現(xiàn)的是單一的企業(yè)，出于不同的目的，和不同的云服務提供商建立了多種關系。這些服務提供商可能忙于實現(xiàn)所有的功能，從基礎架構即服務（IaaS）IT消費化（比如，災難恢復、按需容量改善、虛擬測試平臺等等），到應用支持服務（PaaS），企業(yè)內部開發(fā)者可以部署應用和組件開發(fā)到外部托管的應用（SaaS），直接實現(xiàn)不同的業(yè)務部門的業(yè)務需求支持。

從業(yè)務部門的觀點來看，可能有一些預期的優(yōu)勢，比如服務交付即時性，但是從技術治理的角度看，就會導致問題。其中一項挑戰(zhàn)就是個人業(yè)務單元很少彼此協(xié)作，來確認他們正在從同一個提供商購買類似的服務。從安全和法規(guī)遵從的視角來看，造成了確保每一個廠商合適的審查以及管理的挑戰(zhàn)，法規(guī)遵從問題則關乎敏感數(shù)據(jù)和法規(guī)數(shù)據(jù)，只能發(fā)送給企業(yè)，而且要能以安全控制的方式來審批。

服務目錄價值

盡管一些配套齊全的企業(yè)正準備著手管理企業(yè)業(yè)務使用的多種云服務提供商，大多數(shù)企業(yè)卻并沒有這么做。由于很多這種關系都涉及了存儲規(guī)定或者敏感信息，或從業(yè)務連續(xù)性角度看，數(shù)據(jù)對于業(yè)務是關鍵的，對這些關系不施以合適的治理，就會導致潛在的安全和法規(guī)后果。此外，因為這些關系可能出現(xiàn)在IT外部（多個源頭），存在邏輯負載型，因為這些關系可能并不能很好的適用于以前的治理模型。

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

一個架構化服務提供商關系目錄意味著很多事情。能夠協(xié)助企業(yè)確定每一種關系的具體所有者，比如，誰簽訂的這項服務就來對這項用例負責。也要幫助保持與服務提供商產品更新保持一致，協(xié)助本地區(qū)域潛在的整合實現(xiàn)。比如企業(yè)可以利用服務提供商來部署更多，這都要進行協(xié)商，或者對比不同產品的效果。簡而言之，追蹤云服務提供商關系對于企業(yè)來說，和追蹤第三方關系具有同樣的價值。

構建詳細目錄

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

實施云服務發(fā)現(xiàn)流程最好的辦法就是查詢企業(yè)內所有不同的業(yè)務、技術和支持團隊，確定他們使用的用例是什么，包括正在使用什么服務，如何使用。

比如，如果針對企業(yè)可持續(xù)發(fā)展計劃（BCP）的商業(yè)影響分析實踐是定期管理的，收集云服務使用的用例，對于自動化這個流程也有幫助，減少了一些問題?；蛘撸趹蔑L險回顧中詢問目標問題，也有助于新計劃和業(yè)務流程的回顧。

從個體收集數(shù)據(jù)時，記住很多用戶對于“云”是什么并沒有概念。比如，如果你問一個問題“你使用什么云服務？”，他們可能不理解像SalesForce這樣的工具就是云服務，因此他們也不會提供你尋求的數(shù)據(jù)。相反，要問一些更合適的問題，“比如哪家公司托管和管理XYZ服務？”如果他們不知道答案，至少你知道下一步工作的方向。

底線

在企業(yè)中將云服務提供商目錄放在一起是一項生產性實踐，允許管理者對比他們正在審查和批準的關系，評估具體的用例類型以及對象可能要求遵守的法規(guī)環(huán)境。此外，在先關的調查中，可靠的目錄格外有用。