一、上线评审在评什么

验收中挑出一堆问题，如果不分级处理，很容易陷入僵持。临沂物联网应用公司在物联网应用项目验收时会事先约定分级：阻塞上线的严重问题修复后复验，体验类问题记录排期不阻塞主流程。这样验收进程保持节奏，双方都不至于因为一个小问题全盘停摆。

非功能验收经常被忽视，却直接决定上线后的口碑。响应速度要在真实数据量下测，而不是用演示数据看个新鲜；并发能力要按约定的人数压测；浏览器与手机机型覆盖范围要按前期约定逐款确认。这些指标没有在前期写进需求文档，验收时再补谈就很被动。

上线评审是一次综合把关：除了功能与性能，还要检查数据迁移是否完整、权限是否按岗位配置、运维手册是否交付、应急预案是否演练过、旧系统的并行或切换方案是否确认。评审会由开发、测试、运维与客户方代表共同参加，逐项签字确认，全部绿灯才允许上线。

二、上线前的检查清单

上线前的检查清单应当具体化：证书是否到期、备份是否可用、监控告警是否配置、回滚方案是否演练、客服与培训材料是否就绪。这种清单的价值在于防止低级疏忽——事故复盘里占比最高的，从来不是高深的技术故障，而是配置漏改、证书过期、忘了通知这一类本可以被清单拦住的问题。

对重要系统，建议安排一段时间的试运行：新系统先与旧系统并行运行，业务两边都操作或先跑新系统再核对旧账，确认结果一致后再正式切换。试运行期发现的问题属于正常磨合，修复成本低；直接全量切换、出问题再回退，代价就大得多。

三、验收发现问题怎么办

验收中发现的问题要分级处理：阻塞上线的严重问题必须修复后复验；体验类问题记录下来排期修复，不阻塞主流程。问题分级在验收启动时就约定好标准，可以避免"挑一个小毛病就整批拒收"的僵持局面，让验收进程保持节奏。

验收签字意味着责任边界的切换。签字前，缺陷修复由开发方负责；签字后进入质保与运维阶段，新提的需求走变更流程另计。把这层边界在合同与验收单里写清楚，对双方都是保护：开发方知道什么时候算交付完成，客户方知道后续新增诉求如何计价。

问题分级标准先约定好，验收才不会被卡住。

客户方在验收阶段的投入程度直接决定验收质量。只派一个不太懂业务的人走马观花点一遍，等于把风险全部留到上线后。成熟的做法是让真正每天要用系统的岗位人员参与验收，他们提出的意见才代表真实使用体验。

备注：验收问题分级，避免小问题阻塞整体进度。