工程质量保障的基本规范和建议

对于正式运行在线上的大流量服务，保障工程质量和系统稳定性尤为重要。 根据组内实践及现状，制定工程质量保障的基本规范和建议。

三个级别###

【必须】： 一定要做到的，不做容易出BUG或故障。没有的话，必须立即补上。

【应当】： 应当要做到的，有益于从团队角度和新人接手时保障质量。没有的话，尽早补上。

【建议】： 建议要做到的，有益于提升工程质量和个人编程能力。 逐步完善。

级别与内容分离。内容尽量不包含级别。

规范和建议###

质量保障说明####

【应当】每个工程在 README.md 里面，添加一项“质量保障说明”，说明本工程发布应当遵循的质量准则和措施。

【应当】工程的接手同学应当首先熟悉工程的质量保障手册，才能在该系统内开发和发布代码。

发布准则####

工程发布遵守以下准则： 单测全部通过 - CR通过 - 接口测试用例集合通过 - 预发线上对比工具通过 - 线上验证无误。

(0) 【必须】变更代码或者新增代码，有单测覆盖； 捕获异常有异常单测；单测全部通过。

       a.  【建议】像写生产代码那样编写优雅的单测代码。                                                                                                                                

(1) 【必须】提交代码Review， 通过应用Owner及另一位有经验的开发同学CR通过；

       a.   【应当】对于任何CR意见，给予及时改进或合理的回应；通过代码优化及积极沟通确保CR及时通过； 
       b.   【应当】非紧急发布，CR在发布前一天完成； 紧急发布，CR与发布时间相隔半天。                     
       c.   【应当】核心应用不应当有硬编码（魔数、写死的业务名）和重复代码；想办法消除它。                           

(2) 【必须】有相应的单接口测试用例集合，并且确保QA环境接口测试用例集合全部通过；

(3) 【建议】 分支代码合并master后在预发部署，确保 service.log , trade.log , root.log 都正常启动，无任何异常；

(4) 【应当】实现一个预发与线上的对比工具，分别发送请求给预发和线上，检验预发和线上的结果是一致的。

(5) 【必须】谨慎发布，密切留意日志与监控报警。

       a.   【必须】确保 service.log , trade.log , root.log 都正常启动，无任何异常。                                                
       b.   【必须】紧密观察是否错误日志，监控报警信息、 系统监控图表；第一批发布完成后适当停顿一段时间，确定没问题后再第二批。   

(6) 【必须】线上发布完成后，至少停留半小时，校验线上无问题方可。

日志巡检####

【应当】例行巡检线上异常日志、报警， 努力设法消除它们，不可忽视。

监控与报警####

【应当】 对于核心业务流程，配备相应的监控与报警。有相应的监控报表输出，有完善的报警机制。

性能数据####

【建议】 对于大并发量应用，建议有定期性能数据，对系统承载能力了如指掌。

说明###

• CR 工程师必须坚守原则，觉得不能通过的，不应因发布的要求而勉强通过。