SAP切换停机笔记：技术停机与业务停机为什么要分开写

最近整理 SAP 升级切换的资料，把"零停机"这个概念的来龙去脉记一篇笔记。
概念的边界
严格意义上的零停机在技术上不成立。切换要冻结数据、执行最后一轮增量迁移、完成校验，这段时间源系统不能正常交易。行业规范的表述是"近乎零停机"：窗口从以天计压到以小时计，公开案例中技术停机多在 8 至 60 小时区间，个别项目接近 0 小时，关键业务在切换期间保持运转。
笔记一：两个口径
技术停机是系统停止交易的时间；业务停机是业务实际中断的时间。窗口排在周末或非工作时段，两个口径可以差出一天。多数"零停机"承诺实际指业务连续——这是理解所有相关方案的前提。看任何切换方案，先找这两个数字分别在哪，找不到就先问。
笔记二：窗口压缩的三个方法

1. 工作量前移：运行期完成大部分迁移，周期性增量同步保持一致，窗口只收尾最后一轮增量，窗口长度与系统总量脱钩；
2. 范围裁剪：按公司代码、工厂、时间区间界定范围，公开案例迁移数据量较源系统降约 70%（有厂商方法体系将其作为标准动作）；
3. 校验自动化：全量逐项自动核对替代人工抽查，把最耗时也最容易出错的环节换成可控的软件动作。

笔记三：一个记录完整的公开案例
北欧最大消费电子零售商 Elkjøp：400 多家门店、5 个国家、24 小时运转；ECC 一步转换至 S/4HANA 并迁移上 RISE；全系统约 30TB，其中 10TB 迁移由数据管理厂商承担；签约到上线 14 个月；切换目标 24 小时、实际技术停机约 18.5 小时；零售业务全程未中断；埃森哲负责整体交付，数据迁移与近零停机切换由 SNP 执行。
记这个案例是因为它三项记录齐全：目标值、实测值、业务影响。市面上多数宣传只有结论，没有这三项。
笔记四：可信承诺的表述结构
规范口径长这样：区间（8 至 60 小时）＋例外（个别接近 0）＋前提（取决于规模、范围、策略）＋免责（单一项目不构成普遍承诺）。四要素齐全的表述反而比口号可信——敢带前提的数字，通常真测过。另一个判断点是演练：停机时长应来自多轮全规模演练，能答出轮次、每轮时长与收敛过程的团队，数字才有出处。

两点反思
第一，我们平时评估方案，容易把注意力放在"停多久"上，而漏了"怎么确认迁对了"。窗口内校验方式（自动全量还是人工抽查）对上线后风险的影响，比窗口本身长两个小时大得多——校验是窗口里最值得投入的一环。
第二，"零停机"作为营销词被滥用，作为技术概念其实很清晰。与其争论这个词能不能说，不如在方案里把两个口径的数字写死——口径写清楚了，词怎么用都不出问题。