别等供应商先动手：vibe 项目的第三方服务替换逃生计划

供应商不会提前告诉你它要出事

你的 vibe 项目跑在别人的服务上：支付走一家、登录走一家、短信走一家、文件存储走一家、邮件又走一家。平时它们都好好的，于是你会产生一种错觉，以为它们会一直好下去。现实是：供应商会涨价、会改条款、会关停某个套餐、会被收购后换方向，也会出一次持续数小时的故障——而这些事发生时，它不会先征求你的意见，也不会给你留出从容迁移的时间。你能做的只有一件事：在一切正常的时候，就把“换掉它”这件事排练好。

这篇指南给的就是这套排练方法：一份供应商替换逃生计划。它不教你怎么选供应商，也不教你怎么把某个具体服务接进来；它只解决一个问题：当你必须换掉某个第三方服务时，怎么做到用户无感知、数据不丢失、账单不翻倍，并且随时能回滚。

先划清边界，因为站内有几篇容易混淆的邻近指南。技术栈迁移指南讲的是“整个技术栈怎么换”，比如从一套框架换到另一套，范围是整站；本篇讲的是“单个第三方服务怎么换”，比如只换支付或只换短信，范围小得多、节奏也完全不同。依赖升级指南讲的是“开源依赖的版本怎么升”，本篇讲的是“外部服务的供应商怎么换”，一个是代码里的库，一个是账外的服务商。依赖供应链安全指南讲的是“依赖有没有投毒、安不安全”，本篇不管供应商安不安全，只管“换掉它时不断档”。API 熔断降级与超时指南讲的是“对方出故障的那几分钟怎么扛”，本篇讲的是“对方长期靠不住时怎么彻底换掉”。AI 功能降级与兜底策略讲的是“AI 功能挂了怎么保底”，本篇不讲 AI 功能，只讲第三方服务。agent 花费硬上限、agent 数据访问护栏、agent 交接包、agent 权限契约、回归验证基线六层法、agent 改坏代码抢救、发布说明写作、上线前 60 分钟手册、毒依赖 containment、AI 评审二次验证，讲的都是 agent 任务、发布流程或安全事件，与“换供应商”这个主题互不重叠。数据库备份与灾难恢复指南讲的是“数据丢了怎么恢复”，本篇要用到备份，但目标不是恢复，而是迁移：数据从旧供应商完整搬到新供应商，并且搬完能对上账。

第一步：给所有供应商分级，而不是等出事再排队

逃生计划的第一步不是写代码，而是列清单：把你的项目用到的每一个第三方服务写下来，按“换不掉的代价”分三级。分级标准只有一个：这个服务如果明天停掉，你要花多久才能恢复服务。

第一级叫卡脖子级：停掉就等于停服，或者用户数据拿不回来。典型的是支付、登录、核心数据库托管、域名与 DNS。这一级必须有完整逃生计划：备选供应商已经开通过账号、数据导出已经演练过、切换步骤已经写成文档。

第二级叫可替代级：停掉会难受，但有办法绕过去。比如短信可以临时改用邮件通知，对象存储可以临时只读，数据分析可以先停用。这一级需要有备选方案的名字和切换开关，但不需要事先跑通全套迁移。

第三级叫装饰级：停掉只影响体验细节，比如某个分享按钮、某个统计面板。这一级只需要记在清单里，不用准备逃生计划，出事时直接下线它就可以。

分级清单模板很简单，每行五列：服务名称、用途、级别、备选供应商、导出方式与演练日期。清单每年至少复核一次，因为服务会变：去年还是装饰级的服务，今年可能因为用户量上来变成了卡脖子级。清单本身不值钱，定期复核才值钱。

第二步：事前准备三件套，平时就要备好

逃生计划真正值钱的部分都在事前准备里，而且这三件套都可以在一切正常的时候慢慢做，不用赶时间。

第一件是薄抽象层。意思是：你的业务代码不要直接调用供应商的专属接口，而是隔一层你自己的薄接口。比如支付不要满项目散落着某家支付商的调用，而是集中到一个你自己的支付模块里，模块内部再去调支付商。层要薄：只封装你真正用到的三到五个操作，不要试图把供应商的全部功能都抽象一遍，那样抽象层本身会变成第二个供应商。判断标准是：换供应商时，你要改的文件应该集中在一个目录里，而不是散落在全项目。

