讓我們正視現實吧。服務供應商們通常不愿為用戶提供無縫切換機制，畢竟把用戶拱手送給競爭對頭實在不是那么令人痛快。但客戶則很有可能并沒有足夠地意識到，服務供應商同樣有能力且確實會設下種種障礙留住消費者——無論這個供應商有多粗心大意。也就是說，他們很容易就能通過設計刻意提高交接工作的難度，借以提高客戶對自己的依賴程度(也就是所謂用戶‘粘性’)。

 

這種情況在云計算領域當然同樣存在：再次強調，即使是表面上并不工于算計的云服務供應商有時也會故意增加交接流程的難度，而最常見的手段之一就是安全控制。

 

安全控制的目的在于限制使用者對數據的訪問方式，而這往往成為服務供應商最有力的擋箭牌。“安全要求”這一借口堪稱屢試不爽之法寶，有了這面大旗、供應商就可以堂而皇之地拒絕(有時是不能、有時是不愿)為用戶提供關鍵性數據模塊，并最終達成阻撓平穩交接的目的。

 

有鑒于此，我們需要通過一系列問題來弄清當前安全控制架構的具體情況，這樣才能避免陷入云計算供應商們的“留客”陷阱。大家不妨通過以下幾個問題及對應策略幫助自己擺脫已購服務及相關數據的糾纏，從而按照預定計劃調整業務流程。

 

 

頭一個重要議題，同時也是不容含糊的內容——我們發送至服務供應商處的數據到底該歸誰所有?除非大家在服務合約上明確規定了生成數據的所有權劃分，否則這個問題的答案恐怕比我們的想象更加復雜。信譽顯著的服務供應商會將數據的所有權毫不猶豫劃歸用戶，但事實上并不是每家供應商都如此注重信譽。請大家務必在合約中注明，由業務流程生成的所有數據在協作周期內都歸用戶方所有，這非常重要。

 

 

假如我們已經明確了自己對于數據的所有權，接下來的問題就是：服務供應商將以怎樣的形式向用戶返還數據?返還數據又會采用何種格式?我們發現當合作關系結束之后，供應商往往會以相當麻煩的格式將數據提交給用戶，導致大家無法輕易加以使用。舉例來說，專門尋找一種用戶不具備的工具制作出備份磁帶。為了避免這一難題，我們需要在合約中明確數據應以哪類格式進行返還，而且***是那種無論何時都能輕松使用的格式。另外，通過測試確保供應商有能力滿足約定，這樣才能避免在實際過渡時發生意外事故。

 

 

請注意，包括加密在內的多種數據安全控制機制都能防止用戶對數據進行邏輯訪問，即使數據的歸屬權并無爭議。舉例來說，如果數據本身經過加密，我們是否有權訪問加密密鑰?再次強調，請務必通過測試確保自己對數據擁有訪問能力。特別強調：請注意那些可能在特定元素中采取列級加密(column-level encryption)的數據庫結構。因為***，這一特性可能不會在信息輸出時被馬上察覺;第二，一旦加密機制被部署至應用程序層，我們將只能通過供應商手中的密鑰方可訪問。大家不妨考慮自己保留一份密鑰(當然，前提是安全得到保障)，這樣當供應商不再提供服務時，我們就不必把寶貴數據的命運交由態度消極的前合作方加以擺布。

 

 

對于基礎設施即服務(簡稱IaaS)領域，當數據成為虛擬鏡像的一部分時，大家需要確保自己同時擁有對應用程序與底層操作系統進行管理員級訪問的能力。一旦失去管理密碼，我們不僅很難訪問系統、甚至對物理硬件也會失去控制。因此如果供應商將數據以虛擬機鏡像形式返還，請保證自己能夠真正訪問服務的操作系統及應用程序層。

 

 

請記住：除了原始數據之外，我們可能還需要其它輔助信息才能真正實現服務的無縫轉移。舉例來說，如果大家的服務供應商打造了一套用于容納用戶信息的數據存儲體系(包括用戶ID、角色、權限以及身份驗證信息等)，我們自己也需要建立同樣的體系。確保自己有能力將包括用戶信息在內的所有備份數據重新導入服務流程，因為這部分數據很可能被單獨保存在應用程序數據之外。

 

毫無疑問，沒有哪家服務供應商愿意主動提供簡單便捷的平臺交接方案。但為了避免落入供應商那些防不勝防的留客陷阱(至少是給交接流程設下的各種障礙)，我們必須通過測試總結出一套清晰順暢的交接機制，從而在挑選合作伙伴時占據主動、真正以業務需求出發走上適合自身的發展道路。