尽管早在上世纪70年代，某些公司便开始使用早期形式的“云计算”，但这个现今我们耳熟能详的概念的起源最多只能追溯到十年前而已。在这么短的时间内，云服务供应商和使用它们的组织数量已发生了爆炸性的成长。
然而今天，企业对于可供他们选择的云选项的选择变得越来越聪明，并且发展出判断哪些应用程序和数据应该，或不应该被托管在公有云中的标准。事实上，一些组织已经开始退出云。也就是，许多公司正将他们业务的某些部分从公有云中抽离，一部分的原因是由于他们在内部支持一个混合云的能力有了进展。
当组织退出云：原因与面临的挑战
这种反向迁移的趋势，被越来越多的人称为退云，有许多的驱动因素。其中包括未能实现预期的财务优势，意外的安全和合规问题，以及无法完成所需要的与遗留系统的深层次整合，种种这些使公有云不再是一个可行的方案。
一旦一个组织已经决定要退云，要将其基础架构和数据迁移回去本地或一个共同托管设施时，它必须解决一系列的挑战。这个公司将很快发现，离开公有云是一个复杂性不比迁移到公有云更小的过程。事实上，在某些方面，想倒退出来可能是一个更复杂的任务。
通常来说，***的问题都是如何优雅地处理那些在组织的应用之间存在的依赖关系。紧接着的第二个问题是时机的问题。厂商必须在公有云提供商的维护时段中作业，而那些时段并不总是与公司自己的时刻表同步的。
另一个障碍是，那些必须实施到公有云环境中的外部迁移工具多半无法使用的残酷事实。以及***，当工作人员和其他资源在计算能力转移到公有云时被重新分配到他处，组织现在又必须准备再次重新担负起云相关任务的责任。
如何退云：***实践的新趋势
随着云的逆向迁移变得越来越普遍，一组***的实践已经渐渐开始成型。对于那些有能力将组织转移到云端，或执行任何其他类型的技术转化的IT服务企业来说，毫不奇怪的，在退云的时候，那些相同的原则也同样适用。以下是八个让退云过程可以顺利的***实践：
1.建立资产清单
作为***步，你必须建立一份在云端所有资产的完整清单，包括应用和基础架构组件。这一步完成得有多彻底，直接关系到你项目的成功与否。只对你迁移到云端时创建的列表做临场抽查是不够的。从那时到现在，很可能已发生许多环境上的改动，而遗漏任何增加或修改过的资产也可能会带来严重的后果。
2.构建依赖关系图
类似于你投资在一个资产清单的时间和精力，你必须完成一个同样严谨的依赖关系图。同样，任何错误或遗漏都将影响到你退云过程的成功与否。
3.将应用映射到基础架构
又是一次映射，将应用映射回基础架构。当这一步完成之后，你就有一个可以进行之后工作的坚实基础。
4.理解SLA
服务水平协议(SLA)是反向云迁移的另一关键因素。保证组织能够在整个过程中继续满足这些SLA是衡量成功的关键。这就需要对协议的每一个细微之处都有深入的了解。
5.专注于应用
相比系统来说，企业应更注重于应用的退云。通常，以系统为基础的方法会导致关键因素的处理不当以及不够满意的结果。以应用为中心的迁移可以降低风险。
6.预留测试时间
鉴于反向迁移往往必须发生在很短的时间段内，厂商和/或与他们合作的组织有时在测试方面会有所节省。这几乎是一个以后肯定会回来困扰你的错误。
7.重新分配资源
那些在计算能力被转移到云端时被重新分配的人员和资源必须在退云的时候转移回来管理业务。让你的云服务团队到位并且准备好切换将帮助你完成一个顺利的过渡。
8.寻求专门致力于云业务的
不管是迁移到云还是从云迁移出来都不是一个能掉以轻心的过程。那些想要确保他们的转换成功的公司应该同拥有一个专门从事云业务的厂商合作，而不是那些只是涉足云计算作为一个分支副业的公司。
展望未来
除了前面提到的退云原因，再加上企业可以越来越容易的在内部管理自己的云，多半意味着反向迁移的趋势仍会继续下去。为了减少未来将可能需要退云的可能性，公司应该在前期投入更多的时间和精力确定哪些应用更适合公有或私有云。
他们也应该开始把他们的IT部门视为服务代理。在一个IT即服务的环境下运维的IT部门可以让IT变得更加灵活和更快响应。
***，要真正充分利用不同类型的云所提供的优势，组织应该明白，我们最终的目标是正面的商业成果，所以无论公有，私有或混合云，都只是达到目标的一种手段。
原文链接：http://www.searchcloudcomputing.com.cn/showcontent_91754.htm
