项目上线前两周，办公室的咖啡机几乎没停过。我们团队负责的这款企业协同工具，眼看就要正式发布了，可每个人的脸色都不轻松。这时候没人敢说“差不多就行”，因为谁都清楚，正式发布前会怎样，直接决定着产品上线后的生死。
功能冻结后，bug 开始“冒头”
上周五刚宣布功能冻结，测试组当天就扔过来三十多个高优先级问题。有个同事苦笑说，这就像搬家前整理衣柜，以为一切妥当，结果一拉抽屉，全是没收拾的杂物。最离谱的是一个权限逻辑错误，管理员角色在特定页面居然看不到删除按钮——这个问题藏了整整三个月，直到压力测试才暴露。
我们立刻开了紧急会议，重新梳理了用户角色流程图。不是代码写得不够好，而是真实使用场景比设计时复杂得多。比如销售部门喜欢批量操作，而财务习惯逐条确认，这两种行为模式冲突时，系统就得做出取舍。
灰度发布预案：先让一百人用起来
为了避免全线崩溃，我们决定先对内部员工开放试用，再逐步扩大到合作客户。技术上通过配置开关控制访问权限：
<feature-toggle>
<name>new-task-module</name>
<enabled>false</enabled>
<whitelist>
<user>john@company.com</user>
<user>lisa@partner.com</user>
</whitelist>
</feature-toggle>这种做法让我们在周六晚上发现了一个内存泄漏问题。监控系统显示，某个用户的任务列表加载二十次后，前端内存占用飙升到1.2GB。要不是提前做了小范围放量，真等到全员使用，服务器恐怕早就扛不住了。
文档和培训也得跟上节奏
产品经理带着手册去给客服团队做培训时才发现，操作说明里有一处关键步骤漏写了前置条件。这就像教人做饭，菜谱写着“倒入酱油”，却没提要先开火。我们连夜补了图文指引，还录了两段一分钟的小视频，方便一线人员转发给客户。
有次客户试用时问：“为什么我不能修改别人的日程？”技术支持一开始以为是权限问题，查了半天代码。后来才发现，是UI上的编辑按钮在特定分辨率下被遮住了——这种事只有真正用起来才会发现。
倒数三天，全员进入“战备状态”
发布前72小时，所有人都把个人事务往后推。运维同事提前检查了CDN节点，确保资源能快速分发；前端加了异常上报埋点，一旦出现报错能立刻收到通知。就连行政小姐姐都开始清点备用笔记本和充电器，以防万一需要通宵支援。
最紧张的是数据库迁移那晚。凌晨两点，主库同步完成后，我们用脚本比对了八千多条样本数据，确认无误才敢松口气。有人点了宵夜，结果发现外卖地址填的是公司旧办公楼——忙得太久，连基本信息都忘了更新。