随着公司业务需求不断增长，发布也是越来越频繁，周一到周五，各种发布不停，本来计划下午就能上线的，缺因为各种原因拖到晚上，甚至第二天凌晨，总结以下原因大概有以下这些。
需求方面： 需求方面管理不足，产品在列出需求后，直接和具体的业务线开发程序员沟通，而没有更高一层的人员进行全局把控，导致出现以下问题：
- 一个需求本可以使用已有接口，却进行了重复开发
- 一个需求使用了已有接口，但是这个接口是用于已有业务场景，性能功能方面可能考虑不全，功能方面可能不能覆盖所有场景
- 本应进行拆分的接口，却还在原有接口上进行开发，导致接口职责不再单一，耦合度剧增
- 开发人员擅自接了一些看似简单的短时间能完成的需求，一来增加了发布次数，二来由于业务耦合度高，可能造成系统其它方面出现问题 技术方面：
- 由于系统使用RPC调用，业务之间强依赖，一旦一个节点发布出现问题，会直接影响到一片业务，而且不好排查到源头
- 预发布和发布过程中发现的问题，及时排查修复后，没有经过测试验证，便上线，可能会由于短时间内精神紧张或考虑不周，导致出现更多bug
最终，公司出台了这么几条规定来解决以上问题：
- 最直接的，就是控制发布时间，发布时间改为周二周四，常规火车发布
- 剩下的时间，除非为紧急发布，即出现线上bug，且影响程度到达high级别，必须经过各部门总监审批后，才能发布
- medium、low级别线上bug跟随周二周四火车发布修复，其他需求类发布一律禁止
- 发版当天，控制时间在晚上8:00之前必须发布完成，如未完成的，顺延到下一个发布日上线
- 新需求，不管难易大小，必须经过与BA（业务架构师）的沟通后，方可进行开发，保证业务可控，接口范围明确，需求与接口关系明确。
- 技术难点、流量较大接口，开发前需要经过技术架构师评审，开发完成后，需要其进行code review，保证代码质量
- 发版后，排查出的bug，不管解决难易，必须经过测试再次验证后方可上线，如果超过8:00，必须回滚，顺延下一发版日上线