携程为何又被质疑“大数据杀熟”？ _经验知识

随着网友的爆料。携程又一次被推倒了风口浪尖。原因还是疑似“大数据杀熟”问题。

文章插图
回到正题。携程此次事件的起因很简单。网友在携程购买机票之后发现漏填了信息。退出购票程序并补填信息之后再次购票突然发展价格涨了而且余票不足。网友无奈之下通过航空公司的程序完成了购票。而且价格较携程没有涨价之前的票价还要低。这让网友对携程产品倍感失望。之后携程立即做出了回应。表示程序出现了“bug（缺陷）” 。随后也做出了一些具体的补救措施以挽回形象。同时强调并没有“大数据杀熟” 。
作为一名IT行业的从业者（研发人员）。我对程序出现“bug”的情况比较熟悉。任何互联网产品。或者说软件产品都存在可能出现各种bug的情况。这并不奇怪。但是作为一款运行多年且成熟度较高的互联网产品出现如此严重的bug 。还是觉得有点不可思议。不知道此刻携程的测试团队是否正在做出深刻的检讨。是否正在加班加点积极检查是否还有类似的bug没有被发现。毕竟此次事件的影响还是比较大的。
不论此次携程是否有“大数据杀熟”的情况。在信息化高度透明的移动互联网时代。企业通过“大数据杀熟”的方式来实现利益最大化是非常不明智的。这会对产品的形象造成巨大的损害。另外。大数据也不应该屡次成为“背锅侠” 。现在不少人在谈到大数据的时候首先想到的概念就是“杀熟” 。这让不少从事大数据研发的人感到不安。相信未来大数据技术会给人们的生活带来更多的美好。而不是各种“杀熟” 。
我从事互联网行业多年。目前也在带计算机专业的研究生。主要的研究方向集中在大数据和人工智能领域。我会陆续写一些关于互联网技术方面的文章。感兴趣的朋友可以关注我。相信一定会有所收获。
如果有互联网方面的问题。或者考研方面的问题。都可以咨询我。谢谢！
其他观点：
作为从业者。我是不相信给出的“bug论”的。接下来我会结合我的工作经验来说明我为什么不信。
首先概述过程。某大v在携程上买机票。个人原因在付款阶段取消了订单。结果之后再看的时候。机票价格突然上涨。比官网还要贵不少。大v靠着自己的影响力。在网上披露了这件事。结合之前就曾经出现过类似的新闻。携程不得不出面回应。把锅甩给了程序员。说是程序员的bug导致的。携程并没有恶意上抬飞机票价格。

文章插图
我来讲一下我的经历。想证明的是。不要什么事都甩给程序员。我们负责逻辑处理。不负责凭空编造数字。
我目前做的平台每周都需要出一份报表。为了方便。我自己写了一个脚本。每周二凌晨定时触发。调用另外一个服务来拉取我们的数据。我再把这份统计好的数据放到一个数据库表中。这个脚本写好之后。我测过很多次。各种异常情况都能轻松carry 。
但等到正式运行的下周二上班后。我去看数据库。发现里面有个数据不对。应该在60左右的数据。数据库里赫然记录着100 。我当时吓坏了。以为我写的代码有问题了。这种情况下。第一件事是再次调用那个服务。拉出正确的数据。然后手动去修改数据库里值。修复完数值之后。最后再去看脚本。于是修改完数据后。我又开始郁闷的debug模式。一步步执行脚本。结果发现没有任何问题。我当时心里有点纳闷。怎么会出现这种情况。但考虑到目前问题不能复现。我就把这件事暂时搁置了。又等了一周。我发现新的数据还是不对。一些现在看起来是87左右的数据。数据库里赫然记录的是83 。

文章插图
这次我能确认不是我的脚本问题了。如果说因为某种未知的异常情况。是某个数据变成百分制的的上限。也许还能说得过去。但是任何异常处理都不会吧87变成83 。那么真相只有一个。就是在脚本执行期间。对方服务的返回值就是83！于是我在脚本里增加了记录对方服务返回的步骤。拿着这个日志记录去找对面接口人。结果人赃并获。对面才确认是他们的问题。
【携程为何又被质疑“大数据杀熟”？】这个经历想告诉大家。我们程序员只是勤勤恳恳的写代码。只负责逻辑处理。你给我多少数据就是多少数据。照理说。这个查询航班价格的操作。只要输入条件（时间。日期等等）一致。那么执行流程也应该是一致的。不会第一次调用查询的时候是一个价格。第二次查询的时候。就走到有bug的模块里偷偷给你加价的。再说你说加的这个差价。又进不到我们的工资卡里。何必呢？