TGFC Lifestyle - Powered by Discuz! Board

标题: 锤子手机4G版预约人数有水分？天猫回应了 [打印本页]

作者: cpspig 时间: 2014-10-12 20:06 标题: 锤子手机4G版预约人数有水分？天猫回应了

http://news.mydrivers.com/1/324/324391.htm

国庆假期期间，锤子手机4G版现身天猫商城页面显示该机预计将在10月18日正式开卖，售价为3500元。
昨天，锤子科技正式公布了锤子手机4G版即将上市的消息，10月18日的备货数量为1万台，在天猫上参与预约的用户还将获赠价值200元的意外保修服务，相当于花费3300元就买到了一部32GB版的4G版锤子手机。此时，天猫上已经有8万多人预约了锤子手机4G版。
就在这个时候，有用户在网页代码中意外发现4G版锤子手机的预约人数有水分，页面显示的数字是实际预约人数的三倍，从而再度把锤子手机推到了风口浪尖上。
现在，天猫对这一事件做出了正面回应。天猫表示，截至10月7日，锤子手机4G版的预约用户数为62682人，但在10月8日，系统调用一个数据端口时，意外将前端该页面动态数据显示“清零”。
为了尽可能让预约数据还原真实，天猫决定将10月8日起的新预约数，做了“乘以三”的处理，以便后期预约数能快速接近真实数据……
目前天猫已经对页面做出了更新，显示了第一波的预约人数，从10月8日起新的预约人数则单独显示出来。
天猫回应全文如下：
关于锤子预约数据意外的说明
感谢锤子手机，首发选择天猫电器城“新动”栏目。然而，10月8日的一个前端数据展示意外，让我们感觉愧对“情怀”。
事情的经过是这样的：
为了方便锤粉们第一时间抢购，从10月1日起，天猫电器城就开通了锤子手机购买预约服务。点击“立即预约”后，在18日正式开售前意向消费者可以得到手机短信提醒。
尽管是长假，但锤粉们的热情依然高涨，预约的人数每天蹭蹭往上涨。截至10月7日，预约用户数达62682人。
就在长假回来第一天，系统调用一个数据端口时，意外将前端该页面动态数据显示给“清零”了！！！零！了！难道前台要显示“预约0人”吗？这不科学！
着急的攻城狮们加紧修复故障数据接口。为了尽可能让预约数据还原真实，一位自告奋勇的前端程序猿做了一个极其不科学的决定——将10月8日起的新预约数，做了“乘以三”的处理，以便后期预约数能快速接近真实数据……
然后的然后....在热心的网友指出问题后，我们立即组织人员查明真相，修复故障数据接口，系统预约数据现已恢复正常。
在此，我们对锤子科技，以及一直以来信任和支持我们的消费者们，真诚的说声：“对不起 ”！至于那位自告奋勇的程序猿事后非常紧张和尴尬。现在不确定，他是否躲在角落已经羞愧难当......

[attach]696630[/attach]

作者: dorashop 时间: 2014-10-12 20:08

posted by wap, platform: Meizu MX4
逗sb的解释。直接说程序员是临时工就好了。

作者: cpspig 时间: 2014-10-12 20:09

蓝翔毕业的程序猿吧~ 还不如随便填个相近的数字呢。

而且后台没订单核对嚒？ :D

作者: LTFYH 时间: 2014-10-12 20:13

posted by wap, platform: SONY 巨猴
太tmd sb的说法，难道你没法查出实际的预订订单？还前端动态数据清零......

作者: 伪 时间: 2014-10-12 20:14

这个解释太奇怪了，那干脆直接搞个乘65535，然后一个预约之后再改回来不就行了？

作者: tobewind 时间: 2014-10-12 20:25

填个相近的数字不行吗?

这解释也是极其sb, 还卖萌

作者: ofanjx 时间: 2014-10-12 20:26

posted by wap, platform: Chrome
预约都没记录的？就是个计数器？

作者: meidle 时间: 2014-10-12 20:29

你竟然能想到“预约数×3”，却想不到“预约数+62682”，你是猴子请来的救兵吗

作者: ttsyyh 时间: 2014-10-12 20:30

posted by wap, platform: 小米红米
跟老罗多大仇

作者: 纳尼 时间: 2014-10-12 20:44

posted by wap, platform: Meizu MX4
傻逼。。。

作者: 天际线王子 时间: 2014-10-12 21:36

