不要等客户来通知问题

如何更快地发现和处理类似问题？

作者按：以下分析纯属扯淡 —— 它并非基于一系列真实的数据，而是做了诸多很可能不靠谱的假设，分析也并非深思熟虑，就是半个多小时的突发奇想。套用菜头叔的一句话：我所说的，都是错的。

按照已公开的专利：一种基于物联网的公共自行车租赁系统（https://www.google.com/patents/CN105354935A?cl=zh）的描述，借车的流程是这样子的（略修改）：

1. 利用手机APP扫描车身上的二维码，手机APP获取该自行车的唯一标识信息，并把借用请求发送到后台控制系统。后台控制系统同时给自行车的车载控制器发送开锁指令。

2. 车锁打开后，车载控制器会向系统发送开锁成功信息（同时附带GPS定位信息），自行车进入借用状态。

我的情况显然是车载控制器向系统发送开锁成功的信息，系统认为自行车进入到借用状态，而车锁实际并未真正打开。这在实际应用中是很难杜绝的问题，因为机械的开关动作无法完美地和发送开锁成功消息的芯片形成有一个完整的事务（transaction）。

上文中吐槽过，如果一个信誉良好的用户在「刷开」一辆车后，又重新扫相同的车，那么，非常非常大的几率是车锁并未真正打开。从产品的角度上讲，不应该阻止用户用车，而是再次尝试重新开锁，如果用户反复扫码，则应该在 app 中问问用户这辆车是不是无法正常开锁，并提示其汇报问题车辆。用户此时可以扫别的自行车骑行。

当然，这一优化对信誉一般的用户，或者扫一辆车没扫开，便换一辆车来扫的用户来说，不太适用。很多时候还是会出现系统认为你正在用车进而无法借车的问题，我们需要更快地，更妥善地解决它。

我们先做些定义：

1. session：每次开锁后，到用户使用完毕关锁前是一个 session。session 有下面若干种。

2. active session：正在进行中的 session，当用户扫码开锁借用一部车时，就产生一个 active session。一个用户只能有一个 active session。

3. abnormal session：不正常的 active session，比如开锁后三十分钟却无产生位移。

4. finished session：结束的 session。当用户关锁后，会结束当前的 active session，用户有资格继续借车。

还有假设：