发版检查list

遇到有子系统线上重大故障，去支援，发现回滚居然也进退维谷，开发团队对排障人员的描述有所保留，前后矛盾，埋点不合理导致误导的结论，最奇葩的事dao层进行了买点，直接把sql的一部分拼接上去，导致所有人以为耗时是sql的耗时，一直在看数据库的问题，又说这次是个2期，只是list里面加了十几个，功能和一期一致的，导致大家任务代码问题不大
最后看版本发布，涉及的代码确实是一期上的，但是一期没有调~~没有调
领导喊回滚，居然公共类设计好几个其他部门，如果回滚要把数据库再刷一遍，得刷4个小时，折腾一整天，各种验证，各种脑洞，最后还是我对比2个版本代码找到了原因，就是2层for循环里面调了redis，之前2层for长度是7，7X7也还好，这次for的长度到了30,30X30就要掉redis900次，不故障才有鬼呢

所以还是梳理一个清单，在上线前准备好，别上线之后抓狂

人员	检查项	说明
开发	代码库分支	上线发布的代码库分支，版本，多模块需要全部列出
		是否有公共模块代码，重点进行代码review是否完成
		是否评审过各种埋点合理性，日志脱敏
开发	配置变更	各个环节配置变更
开发	数据库变更	数据库脚本，回退脚本，数据备份，是否有刷表等长任务情况，可能和定时任务时间冲突，兼容情况
运维	开窗时间和方式	部署的时间，是否有灰度发布，任务调度是否需要调整
开发	开关控制	功能点的开关控制
开发	缓存	是否需要清理刷新缓存
开发	策略文件、合同模版更新	是否设计各种权限策略文件、合同模版变更，各环境文件路径
开发	消息中间件	是否有消息堆积，消息是否兼容
开发	数据认同不	数据库表结构变更是否涉及各种抽数，kettle，dts，ogg，确定依赖方影响范围
运维	角色和权限	是否是要变更
运维	工作流	是否需要变更
运维	新增设备	是否需要开墙，白名单等，申请权限
运维	中间件配置	F5，nginx，ingress，cdn点
运维	启动脚本	启动脚本是否需要变更，是否有相关参数调整
运维	日志文件	是否有新增的日志文件，filebeat需要增加配置
运维	监控	部署前后监控的观察，接口耗时对比，日志观察，内存观察，慢请求，慢查询等进行观察
运维	回退方案	回退方案，相关影响，回退预案
运维	移动端	移动端申请发布计划
测试	涉及到的端口测试	功能性之外，需要监控观察耗时，并进行对比

|