posted by wap, platform: Android
这不是罗永浩花钱了是什么。哦，不对，也可能这是一种情怀。

作者: ValuePack 时间: 2014-10-12 21:39

posted by wap, platform: SONY Xperia Z3
故意在黑老罗吧……

作者: pocketmom 时间: 2014-10-12 21:43

posted by wap, platform: Chrome
这个申明，还真以为锤粉都是SB了？

作者: ky-ex 时间: 2014-10-12 21:46

多大仇~

作者: 分分钟叫你做人 时间: 2014-10-12 21:48

posted by wap, platform: HTC EVO 3D
预约没预约记录查不到？非要用这么傻逼办法去还原？

作者: akilla 时间: 2014-10-12 21:57

千亿美金企业连个靠谱的码农都请不起吗？

作者: majian1 时间: 2014-10-12 21:57

posted by wap, platform: HTC Butterfly S 919D
锤子手机简直无时不刻都在制造笑话，几乎任何和锤子沾上边的人和事都是一身屎，这也是一种本事啊。

作者: Livy 时间: 2014-10-12 22:05

posted by wap, platform: iPad
前端清零又不会影响后台数据

除非是本来就作弊，意外重置前端以后显示了后台真实的预定数，而真实数字太难看

于是情急之下直接用了*3大法

作者: 雾桑 时间: 2014-10-12 22:07

锤子真tmd太牛逼了，才5W多台的销量的小企业，就能让创造IPO纪录的企业主动来背黑锅

作者: Crusher 时间: 2014-10-12 22:09

posted by wap, platform: iPhone
锤子：反正不是我的错！

作者: 绯雨流 时间: 2014-10-12 22:10

三倍情怀

作者: holybell 时间: 2014-10-12 22:16

posted by wap, platform: Chrome
不记录怎么发短信？

作者: 天际线王子 时间: 2014-10-12 22:25

posted by wap, platform: Android

引用:

原帖由 @雾桑于 2014-10-12 22:07 发表
锤子真tmd太牛逼了，才5W多台的销量的小企业，就能让创造IPO纪录的企业主动来背黑锅

因为老罗吹过的牛逼他可以无视+不认帐啊。

作者: coin1860 时间: 2014-10-12 22:37

基本能说通，实际预定记录当然存在，但是每次刷页面及时统计数据库服务器分分钟就挂了。所以需要nosql的缓存服务器存储动态数据。而天猫的动态数据是存在hbase上的。丢的是缓存服务器上的数据。
阿里码农一个季度30分故障分。这种故障算B类，故障时长维持一个小时要扣100分。基本年底5个月工资晋升无望。估计是这个码农临时想到一个解决方案紧急发布来降低故障分。

作者: samuelj 时间: 2014-10-12 22:37

posted by wap, platform: 华为
马云缩了，怕被优酷直播吊打啊！

作者: wenhan1026 时间: 2014-10-12 22:42

这声明是真把锤粉当傻逼了，万一哪个头脑不清醒的锤粉到处转这玩意给老罗洗地，那场面惨不忍睹了

作者: riva128 时间: 2014-10-12 22:45

说明阿里经常干这种勾当，双11之类的数据水分都一大把

作者: wenhan1026 时间: 2014-10-12 22:46

虽然只是两三万台销量的小企业，但是企业主满世界收购苹果、剿灭三星的吹牛逼，动不动还要上视频网站在千万网友面前表演插嘴杂技，这种光脚不怕穿鞋、随时和你拼命的货色你就是再有钱，你能不怕？

作者: qwert2002 时间: 2014-10-12 22:46

这是反串黑吧

作者: zo 时间: 2014-10-12 23:23

posted by wap, platform: VIVO

引用:

原帖由 @coin1860 于 2014-10-12 22:37 发表
基本能说通，实际预定记录当然存在，但是每次刷页面及时统计数据库服务器分分钟就挂了。所以需要nosql的缓存服务器存储动态数据。而天猫的动态数据是存在hbase上的。丢的是缓存服务器上的数据。
阿里码农一个季度30分故障分。这种故障算B类，故障时长维持一个小时要扣100分。基本年底5个月工资晋升无望。估计是这个码农临时想到一个解决方案紧急发布来降低故障分。

我觉得这位兄台说得有理。

作者: piposaru 时间: 2014-10-12 23:35

