第 13 课：上线准备与发布策略
上线检查清单
产品做到"能用"和"能上线"之间，有一段经常被低估的距离。上线不只是把代码部署到服务器——你需要确保用户在真实环境下能正常使用。
一份上线检查清单：
功能验证
- 核心流程在真实环境下完整跑通
- 异常场景有合理的错误提示
- 不同浏览器/设备上显示正常
数据安全
- 用户密码加密存储
- 敏感数据传输使用 HTTPS
- 数据库有备份机制
性能与监控
- 页面加载时间在可接受范围内
- 关键接口有超时处理
- 错误日志能被捕获和查看
用户引导
- 新用户能理解产品是做什么的
- 核心功能有引导或说明
- 空状态有提示文字
法律与合规
- 有隐私政策
- 有用户协议
- 数据收集符合相关法规
运营准备
- 有用户反馈渠道
- 有问题报告方式
- 团队有人值班处理上线后的紧急问题
灰度发布与功能开关
不要一次性把产品暴露给所有用户。灰度发布的逻辑：先给一小部分用户用，发现问题后修复，再逐步扩大范围。
灰度发布的常见方式：
按比例：先开放 5% 的流量，没问题再开到 20%、50%、100%
按用户群：先给内部用户或种子用户用，再开放给新用户
按功能：先上线核心功能，验证稳定后再上线高级功能
功能开关是灰度发布的技术基础——一个配置项控制某个功能是否对特定用户开放。不需要重新部署代码，改配置就能切换。
功能开关的另一个用途：紧急回滚。如果上线后发现严重问题，关掉功能开关比回滚代码快得多。
变更管理与用户沟通
上线后的变更需要管理，尤其是影响用户体验的变更：
小变更（修复 Bug、微调样式）：直接上线，不需要特别通知用户
中变更（新增功能、调整流程）：提前通知用户，给适应期。可以在应用内弹窗提示或发公告
大变更（改版、重大功能调整）：提前预告，提供新旧版本切换选项，收集反馈后再全面切换
一个常见错误：产品经理觉得"这个改版更好"，但用户已经形成了肌肉记忆，改版反而让他们找不到东西。更好的做法：新版本提供引导，让用户理解"为什么改"和"新版本好在哪"。
关键概念
- "能用"≠"能上线"：上线需要检查功能、安全、性能、引导、合规
- 灰度发布：先小范围验证，再逐步扩大
- 功能开关：配置项控制功能开放，支持灰度和紧急回滚
- 变更管理：变更大小区分沟通方式，给用户适应期
课后练习
- 为你的产品编写一份上线检查清单——根据你的产品特点增减项目
- 设计一个灰度发布方案——按什么维度逐步开放？每一步观察什么指标？