广告检索一致率排查过程

事件流程：

1、7月11日上午11:15，通过freedom发布dump-ecpm、sn-ecpm、emerge到smoke环境，由于本次dump-ecpm修改了索引结构，因此通过freedom发布sn-ecpm时应用无法启动，原因是索引结构不兼容updated无法正确追消息，也就无法自动拉起master进程。此时只能等待dump模块build索引完成后切换索引。
2、dump在build过程中出现错误，标志文件未删除导致build失败，发现这个错误时已经是15：30左右，解决这一问题并重新build。
3、18：30索引build并下发完成，开始启动updated追消息，大约19:40消息追完，master成功启动。
4、启动后发现一致率由80%降至50%。

排查过程：

1、通过藏经阁对比测试工具发现，返回的广告主不一致情况、竞价收入、ifs反馈为不一致的主要原因。

由于本次改动对ifs串进行了修改，第一时间想到了可能是对比工具不兼容。于是找到了QA同学进行了沟通，将对比工具进行了对应的升级，一致率从50%涨至60%，但仍然没有恢复到上线前的状态。

2、此时开始怀疑是改动引入了未知的业务逻辑变动导致。

本次改动是多个模块同时改动，在所有模块修改均没有错误的情况下，不应该有任何业务上的变化。既然出现一致率的问题，那么怀疑很有可能是各个研发团队之间沟通出现误会。在老的广告检索逻辑中，结合cmo_status和crowfilter这两个字段对广告进行过滤；在新的逻辑中，在这个过滤逻辑的后面又添加了结合cmo_status和targetbuyer这两个字段进行过滤的逻辑。cmo_status数据来自于广告检索请求，不再本次改动中。crowfilter和targetbuyer这两个字段都来源于BP端，事先和BP团队约定好：

（1）由于暂时不希望targetbuyer过滤功能生效，BP会把crowfilter一一映射到targetbuyer字段上面来  
（2）理论上，映射过程中crowfilter的值和targetbuyer的值在过滤逻辑中完全等价。  
    即若crowfilter在老逻辑中被过滤，则其映射的targetbuyer值也一定被过滤；  
    反之，若crowfilter在老逻辑中不被过滤，则其映射的targetbuyer值也一定不被过滤。  
（3）由于广告主数据庞大，对于BP团队未来得及映射这种情况，targetbuyer会不存在，检索逻辑中对这种情况，对targetbuyer不进行过滤。

由于不一致率异常，怀疑BP映射的数据存在问题，导致暂时本不应该生效的targetbuyer过滤生效了。检查广告检索的逻辑，发现crowfilter有一个取值为2的情况，是无法无损的映射到targetbuyer中的，若果出现crowfilter=2的情况，业务逻辑就会出现问题。于是写了脚本到海量索引数据中去抽样检查映射关系是否存在crowfilter=2。结论是，线上与smoke环境均没有出现crowfilter=2的情况，映射关系完全正确。

3、决定回滚上线模块，恢复一致率，再进一步追查

回滚emeger：一致率60%  
回滚master：一致率60%  
拉取线上索引到smoke：一致率60%  
怀疑rtp与线上基线不一致，smoke环境sn直连线上rtp：一致率60%  
emerger直连线上sn：一致率60%  
emerger直连线上uts：一致率60%  

至此，发现一致率无论如何也回不到最初的80%了。开始怀疑是除我改动的模块外，smoke有其他地方发生了变动。由于11日smoke上线经历了8个小时，上线前一致率80%。上线后60%，因此怀疑是在我上线的期间有人恰好动了环境。于是到各个群去和同学们询问，未果。

4、确定环境变化位置

eswitcher直连线上emerger和supermerger：一致率60%  

由于一致率对比工具的流量直接打到eswitcher上面，因此严重怀疑是eswitcher发生了变化。于是对比smoke和线上的eswitcher二进制文件，发现是完全一样的。检查log文件，没有发现异常。至此，已经毫无头绪。

问题的解决：

由于毫无头绪，决定将藏经阁分析出的不一致请求复制出来，利用华佗系统向smoke和线上重发请求串，并进行trace，企图从trace数据中看出端倪。分析了很久，定位到sn返回给emerger的广告候选集有较大不同。由于sn内部没有trace埋点，无法进一步进行排查。偶然间，扫了一眼trace记录中的机器列表trace，发现出现不一致的请求串如果通过smoke环境的eswitcher发出，都会访问rtp机器，而如果直接通过线上eswitcher发出，则不会访问rtp。结合之前的分析，定位到可能是eswitcher中的某一配置文件，影响了部分请求是否访问rtp，而smoke和线上的这一配置文件不一致。根据以往梳理代码的经验，rtp的访问参数是写在试验参数里面的，而试验参数的配置文件是在eswitcher模块中。于是md5sum检查了线上和smoke环境的exp_param.conf文件，发现果然不一致，线上的配置文件最近被更新过，而smoke环境没有更新。查询改动时间，刚好是11号16:40左右，也就是我上线的期间。将配置文件从线上拉到smoke，一致率回到了80%。

收获与教训：

收获：

先从自己的收获说起，通过这次故障的排查，最直接的收获是对系统的整个链路有了更直观的感受，并且体会了很多细节。在排查问题的思考过程中，除了考虑代码本身带来的影响，还要深入思考数据的变动、广告主行为的变化是否会影响竞价结果，导致不一致。虽然问题最终没有出在这里，但是仍然锻炼了这方面的思维。

教训：

1、上线前一定要理清流程。主要是保证两个点：
（1）尽量缩小影响范围，即尽量“分步上线”，每次上一个模块，这样如果出了问题，可以迅速划定引入故障的原因的范围。比如，本次上线应该先只上emerger，观察一致率没有问题了，再上其他模块，以此类推。
（2）“缩短时间”，针对smoke环境，每次变动消耗的时间应尽可能短，规避有其他同学同时改动smoke环境带来的风险。
2、问题排查
（1）总体感觉这次排查在思路上还是存在问题，这个问题可能很多人都有。在怀疑问题的时候，有时候因为基于速成，会把问题定位在一个很小的范围内，比如代码逻辑出了问题、BP数据出了问题，然后一个一个的试错。运气好，或者定位的准的话，这样确实可以很好的解决问题，但是对于不明所以的异常，这样试错其实是浪费了时间。因此，对于“不明所以”的异常现象，应该首先确定异常原因的范围。比如本次异常，第一时间就应该将smoke的emerger连到线上，查看一致率。若一致率仍然为60%，可以直接断定sn没问题，问题出在emerger及其以上的链路中。
（2）在设计和写代码时要思考再三，不断质疑自己；而在出现问题时，反而要对自己自信，相信很大可能不是自己的问题。
（3）团队合作时一定要按套路出牌（比如先上smoke再上生产），否则误伤队友总是不好的！