利用数据依赖关系，多维锁定SEO-BUG

事件背景：我工作的一部分是负责看准网seo流量转化，流量转化的考察指标是：app下载激活，我负责的就是如何把更多的流量转化为app新增。当年发生过一个事故，而且发生了2周后，被其他同事发现，事情比较：严重，事情是：app下载包被删除，导流链接出现404。事业部leader问罪是肯定的，但本文主要讲一下如何处理此事并锁定bug。

先认错：对，这是必须的。事情从职责划分来看背锅顺序：首先，我是负责人，责无旁贷，第一背锅人，且负有追查此事的责任；其次，导流数据部分异常，却没有被数据组发现，数据同学这个锅也甩不掉；最后，也是关键的，好端端在用的app包，怎么会丢了呢？恶意被删？技术失误？运营失误？其他？这肯定是这件事的追查的要点。如果从事件发展顺序来算锅，这件事是这样的：第一，谁把包搞丢了；第二：数据组没发现异常；第三：和第二一起，项目负责人。但是，我作为负责人还有个补过的机会：查清事情原委，找到问题的原因所在，算清楚损失，建立防范避免机制。

开始查：是的，必须要积极（搞好了可以甩锅）。先算清楚，损失多少吧，这可能是罪过大小的指标了。根据包被删除前后的流量数据和相似渠道数据，发现当时基本稳定，且这本身是个小包。以前两周数据相加为准算作本次损失，没有问题。当然，如果赶在流量变化期，应该是采用原转化率与相似渠道增长趋势，来共同计算损失量。这里不再多讲。算清了，是xxx，不大。

再查bug事件过程：目前已知的是，xx月xx日发生了这件事，如果能从管理后台日志查到谁删除了包不就好了？或者从服务器操作日志中查？但是，这种事还是发挥自己的优良传统吧：穷尽自己能查到的所有进度，提出所有可能发现问题的关键点，再去找协同部门。

认真看了下app渠道新增数据，发现，事故当天的数据是前一天数据的70-80%左右。如果能够锁定事件发生的具体时间，那就好查日志了。从前文也能知道了，我的app新增是和流量有最强的依赖关系，有流量才有转化。于是把SEO流量按照小时细拆，同时把app新增数据按小时细拆，不就可以对比出事故的时间么？好像这个事有个前提，不同时间点导流转化效果要一致，也就是夜里1点钟的流量和中午11点流量质量一致。额...以前没搞过这个数啊，这...不管了，先出数上图。

第一张，流量系数图，用小时流量除以当天总流量就代表了该小时的系数：

第二张，app新增预估图，用事故昨天的新增量作为预估总量，按照上图系数，出每小时理想预计值。

第三张，时间锁定，把app小时新增连续相加，直到当天的实际新增值，即可基本锁定事故发生的时间。当日实际新增52个，根据数据显示，事件发生的时间应该在下午17：30到18:00

至此，事件发生时间已确定。

找技术协同：先找运维协助，查当天17:30-18:00的日志，找到一条含delete的json接口有执行；找研发，找到程序日志有点击删除确认操作。到这里基本确认，这事不是研发搞的，和运维也无关，是某人在后台删除了。结合该UA的其他操作，以及当天工作业务还原。基本确认为后台运营小伙伴误删了，他自己也不知道这事。还好还好，只是一个工作失误，上报leader。

建立防范机制：1.后台的删除按钮，建立两级确认操作，意思是，要删除，必须确认两次。2.建立单独的渠道包监控程序，当渠道流量环比上周同期有低于20%的波动，则邮件报警。

好了，以上重点介绍了如何处理这个工作失误，如何利用流量依赖数据锁定具体时间，以及利用运维日志、程序日志、后台操作流程等多维定位问题，对事不对人。