云与企业软件中的供应商锁定：如何评估风险并准备退出策略

对大多数企业来说，使用云服务和第三方软件几乎肯定是正确的决定。您不需要自建数据中心，也不必从零编写所有功能。但在报价阶段很少有人谈及另一面：随着时间推移，数据、工作流程和团队习惯与某一家服务商融为一体，直到有一天您想迁移，或者服务商涨价、更改条款、关闭服务，才发现退出成本极其高昂。这种状况称为供应商锁定（vendor lock-in）。

本文介绍什么是供应商锁定、它在云、ERP 和定制软件中的表现形式、如何评估风险程度，以及在不必拒绝托管服务的前提下降低风险的实用策略。目标不是完全避开服务商，而是确保您始终保有选择权和议价能力。

摘要

• 供应商锁定并非总是坏事；它是便利的代价，问题出现在从未计算退出成本时
• 形式多样：数据格式、服务商专属 API、长期合同、团队技能和嵌入式集成
• 风险按系统的关键程度、数据迁出的难易程度，以及有多少事物依赖它来评估
• 降低风险的策略：数据所有权与导出、标准接口、分层架构、公平合同，以及经过测试的退出计划
• 目标是拥有选项，而非绝对自由：决定哪些锁定值得接受，哪些不值得

什么是锁定，为什么会发生

当迁移到另一家服务商变得极其昂贵、缓慢或有风险，以致即使情况恶化您实际上也被迫留下时，就发生了供应商锁定。它很少来自某个恶意的决定，通常是许多合理决定累积而成。

• 专属功能的便利：服务商的服务提供别处没有的便捷功能，团队乐于使用
• 不断积累的数据：多年的交易、文档和历史记录，以服务商自己的格式和结构存储
• 嵌入式集成：数十个其他系统通过该服务商专属的接口相连
• 团队专长：您的员工精通某一个平台，迁移意味着重新学习
• 合同：长期订阅期限、解约罚金，或只有留下才适用的折扣
• 数据传输成本：即便只是把大量数据从云中取出，也可能产生出站流量费用

另一方面，试图完全避免锁定同样昂贵。把一切构建得与服务商无关，意味着放弃各平台最好的功能并增加复杂度。因此正确的问题不是“如何避免锁定”，而是“哪些锁定值得接受，退出的代价是多少”。

需要识别的锁定形式

数据锁定

数据以封闭格式存储，或者导出只能得到部分信息，例如缺少变更历史、附件或数据之间的关系。这是最危险的形式，因为数据是企业的核心资产。请从选择系统的第一天就考虑为新系统做数据迁移准备，而不是等到被迫之时。

技术锁定

应用使用仅存在于某一个云上的服务，例如数据库、队列、无服务器函数，或接口专有的 AI 服务。迁移意味着重写调用这些服务的部分。

合同与价格锁定

锁住客户的合同、高于通胀的年度涨价，或强迫您购买不用模块的捆绑套餐。与一次性买断模式的比较见SaaS 还是永久许可。

流程与人员锁定

团队的工作流程是围绕某个软件的运作方式形成的。更换系统不只是技术问题，还会改变人们的习惯，这正是最大阻力所在。另请参阅更换系统时管理团队阻力。

开发者锁定

对定制软件而言，锁定可能意味着依赖某一家供应商或某一位了解代码的程序员，且没有文档或代码库访问权限。一旦关系恶化，企业就被挟持。极端情形见挽救停滞的软件项目与更换供应商。

生态系统锁定

一家大型服务商提供涵盖身份、邮件、存储和分析的集成套件。便利性很大，但更换其中一个组件意味着要触及其他所有部分。

评估锁定风险的程度

并非所有锁定都同样危险。请用几个问题评估每个重要系统。

• 有多关键：如果这个系统宕机或服务商停止运营，业务多快会陷入瘫痪？
• 数据多容易迁出：是否有开放格式的完整导出，包括历史和附件？是否试过？
• 多难替换：市场上是否有同等的替代品，实际迁移需要多久？
• 有多少事物依赖它：有多少其他系统、流程和报表与之相连？
• 服务商多稳定：财务状况、价格变动的历史记录以及产品停用政策
• 您有多大议价能力：您对服务商而言是重要客户，还是数百万客户之一？

结果可以汇总为一张简单的表：系统、关键程度、数据导出难易、替换难易和决策。关键程度高且难以退出的系统要获得更多关注。容易替换的小工具无需担心。

降低风险的策略

1. 确保数据所有权与导出能力

最重要的原则：您的数据属于您，并且您必须能在任何时候完整取出。

• 检查合同：谁拥有数据、是否有导出权利、什么格式、费用多少
• 定期测试导出，而不是只依赖承诺。判断结果是否完整、是否可被其他系统读取
• 按照[企业数据备份策略](/blog/strategi-backup-data-bisnis)，在服务商之外保存独立的备份副本
• 记录架构和数据字典，使导出内容在未来仍能被理解

2. 选择标准接口和格式

开放格式和广泛使用的接口使迁移更容易。优先选择接口广泛兼容的存储、常见的数据库，以及许多应用都能读取的文件格式。在集成方面，如企业 API 设计所述，文档完善的 API 可减少对单一系统的依赖。

