出站流量核验
用流量镜像或出口白名单日志，逐条比对实际外连目的地址与申报清单是否一致。为什么放在第一位：边界是否成立最终靠流量说话，架构图只能说明设计意图。通过标准是白名单外请求为零，例外项要有审批与到期时间，测试期间开启全量记录。
断网可用性
拔掉外网后跑一遍核心业务，确认检索、推理、登录与导出不依赖外部服务。怎么做：先在测试环境演练，再在生产窗口执行，记录降级表现与恢复时间；边界是部分在线校验类功能允许失败，但要在界面上给出明确提示，不能静默卡死。
并发与长稳
按业务峰值的一点五到两倍设置并发阶梯，观察任务成功率、响应分位与资源水位，再连续运行数十小时看内存与显存是否泄漏。为什么必须做长稳：短时压测看不出连接堆积与缓存增长，问题往往要到第二天才出现。
故障与删除演练
依次模拟模型服务退出、磁盘写满与网络抖动，检查熔断、重试与降级；删除演练要覆盖主库、备份、缓存与日志副本。为什么合并做：两类演练都会改动真实数据，安排在同一窗口可减少停机；边界是重试要有上限并配合退避。
适用与不适用
适合谁
- 要向上级或监管证明边界成立的信息中心与安全团队
- 正在做上线前验收、需要统一测试口径的项目组
- 承担交付责任的集成商与运维服务方
不适合谁
- 只做演示、不准备留验收记录的小规模试点
- 没有任何测试环境、只能直接在生产上试的项目
典型场景
某医院在上线前组织三轮验收：第一轮核出站流量，发现一个埋点服务在向外发送页面参数；第二轮在测试环境断网跑核心流程，暴露了登录依赖外部校验的问题；第三轮做并发阶梯与故障注入，确认切换与恢复步骤可执行。三轮记录汇总成验收报告，由信息中心与合规部门共同签字。
可执行步骤
- 先写出通过标准与例外清单并书面化，明确谁有权批准例外与有效期
- 开启全量出站日志，跑一遍典型业务并逐条比对白名单中的目的地址
- 在与生产同构的测试环境断网复跑核心流程，记录降级表现与提示文案
- 按并发阶梯逐步加压，并连续运行数十小时观察内存与显存是否泄漏
- 分别做删除与恢复演练，留存带时间戳的执行记录、耗时与复核人签字
常见坑
- 只在架构评审阶段确认边界，没有流量证据，检查时无法证明没有外连，前期结论全部作废。
- 压测只跑几分钟，看不出连接堆积与显存增长，上线次日开始出现超时，排查要花掉好几天。
- 删除演练只清理主库，备份与缓存副本仍在，事后被追问时无法举证，解释成本很高且难以补救。
- 重试次数没有上限也不做退避，故障期间请求被成倍放大，备用侧跟着过载，小故障演变成大面积不可用。
自检与验收清单
- 通过标准与例外审批规则是否书面化并明确签认人
- 出站日志是否覆盖全部服务与关键时段，是否留存备查
- 断网测试是否在与生产同构的环境执行并记录结果
- 删除与恢复的执行记录是否有复核人签字与耗时数据
常见问题
没有测试环境怎么做验收？
至少要用同构的临时环境，或在生产低峰窗口配合回滚预案执行。直接在生产上试错的风险不可控，验收结论也无法复现，建议先申请资源再排期，不要用口头确认替代实测。
压测要跑到多大规模？
按业务峰值的实际并发与请求长度分布设置阶梯，覆盖到峰值的两倍左右，并观察拐点。规模不是越大越好，关键是与真实流量同构，否则结论无法外推，也容易掩盖调度问题。
验收报告需要包含什么？
通过标准、测试环境与参数、样本与流量模型、各项实测结果、例外项及审批、问题清单与整改结论，以及签字人。报告要能被第三方复核，缺少参数的结论很难在检查时站住脚。