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

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

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

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

云計算項目***全身而退作戰(zhàn)計劃

云項目初期階段測試

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

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

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

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

進入“復古云運動”階段

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

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

考慮第二次云嘗試

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

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