翻了翻日志，发现居然有2年没更新了，不知不觉距离上次跳槽到某力已经2年，从一开始的各种加班到如今按部就班，从遇到线上问题抓耳挠腮到现在的宠辱不惊，从接手新需求的茫然到系统分析会上的挥斥方遒，其间也成长了一些，公司采用App + 管理后台结合快速迭代的模式，所以一个月会有一个大版本更新，为了不影响用户体验，一般采用在线发版，发版在10点之后，发版如果过于“顺利”，能从晚上10点一直搞到第二天10点（本人就有幸经历过），如果是大版本更新，正常也要到夜里12点以后，我们的功能要经历 本地》 测试》预发布》线上 四个环境，所以原则上发版不会有太大的问题，原则之外还是会发生七七八八的事情，有些值得记录一二, 话不多说，今天先分享一些。
示例一： 旧数据升级，事发凌晨12点，脚本如下，升级后，测试人员在正式环境发现部分数据无效，查询线上数据库，发现只有部分字段更新（type\route_name），而route_id 等字段未更新， 当时交接的人员武断的以为脚本未执行，选择再次执行升级
结果可想而知，执行后线上异常数据不减反增，阿里云日志上能看到脚本的执行记录double，当时仍未排查出原因，针对这类问题，还是在脚本本身，仔细分析发现， 执行的是多笔更新脚本，而不同脚本之间又存在依赖关系，如第一条脚本的条件 作为后续脚本的更新字段，所以就很明显，脚本是一次性的，若重复执行，第二次只会执行第一笔脚本，后面的脚本都不会运行，而该脚本会覆盖掉第一次执行的2，3，4条脚本，造成的后果就是凡是2，3，4 脚本执行的数据全部都被覆盖掉，线上这么多租户，每个租户又有大量的数据，想到这些简直是脑壳疼，当务之急只能是先行修复线上数据，于是乎修复工具+变更记录 各种神操作手段一一上演。当然问题产生的原因以及处理方式也值得深究
1，脚本都是jenkins 批量升级，不可能单独漏掉
2，脚本的执行记录，阿里云上都可查，发现问题后为何没有优先去查服务器执行记录，以及去分析异常数据，而是武断认为未执行
3，手动执行脚本前没有审查脚本是否可重复执行，
其实如果认真分析，问题产生的原因不难找出，可能是身体在凌晨时早已身心俱疲，脑子不清晰，反应迟缓，在测试第一时间反馈异常数据时，研发可以自行校验，比较异常数据的产生时间和数据库升级的时间进行对比，不难得出，这些异常数据全部都是在数据库升级期间执行，所以升级数据并未执行到位导致， 而脚本升级很快，升级完后可以直接在对这些数据进行点对点处理，或者说这些数据是测试人员方便测试而在特定的时间段处理，记录极少，这是其一，同样在脚本升级时，还需要考虑是否支持重复执行
原文地址：http://www.cnblogs.com/Sientuo/p/16851846.html
