如果你体验过，你一定知道：更换服务供应商不是一件容易的事！如果你没有经历过，想象下订单是改变电话公司、互联网提供商或手机服务提供商已经陷入困境，而结束与服务提供商的合作关系总是比其他决策更困难和复杂行为——当然，这也是商业活动中不可避免的做法。面对现实吧。服务提供商通常不愿意为用户提供无缝切换机制，毕竟将用户拱手让给竞争对手并不是那么愉快。但客户可能没有充分意识到，服务提供商可以而且确实设置了障碍，以同样的方式留住客户——无论提供商可能多么粗心。也就是说，他们很容易通过设计刻意增加交接工作的难度，从而增加客户对自己的依赖（即所谓的用户“粘性”）。这在云计算中当然也是如此：同样，即使看似不计算的云服务提供商有时也会故意让交接过程变得更加困难，而最常见的手段之一就是安全控制。安全控制的目的是限制用户访问数据的方式，而这往往是对服务提供商最有力的保护。“安全要求”的借口堪称久经考验的法宝。有了这面旗帜，供应商就可以公然拒绝（有时不能，有时不愿意）向用户提供关键数据模块，最终达到顺利转移的目的。鉴于此，我们需要通过一系列的问题来厘清当前安全管控架构的具体情况，以免落入云计算提供商“留住客户”的陷阱。您不妨通过以下问题和相应的策略，帮助自己摆脱购买服务和相关数据的纠缠，按照预定的计划调整业务流程。应对云提供商的“留住客户”陷阱问题一：谁拥有数据？第一个重要的问题也是一个明确的内容——谁应该拥有我们发送给服务提供商的数据？除非大家在服务合约中明确规定了生成数据的所有权划分，否则这个问题的答案可能比我们想象的要复杂。信誉良好的服务提供商会毫不犹豫地将数据所有权分配给用户，但实际上并不是每个提供商都如此重视信誉。请务必在合同中注明，在协作周期内，业务流程产生的所有数据均归用户所有，这一点非常重要。应对云提供商的“留住客户”陷阱问题二：服务提供商如何将数据返回给用户？如果我们明确了数据的归属，接下来的问题是：服务商会以什么形式将数据返回给用户？数据？数据将以什么格式返回？我们发现，当合作伙伴关系结束时，供应商通常会以一种相当繁琐的格式向用户提交数据，而不是每个人都可以轻松使用。比如专门找一个用户不用制作备份磁带的工具。为了避免这个困难，我们需要在合约中指定返回数据的格式，最好是方便随时使用的格式。此外，测试以确保供应商有能力满足合同，以便在实际过渡期间不会出现意外。应对云提供商“留住客户”的陷阱问题三：用户真的可以访问数据吗？请注意，包括加密在内的各种数据安全控制机制可以防止用户逻辑上访问数据，即使数据的所有权没有争议。例如，如果数据本身是加密的，我们是否可以访问加密密钥？同样，一定要测试您是否有权访问数据。特别强调：注意可能在某些元素中使用列级加密的数据库结构。因为第一，这个特性在信息输出的时候可能不会立刻被注意到；第二，一旦加密机制部署到应用层，我们就只能通过提供者手中的密钥访问。您不妨考虑为自己保留一份密钥副本（当然，前提是它是安全的），这样当提供商不再提供服务时，我们就不必将有价值数据的命运听之任之。被动的前伙伴。应对云提供商“留住客户”的陷阱问题四：如何处理资源访问？对于基础架构即服务（简称IaaS）领域，当数据成为虚拟镜像的一部分时，您需要确保您既可以访问应用程序，也可以访问底层操作系统。具有管理员级别访问权限的能力。一旦管理密码丢失，不仅难以访问系统，甚至失去对物理硬件的控制。因此，如果供应商以虚拟机镜像的形式返回数据，请确保您可以实际访问服务的操作系统和应用层。应对云提供商“留住客户”的陷阱问题五：用户数据能否被访问？请记住：除了原始数据，我们可能还需要其他辅助信息才能真正实现服务的无缝传输。比如，如果你的服务商已经搭建了用户信息（包括用户ID、角色、权限、认证信息等）的数据存储系统，我们需要自己搭建同样的系统。确保您有能力将所有备份数据（包括用户信息）重新导入服务进程，因为这些数据很可能与应用程序数据分开存储。毫无疑问，没有服务商愿意主动提供简单便捷的平台交接方案。但是，为了避免陷入供应商不可预测的客户保留陷阱（至少为交接过程设置的各种障碍），我们必须通过测试总结出一套清晰流畅的交接机制，以便在选择合作伙伴时占据主动.从业务需求出发，走上适合自己的发展道路。
