從事云項目的每個人都渴望成功，但是數據顯示即便周密謀劃，不成功的風險依然存在。統計模型顯示，出于超額費用、宕機或者不適用應用選擇等原因，每家公司都將至少有一個失敗的云項目嘗試;失敗發生時，***的選擇可能就是全身而退，將應用轉移回本地的后端平臺上。這種退出并不容易，但是精心謀劃仍可實現，而且能夠為未來的項目維護好云的聲譽。

從一個云項目中全身而退大致可以分三步走：在云計劃中準備一條撤退路線;“復古云運動(retro cloud movement)”(我的意思是回到云之前的企業IT環境中)以及考慮再啟動。

事實上，每一個報告從云項目中退出的用戶都表明，如果他們能夠預先構架好云項目，只會面臨很少的問題，至少從失敗的風險上來看是這樣。一些調查顯示，十個云項目中至少有一個要包含可行的退出計劃，通常是由于用戶不理解如何創建這一個項目。

一個云項目要想能夠承擔退出的風險，應該包含失敗預警指示信號，可以在其不運作時保持項目的超前性，提供從公有云中退出的合約流程以及撤退選擇，直到通過風險期。這些退出的關鍵基礎最可能依賴于預警指示信號。

云計算項目***全身而退作戰計劃

云項目初期階段測試

云遷移的業務案例由平衡預期利益和必須抵消的技術風險決定。在大多數案例中，企業會出于性能觀點，全面測試云應用，但是他們可能用測試信息量來做，而不是生產的設定值。此外，他們很少驗證成本假設。

為了避免云退出的這些問題，執行一次功能測試和業務小規模測試。前者應該關注應用完整性、性能和可管理性;后者應該關注測試云價格假設。

有必要進行廣泛回顧，關注哪些變量可能會影響云價格，從而確定精確的云價格。大多數時候，潛在的變量關系到數據存儲、數據訪問、云性能和可用性。比如，很多企業發現“基礎”云服務不符合用戶的體驗質量(QoE)預期，他們被迫投入實例、集群和其他更多的有效服務。這些變量應該在功能測試中找到，但是一些可能只會在全部投入生產時才會出現。

并不是所有的企業對于這兩個測試運行多久就會有效暴露任何成本風險都能達成一致;大多數云管理員認為至少一個月，但是一些人也說最長要一個季度。在一個更為長期的測試周期中，企業會遭遇同云廠商的合同問題，以及維護退出系統的問題。大多數云提供商接受一次性合同救助，實際上全部都會轉變為一個月到一個月的服務，根據可信公司以前的月支付額來提供長期的合同。然而，用戶報告測試階段最長三個月就變得很難交涉了。在大多數時候，也有必要維護本地的退回系統，如果退出是必須的。更長的測試周期，也意味著退出時更多的成本消耗。

進入“復古云運動”階段

如果預警指示信號在測試階段顯示云項目不符合目標，隨后你必須進入“復古云運動”階段。首先，通知云提供商你發現服務選擇失敗，不符合業務用例。云提供商可能會建議補救，如果經濟上可行，你可以接受。但是，大多數云項目失敗并不能修復，除非你***次告知提供商要有麻煩了。

下面準備好本地的應用平臺。如果預警指示信號顯示了測試階段的問題，唯一的需求就是終止測試，排除所有旨在測試期間升級的應用。如果問題直到生產試用階段都沒發生，就需要檢查應用，確保更新了所有事務數據，而且平臺或者軟件應該在回到本地之前變更。這就需要在“復古云運動”之前，在內部系統中進行確認測試。在很多案例中，應用生命周期管理實踐是為了內部應用開發，也可以用于指導企業從云端退出。

考慮第二次云嘗試

***一點是要意識到很多云失敗是可撤回的。一些案例中云成本或者性能不符合業務需求可以通過變更提供商或者重新談判合同補救。

如果內部項目措施協助確保了云遷移的成功，隨后失敗可能會對維持成功之處新的措施。每一個失敗的云項目應該“既往不咎”，來確定是否在不同的條件下重啟項目，讓其能夠更好地服務企業的利益點。