这不是一次两次了吧？淘宝的宝贝收藏数都是X2的，不信你们试下

垃圾阿里巴巴，正好配罗情怀

作者: pocketmom 时间: 2014-10-12 23:35

posted by wap, platform: ZTE N986

引用:

原帖由 @coin1860 于 2014-10-12 22:37 发表
基本能说通，实际预定记录当然存在，但是每次刷页面及时统计数据库服务器分分钟就挂了。所以需要nosql的缓存服务器存储动态数据。而天猫的动态数据是存在hbase上的。丢的是缓存服务器上的数据。
阿里码农一个季度30分故障分。这种故障算B类，故障时长维持一个小时要扣100分。基本年底5个月工资晋升无望。估计是这个码农临时想到一个解决方案紧急发布来降低故障分。

解释不了手机端为啥始终是网页版的3分之一。按道理要改就一起改。。。

作者: Crusher 时间: 2014-10-12 23:51

posted by wap, platform: iPhone

引用:

原帖由 @coin1860 于 2014-10-12 22:37 发表
基本能说通，实际预定记录当然存在，但是每次刷页面及时统计数据库服务器分分钟就挂了。所以需要nosql的缓存服务器存储动态数据。而天猫的动态数据是存在hbase上的。丢的是缓存服务器上的数据。
阿里码农一个季度30分故障分。这种故障算B类，故障时长维持一个小时要扣100分。基本年底5个月工资晋升无望。估计是这个码农临时想到一个解决方案紧急发布来降低故障分。

hbase集群要丢失数据太难了，
连我们的缓存服务器都有二十几个节点，我不信天猫的会比我少

退一万步，缓存真的在全部节点丢了，重建也要不了多久

总得说来，就是玩猫腻被人揭穿找个台阶下罢了，和技术无关

作者: shui192168 时间: 2014-10-13 00:27

引用:

原帖由 coin1860 于 2014-10-12 22:37 发表
基本能说通，实际预定记录当然存在，但是每次刷页面及时统计数据库服务器分分钟就挂了。所以需要nosql的缓存服务器存储动态数据。而天猫的动态数据是存在hbase上的。丢的是缓存服务器上的数据。
阿里码农一个季度30 ...

你要知道对于互联网企业真的出了技术问题是不会发通知的

作者: coca360 时间: 2014-10-13 00:31

posted by wap, platform: iPad

引用:

原帖由 @Crusher 于 2014-10-12 23:51 发表
hbase集群要丢失数据太难了，
连我们的缓存服务器都有二十几个节点，我不信天猫的会比我少

退一万步，缓存真的在全部节点丢了，重建也要不了多久

总得说来，就是玩猫腻被人揭穿找个台阶下罢了，和技术无关

数据丢失我相信不会，但做前台的码农有没有权限快速恢复又是另一件事了。我觉得24楼应该猜的八九不离十，这很可能是自作聪明的临时工干的，如果前台有权限的话直接更新数据库的时候乘以三倍不就行了，还用得着呢么费劲的写在JS里给你们打脸。。。

作者: heven2004 时间: 2014-10-13 01:20

posted by wap, platform: VIVO Xplay3S
都什么时候了居然还有帮锤子洗地的？

作者: gundamlrc 时间: 2014-10-13 01:36

有情怀的锤子当然得配有情怀的程序猿

物以类聚人以群分啊，锤子就是那手机中的战斗机

作者: CAGY 时间: 2014-10-13 02:07

数据都是刷的有什么可说的，天猫这种解释只能骗骗外行

作者: babylover 时间: 2014-10-13 02:21

posted by wap, platform: iPhone

引用:

原帖由 @coin1860 于 2014-10-12 06:37 发表
基本能说通，实际预定记录当然存在，但是每次刷页面及时统计数据库服务器分分钟就挂了。所以需要nosql的缓存服务器存储动态数据。而天猫的动态数据是存在hbase上的。丢的是缓存服务器上的数据。
阿里码农一个季度30分故障分。这种故障算B类，故障时长维持一个小时要扣100分。基本年底5个月工资晋升无望。估计是这个码农临时想到一个解决方案紧急发布来降低故障分。

拜托，都知道是原来是多少台了，直接重建hbase写进去一个初始值不就完了吗？

这个紧急方案都能让外行看笑话了

作者: axb 时间: 2014-10-13 02:41

引用:

