割接 — 用能撤回来的方式上线
一句话总结
割接不是一次部署，而是多个团队按既定顺序协同行动的作业；成败取决于是否事先用数字明确了回滚标准。
为什么要预先确定标准
“出了问题就回滚”不是计划。凌晨三点，人们疲惫不堪时，每个人对“问题”的定义都不同；如果到现场再判断，总会发生同一件事——一次次说“再观察一下”，最终错过还能回滚的时间窗口。
因此，应在计划书中提前写明阈值、观察区间和判断时限。如果明确写着“04:00 前冒烟测试未通过就回滚”，到时负责判断的人无需鼓起勇气，只需执行已经作出的决定。
割接不是“部署”
对开发人员而言，部署是上传文件并重启服务。 在 SI 项目中，**割接（移行，cutover）**的范围远远更广。
[사전] 이행 계획 승인 · 백업 · 공지 · 서비스 중단 안내 · 배치 정지 · 연동 상대 통보
[본작업] DB 스키마 반영 → 데이터 이관 → 애플리케이션 배포 → 설정 반영 → 기동
[검증] 스모크 테스트 → 핵심 업무 시나리오 → 연동 시스템 상호 확인 → 배치 재개
[종료] 이행 결과 보고 → 상황실 운영 → 롤백 판단 시한 경과
多个团队需要同时按规定顺序行动。因此，割接需要检查清单和 时间线，每一项都要标明负责人、预计耗时和“预期结果”。 没有预期结果，就没人能够判断该项是否成功。
回滚不是计划，而是“标准”
“出了问题就回滚”不是计划。凌晨三点，人们疲惫时， 每个人对“问题”的定义都不同。因此，必须提前制定数字化标准。
| 指标 | 阈值 | 观察区间 | 措施 |
|---|---|---|---|
| 订单 API 错误率 | 超过 5% | 10 分钟 | 回滚 |
| 登录响应时间 p95 | 超过 3 秒 | 15 分钟 | 观察后重新评估 |
| 批处理延迟 | 超过 60 分钟 | 1 次 | 回滚 |
| 数据一致性不符 | 哪怕 1 条 | 立即 | 回滚 |
还要确定回滚判断时限。“凌晨四点前验证未通过，就无条件回滚。” 没有这个时限，即使到了早上六点，人们还会反复说“再观察一下”， 最终在业务开始时间用一套半故障的系统对外营业。
没有备份就不开始
割接检查清单的第一项永远是备份。而且，不是确认备份“已经生成”， 而是必须确认**“能够恢复”**。从未尝试恢复过的备份，不算备份。
至少要准备以下三项。
- 数据库备份（以及实测恢复耗时——需要 3 小时的恢复，在凌晨割接中不能算回滚手段）
- 应用产物（旧版 WAR/JAR + 配置文件）
- 配置文件（Tomcat
server.xml、context.xml、nginx conf、防火墙策略、批处理计划）
尤其常见的是遗漏配置文件备份。应用虽然通过标签回退了，
但 server.xml 中的连接器设置或数据库连接池大小，却无人知道何时由谁修改过。
冒烟测试——必须在 5 分钟内结束
割接后立即进行的冒烟测试，不是确认“所有功能是否都能运行”， 而是在 5 分钟内确认**“系统是否发生致命故障”**。
- 服务是否开放端口并响应（健康检查）
- 是否能够登录
- 数据库连接是否存活（查询 1 条数据）
- 是否能向对接系统发出调用（1 条核心接口）
- 错误日志中是否正在涌入新的异常
如果将这些检查做成自动化脚本，即使凌晨操作时双手发抖，判断标准也不会动摇。 依靠人工点击页面的冒烟测试，会随着人员疲劳而变得越来越不准确。
集成测试中经常暴露的问题
割接前集成测试发现的缺陷具有固定模式。
- 环境差异——只在开发环境正常。首要原因是配置文件和防火墙， 第二是数据库数据状态（开发环境存在的代码值，生产环境没有）。
- 对接时序——对方系统的批处理在 03:00 运行，而我方批处理在 02:50 运行。 文档中只写着两边都是“凌晨批处理”。
- 字符集与长度——韩文每字 3 字节（UTF-8）与 2 字节（EUC-KR）的差异。向长度 20 的列 写入 10 个韩文字符时，会在 UTF-8 下被截断。
- 权限——生产数据库账户的权限比开发环境更窄，直到割接当天才发现无法执行
CREATE TEMP TABLE。
如果在割接前使用与生产环境配置相同的验证环境进行一次演练， 大多数问题都能被过滤掉。跳过演练的割接，只能在凌晨即兴演奏。
割接结果报告
凌晨作业结束后，要编写结果报告。各公司的格式不同，但必须包含以下内容：
- 实际开始/结束时间，以及与计划的差异
- 已执行的作业列表及每项结果
- 发生的问题与处置记录（未能解决的也要写）
- 备份文件位置与回滚流程（整个稳定期都会参考）
- 下一个工作日需要确认的事项
认真编写这份文档，可以让稳定期的故障分析工作减少一半。 因为它是唯一能够回答“上线时修改了什么？”的文档。
生产现场中的常见情况
割接失败的典型原因不是技术问题，而是顺序问题。
- 未停止批处理就开始迁移数据，导致迁移过程中进入的数据被遗漏。
- 没有通知对接方，对方系统在我方停机时段发送报文，结果全部积累为失败。
- 备份时间晚于模式变更，真正需要回滚时已经没有可恢复的内容。
验证阶段的另一个问题是冒烟测试耗时过长。无法在 5 分钟内结束的冒烟测试会消耗判断时限，最终不留时间决定是否回滚。冒烟测试只确认“核心业务能否运行”，其余内容留到联合值守期间观察。
要求在割接结果报告中填写实际备份文件名，也是同样的原因。只写“备份完成”的报告，在真正需要时无法告诉人们该使用哪个文件。