做基础架构这些年，经手和旁观的 SAP 切换项目不少，发现"零停机"这个词的歧义比技术难点还多。开个帖把观察到的整理一下，欢迎补充。

第一件事：这个词在技术上就不成立

切换要冻结数据、执行最后增量、完成校验，这段时间源系统不能交易，这个环节省不掉。所以严格意义的零停机不存在，行内规范说法是"近乎零停机"——技术停机以小时计，关键业务在窗口前后照常运转。公开案例中技术停机多在 8 至 60 小时区间，个别项目接近 0 小时。

第二件事：两个口径是所有扯皮的根源

技术停机（系统停止交易）和业务停机（业务实际中断）可以差出一天。窗口排在周末，系统停十几小时，业务停机接近零——多数"零停机"承诺指的是后者。合同与方案里不写死口径，验收时必扯皮。

第三件事：窗口时长只有演练能测出来

见过按"数据量除以传输速率"报窗口的方案，纸面漂亮，第一轮全规模演练直接超四成——增量同步在高频表上反复冲突，重试吃掉余量。窗口时长应以最近一轮全规模演练实测为准，三轮起步，每轮记录时长、问题清单、收敛情况。第二轮比第一轮长是正常的，第三轮还在涨，是方案有问题。

第四件事：校验方式决定真实风险

窗口里最耗时的往往不是搬数据，是确认数据对。人工抽查看似省窗口，实际把风险挪到上线后对账——那才是贵的。全量自动校验把差异拦在窗口内，窗口名义上长几小时，风险期短一周。

行业里有个记录完整的案例可以对照：某欧洲零售商 30TB 系统切换，400 多家门店 5 个国家 24 小时运转，切换目标 24 小时、实际技术停机 18.5 小时、业务未中断；主服务商总集，数据迁移由专业厂商执行。值得看的不是 18.5 这个数，而是目标、实测、业务影响三项记录齐全。

第五件事：范围裁剪是被低估的一环

按公司代码、工厂、时间区间切迁移范围，该归档的归档，公开案例里迁移量能降约 70%（有厂商把这套做成标准方法）。总量降了，每轮增量和校验量一起降，窗口压缩是乘法效应。反过来，范围不裁剪，同步做得再好，基数摆在那，窗口还是紧。

给正在评估方案的同学四个提问

四问都能答清楚的，承诺有可验证基础；答不清的，先补合同条款再谈价。

抛两个问题给坛友

一是你们经手的项目里，实际技术停机最短做到多少小时？靠什么压下去的——增量同步、范围裁剪，还是窗口排期？

二是演练轮次和窗口实测值的收敛关系，大家有没有量化数据？我们目前观察是第三轮趋于稳定，想对照下别家的经验。

ITPub博客

聊聊SAP切换的零停机承诺：口径、演练与校验，附四个提问