原帖由 coin1860 于 2014-10-12 22:37 发表
基本能说通，实际预定记录当然存在，但是每次刷页面及时统计数据库服务器分分钟就挂了。所以需要nosql的缓存服务器存储动态数据。而天猫的动态数据是存在hbase上的。丢的是缓存服务器上的数据。
阿里码农一个季度30 ...

hbase什么时候能当缓存使了？我代码写的少，你不要骗我。
退一万步就算是前端要修这问题也用不着改线上js吧。。。

作者: axb 时间: 2014-10-13 02:46

引用:

原帖由 Crusher 于 2014-10-12 23:51 发表
posted by wap, platform: iPhone
hbase集群要丢失数据太难了，
连我们的缓存服务器都有二十几个节点，我不信天猫的会比我少

退一万步，缓存真的在全部节点丢了，重建也要不了多久

总得说来，就是玩猫腻被人揭 ...

代码有个bug，incr变成del，数据不就丢了？跟集群大小有啥关系？

作者: 莫斯利安 时间: 2014-10-13 05:23

引用:

原帖由 Crusher 于 2014-10-12 23:51 发表
posted by wap, platform: iPhone
hbase集群要丢失数据太难了，
连我们的缓存服务器都有二十几个节点，我不信天猫的会比我少

退一万步，缓存真的在全部节点丢了，重建也要不了多久

总得说来，就是玩猫腻被人揭 ...

作者: trashman 时间: 2014-10-13 06:35

posted by wap, platform: iPhone
尼玛，这逗逼解释是把我们当傻逼了吗。不要碧莲。

作者: yy915cn 时间: 2014-10-13 08:02

posted by wap, platform: Android

引用:

原帖由 @trashman 于 2014-10-13 06:35 发表
尼玛，这逗逼解释是把我们当傻逼了吗。不要碧莲。

别说，还真信的

作者: 莫言 时间: 2014-10-13 08:11

posted by wap, platform: Chrome

引用:

原帖由 @雾桑于 2014-10-12 22:07 发表
锤子真tmd太牛逼了，才5W多台的销量的小企业，就能让创造IPO纪录的企业主动来背黑锅

创造IPO记录的企业还篡改客户前段数据呢。有什么奇怪。傻得要死。

作者: 测试一下 时间: 2014-10-13 08:47

posted by wap, platform: iPhone
19楼24楼35楼信了...

就是不知道是不是真信...

作者: LTFYH 时间: 2014-10-13 08:55

posted by wap, platform: SONY 巨猴
就算真把缓存的删了，缓存没自动同步机制？没重建机制？这缓存机制也太sb了吧

作者: koholint 时间: 2014-10-13 09:05

posted by wap, platform: Android
说明程序员在公司属于底层背锅的，泪流满面。

作者: cpspig 时间: 2014-10-13 11:37

4G锤子变相降价，龙哥还是蛮识时务的。

作者: mechanus 时间: 2014-10-13 14:41

程序员好惨，背了黑锅不说还成了“自告奋勇”背黑锅的程序员。
另外天猫没接口给商家改数据，所以我认为这个跟锤子没关系。

作者: 乌鸦 时间: 2014-10-13 14:47

引用:

原帖由 pocketmom 于 2014-10-12 21:43 发表
posted by wap, platform: Chrome
这个申明，还真以为锤粉都是SB了？

不傻逼会买锤子？

作者: majian1 时间: 2014-10-13 21:05

posted by wap, platform: HTC Butterfly S 919D
上wall streat journel新闻了，锤子太牛逼了，马云不投钱，老罗很生气，后果很严重……233

作者: 离神最近的人 时间: 2014-10-13 22:00

posted by wap, platform: iPhone
刚想发帖说这个，知乎上连前端代码都被翻出来了，丫直接乘3，简单粗暴，笑喷
http://www.zhihu.com/question/25951778/answer/31695535

本帖最后由离神最近的人于 2014-10-13 22:00 通过手机版编辑

作者: 离神最近的人 时间: 2014-10-13 22:13

posted by wap, platform: iPhone
阿里的前端程序员已经在知乎上开喷了，目测是运营造假，程序员背黑锅

作者: zhang777 时间: 2014-10-13 22:26

posted by wap, platform: Chrome

引用:

