编者按
本文受启发于支付团队一次项目上线中遇到的问题，特结合自身经验，对一些常见问题做统一整理，给出一些解决方案，以供参考。
问题汇总
1. 需求改动点多，涉及较多项目，构建及发布耗时太长
解决方案：
- 改动的模块越多，带来的不确定性就越大，需要考虑是否可以分拆需求，每次只做少量更新。
拆分的维度：1.功能上，2.前后端。 - 思考业务模块划分的合理性，如果可以，从功能的角度对模块的划分做一些优化，从公用及特性化的角度划分，做好各个模块之间的接口设计。
2. 产品上线环节验收周期长，产品经理投入度不够
解决方案：
- 提前确定好上线时间，尽量与产品提前沟通，尽可能协调大家的时间集中火力，速战速决。
3. 上线后发现功能与产品预期不一致
解决方案：
- 需求经评审后，不应该再做变动，如有变动需要通过变更流程（可以按较轻的流程处理），变动应第一时间知会开发人员，开发人员评估后，应给出反馈，如对项目计划有影响，应提前告知
- 产品经理需要在上线前做功能性验收，尤其是有需求变动的项目。
- 正式发布前的上线审批环节，应加入”产品经理确认-功能已实现”的环节。显式的流程有助于提醒产品经理，在开发完成或者测试完成后做功能验收，而不至于在上线后才发现，打乱上线节奏。
4. 上线后发现某些功能验证困难或者无法验证
解决方案：
- 设计或者开发阶段应考虑的功能的可测试性，从技术角度做一些工作，比如可以增加一些特殊的配置，减少这种问题的影响
- 如确实无法避免，应该提前考虑，提前告知，让大家有所准备。
- 考虑将验证环节遗留到可以验证的时候再进行
5. 上线过程遇到预期外的环境问题（服务器、网络等等）
解决方案：
- 此问题可能无法100%避免，因此建议提前将发布时间、发布方案告知运维人员，尽可能在运维人员知晓并能配合的时间发布，避免出现有问题时找不到人处理的情况，而延误上线计划。
6. 上线过程中发现依赖的内部或者外部资源并未准备好
依赖资源包括但不限于：数据库库表结构、数据库权限、网络策略、IP白名单授权、依赖的内外部服务等
解决方案：
- 上线前增加梳理依赖资源的环节，将可以在上线前准备好的依赖资源申请或者准备好，并做好验证。（多数依赖项可以独立与上线过程提前准备）
- 提前知会依赖的内外部资源的相关干系人，以便出现问题时能及时联系
- 对于依赖的外部资源更要协调好可以支持的时间。
7. 上线验证环节发现了功能性Bug
解决方案：
- 及时上报已发现的问题，对问题的严重性及影响做评估，并及时报告
- 对问题的严重性及影响做好评估，采取下一步措施：1.发布中止，回退，2. 继续发布，已经发现的问题在后续版本修复，3. 发布暂停，立即修复问题，完成后继续发布。对于需要立即修复的问题，一定不要操之过急，避免在修复问题的同时引入新的问题。
8. 项目上线后，一些依赖该项目的产品或者服务发现异常情况
此情况可能发生在一些对公共模块的修改中。
解决方案：
- 首先在项目开始阶段，应该正确评估此类模块修改的影响，对于已有的接口尽量采用兼容性的修改，对于无法兼容的情况，应该及时告知调用方做必要的修改。
- 问题出现后，及时上报，遇到不能快速修复问题，应及时回退已更新的模块，避免造成更大的影响。
结语
以上便是结合历史项目的经验，对一些常见问题整理，并给出的考虑解决方案，希望对后续项目上线有所参考。总体上讲，应该坚持：早准备、早评估，早发现，早解决。对于可能出现的问题应该有所预见，这样才能临危不乱，游刃有余。
欢迎评论、补充、讨论。