3. 在架构中分离层次

不要让核心业务逻辑通过直接调用服务商服务而散布各处。把对专有服务的使用包装在由您掌控的薄薄一层之后。如果有一天更换服务，改动集中在一个地方。可组合 ERP和无头网站架构等模块化方法采用相同的原则。

4. 有意识地使用服务商专属功能

服务商专属功能有时非常有价值，使用它们没有问题。重要的是决定是有意为之：记下哪些功能是有意让您被绑定的，为何收益值得，并估算替换它们的成本。避免在不知不觉中被益处很小的功能绑住。

5. 谈判公平的合同

• 合同期内及期满后享有完整的数据导出权利，且费用不过高
• 书面约定的年度涨价上限
• 合同结束时的过渡期和移交协助
• 服务商被收购、变更或终止服务时的条款
• 针对定制软件的源代码所有权条款，附带代码库访问权限和文档，与[软件开发合同要点](/blog/poin-penting-kontrak-pengembangan-software)一致
• 带有违约实际后果的服务水平协议

6. 留意组件许可证

锁定也可能来自所用组件的许可证，尤其当部分代码受限制性条款约束时。请在开源许可证与代码所有权中了解风险。

云策略：一家、多家还是混合

一个常见的问题：是否应同时使用多个云以避免被绑定？答案取决于团队的规模和能力。

• 一个主要服务商加可移植性纪律：对大多数中型企业而言这是现实的选择。利用一个平台的优势，同时让数据、容器和配置保持可移植
• 不同功能使用多个云：当每家服务商各有所长时有用，但会增加运营和安全负担
• 部分放在自有服务器的混合方式：适合敏感数据或稳定负载，在[云还是本地部署](/blog/cloud-atau-on-premise)中讨论
• 完整的多云：昂贵且复杂，除非有严格的监管或韧性要求，否则很少值得

有一点常被遗忘：成本。我们理解不足的云往往会膨胀，而锁定使情况更糟，因为很难转向更便宜的选项。完整的讨论见企业云成本控制。

退出计划：成文且经过测试

退出计划是一份简短的文档，回答这样的问题：如果我们必须在六个月内离开这家服务商，需要做什么？这并不意味着您会离开，而是显示该选项有多现实。

• 数据清单及取出方式，附估算的规模和时间
• 必须重建的集成清单
• 替代候选及简要比较
• 估算的迁移成本和时间
• 业务方与技术方的责任人
• 最近一次导出试验的结果

将其与灾难恢复与业务连续性计划联系起来。服务商停止运营或长时间中断也是一种灾难情景，退出计划是答案的一部分。定期测试其中一部分，例如导出数据并在独立环境中恢复。

定制软件：防止开发者锁定

委托开发定制软件能带来更多控制权，但前提是从一开始就确保这种控制。

• 源代码所有权归您的公司，代码库访问权限登记在组织名下，而不是开发者的个人账号
• 有架构、运行方式和发布方式的文档，并保持更新
• 环境和凭据由公司管理，供应商的访问权限可以撤销
• 所选技术被广泛使用，因此易于找到替代的开发人员
• 自动化测试和发布流程有文档，使新接手方能放心工作
• 定期移交，而不是只在项目结束时

有了这些习惯，更换供应商就成为可管理的事务，而不是危机。

常见错误

• 在需要之前从不测试数据导出，然后发现结果不完整
• 为了大幅折扣而签订长期合同，却没有检查退出权利
• 在整个代码中嵌入服务商服务的调用，导致替换要触及数百处
• 把数据和备份的唯一副本保存在同一家服务商处
• 过于害怕锁定，以致拒绝最好的服务，并自建非战略性的东西
• 没有记录谁持有服务商端的主账号访问权限

常见问题

所有供应商锁定都应避免吗？

不是。有些锁定是为了便利和更低成本所做的合理交换。应避免的是对关键系统不知不觉形成、又没有退出路径的锁定。

如何检查服务商的数据导出能力？

在试用期内索取完整的导出样本，而不是只阅读文档。检查其中是否包含历史、附件和数据间的关系，然后尝试载入另一个系统或电子表格。

把代码存放在自己的代码库就够了吗？

这是重要的一步，但还不够。您还需要文档、运行环境的方法和配置数据。没有运行知识的代码，新开发者难以使用。

如果我们使用的 SaaS 服务商关闭了怎么办？

退出计划和定期的数据副本是救命稻草。还要留意合同中关于终止服务和过渡期的条款。如果该系统很关键，可考虑对其进行现代化，如不停运地现代化旧系统所述。

退出计划应多久审阅一次？

至少每年一次，并且在系统、合同或服务商发生重大变化时再审阅。对最关键的系统，数据导出测试应更频繁。

结论

供应商锁定是现代服务便利性所伴随的现实。企业的任务不是拒绝它，而是有意识地管理它：知道哪些系统关键，确保数据始终能够取出，分离架构层次，谈判公平的合同，并保有经过测试的退出计划。这样您就能继续使用最好的服务，而不失去选择权。

Agsora 帮助企业设计由您拥有并完全掌控的架构和定制软件，包括文档、移交，以及不会把您绑定在单一服务商上的集成。如果您担心对某个供应商或平台的依赖，欢迎一起评估。