这两天线上有两个定时任务之间产生了冲突，可以说是线上遇到了一些问题，在两天解决问题的过程中，感觉自己的所作所为有待于改进。其实就是解决问题的能力还不行，经过思考，感觉有以下值得注意的地方
注意点
- 解决问题需要时间。一下午跑了好几趟，但是都没有想清楚
假如突然之间遇到一个问题，如果这个问题是自己写的bug，可能有很多原因导致，(对业务不熟，分布式系统中其它系统不可靠，自己的粗心)，都可能会产生问题。
然不同的条件引起的错误类型不同，如果刚出现问题立刻去说问题是怎么回事，一般是不全面的
- 对业务不熟，那么立刻去汇报，肯定还是不熟，汇报的还有问题
- 不可能只考虑正常的情况，没办法假定其它系统一定没问题。“你自己写的代码都有bug，你能保证其它的系统没有问题吗”，要考虑多种情况，防止其它系统产生的问题波及到自己的系统，其它系统可能出现问题，但是不要影响到我们，不要跟着其它的系统一起出问题。
- 自己的粗心，粗心的问题可以统一归结为没有看重自己所做的事情
因为不同的情况，会产生不同的问题，第一反应我们不可能整理出所有情况，除非问题特别的紧急，否则最好先沉下心来想想是怎么回事，好好整理问题。第二天再去汇报怎么回事，什么原因，产生了什么问题，有什么解决方案，涉及到的技术(服务，数据库，MQ)。
- 每个字段的含义要清楚。概念要理清楚
和现实生活一样，概念不清楚就好做出错误的决定，错误的选择。就比如说order_status，理解为订单状态，那么什么是有效和无效呢。
• 有效：订单已下单，并且未取消。在短租数据库中的体现就是有这条订单记录，而且不是已取消订单
• 无效：订单未下单，但是preAuth表有申请、冻结记录的。 订单已下单，但是取消了, 实际免押类型不是芝麻免押的。(PreAuth表可能有记录，也可能无记录)
可以看出来这个字段代表的意思太多了，这种就是不好的设计，如果设计以及存在，就要尽量的明白这种概念所代表的各种含义。
如果让自己设计，设计的时候就要赋予字段唯一的含义。并且字如其名。如果早期设计的好，order_status分为两个字段：(存在问题，底层存储了业务层的内容，干的事也不干净了)
- order_exists
- order_exempt_type
这个暂时也没想好，可能要多个人讨论，内部的人又共同的认知。
- 一定要刨根问底。
比如这次系统，短租传过来的MQ不对，找短租，短租说是mapi传的啥，他们就是啥，找mapi，mapi说给短租的肯定是正确的，追踪调用记录，是wap调用mapi，mapi传给短租错误数据，短租给我们错误数据，我们没有考虑到会有这种错误。
问mapi，mapi拍着胸脯说肯定没问题，但是事实上肯定是有问题的。(由业务逻辑推导出的)
系统出了问题，大家包括自己都不愿意承认是自己的问题，会推给其它的系统，大家相互推脱，因为写的时候肯定觉得自己没有问题，不然就不会往上面写了。我们要做的是查看日志，还原客观事实，实际是怎么样子的就是怎么样子的。
从自己的系统往下追踪，问清楚明白，查看日志到底是什么样子的。这种刨根问底的习惯要培养。
弄清楚是什么样的原因导致的这次问题？
出现这个问题的系统一定要联系下。
最后
每个公司都会有自己的业务，业务千变万化，出现的问题也是层出不穷，可能每天都有问题要解决，只有抓住了根本，学会了解决问题的能力，才能不至于疲于奔命。
不管什么时候 对工作要头脑清晰 ，除了关注技术 业务一定要精通 要理清 前后关联要很清楚才行