遇到有子系统线上重大故障，去支援，发现回滚居然也进退维谷，开发团队对排障人员的描述有所保留，前后矛盾，埋点不合理导致误导的结论，最奇葩的事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需要增加配置 |
| 运维 | 监控 | 部署前后监控的观察，接口耗时对比，日志观察，内存观察，慢请求，慢查询等进行观察 |
| 运维 | 回退方案 | 回退方案，相关影响，回退预案 |
| 运维 | 移动端 | 移动端申请发布计划 |
| 测试 | 涉及到的端口测试 | 功能性之外，需要监控观察耗时，并进行对比 |
|