某天晚上突然公司Bug群里出现一个投诉，某个司机反馈近期自己的跑的订单都出现了不同程度的里程丢失问题，要求补偿。司机情绪比较激动，要求我们立即处理，否则要走法律途径balabala...
收到问题后大家都还是蛮紧张的，担心事态严重，不是个例行为。RD内部开始抓各端的人以这个司机作为案例，查原因。另外一个团队(开始只有我1个人)开始着手补偿数据的统计。这个问题两个方向同时进行。
本文只讨论数据补偿中遇到的一些思考。刚开始接到这个任务的时候还是有点懵，怎么算里程丢失？换句话说标准什么，以谁为基准，多大范围算里程丢失。
先解决第1个问题，以谁为基准。我们当前用的是高德地图，所以就不假思索的以他为标准了。
再说第2个问题。多大的范围偏差算里程丢失？
V0.1版本——理想版本
本来我脑海里第一个反应是想看看我们送驾里程的分布情况(之前听某次数据分享上说主要以短单为主，跟我们的发券有关系)，然后拿占比80%的平均接驾里程*25%作为里程丢失的标准。至于为什么25%，为什么不是20%，不是30%。别问，问就是拍脑袋的(此刻内心深处一万个CNM，平时对数据关注度严重不够)。实际上我也不是按照这个思路来统计的，以上只是在脑海中浮现了一下下，我选择了一个更蠢但相对准确的方式，于是有了以下的版本。
V0.2版本——现实版本
我从Mis后台抽取了这个司机最近两天的所有订单，肉眼一条一条观察。看啥？两个点：a. 预估里程和实际里程差异(大概看了下订单情况，心里大概有个数了)；b. 预估和实际地图对比，只要出现拉直线的case都要算，数学老师从小就教过的，两点直接直线最短。另外两条线不重合的case也有可能是问题。
通过这两个条件，基本上可以把这个司机里程丢失的badcase都找出来。很Perfect，对不对，但是...还是有问题。问题在哪？回到问题的本源：里程丢失。
里程丢失只是一个客观存在的现象，这个并不是都是“真的丢失”。上面我们分析过，实际里程小于预估里程，就是里程丢失的case。这个推论没毛病，但是有个大的前提条件：预估和实际的上、下车点基本在同一个位置。这下大家理解了吧，乘客并不一定就是在预估的上车点上车，下车点也并不一定在预估的下车点。
V0.3版本——优化版本
基于上面分析，想到方案也简单了。把所有订单的实际上车点、下车点做一次预估，然后再拿这个预估和实际里程再做对比。这里感谢RD同学(“不吃粉条”)写了脚本把数据抽出来，挽回了我的眼睛(2天的订单的肉眼查看，眼睛已经快瞎了，全部历史订单，只能呵呵了)。
还有个小插曲，关于补偿金额
补偿金额=预估金额-实际金额，讲道理没啥问题吧。内心觉得没问题的，要好好反思(包括我自己)。计价由几部分组成：里程、时长、远途、附加费。从问题来看，只是里程这个变量出了问题，如果以预估金额算，那么实际上引入了里程、时长两个变量。所以补偿金额=(预估里程-实际里程)*里程单价。
One more thing
本次事件虽然已经结束，但是还是给我们抛出了很多的问题去思考：
1. 对于里程丢失问题的定义是什么？衡量标准是什么？拓展开来，其实是对业务拆分和指标定义。
2. 虽然只有这1个司机投诉了，系统中还有没有其他的司机也存在着类似的问题(本次事件原因只有4位司机有影响)。有没有途径预先就抽样badcase来分析问题，而不是被动的等待问题上门找我们。
1是2的前置条件，想想又是一个庞大的工程。