第二件是数据导出演练。每年至少做一次：从供应商后台把核心数据导出来，看看导出的格式是不是你能用的、字段齐不齐、有没有缺失关键关联。比如用户表有没有导出用户标识与注册时间，订单表有没有导出支付状态与退款记录，文件存储有没有导出文件清单与访问地址。演练时要真的把导出文件打开、数行数、抽查几条，而不是只确认“后台有个导出按钮”。导出按钮存在，不等于导出的数据能用。

第三件是备选账号与密钥轮换准备。卡脖子级服务的备选供应商要提前开好账号、跑通过最小调用、确认它的套餐与价格你能接受。同时准备好密钥轮换清单：哪些环境变量、哪些配置文件、哪些定时任务里藏着旧供应商的密钥，切换时要换哪些、换完怎么验证。密钥清单平时就要维护，切换当天再去满项目找密钥，一定会漏。

第三步：替换六步法，顺序不能乱

真正要换的时候，按六步走，顺序不能乱，跳步是数据丢失最常见的来源。

第一步是锁定新供应商并跑通最小调用。不要一上来就迁移数据，先用新供应商跑通最小闭环：支付能收一笔测试款、短信能发一条测试短信、存储能存取一个测试文件。最小调用跑不通，后面全是空谈。

第二步是数据迁移与校验。把旧数据导出来、导进新供应商，然后做三层校验：总数对不对（行数、文件数、用户数）；抽样对不对（随机抽 20 条，逐字段比对）；关联对不对（订单能不能对应到用户，文件能不能对应到记录）。三层有一层对不上，就停下来查，不要带着疑问进入下一步。

第三步是双写期。新旧服务同时跑一段时间：新数据同时写进旧服务和新服务，读还是从旧服务读。双写期的长度看数据量和风险，一人团队通常 3 到 7 天就够。双写期是逃生计划里最重要的一步，因为它给了你“随时能回去”的底气：只要旧服务还在写数据，回滚就只是改一个开关。

第四步是灰度切换。先把一小部分流量切到新服务，比如你自己的账号、内部测试账号、百分之五的新用户，观察一天没问题再逐步放量。灰度不是为了显得专业，而是为了把“全量出问题”变成“小范围出问题”。

第五步是观察期。全量切换后至少观察一个完整业务周期：支付要覆盖一次对账周期，短信要覆盖一次高峰时段，邮件要覆盖一次定时任务周期。观察期里旧服务保持只读，不要急着关。

第六步是旧服务下线与账单收尾。确认新服务稳定、旧数据已归档、旧密钥已作废后，再关旧服务。关之前做三件事：导出最后一版旧数据并归档；确认自动续费已取消；确认账单周期内没有未结费用。下线不是“点一下删除”，而是一张收尾清单，逐项打勾。

第四步：切换日执行表，从 T-7 到 T+7

把六步法排到时间表上，切换日就不会手忙脚乱。T-7 天：发出内部通知，冻结与该服务相关的其他改动（切换周不叠加别的上线）；T-3 天：完成数据迁移与三层校验，演练一次回滚开关；T-1 天：确认双写正常、密钥清单齐全、值班人明确；T 日：按灰度比例切换，值班人全程在场；T+1 天：检查第一批真实数据，核对账单与日志；T+3 天：放量到百分之百；T+7 天：观察期结束，执行下线收尾清单。时间表可以按你的项目压缩，但顺序和检查点不能省：尤其是“切换周冻结其他改动”这一条，一人团队最容易犯的错就是在切换当天还顺手上别的改动，出问题后根本分不清是谁的锅。

回滚触发线要提前写好、写死，切换当天只执行、不讨论。五条红线，触到任何一条立即回滚：新服务错误率连续 30 分钟高于旧服务；真实用户资金、订单、账号数据出现不一致；新服务账单出现未预期的高额计费；关键功能（支付成功、登录成功、短信到达）成功率跌破你事先定好的数字；你发现数据校验有问题但一时查不清原因。回滚不是失败，而是逃生计划正常工作：有回滚线，才敢切换；没有回滚线，切换就是赌博。

三个典型替换：支付、登录与短信、对象存储

支付替换最要紧的是对账与退款链路。迁移时除了用户与订单，还要确认历史退款、争议订单、订阅状态能不能对应过去。切换后第一个对账周期要逐笔核对，订阅类服务还要确认下一期扣款走的是新服务而不是旧服务。支付切换的灰度要从小额、内部账号开始，绝不能一上来就切全量。

