2、排查数据问题总结
在进行问题排查时，我们要抱着大胆怀疑，小心求证的态度。不要假设某个地方不会出问题，如果这个假设前提是错误的，你将永远陷入困惑的漩涡，要敢于大胆怀疑一切，不放过任何线索，综合所有知识，寻找问题的答案。
2.1、排查数据源
在遇到数据问题时，最好要先保证数据源没有问题。但是，并不是每次都要去查一遍数据源，而是要有这方面的意识。所以，最好在数据采集和数据ETL过程中，多打一些日志，并对程序和关键节点做监控，如有异常，要及时告警出来。这样，每次排查问题前，可以先检查下，是否有错误日志，或者告警信息。
当然，有时即便没有错误日志或告警信息，也不代表数据源没有问题，可能是数据程序中的某个bug，导致数据不正常。这时，需要首先缩小范围，明确是数据源层面的问题后，再去排查相关的代码逻辑。
数据源层面的问题，也有可能是采集端版本更新引入的bug导致的，所以在排查时也要考虑到这个因素，请相关部门的同事协助排查。
2.2、多维度分析
有些数据问题，排查方向一开始会觉得比较模糊，这时可以使用多维度分析的方式，使其逐步清晰。
例如，遇到日活下降的问题，数据偏低，可以对日活的时段、地域、版本、终端、渠道等维度进行分析，查看是否在某个纬度值上有明显的降低，以进一步的去排查。
实际场景中，之前发现公司新上线的APP应用，在推广一段时间后，人均浏览时长逐步下降。我们通过上述各维度的分析，最后发现新版本的人均浏览时长明显降的更厉害，所以猜测可能是版本问题，最后经由前端同事协助排查发现是合作方的SDK存在一个bug，导致我们数据上报时存在漏报的情况。
2.3、对照分析
对照分析的要点是找到一个参照系，从而确定是否有问题，以及问题的大致范围。这种方法是要找一个相近的其他数据，来做一个对比。
比如，时间上的相近（上周、上月），位置上的相近（临近的广告推荐位），类型上的相近（形态上相似），或者业务上的相近（相似的业务事件场景）等。有了参考之后，你才更容易判断数据的合理性。对照分析的核心要点是找到可以对比参考的内容，最好是可以找到多个可以对比的点，综合分析，得出结论。
2.4、debug代码逻辑
其实大部分的数据问题，最后查下来都是程序bug。但是，有时统计逻辑过于复杂，bug非常不好找。
我的建议是，分段排查，可以考虑把中间结果存储下来，或者抽取部分数据打印出来，然后分段逐个比对，不断缩小范围，最后定位到问题。
2.5、由近到远，由简单到复杂
排查的过程，应该符合先考虑和异常数据关系最近的维度或指标，排查过后再考虑较远的指标。
执行排查时，也要先排查简单的方案，再排查复杂的方案。
这是因为，排查过程中，可能会发现新的疑点，帮你找到新的线索，所以要先做能尽快执行的方案。
排查数据问题，是数据仓库工程师、数据分析师、数据产品经理工作中很重要的一部分。
而且同样的数据问题，可能会反复出现。所以，比较好的做法是，每次排查后都做下总结，在一个公共页面(WIKI)上，记录下问题的现象、排查的过程、找到的原因、对应的解决方案。这样不断积累下来，后续排查问题的效率就会越来越高，并且可以让自己以后避免再犯类似的错误，持续精进自己。
那么，在进行总结时，我们要注意以下几点：
1、问题描述要清晰，排查步骤要明确。这里说的描述清晰是指要把问题发生的背景和现象都要写清楚，这样其他人才容易看明白。另外排查步骤要进行总结，这里不是写最终找到问题原因的那个排查方向，而是把所有做了的，都按照顺序记录下来。因此，下次在遇到类似问题，可能问题原因不是上次的原因，但是排查方向是可以参考的。
2、回顾排查过程，提出更好的思路。在排查完成后，要复盘下排查的过程，设计更好的排查思路，在下次遇到类似问题时，可以更快地找准排查方向。
3、要有交付意识。在记录相关文档时，要有交付的意识，即你写的东西是为了让别人能看懂，而不是写给自己看，要从方便他人阅读的角度去写，尤其是有些业务背景知识或技术知识，不能默认大家都知道就不写，应该关注的是逻辑链的完整性，如果缺少了某个知识，逻辑推断会有点跳跃，就要把它也记录下来。
福利大放送
为了更好地帮助大家学习，
限时放送1v1模拟面试and职业规划分析诊断大礼包！
不管你是想在职提升，还是跳槽学习，
亦或者转行学习and毕业求职
这份礼包都是你不可错过的必备神器！
果汁建立了数据知识分享社群，
群内每天都有干货和免费小课资料分享。
数量有限、先到先得
根据下方方式
领取大礼包