原帖由 @coin1860 于 2014-10-12 22:37 发表
基本能说通，实际预定记录当然存在，但是每次刷页面及时统计数据库服务器分分钟就挂了。所以需要nosql的缓存服务器存储动态数据。而天猫的动态数据是存在hbase上的。丢的是缓存服务器上的数据。
阿里码农一个季度30分故障分。这种故障算B类，故障时长维持一个小时要扣100分。基本年底5个月工资晋升无望。估计是这个码农临时想到一个解决方案紧急发布来降低故障分。

看似有道理，但这种故障出来要牵扯到的显然不是某一个码农，而是大到一个team几十个码农以及经理那种级别。因为按你说的出问题的是缓存数据库，但改动的是前台JS，涉及到两个责任方，完全可以互相扯皮（实际操作中上也是这么做的），没理由负责前台的码农给缓存服务器的码农擦屁股。所以解释为个人行为说不通

作者: 阿喀牛斯 时间: 2014-10-13 22:36

引用:

原帖由 zhang777 于 2014-10-13 22:26 发表
posted by wap, platform: Chrome
看似有道理，但这种故障出来要牵扯到的显然不是某一个码农，而是大到一个team几十个码农以及经理那种级别。因为按你说的出问题的是缓存数据库，但改动的是前台JS，涉及到两个责任方 ...

哪里有道理了，紧急解决方案，再怎么着也是用JS把预订数+60000 来解决吧，预订数*3至少要在出事故以后再来30000个订单才会与后台持平，这么没有时效性的方案也能说紧急弥补？

作者: coin1860 时间: 2014-10-14 00:00

. . . .

[ 本帖最后由 coin1860 于 2014-10-14 00:07 编辑 ]

作者: 离神最近的人 时间: 2014-10-14 00:07

匿名用户
马兴佳、skaic、李康等人赞同
阿里前端，匿了。
这个事情，程序员绝对是背黑锅，我们来看看最有可能是谁乘的这个 3：

阿里内部使用一种叫做 TMS （淘宝模版管理系统）的技术。（在阿里做过的肯定都知道）
这个技术大概就是：

前端事先写好一堆通用的模版，这些模版提供了很多的配置参数，然后运营就可以在后台通过我们的工具（类似 Lofter 的那种让用户自主选择模块，上传图片，编辑文字的 Blog 工具）完全自主得编辑页面，配置参数，上线活动页面。

再说一遍：运营不但有权利修改数据，还可以完全自主得上线页面。
（嗯，阿里的运营就是有这么大权限）

所以你也知道了，这个数据根本不需要也没有机会经过前端，去乘那个愚蠢的 3。

这也说明了为什么修正问题后，代码还是
.innerHTML = (_self.data.bespeakNum)*1)
因为运营将参数改成了 1 。

包括那个神奇的 0.5 、 NaN （NaN = Not a Number）
鬼知道傻逼运营输了什么奇怪的东西进去！

但是。至于是阿里自己的外包运营，还是开放给了厂家或者其他什么的运营，暂时还不能确定。
（来自阿里内部论坛）

再上几张阿里内部论坛的截图：

PS : 阿里内部论坛的背景实际上是有水印（姓名＋花名＋工号）来防止截图泄密的……但是这对前端来说根本不是事儿。你懂。

PPS： @黄江舟同学居然还未正式离职……你在内网要火。

上面的就不要再吐槽程序员了。

以上。

利益相关：阿里前端工程师

作者: 离神最近的人 时间: 2014-10-14 00:09

喷了，LS为啥瞬间编辑掉...

作者: VEVAN 时间: 2014-10-14 00:13

posted by wap, platform: GOOGLE Nexus 4
简单来说呢，程序or数据库那边出了个大事故，然后有个NB的前端（特指脑洞，技术就不说了，你直接+65535么，就算要x3，tm随机+0～2都不会么…），自告奋勇跑去大无畏顶缸，这TM就是圣人啊。
至于前端调用数据会清零+全淘宝就丢你一条数据+缓存不更新+无法手动强制更新缓存+无法人工改写数据，所有这些事件必须同时发生的概率…

啧啧…

作者: limboking 时间: 2014-10-14 00:45

问题是改了之后还是*1 妥妥打脸嘛

作者: cpspig 时间: 2014-10-14 08:03

龙哥还没在微博回应呢，能否和马云约战优酷呢，拭目以待。

下战书了，马云会如何反应呢。:D

欢迎光临 TGFC Lifestyle (http://bbs.tgfcer.com/)