登录与短信替换最要紧的是用户身份连续性。用户在旧服务里的标识、手机号、验证记录，要能对应到新服务里的同一批人。切换期间老用户登录不能被要求重新注册，验证码通道切换时要准备备用通道（比如短信不通时走邮件验证码），否则用户会被锁在门外，而你会在客服消息里才发现。

对象存储替换最要紧的是访问地址与权限。文件搬过去只是第一步，旧的文件访问链接要不要继续有效、公开文件与私有文件的权限规则有没有对齐、历史文件的引用（文章配图、用户头像、导出文件）有没有批量替换，都要逐项核对。文件迁移最容易漏的是“没人访问的旧文件”：它们平时没人看，迁移时最容易被跳过，出问题时却是最难找回的。

合同与账单检查点：技术之外最容易亏钱的地方

切换前要把旧服务的合同与账单条款翻一遍，重点看四项：提前通知期是多久（有的服务要求提前 30 天书面通知，否则自动续费一年）；数据保留期是多久（关掉账号后数据保留几天，过期是否彻底删除）；导出格式有没有限制（有的服务只允许按页导出、不允许全量导出，大数据量导出要提前排队）；自动续费与最低消费有没有坑（关掉服务不等于关掉账单，账单开关要单独确认）。这四项每一项都可能让你在技术上切换成功、账单上多付一年钱。检查结果要写进切换清单，切换日逐项确认。

五条反模式：逃生计划写了也白写的五种死法

第一，备选供应商只存在于收藏夹里：没有开过账号、没有跑通过调用的备选，等于没有备选。

第二，抽象层做得太厚：把供应商的全部功能都抽象一遍，抽象层本身变成维护负担，换供应商时反而要先重写抽象层。

第三，跳过双写期直接切换：没有双写期就没有回滚底气，切换一旦出问题，只能停服修。

第四，切换当天叠加别的上线：出问题分不清责任，排查时间翻倍。

第五，下线旧服务不做收尾：账单继续扣、密钥继续有效、数据没有归档，旧服务像没关一样继续产生风险。

一年一次的桌面演练：不花钱的保险

逃生计划写完不是结束，每年做一次桌面演练：不真的切换，只把团队（哪怕只有你一个人）拉到一张表前，假装某个卡脖子级供应商明天停服，按清单走一遍——备选是谁、数据怎么导、双写怎么开、回滚开关在哪、账单怎么停。演练中发现的每一个“不知道”都是一个待办：不知道备选账号密码、不知道导出格式、不知道回滚开关在哪，演练后逐个补齐。演练花不了一小时，但它能保证：真正出事的那天，你不是在现找答案，而是在执行一份已经排练过的计划。供应商不会提前告诉你它要出事，但你可以提前准备好：清单在手、备选就绪、回滚有门，这就是一人团队能买到的最便宜的保险。

三个常见提问：先把疑问答在前面

第一个问题是：一人团队真的需要写逃生计划吗？答案是：正因为只有一个人，才更需要。因为人多时有人记得备选供应商在哪、有人记得密钥清单在哪；一个人时，所有信息都在你一个人脑子里，而你恰恰会在最忙、最慌的时候忘记它们。计划写下来，就是给未来的自己留一张纸条。

第二个问题是：备选供应商要不要真的付费开通？不需要全量开通，只需要开好账号、跑通最小调用、确认价格在可接受范围。付费订阅可以等到真正切换前再开，但账号、调用方式、价格这三项必须提前确认，否则切换当天你会发现备选根本不可用。

第三个问题是：逃生计划会不会很快过时？会的，所以它才需要每年复核一次。复核时只做三件事：供应商分级有没有变、备选供应商还在不在、导出演练日期是不是一年以内的。复核花不了半小时，但能保证计划在需要的那天仍然有效，而不是一份写完就没人再看的旧文档。

附：供应商逃生清单总表（每项打勾才能算准备好）

所有第三方服务是不是都已分级？卡脖子级是不是都有备选供应商与导出演练日期？业务代码是不是只通过薄抽象层调用供应商？备选账号是不是跑通过最小调用？密钥清单是不是齐全？数据迁移三层校验是不是都通过？双写期是不是已排进时间表？灰度比例与观察期是不是已定？回滚触发线是不是已写死？旧服务下线收尾清单（归档、取消续费、作废密钥）是不是已准备？十项全是“是”，这份逃生计划才能用；有一项是“否”，先补那一项，再谈切换。