反思线上问题定位效率

背景说明

我在排查 https://www.cnblogs.com/xushengbin/p/18368362 问题过程中，前前后后花了超过16小时。
做了各种尝试，才搞明白原来是自己上周做了一个性能优化引入的问题。

定位问题原因时间成本很高，原因如下：

1. 最近几天数据不一致的行数明显增多（1天2000多行），之前是稳定的100行。 这造成了干扰，让我无法对问题引入时间下确定性结论。因为到现在还不确定为啥每天有100条左右数据不一致（对用户影响较小，没有反馈类似问题）
2. 有考虑过可能是最近代码修改引入的问题，做过相关代码的review。但是这一条执行的不够彻底，没有对上游关联代码做check
3. 后来加了日志，基本能推断是乱序导致的。但是无法100%肯定，后来又加了花时间加了一些日志定位、分析问题。
4. 被问题表象困扰了。 每天设置一个window，允许1天的迟到数据。第二天凌晨5点会做当天数据初始化，此时，也触发了前一天window的计算，这个应该是合理的。 当时把心里花在：为啥会触发前一天的计算？即使触发了为啥会有bug，是不是代码逻辑有问题。 后来发现，trigger只是表象，最关键是前一天内存中数据已经乱序了。

教训

1. 还是应该更多聚焦在引入问题诱因上。诱因找到了，问题就很容易修复。诱因分析要全面。 显然，我花了大量时间在分析各种可能性上，最终虽然问题解决了，但是时间成本真的太高了。
2. 知识盲区（如不知道为啥每天有100行左右的不一致数据）会增加问题分析的复杂度。

好在问题还是解决了，这里面借助了阿里云SQL审计、内存数据写入DB等手段。