凤凰网CEO刘爽2013年会致辞:拥抱生活,顺势而为

大时代VS 小时代———当理想撞上现实

前面我讲了今年的业务情况,最后我想和大家分享些想法。前阵子一部非常火爆的电影《小时代》,我试图看下去,但没有成功,这部电影唯一牛的是名字,非常犀利,一语道破我们这个时代的主旋律。很不好意思跟大家说,我来自大时代,准确的说,来自大时代的尾巴,70年代末到80年代末承载着我的青春期,这十年,百家争鸣,巨星闪耀。这个时代的特点是物质极度匮乏,但精神世界极其丰富,什么思想都可以讨论,人们对国家的未来有无限憧憬和设想。在那个时代,时髦的是兄弟们通宵辩论三权分立和新权威主义,上下铺吐沫横飞,现在你要跟谁谈这些,别人可能以为你有病。在那个时代,我们骑着自行车十几里地进城,顶着四五级风沙,从黄牛手里买柴可夫斯基音乐会票。但现在,我们的年轻人可能更爱把玩王力宏和李云迪之间的友谊,关心汪峰老师什么时候能上头条。那个时代,同学们人手一台短波收音机,美国之音是我们和外界的联系,现在连翻墙都不用了,微博微信上的内容比哪里都火爆。

商业机会VS 媒体梦想——— 让生意拥抱生活

时代真的不同了,我们现在处在一个物质消费的时代,这个时代的主旋律是创富、致富、是娱乐、享乐,极端的甚至是炫富、奢靡。看看我们周围那些大市值的互联网公司,看看那些取得巨大商业成功的互联网公司,你会发现他们都有一个共同的特点,就是把握了时代的脉搏。先看淘宝,无数的小屌丝小白领在淘宝开店当小老板,梦想有朝一日升级为小土豪,那些成为小土豪的人,可能面临空虚无聊,于是他们来到YY(欢聚时代社交视频公司),在YY上用他们从淘宝赚的钱,给心仪的小清新小卖萌点歌送玫瑰。当然还有很多小屌丝,即使屌爆天,也许也成不了小老板,更别说小土豪了,但没关系,还有腾讯,他们可以来腾讯打飞机,这还是免费的,这就是这个时代的主旋律,在这个旋律的伴奏下,无数个上市公司,拥有百亿千亿美金的市值,在这样的小时代,你跟小白领小清新小土豪,谈大理想大抱负大情怀,可能真的会笑场了。作为一个媒体人,我们要意识到这样的变化,我们要问自己,这个时代的主旋律是什么?大需求在哪里?围绕这些大需求,商业潜力和商业机会在哪里?并放下媒体人的清高,倾力让我们的生意去拥抱生活,否则就有被边缘化的危险,被这个小时代抛弃。这就是为什么,我们凤凰网立足在这个小时代,除了要建立媒体信息发布平台,还必须打造生活消费娱乐的双平台,必须做大游戏业务,做大房产、汽车、娱乐、财经、时尚的根本原因。

既然是追求物欲的小时代,是不是我们媒体人,都将没有作为?非也,仓禀实而知礼仪,当人们的物质满足到一定程度之后,对精神,对高端品质内容的需求,一定会高扬,这是一个普遍规律,看看发达国家的经历,就印证了这点。我们也可以看看这些年优质电影电视的票房,看看我们自己的凤凰读书会,我们上上周在清华大学举办的读书会,邀请了15位重量嘉宾演讲,三四百位听众,场场爆满,挤的水泄不通,不用怀疑这个市场对优质内容的需求依然强劲。

现实骨感VS 理想丰满——— 找准sweet spot

既然是小时代,是不是我们媒体人,可以放弃使命和理想?让我们先问问自己,我们能持续偷安在这个繁荣的小时代吗?如果社会的公平正义得不到伸张,个体尊严得不到保障,社会矛盾任由激化,我想小时代也许顷刻之间,会变成风云突变,激荡甚至动荡的大时代,那是任何人都不愿看到的。所以即使在小时代,作为媒体,我们维护社会公正推动社会进步的使命依然沉重。我们捍卫老百姓的话语权和知情权,来提高我们影响力公信力的使命依然神圣,我们必须心怀媒体理想。

我想给大家看两张照片,一张是上海中共一大的会址,一张是灯红酒绿的上海新天地。大家有的可能不知道,中共一大会址是包围在新天地里的,每次我去新天地,站在中共一大会址门口,看着街上红男绿女,看着小白领小资们沉醉甚至疯狂的脸,总是感慨万千,90年前,那些志士仁人抛头颅洒热血,在这里设计新中国未来的时候,他们的新中国是什么?他们的新中国,跟我们现在看到的新天地有什么差异?沧桑巨变是毫无疑问的,街上没有巡捕了,再没有“华人与狗不许入内”的牌子,吴淞口日本的坚枪利炮再不会不断的攻击我们了,中国人站起来了,不再受列强的欺辱,新天地卖的雪糕汽水,也不再是只有旧上海的达官贵人才能享受了,人民生活得到极大的提高。

但无论时代怎么变化,有一点是永远不会变的,就是大家对美好生活的向往,对公平正义尊严的追求。从百年沧桑看,中国的进步必将漫长而崎岖,急躁冒进必于事无补。有一句俏皮话“理想很丰满,现实很骨感”,正是因为理想和现实的反差,我们必须非常谨慎,我们可以有理想,但不能理想化,作为媒体人,也作为商人,我们应该在理想和现实之间找到一个甜点,注意这个甜点,是sweet spot,不是蛋糕不是甜品,是高尔夫球的中心点。打高尔夫人都知道,只有击中甜点,球才能笔直飞的很远。我过去也打高尔夫,但常常是使了很大劲一杆挥出,球纹丝不动待在tee上,静静看着在风中摇晃的我,有时候虽然打到了球,但因为没有碰到甜点,球飞到了别的球道,那感觉很沮丧,所以在理想和现实之间,我总结了十六个字与大家共勉,前八个字是“心怀理想,举重若轻。”说的是纵有理想,也不能发力过猛,要用巧劲,否则不仅扭着腰,也无法致远,下面八个字是“拥抱生活,顺势而为”,提醒我们要站在潮头,要顺应时代的主诉求。不是有这么一句话吗?台风来了,站在风口,连猪都飞的起来,何况我们是凤凰,是一鸣惊人一飞冲天的凤凰。

分享寄语

最后我想跟大家分享一段讲话,这段讲话深深触动了我。他的演讲者,在十来岁时候,家里受到迫害,从天堂掉进了地狱,他的青春期在黄土高坡度过,经过七次申请才最终入党,他从基层河北正定一步一步做起,从厦门、宁德、浙江、上海一路走来,我想大家应该猜到了,他就是两星期前,在庆丰包子铺,点了二两猪肉大葱馅包子一碗炒肝的,我们的国家领导,也是我们敬爱的一个长者,他的新年致辞,没有套话,真挚朴实,充满哲理,震动了中国,感动了中国,我们为此做了一个专题《习近平的新年贺词为何令民众动容?》,下面让我们一起来看这段视频;

“生活总是充满希望的,成功总是属于积极进取、不懈追求的人们。我们在前进的道路上,还会遇到各种风险和挑战。让老百姓过上更加幸福的生活,还有大量工作要做。我们要谦虚谨慎、艰苦奋斗,共同谱写伟大祖国发展的时代新篇章。”(习近平总书记新年致辞结尾部分)

我想这是一个历经磨难,风雨行过的一位领导,也是一位长者,发自内心的话,让我们一起用心体会,在未来的日子里,一起携手奋斗,为自己的梦,也为中国梦,谢谢大家。

反思汽车业的互联网化

http://it.sohu.com/20131126/n390835462.shtml

最近在研究特斯拉,因为很多消息和故事串在一起,引起了我的兴趣。最终也归结到一点:我们如何看待特斯拉的互联网思维,以及我们如何学习特斯拉。

这是一个特别大的话题。让我们先从小的噱头开始,今年8月份,比亚迪总裁王传福这样说“家庭消费一旦启动,比亚迪分分钟能造出特斯拉”。我似乎不怀疑比亚迪在电池和电动车技术和制造能力方面的积累,但即使它能够造出外观完全一模一样的跑车,还能一并复制特斯拉的内涵与极致体验么?

此后,接力棒交给了吉利董事长李书福,他说,特斯拉如果能够取得成功,吉利分分钟就能造出类似产品。不过,他提到了传统汽车产业完全有可能会被信息技术打败,并说:

这一天什么时候会到来,时间节点很难判断。各种新技术新材料的应用,完全有可能改变整个汽车的结构和形态。现在能看到的就是,一部计算机和一堆电池构成一部汽车,这个时代很快就要到来。

实际上,我看到的只是一种“工具论”,即我将一堆堆的智能系统或零件塞到汽车里面,就变身成了新一代的互联网汽车。这种“工具论”在其他行业的传统企业管理者中不在少数,却极少去研究和承认类似特斯拉汽车等新势力背后的互联网思维。

特斯拉有两大核心竞争力,一是在传统电池技术方面的重大革新,二就是互联网思维模式。前者也许可学,后者恰恰容易画虎不成反类犬。

我的同事兼好友刘晓芳为了研究特斯拉与其创始人Musk,查阅了大量的资料,采访了特斯拉ModelS的几位中国试车者,有了这样的慨叹:

关键在于,特斯拉是一家没有任何包袱的小企业,它根本不是为了做汽车而做汽车,而是为了用一种全新的方式去控制和驾驶去做汽车,它一切的研发体系,生产,供应链也都是在这上面生长出来的,完全就是一种汽车业的“逆生长”。

她采访的易到用车网创始人周航说,“不是你在车上加一个互联网装置,它就是互联网汽车了”。所以,简单的学习和复制,只不过按葫芦画瓢,学不到它的“灵魂”。

其实,在中国可以找到一个更接近或者更能理解Musk的人,那就是小米创始人雷军。有趣的是,他今年前后两次前往美国,每一次都去拜访了Musk,在后来他撰写的“Musk是个酷同学”一文中,我们多少看到了真正带有互联网思维的解读:

比如雷军说,从智能程度看,Tesla跟其他汽车的设计思维和功能服务实现水平对比,是移动互联网应用与单机本地运算的代差表现。

再看看特斯拉跑车与小米类似的地方,比如参与感、电商、口碑圈子营销等

他把互联网的参与感啊,口碑营销啊,这一整套全整上去了。他让你觉得你有一辆Tesla就是时尚,很酷。而且Tesla也是在互联网上预订,网上直销,排队,把所有中间渠道去掉,不靠广告,靠最早的用户使用后的良好体验进行口碑营销,反正他的目标客户相对圈子比较集中,这类对科技感有尝试热情的新贵们总是在他们自己的圈子里交流。有一个人买了Tesla,这会成为一个圈子的时尚话题;当有很多人都买了Tesla时,这又成了圈子里的标准配置。

所以在那个圈子里,以后汽车就只剩下了两种:一种是Tesla,另一种是其它。而当种子核心用户圈内普及之后,它又能产生新的辐射势能,影响、吸引更多的用户。

我印象最深的恰恰是一个很简短的对话。雷军问:大家都特担心你的车死机了怎么办?Musk说,死机了不要紧,重启就好。

是不是有点很熟悉的感觉?是的,一种纯粹互联网思维下的条件反射。

接下来,我又看到了上汽MG5Geek版的宣传海报,主打“极客”概念,将其乔布斯、扎克伯格、拉里佩奇、杰克多西(Twitter创始人)列为要学习的偶像,尤其是它将Musk作为了致敬的对象,并尊封他为“汽车界最热的极客”。

这是一种有趣的态度转变,汽车商们由看不起、看不懂到真正开始用心反思、研究,并推出一款专门主打极客精神与智能用车体验的车型。

我也查阅了一些相关资料,发现一些趋势转变正在发生。比如,为了宣传即将到来的新款极客汽车,@上汽集团MG做了一些有趣的微博新营销尝试,以倒数计时的设计,向“极客”致敬,不断制造可延续性的话题与紧张的期待感,这一种社交化口碑传播的尝试。

另外一个亮点在于,MG5Geek版会推出个性化的电商平台,并且只通过网络定制销售。官方说法是在3~5分钟内,用户通过选择模块既可以打造一辆属于自己的Geek车,支付定金后,还能够全程跟踪汽车制造与发货等流程。

类似这种个性化C2B模式,此前在欧美高端车中已经较为流行,此前大众曾推出一个“大众造车”项目,但与后端制造流程无关。

此外,MG5Geek版还搭载了上汽inkaNet3.0车载系统,该系统已经具有大数据运算、云服务、人工智能等移动互联网时代车载服务的雏形。

最后,还是需要做一个总结,什么才是汽车业应该有的互联网思维模式?

一、“搭班子”要混血。请看特斯拉的高管构成:Musk本人是发明家、企业家、亿万富翁、慈善家、空间的先驱、工业巨头以及钢铁侠原型的极客集合体,互联网基因浓厚;DougField,苹果Mac硬件工程的前副总裁,代表作为最新版本的MacBookAir,MacBookPro和iMac;GeorgeBlankenship,前苹果及GAP执行官,担任零售店开发与设计副总裁;CTO兼联合创始人JBStraubel,来自航天领域;彼得·卡尔松,特斯拉供应链副总裁,曾在恩智浦半导体担任首席采购官。(不完全统计,还有一位来自丰田的高管,我没有搜到)

二、纯硬件将死,产品要“铁人三项”。纯硬件制造的时代正在式微,未来一定是软硬融合加服务的汽车时代。特斯拉的例子较为极端,其堪称是“完全互联网化的智能体验”,操控中枢借助智能终端屏幕来担当,其版本是定期更新的,不断迭代。

三、营销需借助名人效应、口碑传播与社交化网络,也就是说产品须自带媒体属性。我看到的一个说法是,特斯拉在传统媒体上的广告投入是0。由于初期用户都是发烧友、富豪或名人,他们的体验与自传播就是最好的营销病毒载体。

四、改造甚至颠覆传统渠道模式,即“电商预售与定制O2O一体化”。特斯拉是从零起步,因为没有传统汽车商在经销渠道方面的历史累赘,依靠“体验店O2O电商预售与定制”的模式,实现最大范围的直销网络铺设。由此带来的启示跟所有的正在被电商化的行业是一样的,扁平化渠道,产品趋于反传统大工业思维的个性化定制制造,强调O2O一体化。

先写到这里,文章有些长了,希望对你们理解互联网思维有所帮助,也欢迎各种吐槽批评。

马化腾三小时讲话实录:千亿美金这个线,其实很恐怖

http://www.huxiu.com/article/23155/1.html

邀请我来这里是很好的机会,能跟各位企业家聊一聊,其实也不是什么演讲,最主要是希望能够跟大家互动交流,提出很多的疑问想向各位企业家请教。
当然回到最近的一些话题其实挺热的,包括三马同槽,现场也是有点火爆,主要是郭广昌,刚开始说不讲敏感话题,后来也讲了,所以很精彩,像平安传统金融,和纯互联网,有很多激烈碰撞。所以今天也想借这个机会把腾讯和我的观察和体会跟大家分享一下。
如果没有微信,我们现在根本就挡不住
很多人说腾讯是最早拿到移动互联网门票的公司,指的就是微信,很多朋友都用了。微信的确是唯一一个在手机上开始做的,并且是以手机为主的,这在以前是不多见的。以前一般都是在传统互联网上做好,换掉屏幕,转到手机上,所以这个路径跟之前完全不一样。但为什么反而特别有魅力呢?因为这个产品让我们看到很多独特的体验。它充分利用手机和PC的区别,就是把人们用计算机的终端变成人随身的一个器官,以前用PC还不能称之为器官,离开电脑,站起来就脱离了,只有手机第一次跟着人体一起,连在一起,所以内置的摄像头、传感器、麦克风都可以成为人们在网络世界里面的眼、鼻、口、耳,甚至你的触觉跟颜色,都可以通过互联网把你的朋友连在一起。即使我们有手机QQ,但因为它有一半用户在PC上,一半用户在手机上,只有微信是完全基于手机来开发的。
你也看到微信其实没有在线、离线的概念,以前我们做产品,肯定要有在线、离线头像可以看,为什么呢?要简化它,因为一定是在线的,不可以离线的。但里面又考虑了很多细微的区别,比如说隐私的问题,以前这个消息送达之后,你收到了还是阅读了,对方是否看到,这个功能我们可以做出来,但我们希望人们在便捷的时候,又保持一份隐私。你们肯定有感受,很多人建议说我发了这个消息过去,他有没有看到,希望我能知道,那是发的人爽,但是接受的人不一定很爽,他不希望说,他希望这个东西还保持一个隐秘,不希望太透明,这里面其实是很复杂的,不单是一个技术或者是一个软件的水平,很多是要靠对人性的把握。
从这个产品案例,我们可以看得出,即使是像QQ已经有每个月超过六亿多的活跃用户,两三年前已经达到这个水平了,但是在这个领域里面依然有创新或甚至差点被颠覆的可能性。坦白讲,微信这个产品出来,如果说不在腾讯,不是自己打自己的话,是在另外一个公司,我们可能现在根本就挡不住。回过头来看,生死关头其实就是一两个月,那时候我们几个核心的高管天天泡在上面,说这个怎么改,那个怎么改,在产品里调整。所以也再一次说明,互联网时代、移动互联网时代,一个企业看似好像牢不可破,其实都有大的危机,稍微把握不住这个趋势的话,其实就非常危险的,之前积累的东西就可能灰飞烟灭了,一旦过了那个坎儿就势不可当了,这是一个感受。
移动互联网不只是延伸,而是颠覆
我们再看移动互联网,有些人说移动互联网就是加了“移动”两个字,互联网十几年了,它应该是个延伸。我的感受是远远不只是一个延伸,甚至是一个颠覆。看过去的PC互联网都已经不算太互联网了,移动互联网才是真正的一个互联网,甚至以后每个设备都能够连上网络之后,人和设备之间、设备和设备之间的通信全部连接在一块,一切都连起来之后。这个还有更多的想象空间,现在还没到这个程度,还在慢慢摸索。
我们再来看我们的使用时间,以我们的过去统计来看,大概每个人平均用PC互联网是2.8个小时/天,现在移动互联网,怎么用呢?除了睡觉8个小时,16个小时是清醒的,跟它在一块,不太容易丢开它,未必是每分钟、每秒钟在看,但是有消息到达,就会使用它,这样的话就是16个小时,再加上设备本身,比PC多出十倍以上的使用时间。这里的空间我觉得是无比巨大的。从去年7月份,PC的服务已经开始低于手机上服务的时候,不管是原有的QQ,门户网站、微博、搜索引擎,包括360,这一年来已经十倍的增长了,这一年已经开始超越,甚至是70%多的流量是来自移动互联网终端,但来自移动互联网终端的收入,全行业看应该不超过10%-20%,它的商业模式还不清晰,但是时长多了十倍。
可以说半年前我还是比较悲观的,我在很多场合也说,这个叫好不叫座,增量不增收。比如说搜索引擎转到手机上,排满了广告位置,没法排在右边,就那么一列。或者是游戏,在微信的游戏出来之前,传统的手游其实大家也不觉得怎么样,这个市场没有人用手机玩游戏玩太长时间,付费欲望估计也不高,因为体验也不是太好,而且用大屏幕电脑玩游戏比较爽。还有包括其他,比如说打广告,手机流量这么贵,还加一个广告,一个大大的图,一个视频。不可想象,在PC互联网这些都是成熟的模式,但在手机上不敢这么做,把他们的流量转到手机上,白白降低了收入,这是很恐怖的事情。
Google、Facebook也一样会面临这个问题,直到最近这半年看到Google和Facebook股价创新高,包括Facebook也是最近这一两个月才创新高,一下子从25块到50块,主要的问题就是大家终于看到他们在无线上的收入模式开始显现,Google来自无线的收入增长加速,Facebook好像40%的收入开始来自于手机。原来他没有想商业化,Facebook上怎么加广告?原来不敢做,没敢想手机上能商业化,现在做了发现体验还不错,因为这里面还得做很多研究,怎么加了让人不反感,这个数据出来之后股价开始上涨,从PE上给了很高溢价。
即使我在这个行业,我都有时候看走眼,因为我记得Facebook最初上市的时候,通过私人银行还拿了一些股票,熬啊熬啊到最后还往下掉,都快跌穿当时拿的那个价钱了,后来终于上来一点之后,熬不住了,就出手卖掉了,25块就卖掉了。当时我都觉得很难的,怎么商业化?他确实厉害,美国互联网尖端企业商业化了,后面的金融广告、社交广告的水平还是全球第一流的,他还真的做到了,当然他也得益于各种各样APP需要大量广告的这种需求。有时候我们身处其中,甚至可能外界的投资者也搞不太清楚,他只是看到一个大趋势,我们有时候还更加担心自己,觉得还挺悲观的,这个也很有意思。
腾讯股价为什么炒的这么高?
我们压力很大,因为我们也莫名其妙,把股价哄抬那么高,其实我们压力很大。这个怎么能玩,所以社会不要给我们那么大的压力,还是未来长远的看,我觉得投资人理解就理解,不理解的就亏损了,股价高低都不是我们太关注的。
腾讯的股价为什么炒的这么高?一是我们感觉资本市场给我们的期望很高,很多是因为微信突出来了,有门票了。微信出来之后,就两个月前,游戏出来了,很多从来不玩游戏的人痴迷于里面。第二个是因为泄露了那篇文章“千亿美金下的反思”,外面人说看了很震动,我当时觉得很奇怪,为什么这么激进?大家的期望是寄托未来,说移动互联网肯定很有前途,现在挣钱不多不要紧,关键是把这个事列出战略,以后肯定是有办法挣钱的,所以有很多的投资者是这样的一个期望,把股价炒的很高,PE也很高,所以我们压力也很大。但是我们也知道这是一个长期投入,因为很多的收入商业化未必那么快,但趋势是看到的,这么多人用手机、用互联网的服务,这个东西不可能坏到哪里去。所以说,抱着一种长远的发展思路,让现在该投资的还投资,中短期的利润多点少点都不要紧,都是阶段性的问题,目前全行业都更加重视移动互联网。所以我们的文章泄露出去之后,不仅是阿里了,很多互联网公司都说要移动为先,一切都以移动来发展,都把这个作为下一阶段极其重要的竞争要领来看待。
为什么移动互联网的魅力远远不止这些?因为有了移动互联网,才第一次发现互联网其实跟很多传统行业的结合更紧密了,因为它是随身带着,跟随着使用者,很多东西是可以跟传统行业结合更加紧密的。互联网颠覆了很多行业,大家都可以数一数,像音乐,游戏其实也算颠覆了,包括索尼PS,现在可能只有微软游戏机xbox大家还在用,其他的那些都已经没有人打了。媒体更不用说了,电子书、网上看资料,有微博、微信,很多媒体都占去了大家阅读的时间。还有很多行业,包括电子商务颠覆了零售行业,包括最近很火的互联网金融也开始,最近几个月突然炒起来,炒的非常火热。大家是不是觉得互联网怎么那么神奇?以前觉得还是新经济、虚拟经济,反正不是主流,现在就变成好像主流化了。我的态度是比较辩证了,我会觉得这个不是那么神秘的,它不是说,那是你们那个行业,这是我们的行业,其实中间是有很多的连通性。
 
改良肯定不行了,一定要有颠覆
前几天三马论坛,我去讲了一个观点,这是第三次工业革命的一部分,打比方就像有了电力,以前是蒸汽机,后来有了电力对所有行业都发生了变化,都发生了影响一样。有了互联网,每个行业都可以把它变成为工具,都可以升级服务。当然有了互联网,玩法是不一样了,会有点不一样了,每个行业,就算是金融业没有电之前,以前还有银号,还可以记记账,有银票,也能做,包括股票那时候也没电,也能炒炒,叫叫价钱,也能买卖,有了电之后电子化,一样是升级换代。但是有了互联网之后,我相信每个行业都会有升级换代的这种变化,有人称之为改良,我觉得改良肯定不行了,一定要有颠覆。我是比较客观,为什么一定要颠覆呢?因为只要在这个行业内用互联网的方式做,我会称之为颠覆,你在这个行业扎得很深。就算是电子商务,我们现在看到很多垂直的,比如京东做3C产品,唯品会做服饰,毛利很高的包括有人专门卖钻石的,看似它是互联网公司,实际上还是传统行业,只是用互联网的方式去实现,一定也要在这个行业扎得很深,得知道你的供应链、货源在哪里,怎么做,服务怎么样,是不是很专业。包括很多以前不起眼的,比如搜房网,不知不觉市值已经跟三大门户不差了,和新浪差不多了,以前觉得搜房网好像很小,但搜房几千人在不同的城市扎得很细。还有最近上市的几个企业,比如58同城,包括还没有上市的,比如美团,团购网站几千人,看着不像那种互联网的清新,其实都要扎得很深,只不过用互联网的方式去做,本质上剥掉互联网的壳,还是传统行业,看到这些都是“又是颠覆、又是改良”的一种结果。
再看制造业,国内冒出的小米,做手机还能做成这样,它就是用互联网的方式来做的。因为雷军对互联网很熟悉,所以看到他很多的软件、硬件加服务,加粉丝经营,加用户高度介入生产过程,在微博上搞活动,很多人觉得传统手机商不就在微博发几句话吗?是忽悠吗?以为很简单,实际上背后很多是用互联网的思想来做,甚至说硬件不挣钱,靠服务,靠产生的用户群,因为网络硬件是跟用户连在一块的,不是卖完就丢掉用户,不是一个简单的客服,他是卖完之后生意才刚开始。所以很多的产品和服务,其实可以用互联网的思想去做的,最近好多案例都是用一种我们看似是有一些互联网精神的方式,请粉丝内测,测一测这种好不好用,其实这是口碑、高端用户才能试的,慢慢慢慢形成在网上开始传开了。包括现在美国很火的汽车特斯拉,电动互联网化的智能汽车,也是一样的,一看也是口碑经营,少数的高端精英用户才可以用,然后很酷,这个电动汽车深圳比亚迪不都也有吗?但是思路又不一样,先做跑车,很互联网化,里面全智能的,全部联上网,你做什么事情,车要不要维修,全部通过智能手机可以感应到,包括很多各地充电的桩都是用服务的形式去做,在网上形成口碑。这些都是很有互联网思想的方式去跟传统行业结合,这是很好的案例。
每个企业都要给自己多一个准备
这些是我近期观察到各行各业和互联网有些结合的一些点,也是有点感受,跟大家分享一下。但是我想可能很多人问这个潮流来了,以后怎么办?都知道又该怎么变,但是好像做不到,因为有时候会跟自己既得利益,或者说基因或者DNA好像不适应有关系,其实坦白讲这确实是最大一个区别,可能十年以后再回头看到底能做什么,不能做什么,或者说现在应该改变什么,可能会有更清晰的认识,但现在往往是人在其中没有切肤之痛,其实很难去放弃自己的一些利益,去做改变的。我自己的感受就是说,怎么样能够给自己多一个准备,即使是比如你开一个另外的部门、另外一个分支,调一些团队,做一些可能跟现在已经拥有的业务其实是有矛盾的,不妨尝试,因为你不做的话你的对手或者是他想抢你市场的对手一定会做,还不如自己先试一下。
我们看为什么诺基亚曾经如日中天,2000亿欧元的市值,后来47亿美金卖掉了,我们看到他曾经很坚持说我一定不用安卓,我控制不住,它是别人控制的,我坚决不用,但后来衰落了。微软也是坚持说要维护我的Windows,还有Office,这是我的摇钱树,这两个是他最大的收入利润,不肯放弃,现在很被动。现在苹果刚发布新版本,里面什么的Office软件全部免费,以前还收钱。这是一招错后面步步被动,所以还是要做软硬一体化。
就像我们当时微信推出来的时候,手机QQ部门反对,虽然他也看到方向了,他甚至也有一个团队已经在做一个类似的产品,其实两个团队都在做,只是最后谁跑出来受欢迎了,谁用这个软件,最后是我们手机QQ的那个团队失败了,他做出来的不好用,微信出来了。我记得我们推出的时候,因为我们的无线业务部门做出来的东西不如广州研发中心做QQ邮箱的团队做得好,那时候运营商,我记得中国移动正在广西、云南开会,数据部立刻打电话给我们QQ无线说,这个东西谁做都可以,腾讯做就不行,因为我们有业务合作,在别的地方可能要惩罚你,不结算,是不是有什么不可以做了,这个压力很大。所以我们第一个版本是没有做通信录匹配的,当时联通说你做了那个就触红线了,不许做,好吧,不给匹配。然后出来的东西就好像一个简版的QQ,大家用着没意思,这个东西有什么区别,简版QQ,阉割版QQ,没有意思。后来开始竞争了,国内已经好几家出来了,我说不行了,给人罚,给人惩罚我们都不管了,通信录要加入,原来我们导入的是QQ好友,再加上手机通讯录,这是个很丰富的实验,大家为什么一加入之后,看到有好朋友冒出来,这是通讯录匹配的结果。第二是加语音对讲,原来没有这个功能,就看着这个增长曲线,很难看的,平的,用的用户不用了,不就是简版的QQ吗?没意思,直到加入这个以后,瞬间就上去了。这个很高科技吗?不高科技吧,十年前我们在PC上就做过这个尝试,做完之后没人用把它摘掉了,因为早年如果说有印象的话,十几年前美国有一个运营商,就是基于通信电路做的产品,但是那个时候是给酒店的门童通知,把它拿到对讲机网络里用,还没有用在我们大家日常来使用,叫做通过移动电话通信网络来实现集群调度的这种性能,以前大家就有对讲机集群,一喊就通,集群系统。

以前我们做,觉得很老的技术,反而用在移动互联网这个地方,为什么呢?以前PC上我们模拟了,那种用途太少了,因为QQ已经视频风行了,再加这个有什么意思呢?第二,你给我留了言,我不在线,再上去听你的话,中间对不起来,真的是像电话留言了,大家觉得没意思了。反而在微信里面用移动互联网、用手机结合了之后,大家发现它还比较实时,因为很快可以收到,可以回应。第二,又没有电话这种压迫感很强,你现在忙,在洗手间,在睡觉,正在会议中或者是父母和你,一个在美国出国留学,一个在这边。
这个发现出来了,它有独特的魅力在里面,同样的一种形式在不同的环境技术下它是很有特色的,而且这个也是之前传统运营商肯定做不到的,不管打电话也好,发短信也好,很多人说发短信可以群发,是群发了,但收到之后回是回给你一个人,不是回给所有的群,跟你现在群里面一讲大家是一起分享,这种感受是不同的。这种感受只有在邮件里才能体会到,大家就讨论了,这就是大家商业中都离不开的行为,其实这个原理就是微信的原理。为什么在我们广州的邮箱团队做出来的,因为它实际上就是个邮箱,它就是邮箱系统改造出来的。
又回过头来,这里面其实我们当时是做了一些伏笔,现在回头看还真的有用,是追溯到以前了。当时邮箱团队,以前大家很难通过手机处理邮件的,最好就是黑莓,我是好几年前开始用,用是香港的号,香港的运营商开通的。当然回头说现在黑莓比较悲惨,热的时候如日中天,奥巴马总统全都用这个,高端的历史,商业精英的形象。那时候我想什么时候可以把这个让老百姓可以使用,因为那时候还不是你主动去查邮件的,邮件是推到你的手中的,所以我说能不能我们把邮箱改造成一个客户端软件,基于这个来做,我们希望普及化这个移动邮件。现在这个已经不神秘了,所以这也难怪为什么黑莓这么惨,从曾经千亿美金,现在是卖又卖不掉。
1000亿美金这个线,其实很恐怖的
可以看得到在一个温室里面很舒适的情况下,这种危机是突然间就发生了,当然也给我们敲警钟,我们摸了一千亿美金这个线,其实很恐怖的,如果做得不好,真的能跌到只剩下几个点的市值,几个百分点,是分分钟可能发生的,因为前面就倒下几个,好多都那么倒下的,尸体还温着,还是很吓人的,这个也是给我们这个感受。我们当时做了这个邮箱客户端,后来我们要做一个类似像简版手机QQ的那个版本,怎么改呢?就直接拿这个,就这个团队三五个人,赶紧抽调人马做这个,后端拿邮箱改造一下,就出来了,只做手机,很快,做了两个月,一路一路这样,最后我们感觉到跟发现新大陆一样,开始也觉得不如意,这个东西应该是补充。甚至在发展过程中,还有信息安全问题,比如说用微信练法轮功,还有摇一摇、查看附近,又成为什么约泡工具了,赶紧给处理掉。当时中国移动意见很大,工信部压力很大,我就问工信部,我说如果你能出一个命令说禁止微信团体用,可以,我还有手机QQ,我不怕,你能不能把全部封掉,包括国外的那些全部封掉。我说那不就是啊,你不做别人进来做了,如果你能一声令下说会威胁运营商,这个东西一律不准做,也可以,而我手机QQ一直这么多年都在,最后大家也都明白了,这个是大势所趋,但我们花了很多很多时间,到现在有的运营商想明白了,有的运营商还想不明白。
所以说我们做很多,一路上好麻烦,都有还没有解决的问题。还没有安稳多久,现在就很多了,网易结合中国电信搞了易信,今天说是全网要免流量的,说是送流量。前两天会议我说我们当年跟旺旺竞争,当时主持人郭广昌说,你就把来往当成一个移动旺旺而已啊?我觉得这还是要跟他自己的淘宝用户、电子商务结合,他的定位用于商家和买家之间的,它很难成为一个消费体的沟通工具,这个过去PC时代已经完全沿着这样的路,15年后又再重演一次。我们回头看,为什么中国的运营商对这些业务这么敌视,一年前我们刚好还投了一个韩国的微信,我们问他你们那边怎么样,是不是也是这样,一年多了,发生一模一样的情况,最大的运营商开始使坏,在网络上让它信号断一下、网络断一下,可以做这个事情,他公开这些数据给所有老百姓,说是被干扰,没有被干扰是很好,一公开之后网民就炸锅,因为人家给你运营商交了钱,凭什么断网,你是违约了,最后类似工信部这样的部门就出来叫禁止。然后好,那我自己搞一个,几家运营商,自己搞,也搞个类似像他这样的团队,就这么失败了,没办法,反正最好是天下大乱,他可以重新划分界线,通常是最大的运营商最反对,因为既得利益。
所以看到这个东西,全世界都是一样的本能反应,一样有这个过程,要闹,甚至有可能都会搞背后小动作,媒体再炒一炒,但最终都抵挡不过潮流,该怎么样还怎么样。因为不是我们去编这个,不是我们做的话,也有国外的竞争者会做,他也一样会做这个事情,所以这是一个大势所趋。移动互联网还没有这么流行的时候,大家用的是物网,打个电话,现在用的是电脑,现在把用电脑的时间用在移动终端,用你的移动通信网络服务,其实运营商还担心什么?至少是薄利多销,或者是以后语音、短信完全免费,甚至在套餐里面随便用,其实最主要是流量数据包经营就可以了,因为谁也离不开你的数据流量,这个做得好的话每月其实并不会降价,完全是可以经营得好,当然利润率也没那么高。再说,毕竟是中国运营商应用,这还是比国外高很多。未来运营商和很多服务提供商其实还有很多合作的空间,软件硬件服务和通信服务其实可以连为一体提供一个综合体验的服务,我觉得这里面是有很多空间的,跨界的合作其实是应该多想一想,因为靠以前每一个细分的领域去做,越来越不实用。现在软件硬件加服务要一体来做,就是这个道理。
O2O和手游发展特别快
我们泄露的出去文章里,当时我们总裁提到一个说法,现在日活跃使用最多的APP除了游戏以外,的确是用QQ、微信是占头两名,第三是搜狗输入法,这个因为我们投资了,所以我们算半个,第四是Q Zone,是我们传统的QQ的空间,这个在座不用,但是年轻人很喜欢用,第五个360,按日活跃数来看排序是这样。我们为什么有点幸运占优,就是因为手机其实本身是一个偏通信的,电脑还更偏资讯、看视频,但手机是通信属性偏强,所以很幸运我们刚好做了通信,这是我们占了先机。但是看后面其实手机功能越来越强、越来越大之后,其他东西开始被占了,包括微博类,微博类虽然是算社交媒体,但它也是属于传播类的,转来转去的,是广播型传播的通信,新浪微博在手机上的活跃度,还进不了前五,但是前十以内。之后我们再看到移动支付在最近起来了,现在看到阿里是特别上心,对这个,因为看到他冲的很前,需要移动支付,当然也可能是受了微信支付的刺激,一下子定这个市场,听说是抽调了公司的好手全部扎在无线这个业务上面,要打造几个所谓的门票,所以他的支付宝钱包是比较跟进。
这个其实是一个蛮结合线上线下的,因为差不多两年前我就开始鼓吹,应该说我在业内最早讲这个二维码,扫码,这个技术已经存在了好多年,二维码,但是真正说让大家觉得很有意思的,更多是移动互联网,特别是智能手机起来之后,这个扫码率先在微信里面先火了。如果在座大家有印象的话,是火在什么地方呢?是火在我们推出公众账号之后,很多人发现公众号是有机会拥有粉丝的,赶紧去经营,当时我们设了一个必须是超过500人成为你的粉丝才可以加V,才会给你认证,大家积极了,赶紧在微博,新浪微博也有,腾讯微博也有,很多在新浪微博的高端大V,拼命传播微信的这个公众账号,帮我们做了大量广告,知道什么叫二维码、什么叫扫一扫,用微信扫,拼命做“请用微信扫一扫”,那个传播的很快。那个之后我们这种扫一扫就成为一个脑子里联想用微信的,虽然之前有一些什么扫一扫,但那个不是主流。
我当时跟业界说,PC是用一个网址,但这个可能涉及到线上基于IP网络世界跟线下世界的一个关键连接点,一扫就连起来了。一扫三秒钟你要的那个,完全无接触,很多很酷的体验,包括现在用手机,因为你一直登录着,有你的账号,在电脑上不在登录状态的,扫一下电脑,自动进入,登录完毕,都可以做到,手都不用敲,无接触式直接登录。所以这些很酷的体验都是以前没有移动互联网扫码做不出来的,我们率先做出来,这些体验有一点颠覆性和创新性。现在竞争越来越大,是移动支付。但电子购物没有那么快,因为很多人还是希望在PC上慢慢看,但是反而O2O,携程也好,包括去哪儿也好,现在几乎都已经呈40%,甚至有时候到60%的下载量,手机上,包括团购,现在大量通过手机上,为什么呢?他本身需要这种商务,或者团购去吃饭,他就在路上,不在电脑上。那次见美团的CEO王兴,就问他现在团购吃饭到进餐厅要隔多久,他说以前是比较长,现在团购都慢慢团,只有一个小时,就在他去餐厅的路上,去哪儿吃找一下就订了,一小时内就到店了,到店以后就消费,这很快,都在路上就完成了,这个演变速度比我想象中快得多,我观察到这些。手游就更不用说了,也就这两个月,大家突然间发现微信是用社交做手机游戏,是这样,一天超过2000万人,我们当时算了没有任何付费,没有试探出这个怎么付费。前不久是斗地主,一天超过2000万人斗地主,原来我们有一款老游戏,是单独的一款手机游戏,叫节奏大师,是音乐类的,我已经上线一年多了,日活跃70万,一上这东西1700万,主要就是加社交,最主要是可以跟你的朋友比。但是这些都还是属于那种轻度的尝试,因为我们看到韩国、日本,他们在这方面其实是很早就已经证明这个,我丝毫不担心,这个很容易做成的,但是往后怎么发展,特别是很深的,重度的、大型的游戏要怎么开发,用户会用,其实这个还不太清楚。
百度股价一度比较低迷,曾经到80多块钱,最近到160了。Google也是一样,它有安卓,有很多资产,还没有体现出,最近有移动业务来证明这个,股价就迅速起来。一是,搜索行为平移到手机之后,每千次搜索的变现能力会不会降太低,因为以前的数据很悲观,只有1/7,1/10,变现能力,很恐怖的,如果说这个,转过来只剩几分之一,这个变现能力多吓人,现在开始慢慢上来了。第二,在手机上大家是不是不搜索了?直接有APP不就完了吗?确实存在这个问题,因为直接点APP好过我在手机上打开浏览器搜索。我们现在看这个可能会有一半或者不到一半,但是即使一半,因为刚才讲了,使用时间多很多,薄利多销,这个盘子分母大,就算乘以1/2,可能总数还是达不到,所以也不用那么悲观。

微信站内搜索其实很难,觉得还是很难,除非是语音,问他要去哪里,问的问题,让他解答,传统的这种搜索搜资讯,如果没有标准APP的话,我觉得还是离不开浏览器的搜索,尤其是在手机上打开浏览器操作模式这样一个流程,相对不会说打开一个搜索引擎。
穿戴我们觉得最近有点火,但是我都感觉好像还打动不了我,原来我买健康的设备,我买了好多送人,结果发现我自己不能坚持去戴,虽然可以监测身体状况,生病写了几次,发现原来也就是那样,算了不戴了,好像也很难,包括智能手表这些,我都感觉有个手机也够了,智能手表没什么意思。所以我现在还有点慢慢从很兴奋冷静下来,看形势。语音搜索,我也戴过,而且你戴了之后很反感,你一个人爽,我们所有人都觉得你在监视我,我觉得不太好,我这个是比较保守。
语音搜索突然也觉得这个是好的,但是有时候会觉得未必太好,比如说一个人说我要去干嘛干嘛,好傻,人一多我都不好意思这么说,而且也不私密,宁可按几下。我是觉得按道理我应该是支持,但不知道为什么觉得,你跟他讲半天还什么什么,下次就自己输入算了。所以目前这个某些情况下可能可以用,但是我感觉离实用化还远,但是我相信一定会能解决,但是目前人工智能理解,人讲话的意图还没到这步,但我们自己内部也在研发,这一块。
所谓的颠覆,是让你之前的产品和服务受到很大的挑战
我们原来也很不适应这种,为什么搞内耗嘛,这个东西打乱,不太想这样。但是两面看,因为有时候内部竞争还真的是瞎搞,是捣乱,也没看他做出什么,就是同质化,大家水平差不多,都是你搞我一下,我搞你一下,然后你不服我不服,最后谁都不成,这种还挺多的。我们是这样想,在大的环境变的时候,你的对手或者是假设你挑战你自己,假设你不在这个公司,你有什么破绽是我可能会抄你后面,可能不是完全一样的做法,但是你会非常难受,有些优势是成了包袱,有没有这样的动作,如果有的话就会怎么样,会怎么样,别人会出什么招,想出什么办法。当然这个东西其实也不能,因为我们看到很多都是同质化,大家水平、团队水平不是很高,往往做又做不好。
我还有一个感受,所谓的颠覆,是让你之前的产品和服务受到很大的挑战,这个产品往往都是一个几乎一样的东西,看我们过去其实有很多很多失败的案例,比如搜索,我们的团队就完成照着百度,人家有什么我们有什么,他就没有想到别的路径,比如像搜狗就很聪明,他说我拼搜索拼不过你,我就拼浏览器,浏览器靠什么带?输入法,输入法带浏览器,浏览器带搜索,迂回地走,走另外的路,就比我们做得好,人家花的钱是我们1/3,最后是我们2.5倍。像我们电子商务原来团队是照淘宝做,做来做去,越做越没希望,一模一样的东西很难,包括我们微博,虽然说活跃量跟新浪微博差不多,但是始终没办法突破,最麻烦的是新浪微博也没突破。所以就发现让新浪微博绝望的不是微博,是微信,特别是加了朋友圈之后产生的,不加朋友圈还没有,大家觉得不过就是这样,加了朋友圈大家发现大量实际上阅读朋友圈的,私密社交比公开社交还有意思,很多话不喜欢公开讲,私下讲很好。但是也会在外面说,还要出去讲讲话,还在外面讲,感觉这两边比较,让我们朋友圈保持一个私密社交,可能说为什么不能转,为什么不能互相看到,我们说不要,就是保持私密,不能说又要私密,又要公开,就坚持你的定位,就是这样,肯定是不一样的东西,但是最后发现在人的时间分配上你是打得开,有些发图、发帖的量远远超过新浪微博。会发现我们无意中形成,这个东西也给我们启发,好像是应该打败一个东西,就好像打败微信的肯定不会是微信,肯定是另外更好玩的,就是它用掉了你的所有时间,所以就打败你,是这样的一种想法。
我现在反正也开窍了,以后我们就跟进,看到团队有什么想法,我们还是鼓励,没准他抓住了未来的一个机会。因为现在很多新奇的玩意儿,大家觉得我年轻,但我觉得我很老了,现在有些产品我都看不懂了,这两天讲Instagram,我投了一点点的股票,说起来很后悔,因为当时这个公司还不到一美金的时候我没投,公司只有几个人,当时我们副总裁看着说,这个公司不太靠谱吧,在一个公司就那么几个人,再一个靠近海边的一个房子,就是玻璃,外面都看得见,扔个砖头就可以把里面的电脑全拿走了,创始人也好像挺高傲的,后来他说算了,不要了,后来我们就找回,他的数据增长不错,所以我们是在他8亿美金估值的时候,进入这个节点。火在什么地方?应用数据很火爆,好几倍,12岁到18岁的女性用户开始喜欢,它的服务类似微信,但是不发消息,全部是拍个照片,发过去,只能按着才能看,如果COPY下来的话,因为你一截图的话对方知道你在截图,这个软件会感知截图,只打这个。我们当时说要投资,几个人试着玩一玩,好无聊,我们干这一行都觉得无聊。后来我们请一些投资调查一下,为什么喜欢这个,用户觉得这个东西没有压力,是消费照片,不记下来,所以他没压力,就是告诉你把一些好玩的东西给你一拍,就跟大家打个招呼,表示我存在,有存在感,这样很神奇的,但是看到这个东西层出不穷在美国,幸好是Facebook把它收购了,要不然对Facebook有很大挑战。在中国其实这个需求是给微信的朋友圈取代了,这个需求还很强,他也是通过手机通讯录加为好友之后大家就以发图为主,发图就可以Follow他,就可以看到了,有公开的,也可以私密的,是这样的。对Facebook威胁很大的,要不买下它很危险的。还有Twitter刚刚上市了。
可以看到创新层出不穷,它跟每个人做的东西都是不一样的,都是要走一个差异化的东西,说这个东西有没有吸引力不知道,也有些不成功的,还有很多看似好像一开始觉得很创新,但最后无疾而终,买的时候很贵,多少亿美金,最后也就无疾而终了。所以有时候真的,各个行业都搞不清楚到底哪一个行业,因为我们不是十几岁的小孩,不知道为什么他们喜欢,不懂。所以现在有时候要问小孩,怎么样,来做测试一下,觉得你们喜欢吗,你们的小伙伴喜欢吗,比我们还看得准。所以我想说,我们老的如果判断不出,起码要找人看,听他的意见。
移动互联网与传统行业的结合
我也没有太清晰,游戏当然最简单了,刚才讲的O2O,无线支付当然这个也比较清晰。O2O我们现在尝试用公众账号,能不能重新再发明一次会员卡,所有商家的会员卡,放到微信上,好处就是已经做了一些尝试了,效果还不错。过去每个商业都有自己的客户,但他跟客户的联系以前靠发会员卡或者是在所有的CRM,企业有他的客户群,他的客户关系管理,那能不能把他放到微信、移动互联网上来管理,你跟你的用户是可以直接沟通的、是互动的,不像短期那么单调的,是可以写程序在里面,可以交流,甚至还可以充值,我们正在比如跟星巴克谈这个合作,星巴克用微信做他的会员卡,充值、储值,储值之后就可以算账、可以消费,微信就在卡里面,在星巴克储值卡里面消费就行了。他节省了大量的发卡成本,而且是传播,成为他会员很容易。我们现在拓展B2C,比如当当接入,你买这个书的时候用微信支付可以在完全没有登录状态下匿名访问当当,可以扫这个东西,这个东西我要买,微信登录,一扫之后,然后把微信里面已经开通的银行账号,微信支付,以及我的地址已经带到微信了,直接过去就拿下,不用再输入地址,这个形式可以给所有网站,这个还是蛮创新的,这样的体验。然后他买完之后,顺带订阅了这个账号,成为当当的粉丝,这个书或者你买的商品什么时候到账,通过这个通道告诉实时通讯,这是一个闭环的体验,而且是开放式的。线下也可以有,线下的店就可以通过一扫描,就可以进来,而且现在不买不要紧,售货员可以跟你慢慢谈,如果现在知道了,加我的微信,给你的东西什么到,拍几张照片微信发给你,现在是用那种土的方法,暂时是那么做的,现在希望给他一个技术架构,让传统的零售商可以充分发挥他的店员平时的时间,其实可以通过手机,也不用搞电脑,用手机继续维护他的客户群,新货到了开始促销,或者是这个不满意,远程都可以玩,不用来店,好的话给你送货过去,或者说下次来给你留下来。用户一看到这个衣服不错,发朋友圈,朋友圈再一点,也可以一键购买,会觉得这个好像是挺有意思的,而且是可以结合传统零售行业的这些因素继续做。这么一谈很多老板挺感兴趣,太好了。
移动互联网与传统行业,我相信肯定能结合,因为怎么说呢,现在连3D打印都可以跟互联网结合,传统行业一样可以用互联网化推,这个我觉得要你们想,各行各业的导向我把握不准,甚至有时候不是跟互联网结合,但是用互联网的思想去做,刚才讲到线下餐饮,看海底捞,其实里面蛮多思想是互联网化的,是做得很极致,做的是口碑,那是可以的,这也是一种想法。
具体开放到什么程度?
这个问题很实际,因为我们在想一个问题。肯定是很开放的,但问题是说开放出来的经营者为什么是你这家,而不是另外一家,因为跟你一样的公司很多,这就涉及到你怎么选择的问题,有可能是多家一起进来。
就算是O2O我们做,我们是扒了第一层皮,第二、第三层是由你们来做,而且是非排他的,家家都可以接入,我觉得这样比较完美一点。我们内部的部门,实际上坦白讲他是希望包下的,因为我们电商的部门,说这样太好了,这个东西我要自己做,我有时候谈到说,行不行,搞了几个月都没出一个好方案出来,做的很慢,因为我们之前做微生活这个,也是搞了好久,最后出来我说这个体验肯定不行,商家热了一下之后慢慢不行,这个很难坚持很久,为什么?因为你自己一家做的速度太慢了,你还不如放开一点把它介绍给别人,让他们去,有时候他们做出来的东西简直超乎我们想象的,我们原来公众账号为一个接口,以前有了,给一些明星开,讲几句话觉得很好,有粉丝,最后慢慢也不行了,这个意义不是很大,没有意义。直到后面冒出来一个叫陈坤,觉得好酷,这个成为一个标杆应用,是全屏幕的,连论坛粉丝甚至成为他的会员,还要付费,做了全套功能,我们说可以做成这样,我们下一步的时候要接手这个,那微信部门说这个东西由他包下来了,算了,这个你自己不能做,没有这个想象力,或者你都不能拿到这个明星的授权,没办法成为官方的一个战略,凭什么去承包的,因为这些有的还要做客户端,这个做也做不好。但有时候下面部门会很坚持,说这个是我以后的未来,是我成败的关键,一定要让我先尝试,那行,我说大家定好线,你做哪一层讲清楚,不要过线,过了之后反而害了我,浪费我的经费成本,本来给我外面人做得会更好,非要移到自己手上,做又做不好,怎么办?
所以这个时候不是说我们一个态度大家就能做,其实还有细节的,因为说是开放具体到哪一层,一到十到底是2.5还是3.5,还是5,或者不同的玩法,所以我们现在还在摸索。我的思路还是希望指导他们,第一,不要太乱,因为有些人是拿到手之后就乱来了,他首要的目的就是粉丝,你们传来传去那些东西全部是有专业人士运营的,你很感动的东西都有人运营,他为什么写着让你去转,他知道怎么样打动你,讲讲家庭、讲讲教育、讲讲企业思路,最近心情不好,会有人专门去写,有什么东西最打动你,20个人你们去分头想,一天写20个,然后我们筛选哪个最好,结果就放这个出去,都会有公司来运营,后面跟所谓的营销公司、营销专家,最后多少粉丝之后可以卖的,这个东西只是钱,应该是有这些产业,所以你稍微不慎就会落入这种圈套,最后正常的用户没用上,钱已经花掉了,其实后面是几个帮派,我们最怕是这样的,一抓就死,所以有时候捏在手上不是说我们不开放,是开放了之后乱套了,外面无法无天,以前还是有刷活动,后来停掉了,真的是你有政策,他们比我们内部所有部门动作都快,连夜都赶出来了。
所以这个时候是我们摸着石头过河,现在要表态开放我没准备好,我觉得冒然开放的话大家都把这个东西搞乱了,因为所有人说要开放的时候,做完了怎么办,有没有想到有千千万万像你这样的公司都提同样的要求我怎么办?如果只优待你的话,或者头两三个,其实也是对其他人的不公平,所以我们有时候还要长远来看。我们两难,一是内部的人有时候不该他做的他抢,我们要适当解决;第二是开放出去之后,也可能有不公平,这个是挺为难的,但是我觉得慢慢摸索,一步步去做。

 

腾讯刘炽平:1000亿美金下的成绩与危机感

http://www.huxiu.com/article/21404/1.html

首先想问大家一个问题,昨天回到房间有没有冲动打飞机的?尤其是看到Pony 和Tony 巅峰对决?提醒一次,过多打飞机有害身体,尤其对眼睛不是太好,小心一点!

开个玩笑,我想说的是我们已经进入了全民移动游戏的时代!对此,我有一个比较深的感受,移动互联网有可能为我们未来带来10 倍的可能性,这个感受在过去几个月里面越来越深,尤其是看到移动游戏突然这样爆发,变成全民游戏的时代。所以,今天我希望进一步跟大家探讨一下,过去半年里到底这个行业的格局有什么变化?我们整体的执行是怎么样的?公司的战略思考是什么?
移动互联网数字洪流
首先来看互联网总人数。整个互联网人数的增长继续维持在10%左右,但是,智能机的增长是翻倍的,体量已经接近4个亿。比如,游戏这一块,过去1-2 年增长比较缓慢,今年反而增长得快一些,比较大的因素是移动游戏的快速发展。再如,整个门户的模式慢慢被颠覆,所以门户广告增长非常缓慢,甚至有些是倒退的,这是看到了移动大潮里的颠覆;还有,搜索引擎虽然增长还是挺快的,但增长率比上一个年度有所下降,现在支撑整个增长的很大程度上是RTM的增长,而不是用户量的增长,从PC 转到无线,无线上整个搜索的变现模式并没有完全成立,颠覆也在出现;另外,我们看到电子商务、在线支付,与人们生活有关的还在不断增长的态势当中,被移动颠覆的程度没那么高。
再对比我们自己的数据。第一,通讯社交这一块,在PC 侧的下降,移动侧的增长非常明显;第二,媒体这一块,腾讯网整体的阅读文章量和整个用户量在 PC侧有所下降,但移动侧在非常、非常快地增长,移动侧的UV 超过了PC 侧的UV ;第三个,微博75% 都在移动侧了;第四个,我们可以看到游戏的移动渗透额相对小一些,最主要的是PC 上端游的重度玩家与手机没有太大的对冲,我们相信对移动侧是一个增量;电商相对来说移动化的速度比较滞后,相对来说移动化没那么快反而给我们的电商有一定的机会,希望当移动化潮流爆发的时候或者我们是引领者,或者那时候整个电商体系准备好了去获取爆发的红利。
移动互联网加速变现
另外一个较大的趋势是整个移动互联网的变现模式日趋清晰,上一次开会我们还说变现有一定的挑战性,现在,我们看见变现的增长速度非常快。
整个移动互联网变现的发展速度会超乎所有人的预期,而且会不断地加速。第一个例子,游戏,KaKaoTalk 是行业典范,在韩国一个季度的流水已经接近2亿美元,占领了整个韩国手机游戏的60% 以上的市场份额,这是非常巨大的新增市场,Line 在日本的游戏收入也非常高;
第二个,广告这一块,Facebook 在短短一年之内广告收入已经有41% 来自移动侧,去年大家还是在怀疑它能否移动化的时候,但在变现侧的速度非常、非常快,昨天它的股价又了创新高,达到1227 亿美元的市值;
第三个,电商这一块,在没有物流的模式里移动化趋势非常、非常明显,比如GroupOn,Amazon 这种有物流的相对来说转化速度比较慢,但可以看到年比增长非常快,增速超过400% ;
第四个,我们可以看到很多O2O 发展速度非常快,携程这种酒店模式,现在移动渗透率是40%,6 个月之前移动渗透率还小于20%。
正因为看到这种态势,过去半年、一年当中,各大巨头非常、非常关注移动入口,所以收购大动作连连出现。阿里的战略是广撒网、先占位,阿里自己没有相似的产品,所以对于这些有可能成为移动入口的公司采取了非常激进的,少数投资先占位的态度,涉及新浪微博、高德、UC Web ;百度是很久都没有动作的巨人,它要展现狼性,对91进行了19 亿美金的天价收购,还有PPS和糯米网;360看来好像打酱油一样,但是对UC真正想吞掉,与搜狗有一个合约随时可以签,感觉在打酱油,但魄力非常大。腾讯的动作也不少,我们总体策略希望在投资并购作为整体战略的延伸,比如,可以看到对于搜索来说,我们希望通过投资和深度合作,让我们重新在搜索里达成规模,重整军容,再次上路。
我们今天在哪里
看了整个市场环境之后,让大家也看一看我们自己半年以来移动化战略的执行是什么样的?
我们把全中国20个最高DAU 的非游戏应用放在这里,看看我们占的位置。可以看到前五名最高DAU 的应用里我们占了3.5 个。为什么是3.5个?QQ 和微信是龙头;半个是新联姻的搜狗,搜狗输入法是7000万DAU 的量级,占在第三位;然后是Qzone和360 安全卫士。前十名里我们占5.5 个,还有安全管家和手机浏览器;前20 名我们占7.5个,还有资讯类的腾讯新闻和QQ 音乐。其实我们还有很多应用,微博、视频、电商有机会打入这个榜,我们能不能有更多的产品加速移动化?这是我们今后半年希望能够大力做的。
从收入来说,我们不断地加大移动投入,但移动化这一块短期给我们的收入相对来说是很少的。从收入来说我们的增长相当稳健,游戏是150亿,增长了33%,主要动力还是端游;广告这一块年增长51%以上,一个是视频,一个是广点通;社区明显受到移动的冲击,因为我们整个VIP 体系还没有真正的嫁接到移动侧,今年还是比较关注怎么样可以重塑QQ、Qzone 整体移动化的竞争力;电商这一块,自营电商快速发展,希望势头可以持续。
我们相信未来要是移动化这一块可以开始变现,我们现在也义无反顾对未来进行投入,哪怕可能利润会受损,但我们还是要做。
移动化下的新机会
展望未来,移动化会给我们带来很多新的机会,让我们一方面巩固现有的业务,另一方面让我们很多在追赶的业务有新的契机。
在平台侧,微信+QQ 把我们整个在社交和通讯的安全系数有一个很大的提升,同时让我们接触了可能有1000-2000 万高端用户,这些人可能看起来数字不是很多,但对我们未来做很多业务,尤其跟媒体、电商和商业有关的应用带来很大的未来机会。WeChat 让我们可以扬帆出海,这也是一个全新的新市场空间。
在流量平台这一块,我们在无线侧看到很多新的机会,在PC 侧是晚进入市场者,安全上非常艰苦,但是在手机侧是四六开,在流量平台这一块移动给我们新的机遇。
产业这一块:手机游戏很大程度是新机会,手机游戏未来可能是好几百亿的市场,对我们来说非常、非常重要;媒体这一侧,我们也看见了让我们一下子就接触了很多、很多以前不看我们新闻和媒体资讯的用户;投资搜索,一个是增加规模,另外一个是希望规模可以延伸到无线互联网上,让我们在移动互联网上有更好渠道之下,更好机会获取市场份额的情况之下,能跟商业化体系产生联动,这是无线互联网给我们的机会,这也是为什么能够打动搜狗跟我们合作;还有电商,能不能找到移动电商的窍门?让我们在电商领域可以乘着移动大风去破浪。
新的产业林林总总,基本上与人的生活相关,最大的服务是金融服务、O2O。来看整个世界上最大块的公司,自然资源、房地产是资源类,除了这些之外最大的服务类,一个是金融,一个是零售,一个是媒体和娱乐。基于整个互联网第一轮发展,我们在娱乐和整个媒体这一块占据了好的位置。未来互联网必定会深刻的影响其他行业,包括金融、零售服务,所以我们要思考,不断地想有什么机会。正如Pony 所说,移动互联网给我们开启一个新的创业机会,希望我们都可以用十分的精神去面对。
1000亿美金下的危机感
我们业绩不是涨得很多,但是在移动化的冲劲之下,公司股价今年涨得非常、非常厉害,9 月17日我们的市值突破1000 亿美金。我们知道很多、很多公司对此梦寐以求,但是对很多总办的兄弟来说、对公司来说,这是一个最好的时候,其实也是最坏的时候,我自己感觉到心里相当不安。
诺基亚曾经2000 亿美元的公司,一下子70 亿美金把最有价值的业务卖出去了;BlackBerry,差不多摸到1000 亿美金,900 亿美金市值的公司现在也40 多亿卖掉了……可以看到,IT 行业的变化非常、非常残酷,千亿公司没落是非常、非常正常的事情,甚至到千亿的时候没落的机会更高。
为什么呢?首先,行业非常残酷;更重要的是,一个公司大了,一个公司成功了会有自满、安逸的情绪,会内斗。以前大家都是一起创业的团队,之后开始利益分配不均就内斗了,还有官僚等问题。传统行业可能没有这么明显的感觉,我们这种新的行业里,包袱越重没落越快。所以每个人都要有非常强的危机感,外面的人给你很多掌声的时候,这时候是最危险的。
所有,我们需要居安思危,有战略思考,下面,我还和大家做三个战略分享。
对搜狗结盟的战略再思考
第一个战略分享,是Pony 刚才说的搜索业务,包括我们针对搜狗的合作,也代表了我们对做了7 年搜索业务的整体思考。
做这个收购后,我们会进一步加大对搜索的投入,而不是放手不理,未来PC 浏览器、手机浏览器,甚至其他的产品要和新搜狗这个紧密合作的伙伴有很强的互动,不是说我们退兵,而是进一步的往前走,整个打法会不太一样。
对比搜搜和搜狗,进行反思,为什么搜搜在过去那么多年没有做成?搜狗在资源相对匮乏的情况之下市场份额还是我们的2.5 倍,什么原因?第一个,领军人物非常、非常关键,有没有专注的领军人物,把所有的时间、精力砸在上面,干部能不能团结一致?大家知道我们这块的干部一波又一波,没有办法形成有人有难,大家拼死相争的状态。第二个,战略思考很关键,你是搜索后来者,渠道是非常重要的,浏览器是非常关键的路径,没有关键路径,使用很多腾讯的资源,最后来来去去还是没有办法把流量弄上去。第三个,态度,我们有一定的富二代的感觉。有一天搜狗的人打电话给我,盘点我们的服务器,我们的服务器数量是它的三倍,这些背后说明了一些问题。
我们看到“5·18”变革之后,搜搜已经有一个很大的好转,技术上的进步已经快很多了,团队状态也好了很多。但是,整个市场格局在变化,假设360不买搜狗,我们还有意愿、有能力自己做,因为PC 浏览器最近发力挺好;但是假设它买了之后,市场份额是63%、28%,继续做搜索难度就很大了。这也是为什么我们最后必然要做一个选择,要不然有机会三分天下我们出局。
坦白说,如果我们可以更早做出决定未必会是今天这样,这是总办的反思。但所有管理者管理业务的时候一样,当你看到有些不对头的时候马上要进行变革,等的话往往到最后出来的结果越来越差。
从两个登船业务看关键路径和合作机制
第二个战略分享,我们可以看见有两个业务,一个是手机游戏,一个是移动媒体,在整个大移动格局里借着微信和手机QQ 登船了。它们关键路径到底是什么?
手机游戏的关键路径很清楚,在微信和手机QQ这两个大的平台里有一个游戏中心,下载之后可以用平台进行好友排名、送心、提醒等SNS 特性带动。看起来很简单,但我们达到这个,执行花了9个月时间,因为各个平台之间要统一思想,到底谁做?做的时候怎么样?当关键路径做好,你看到整个成果非常、非常巨大,注册量非常高,DAU 非常高。比如节奏大师,这个游戏已经发布了十几个月,游戏也相当好,但是DAU不到100 万,发布这个平台之后,DAU1600 万,这是关键路径放大的作用。
第二个是腾讯网,关键路径是,开始的时候在微信里面做了一个新闻插件,现在是唯一剩下的必装插件,手机QQ 也把这个体系放进去,也是新闻插件。新闻插件每天阅读文章量是2.8 亿,新闻客户端阅读量1.5 亿,过去10 年我们做的PC Web 的成果,一年之内在无线上就超过了。
关键路径要有用户价值,如果没有用户价值,这里放一个流量,那里放一个流量,价值不大,有机式整合比无机式整合更好,很多东西非常简单,但你要找到简单的路,要把整个地图都准备好,很快速地考虑100 个可能性,90 个刷掉,10 个当中选3 个,结果很简单,但经过是非常复杂的,你自己要考虑得非常周到才可以,用机制不断地筛选,做逻辑判断才可以找到简单的路。
对此,还需要有比较好的分工机制,到底平台做什么,业务做什么?如果把平台和业务分工比较好,这个威力是可以发挥出来的。同时,我们在机制上也要给平台商业模式、分成机制,真正归平台的也可以看到自己的努力成果,这样给平台足够的激励。
平台本身的前置条件是什么?平台本身要有开放的态度,要有信任的精神,而且自己在平台里面的东西,重的东西要给业务做才行。什么东西都揽在身上,越来越重做不好。业务的前置条件是本身要有很强的专业能力,游戏10 年的累积已经是市场老大了,媒体也有10 年的累积,不是新兵上场就可以做好。同时把自己换到平台的角度,我做什么东西才让平台得益,这是相辅相成的。
开放和专业这两个相互互动,换位思考,大家彼此信任。有了这些之后是细节,在关键路径上,你有了关键路径之后我可以不断地迭代,比如,游戏这一块入口、UI、分布机制怎么做?新闻也是,放4 条、5条、3 条,一次push 一次还是两次?导语是什么?怎么拉动导语,下载成功率低的时候有什么互动?有很多,当你找到关键路径就知道怎么使力,团队就做得很high。
韩国之行的启示
第三个我想和大家进行的战略分享是,前段总办去了韩国到Kakao 和三星进行访问。
Kakao 短短几年成为韩国最有影响力的移动互联网公司,甚至是最有影响力的互联网公司,他们的产品推出一个又一个,不是说每一个都成功,但很多个都成功,包括Kakao Talk、Kakao Story。三星是另外一个极端,1938 年创立,那么长历史的公司,看到他们的几个大的战役,一波一波都花上10-20 年的时间。这个行业是日本和美国、欧洲专门的市场,它1974 年介入,一步步做,从投入最低技术含量的产品,到现在做手机的处理器,一步步成为行业领先者:电视方面,曾经觉得这是永远不可超越的大战,但三星不断地建立能力,趁着TFT-LCD技术的变革,一下子成为了行业领导者,2007 年之后开始领军;手机方面,1993 年开始做,到2013 年成为出货量最高的,做一个事业花20 年,到最后都会超越!
这两个都是非常成功的公司,非常值得借鉴,但是有很不同的对比:
Kakao Talk 是小团队的精神。450 人的公司,做的东西相当多,做事情每一次都深入洞察行业的趋势。它一开始做了好几个不同的移动App,后来发现通讯是最有效的;然后,发现通讯和社交有很好的联动,推出了Kakao Story,还变成了独立的App,他觉得这样可以互相联动,觉得只有单个应用不安全;最后做游戏,游戏用SDK 拉下载进行分成,用社交拉游戏——这些都是非常深入的思考。真正做的时候,又有非常强的执行力,做出来就算市场不成功的产品,它的界面、交互水平都比较高。另外它一个有平台,其他的甩出去给合作公司做,不是什么东西都要拿着。
三星整个专业、体系化的动力非常、非常强,那么大的公司居安思危。1993 年三星在韩国已经是一统江湖了,但创始人说走遍全世界,看到三星的产品都在角落里,非常有危机感。1993 年他就组织干部开了三天三夜的会,他讲了三天三夜,这是最出名的讲话,目的就是要改变一切,提出“除了老婆和孩子,所有东西都要改变”。麦肯锡跟他们沟通了很多,他们说三星这个企业确实非常好学,可以看到它进入新的领域后,在追赶的过程之中不是它第一个创新的,但可以快速比人家做得更好,然后超越——这个东西值得我们效仿。另外,三星的各种体系化运作,HR 体系、战略体系,它们不是用体系约束业务,而是用体系帮助业务成长。如果这种精神可以真正融汇到我们的管理里面,这对我们非常重要。
最后,我想说,15 年的腾讯依然非常年轻,如果真正能够把握移动互联网,爆发互联网的创业激情,机会可能是以前PC互联网的10倍,我们希望团队能保持激情,保持好学,让我们BE THE BEST!

马化腾内部讲话:干部要饥渴,不要做富二代

大家上午好!每半年的时候又有一次这样的机会和大家分享、交流一下最近的感受。
与过去十五六年相比,最近这几年互联网市场变化非常快,我们怎么应变的?我们首先回顾一下最几次管理干部大会:去年“5·18”一次七年之痒之后的剧变,组织架构做了相当大的调整;在去年下半年我们又提出了精品战略;今年上半年对管理干部提出了激情、好学和开放等要求。在这一次管理干部大会,我们将坚持过去一年半的基本原则,也就是顺应“打造精品、拥抱移动互联网”这个非常明确的潮流。
面对这个潮流,最近这两年给我一个感觉,我们好像又回到了15 年前激情燃烧的岁月,我发现我们做了15 年,从零开始打造的工具、平台,从一个没有商业模式的产品,逐渐、逐渐成长为丰富的商业模式。从头推翻,重新来一次,这个过程也是很让人激动的。
对于在座的各位,今天是好的时机,让我们有机会重新来一次,这个过程是一辈子都很难轻易找到的,我希望大家能有更紧迫的使命感!
从搜狗之盟,看变革心态
再看看最近比较大的动作。我们最近和搜狗达成了战略合作联盟,这对腾讯来说是从未做过的事情,就是把我们一部分业务“嫁”出去,和一个曾经的竞争对手结合在一起,合为一体。这个事情到现在还没有完全整合完毕,这毕竟是腾讯没有做过的事情。
为什么大家认为很突然?因为相当复杂,这个领域的竞争对手很多,所以任何的泄密都可能会造成整个事情做不成。这个事情结束得很快,所有事情都发生在不到 一个月之内,真正执行只有两周时间,甚至对于总办,也是提前2、3 天所有总办才一起沟通。整个事情我们觉得比较奇迹的是居然保密了,因为互联网时代是很难保密的。
因为腾讯从来没有做过这样的事情,对很 多员工来说是很大的震撼,有很多不理解,也有人有彷徨。首先要从大的方向来看,这件事情是正确的,我们应该做。但我们怎么做?怎么能够让腾讯的企业文化关 注员工的精神能够持续?从另一个角度来说,对于搜索线的同事、干部也要有更开放的心态,其实并不是远离家乡,你可以理解成派到一个合作伙伴去、或者是分支 机构去工作,我相信未来的人才还是可以流动的。大家还是要抱有开放的、可上可下、可进可退、可内可外的心态才比较健康。
这一次不仅是搜索线,我相信对其业务板块、干部也一定会有所启发,腾讯还能做什么?我相信很多同事在这之后会思考很多问题。这是从“5·18”之后对整个组织架构又一次在组织方面比较大的变化,它一定会带来一定的思考。
以前,不少同事会抱怨,公司很多东西该变,但变得太慢,瞻前顾后,考虑的东西太多。不变的话,像行业里的诺基亚、BlackBerry 等公司到最后怎么样?拖着、拖着一个又一个季度,最终还是不行,非常悲惨的过程。我们希望在这个动荡的行业里,我们一定要主动求变、主动应招,有问题尽快解决,拖3个月、半年、一年,慢慢就会积重难返,谁也救不了。所以这个心态大家要统一,在执行的时候、遇到问题的时候,大家要抱着坚定的信心,比较正面的看待问题。 主动变化往往会好过一成不变、束手无策。
刚才也说了,行业往移动互联网方面走,这是大趋势,我们要因势而变,我们不断从内部组织架构、从产品关注度,要从过去PC、手机相对分隔的状况走向统一。“5·18”之后我们做了很多调整,但还不够,还需要很多调整。
比如,最近我们把手机安全和PC 安全整合在一块,放在MIG。在这背后,大家看到MIG 做几次手术之后,开始重塑MIG 的核心使命,管理干部重新规划职责。现在在安全方面,整个国防都放在MIG,这也是公司的重点,也是为整个腾讯下一个十年移动互联网商业模式的保驾护航, 这非常、非常重要。不能有任何侥幸心理让你缓一缓,或者不去想,这个挑战大家要牢记在心中。所有的产品线都应该积极思考怎么样带动安全的份额,怎么样提升 安全领域的专业能力和形象,这是希望大家永远要想的问题,否则永无宁日。这和人类历史上国家和地区的发展一模一样,没有什么区别,安全性始终是安居乐业、 商业发展的基础。
干部要“饥渴”,不做富二代
在这样的变化情况下我们的人怎么样才能打赢这场仗,怎么样才能走得更好?对人的要求很重要。我们提到要有激情,要好学,要开放,我不一一展开,我想说的是,从很直观的感受来说,我们很希望整个管理干部的氛围是非常饥渴的。
要解决这些问题,你真的要当成是自己家里的事情,要有很紧迫的使命感才有可能做得到。如果说十几年过去了,很多同事加入公司时间也很长了,慢慢、慢慢地“皮”了,应该主动积极地把位置让给下一代更主动积极的团队或干部上来带领团队。
有些业务做得不是太好,回头看不是钱的问题,不是资金或资源没有给够,很关键的还是团队的精神。尤其是带团队的将帅相当重要,真的会有将帅无能累死三军 的感觉,下面的同事会很失望,觉得公司为什么很多东西决策这么慢?为什么没有发现问题?如果继续下去半年、一年能看到改变吗?
这种情况下,我们看到在传统行业会有资金密集型扭转的机会,但移动互联网基本不太可能,因为这个市场不是拼钱,也不是拼钱去买流量,更多是拼团队,有没有使命感,有没有紧迫感,有没有很好的办法去解决?
我希望打破过去富二代的概念,希望大家成为闯二代、创二代,资源会给你,让大家的起跑线好,但最终赢不赢一定取决于你能不能做出精品,是不是BE THE BEST ?我们提供很多资源给你只是加法,别人产品是100 分、你是80分,我只能给你加100 分的资源,头一、两年你的总分多过别人,如果5年后呢,100的5次方超过80 的5 次方加上100,时间拖长了你加的那点资源就可以忽略不计,最终还是靠产品本身的质量才能和别人比,这已经多次证明了。
因此,我们希望重新整理过去的很多布局。很多业务摊得很大,同事希望下面管得越来越多,什么都不放,这需要重新思考,10 个都弱都不如1 个很强。否则一堆做不起来的东西,只能减分、分散精力。
后面可能还会有很多变化,包括我们在产品方面要加强Review,真的要下决心,做不好的我们要砍掉,关停并转。有些业务,以前自己做的,可能会转给投资公司,只要他做的好,然后持有股份30%、20% 都可以转给他,不一定全部都放在自己手上。
内部挖潜,精兵简政
最后,我们希望员工人数更加精兵简政。今年招聘了1000 多名毕业生,总人数增长控制在10% 以内,明年增长控制在5% 以内。我相信从很多项目会腾出很多人手,大家内部挖潜,不要说我的人就这样,我不想动,为留人或闲着找项目做,而不是真正从本质的需求出发。该调转、该调 拨的,大家要有大局观,应该放就放。
当然从历史来看,这个东西从来不容易,需要Push,甚至抓着执行才有办法,我希望大家从今后开始 要真正想这个问题,人不是越多越好,人是分母,成绩是分子,我们看最后是不是效果好。加的每一个人,每一个精心挑选的人才能真正大于原有的平均值1,否则小于1 的话,加得再多也永远小于1,永远大不过1 的格局是很难、很难扭转的。
产品和业务能不能有起色?前面的启动过程是非常、非常 重要的。我几乎没有见过历史上一直不行、一直不行到最后突然间行的产品。一开始团队要展示出信心,要展示出CPU 的转速超过别人,如果你是精品,最后加东西才有可能是正面的,否则转速低之后加东西永远是拖累——这是相当大的反思,希望与大家共享,希望大家在之后正当 的调整和公司这个原则方面能够更加有共鸣。
希望大家能够拥抱移动互联网,移动互联网和PC互联网将是一起的,我们并不是轻视PC 互联网,因为我们很多商业模式,包括团队、基础、后台很多都融为一体!也希望大家更多地拥抱开放,尤其是内部开放,很多团队在内部的合作方面其实还有很多提升的空间。因为术业有专攻,有的产品和范畴很多同事很擅长,希望大家能够积极开放胸怀,大家一起把事情做好,大家好才是真的好!
谢谢大家!
Pony 2013-10-10

从外行的视角尝试讲解为什么这回丰田栽了

From:http://club.tgfcer.com/thread-6817371-1-1.html

【第一部分】背景简介

前几年闹得沸沸扬扬的丰田刹不住事件最近又有新进展。十月底俄克拉荷马的一次庭审,2007年一辆2005年凯美瑞暴冲(Unintended Acceleration,UA)致一死一伤事件中丰田被判有责。引起广泛关注的是庭审中主要证人Michael Barr的证词让陪审团同意丰田的动力系统软件存在巨大漏洞可能导致此类事件。这是丰田在同类事件中第一次被判有责。庭审过后丰田马上同意支付300万美元进入调解程序。

出于好奇,我漫不经心地下载了Barr的286页证词,却一下子被吸引住了。几天内读完,算是对这次事件进行了一次深入了解。下面就从外行角度总结一下这份证词并尝试以更简单的语言解释里面提到的暴冲原因以及丰田犯下的错误。

Barr的证词下载自他的个人博客Barr Code,但现在该文已经被删除。见2楼。

Michael Barr是谁?他是一位拥有20年以上行业经验的嵌入式系统工程师。在十八个月中,有12位嵌入式系统专家,包Barr,受原告诉讼团所托,被关在马里兰州一间高度保安的房间内对丰田动力控制系统软件(主要是2005年的凯美瑞)源代码进行深度审查。这房间没有英特网,没有手机信号,他们进出不能携带任何纸张、记录甚至皮带。最后的调查结果被写入一份800页,13章的详细报告。而鉴于保密协议,调查内容一直没有公布,直至俄克拉荷马这次庭审才首度部分公开(报告本身似乎还没公开)。

回到正题。丰田的软件有没有缺陷?根据Barr的调查,答案是有。这其实是废话,任何软件都会有缺陷,关键在于是什么样的缺陷。丰田的软件缺陷分为三类:

  • 非常业余的结构设计。
    软件设计的基本要求是模块尽量简单化,因为这样可以一来更易于阅读二来更易于维护。但丰田的工程师显然没有遵循这原则。Barr使用一种工具自动根据代码的可能分支数量评估函数的复杂度,结果是丰田的软件中至少有67条函数复杂度超过50,意味着运行这个函数可能出现超过50种不同的执行结果,属于“非可测”级别。因为为了测试这50个不同的结果,必须准备至少50条不同的测试用例以及相应的文档,在生产环境中一般是不现实的。作为比较,Barr表示他自己的公司严格执行的其中一条规定就是任何代码复杂度不能超过30,否则不合格。而在这67条函数中还有12条复杂度超过100,达到“非可维护”级别,意味着一旦发现缺陷(Bug)也无法修复,因为实在太复杂,修复缺陷的过程中会产生新的缺陷。其中最复杂的一条函数有超过1300行代码,146个可能执行路径——正好用于根据各传感器数值计算节气门开关角度。
    如果你不知道什么是节气门,那么这里我稍微解释一下。为了让内燃机运行,有三大要素:燃油、空气和点火时机。空气和燃油的混合物进入气缸,被火花塞在正确的时间点燃推动活塞并最终推动曲轴和车轮前进。在电喷技术发明以后直到2002年以前,三大要素的燃油和点火时间是由电子设备控制,节气门机械连接加速踏板,由司机直接控制。节气门大致是一个连接加速踏板的“空气龙头”——踩下去越多,“龙头”打开得越大,允许越多的空气进入发动机输出更大的动力。2002年以后,丰田引入的“电子油门”让电子系统掌管了最后一个要素:空气。加速踏板不再机械连接节气门,而是连接一些传感器,由行车电脑将这些传感器数值计算成节气门开启角度再由马达控制节气门。我们稍后会再讨论节气门开合。
    极复杂的代码带来的是极复杂的功能。下面说一下被称为“厨房洗涤盆”的Task X。这里先解释一下,丰田的软件系统和很多别的软件系统一样,都是由一个统领程序(称之为“操作系统”)和若干小程序(称之为Task)组成。就好比电脑上跑的Windows是统领全局的操作系统,网络浏览器和记事本是跑在操作系统上的小程序。丰田的系统里每个Task都有自己的名字,但这些名字非常敏感,敏感到每次被提及的时候律师都要求法庭内的没有阅读代码权限的人全部清场。为了减少清场次数,Barr将这个最重要的小程序称为Task X。这个Task X有多重要呢?跟厨房里的洗涤盆一样重要。它负责非常多的事情,包括计算节气门开启角度、速度监测和保持、定速巡航监测等等。Task X的不正常运行被认为是暴冲事件的元凶。稍后会再继续讨论Task X。
    还有一些别的匪夷所思的发现。比如丰田的软件包含了超过一万一千个全局变量。如果你不知道什么是全局变量,那么只需要知道软件设计的一般原则是要尽量少使用全局变量,因为有可能带来无法预测的结果。这里的“少”的意思是“尽量接近零”,绝对不会是一万一千个。
  • 不符合软件开发规范。
    如同很多行业一样,汽车行业也有自己的规范。更具体一点,由于汽车的危险性质,汽车控制系统被划分为“安全关键性系统(Safety Critical System)”——说白了就是安全性非常重要,弄不好会死人的。为了达到这一特殊要求,汽车相关软件开发人员定期举行会议讨论并发布编程规范,称为MISRA C。该规范的2004年版的感谢列表里还能看到丰田员工的名字,至少让外界认为丰田确实也在遵循这些规范。
    真的吗?根据源代码来看,答案是否定的。对此之前的NASA报告也有所提及,丰田辩称他们遵循的不是行业规范,而是丰田内部编程规范。这一规范与行业规范的吻合程度达到50%。但是Barr认为根据他的调查,两个规范之间吻合度小于10%,甚至有若干规范条目相互冲突。后来发现丰田的代码甚至没有遵循丰田内部规范,当然比起别的问题这个已经无关紧要了。
    MISRA C拥有超过100条规范,NASA的调查只使用了到其中35条进行校对,发现超过7000处违规代码。Barr使用全部条目,对照结果是丰田的程序拥有超过80000处违规代码。
    这些数字说明了什么?根据统计,违规数量可以用于预测代码中暗藏的缺陷(Bug)数量。在之前提到的汽车相关软件开发人员会议中,有人就这一主题发表过专题演讲,提出每30处违规代码可能包含一个重大缺陷和十个轻微缺陷。讽刺的是这人是丰田员工。
    特别需要指出MISRA C其中一个规则的内容是不得使用递归。
    如果你不知道什么是递归,那么这里我稍微解释一下。递归是一种计算方法。但一般计算方法要么是自己算,要么询问别的计算模块索要结果。而递归则是通过问一层层问自己的方法完成计算。好处是代码简单,坏处是计算层数不固定。可能会2层就出结果了,也可能会是10000层,在设计程序的时候无从得知。
    软件计算需要消耗存储器。越繁琐、越长的计算自然需要占用越多的存储器。递归的问题在于其嵌套层数无法预测,从而导致可能消耗的存储器容量无法控制。稍后会再讨论存储器。
  • 对关键变量缺乏保护。
    什么是变量?变量就是存在一段存储器的0和1的集合。这些变量既可以是一些函数的处理结果,也可以是另一些函数的处理原材料。比方说前面提到有一条程序专门计算节气门开合角度,比如说是20度,这个20就是一个变量,存在存储器的一个指定位置。另一个程序专门负责开合节气门,它知道去那个指定位置读取这个20,然后把节气门开启20度。
    什么是保护?嵌入式系统,或者任何系统,都会在一定条件下发生硬件或者软件错误。客观上这是无法避免的。而且汽车作为一个时常在震动、发热、位移的系统,它的内部环境不能说不恶劣,发生硬件错误的可能性甚至更高。什么样的硬件错误呢?别忘了变量都是0和1的组合,这些0和1由存储器上的高低电平代表。由于某些不可抗原因,一个电平从高变成低,或者反过来,那么这个变量就被更改了。这被称为“位反转(Bit Flip)”。为了对抗这样的事情发生,需要对变量进行保护。保护的方法一般是镜像法。简单来说就是在两个不同的地方写入同一个变量,读取的时候两边都读,比较是不是一致。如果不一致,那么可以得知这个变量已经不可靠,需要进行容错处理。
    丰田的程序总体上对其上万个变量进行了有效保护,但问题出在操作系统上。前面提到丰田的软件本质上分为操作系统和Task。Task是由丰田自己开发,但是操作系统则是由芯片供应商提供,固化在芯片里的。丰田在这里的过失是没有对供应商提供的代码进行深度审核,拿到什么用什么。
    另一个保护措施是错误校验码(Error Detective and Correction Codes,EDAC)。这是一个硬件层面的数据保护措施。简而言之就是给内存中每一个字节(8比特)后面物理地增加几比特校验码。这样万一变量出错了,可以通过校验码得知,甚至可以通过校验码修复一些轻微错误。这个措施十分简单有效,但是在2005年款凯美瑞的系统中完全没有使用,丰田却告诉NASA他们用了。而在2008年款凯美瑞中使用了3比特长的EDAC。Barr认为是为了节省成本,否则应该使用5比特长。
    还有值得一提的是,汽车相关的软件行业有那么几家操作系统供应商,早已形成了一套成熟标准称为OSEK。各供应商开发的符合OSEK认证的操作系统至少都能达到一定的质量。但丰田选用的操作系统却没有通过认证,让人不解。



现在我们知道丰田在编写软件的时候至少有三种缺陷。那么重点问题:丰田的这些软件缺陷是否会导致车辆暴冲?根据Barr的调查,答案是有可能。暴冲的起因需要结合上述三种缺陷来说明。

汽车正常运行需要倚靠若干程序(这里叫Task)的同时运作。Task有很多,CPU只有一块,在任何时刻只能处理一个Task,怎么办呢?这需要操作系统的统筹规划,合理分配CPU的任务,让每个Task都能按时执行。如果出现某种意外,让某个Task突然不执行了,那么就称为这个Task“死亡”。Task死了,自然不能执行它的任务。根据Barr的测试,在某些特定情况下,Task X的死亡可以导致节气门敞开——因为Task X的其中一个任务就是根据司机的操作计算节气门开合角度,它死了也就没法重新计算这个角度,即使司机把脚挪开加速踏板,节气门也无法关闭。此为暴冲的直接原因。更糟糕的是,节气门的开合角度这个数值,被Task X算出来以后保存在一个变量中。这个特定的变量正好没有被保护(缺陷3)。意味着万一Task X死亡并且停止计算,这个数值有可能因为不可抗原因被改变,而程序无从得知。

那么Task X为何会死亡呢?一般是因为内存出错。这个出错可能是一个小小的位反转,也可能是内存里的数值被别的程序错误覆盖。同一系统内同时运行了若干程序,这些程序需要共享一块内存,内存内部必然要被划分成若干块。比如第一块给程序1,第二块给程序2,等等。如果程序1因为某些原因(比如Bug)写到第二块内存上去,就会导致程序2读取了错误的信息。这就是所谓的内存出错。丰田的系统里,正好有这么两块相邻的内存块。第一块被称为“堆栈(Stack)”,这是所有Task存储它们运行状态的地方,大小为4KB。与之相邻的地方储存了操作系统进行任务分配的记录。那么可以想象,如果很多Task给堆栈里写入太多东西,超过4KB,那么就会错误地写入与之相邻的任务分配表。这种错误被称为“堆栈溢出”。操作系统拿到了错误的任务分配表,就会错误地分配任务,造成某些Task多执行几次,某些Task少执行几次,某些Task甚至就再也不执行——死了!必须指出的是,程序死亡并不罕见,甚至可以认为是正常现象。稍后解释处理方法。

那么堆栈为什么会溢出呢?显然是因为要写入的数据超过了堆栈的容量。在设计程序的时候要计算最坏的情况并且允许冗余。即使作出了正确的设计,这种错误也相对常见,所以NASA在他们的调查中重点排查堆栈溢出的可能性。于是NASA问丰田,丰田的回复是最坏的情况下4KB堆栈只写入了41%的数据,换句话说发生溢出的可能性非常低。NASA直接取信了这个数字并没有再深入调查。但Barr他们发现丰田的回答有严重低估,实际上最坏的情况会达到94%,而且还不算递归。丰田在代码中使用了递归(缺陷2)。因而实际数字有可能超过94%而且无法预计上限,因为递归计算的嵌套层数是无法预测的。所以实际情况下堆栈溢出的可能性相当可观。一旦溢出,相邻的任务分配表不可避免就会遭到破坏。此为暴冲的根本原因其中之一。之所以说“其中之一”,是因为堆栈溢出仅仅是损坏任务分配表的其中一个原因,别的还有许多可能性并没有被Barr在法庭上深入解释。而且任务分配表的损坏也仅仅是导致Task死亡的原因之一。

顺便提一句,2005年的凯美瑞的这部分供应商是电装,没有搭载堆栈实时监测功能——溢出了也不知道。同年的卡罗拉却搭载了,因为供应商是通用。


到这里我小结一下,串链子。左边是原因,右边是后果。
堆栈溢出→(可能导致)→任务分配表被改写→(可能导致)→Task X死亡→(可能导致)→节气门敞开→(导致)→汽车暴冲


必须指出的是,这条链子从最左边一直到Task X死亡,都还算是嵌入式系统的常见故障。虽然程序代码写得不好也许导致更容易出错,客观上丰田并没有特别大的过错。只要处理得当,这些故障都不会导致暴冲。

到此为止还只是前奏而已,接下来我们来看看丰田到底做错了什么。

【第二部分】丰田之罪

上面反复提到,嵌入式系统中内存出错或者程序死亡其实是一种正常现象——至少从Barr的证词可以得出这个结论——现在连我们都知道了,嵌入式工程师肯定比我们更清楚才对。确实,为了使系统正常运行不被错误干扰,一般的做法是设置若干层防护措施(Failsafe),让运行中出现的错误无法轻易突破,得到妥善处理。丰田的工程师自然也懂得这一点。很可惜,他们搞砸了。

上面那条链子应该修改成这样:
(防护措施0)→堆栈溢出→(防护措施1)→(可能导致)→任务分配表被改写→(防护措施2)→(可能导致)→Task X死亡→(防护措施3)→(可能导致)→节气门敞开→(防护措施4)→(导致)→汽车暴冲

可以看到,防护措施不可谓不多。只要处理得当,这链条应该是走不通的。现在让我们从左到右看一个小小的内存错误是如何一层层突破防护最终导致汽车暴冲的。

首先防护措施0。这个其实上面提到了,因为设计缺陷低估了最大占用的存储容量,并且不符合规范地使用了递归,最终可能导致堆栈溢出。

然后到防护措施1。上面也提到了,任务分配表紧邻堆栈。作为外行我都觉得这是个十分危险的设计——既然堆栈这么容易溢出,好歹应该将任务分配表放远一点啊。当然我是外行,可能实际上比想象中复杂很多。这段Barr的证词中并未特别提到,属于我的个人理解。

防护措施2。从这里开始丰田的错误越发严重。任务表被改写导致某些Task运行异常,在软件层应该有若干检测措施,比方说用特殊的监视Task来监视别的Task是否正常。但丰田是怎么做的呢?还记得上面的“厨房洗涤盆”Task X吗?它是如此复杂(缺陷1),除了控制汽车运行的任务之外竟然还兼任大部分的监视任务,比如生成DTC。
DTC(diagnostic trouble codes),是汽车电脑系统会根据情况生成的错误代码。有的车主可能会遇到汽车某报警灯常亮,修车师傅拿个仪器插在行车电脑上得出一个代码,再查表就知道哪个元件坏了——这就是DTC。除了用于修车,DTC还被用于检测行车电脑和各传感器的异常状态。
可以想象,这个既是运动员又是裁判的Task X一旦死亡,软件层的检测措施大部分就失效了。


防护措施3。在这里丰田的错误开始到达顶峰。即使设置正确无误,上面提到的监视Task也只不过是另一个Task而已,与它的监视对象算是平级——监视Task自己同样有可能出现故障。嵌入式系统的一般做法是在所有程序之上再设置一道屏障,被称为“看门狗(Watchdog)”。所谓看门狗,是一个优先级很高的倒计时程序。别的程序需要在运行的时候特意去重置一下这个计时器让它重新开始倒计时,这个动作被称为“喂狗”。如果因为程序出问题太长时间不喂狗,倒计时完成,看门狗知道什么地方卡住了,马上采取措施,比如重启整个系统。重启系统听起来似乎很严重,实际上却是一件相当普通的事情。嵌入式系统的重启非常快,时速100公里的汽车中动力系统可以在半米之内完成重启——车上的人根本觉察不到。

通过阅读代码和拟真实验,Barr惊讶地发现上述嵌入式系统的常识性做法竟然在丰田软件系统内不存在!丰田的软件确实有一只看门狗,但它竟然不是用于监视Task异常,而是用于防止CPU过载。首先这个做法不能说后无来者至少算是前无古人。还记得上面提到的800页13章的报告吗?目瞪口呆的Barr将丰田看门狗的分析结果写入了报告的第一章,因为他实在太震惊。其次,丰田看门狗的防止CPU过载功能也相当蹩脚,在拟真测试发现即使它正常工作,还是会允许CPU过载时间长达1.5秒——时速100公里的车能跑40米以上。CPU一旦过载,就会导致所有的Task进入一种“假死”状态,无法处理信息,这时司机无法控制汽车动力,十分危险。
另外,丰田的工程师还犯了一个嵌入式课堂上被反复提到的经典错误:使用硬件时钟中断喂狗。硬件中断拥有非常高的优先级,即使Task卡住(比如出现死循环)也不能阻止硬件中断——可想而知这样一来看门狗就等于完全白瞎了。
这里也提一句,同年的普锐斯却令人意外地搭载了一只运作正常的看门狗,反而让人摸不着头脑。
还没完。这一层防护是嵌入式系统的关键阵地。前面都是电子系统,后面马上进入机械运作,足以造成灾难了。所以仅仅拥有软件级别的防护还不足够,丰田的做法是在主CPU之外单独设置了一块监视芯片,从硬件级别对系统的运作进行监视。监视芯片有两个任务。第一,它运行一种叫做系统卫士(System Guard)的程序,原理上来说是专门用于防止暴冲。主CPU和监视芯片上都会运行系统卫士,可是研究发现Task X一旦死亡,这些系统卫士统统都不起作用了。第二,它运行一个被称为“刹车回声检查(Brake Echo Check)”的程序。这个程序从代码上来看似乎可以检测出Task X的死亡,并且采取相应措施:关闭节气门。听起来像是好消息,但是同样有问题:首先这个程序不太可靠,即使正常运行,理论上也有失效的可能。最关键的是该程序不会自动运行,需要司机先对刹车踏板有“动作”才会触发。注意这里我特意没用“踩刹车”这个词,因为根据分析“触发动作”十分令人困惑。它分两种情况:如果Task X死亡的那一刻司机的脚不在刹车踏板上,那么触发动作是踩刹车。还算可以理解。另一种情况,如果Task X死亡那一刻司机的脚踩在刹车踏板上,那么触发动作是完全释放刹车踏板。没错,察觉车子在不正常加速的司机需要停止踩刹车才能让控制系统关闭节气门!这种违背人类认知的行为应该不是丰田工程师特意设计的。如果是,他们到底在想什么啊?
到此为止,上面提到的都算是“战术层面”的错误,都是“小错”。在讲解这块监视芯片的时候,可以发现丰田犯下最严重的“战略层面”错误——基础设计。Barr认为,如果基础设计正确,上述那些小错都完全不会导致汽车暴冲——不管代码写得多业余,不管内存错误多严重,不管Task死得多频繁,统统不会致命。让我们回到2002年以前,没有电子油门的时候。那时候的拉线油门是由油门踏板机械连接的。当驾驶员的右脚踩下刹车,他的右脚必然不在油门踏板上,节气门自然而然地被关闭。这个动作如此自然,甚至算不上安全措施,仅仅因为每人只有一只右脚,不可能同时踩油门和刹车。当丰田设计电子油门的时候,只要稍微有点常识,都应该从设计阶段就将这一“自然而然”发生的动作考虑进去。但是很显然,他们没这么做。监视芯片上运行的代码是用汇编语言(一种更加接近机器执行代码,远离人类语言,更加难懂的编程语言)编写的,运行层次比主CPU的C语言更低。Barr认为如果设计得当,现有的监视芯片完全有能力胜任上述功能,需要的仅仅是几百行代码,别的什么都不用更改——不会提高任何生产成本。很遗憾,他们没有做到。


防护措施4。现在已经脱离电子系统,节气门已经敞开,发动机全速运转,需要使用机械运作来阻止机械运作了。如何让向前冲的车子停下来?不开车的人都知道,刹车!现代汽车都装备了刹车助力,助力来自于发动机运转的时候产生的负压。我们知道发动机需要吸入空气,吸入体积等于排气量乘以转速。节气门又是用来阻挡空气的,那么节气门关闭而发动机转速相对高的时候(比如高速丢油门),发动机的实际空气吸入量比它能吸入的体积要少,那么从节气门到气缸进气口之间会形成明显低气压(所谓负压,比大气压力小)。刹车助力就是利用了这个负压推动气鼓产生更大的推力带动刹车片抓紧刹车盘。气鼓的结构是有两个封闭的空间,一边连接低压端(由发动机负压或者真空泵带动的真空罐)另一边连接高压端(大气),两边的气压差在隔层产生压力。按理说无处不在的大气压强是最容易得到的,但是丰田偏偏将刹车系统的进气口与发动机进气口相连。当节气门敞开,发动机大量吸入空气的时候,空气流速大大增加。两百多年前的伯努力早就发现,流体流速越高,压强越小。又一个基础设计失误!


但是如果节气门敞开让空气随便进来,低气压就不存在了,这时刹车助力大大减弱,刹车效率也大大降低。这就是为什么暴冲事件当事人都说全油门的时候根本刹不住的重要原因。这个现象称为“真空损失(Vacuum Loss)”,存在于所有自然吸气的汽油发动机汽车(柴油和增压发动机没影响),不算丰田的错。但丰田迟迟不搭载刹车优先系统(Brake Override System)允许刹车的同时敞开节气门,毫无疑问是这个现象的帮凶。
所谓刹车优先系统,指的是保证同时踩下刹车油门两个踏板的时候无条件关闭节气门的功能。这么做很显然主要是为了降低发动机输出,同时也保证刹车助力。丰田在2010年的凯美瑞上终于搭载了刹车优先系统,但是别高兴得太早。根据Barr的调查,丰田竟然将如此重要的修改“理所当然”地写入了他们的“厨房洗涤盆”——Task X。我只能“哑然失笑,扼腕叹息”。


好了,到此为止都还是Barr的一面之词,而且大部分都是在那间守卫森严的房间内进行拟真测试得出的“理论结果”。那么实车测试情况如何呢?丰田对Barr的证词如何反驳呢?


先说说实车测试。为了证明理论,他们把2008年和2005年的凯美瑞放在马力机上,固定车身架起前轮模拟车辆运行情况。他们的做法是首先让车子运行在时速68英里(110公里),启动巡航,脚离开油门踏板。然后暂停巡航,速度开始下降。下降到一定程度恢复巡航,速度开始上升。在到达68英里的设定时速以前,用一台连接行车电脑的笔记本“注入”错误。所谓注入错误,就是人为地反转一个特定比特——将0改成1,或者反过来——模拟内存损坏。结果完全符合理论,时速超过68英里也不停止加速,直至时速90英里(145公里),测试人员踩下刹车。大约1秒以后节气门被关闭,Barr认为这是上述“刹车回声检查”的功劳。


实车测试证明了Barr的理论,却并不是全无破绽。丰田辩护律师就两点提出质疑:

  • 实车测试使用人工注入错误的方法,并不能证明现实中这种错误就一定会发生。
    对此Barr的回答是测试的局限性。因为测试时间、样本有限,而待测试的样本空间无穷大。如果要等待那个特定的错误自然出现,可能需要成百万上亿小时的不间断测试,显然是不现实的。更何况从科学上而言,没有办法对这个错误证伪——就好比无法证明宇宙里没有外星人,最多只能证明火星上找不到而已。但是这个测试足以证明一个小小的位反转确实可以突破重重障碍最终导致暴冲,足以证明丰田的软件存在不能容忍的隐患。
  • Bookout女士(本案原告)声称,在她驾驶汽车离开高速的时候发现不受控加速,她拼命反复踩下刹车并且拉起手刹,现场留下了刹车痕迹。但并没有迹象表明发动机动力中断——换言之“刹车回声检测”没起作用。暗指Barr的理论站不住。
    对此Barr的回答是首先尽管在实车测试中每次都生效,但代码分析表明“刹车回声检查”这一功能在理论上靠不住。其次这一功能的另外一个触发动作是要让脚完完全全离开刹车踏板。试想车子正在不受控地往前冲,任何人都会不由自主地踩刹车,让人完全不踩刹车踏板根本就是违背认知的。Bookout女士即使如同她所称反复踩刹车,很可能只是一直将脚放在踏板上往复运动,从未完全挪开。Barr还引用一位丰田自己的软件专家的证词。该专家承认,如果发生暴冲的时刻脚正好接触到刹车踏板,并且之后一直没挪开,那么汽车的暴冲距离“取决于还剩多少汽油”。

最后顺带说一下那份800页,13章的详细报告完成后,Barr将其提交给了丰田的软件部门,等待他们的反驳。最终结果是“非常少(Very little)”,13章中的11章,包括堆栈溢出的部分、代码混乱的部分、违反开发规范的部分、Task X过于臃肿甚至兼任节气门控制和防护措施的部分、看门狗形同虚设的部分、无EDAC的部分、重要变量缺乏保护的部分、使用了非标准化操作系统的部分,全部没受到任何形式的反驳。


【第三部分】后记

写到这里,谈谈人们比较关心的几点。当然还是外行眼光。

  • NASA / NHTSA怎么没发现这些问题?
    NHTSA本身不具备检验电子系统的能力,于是委托NASA。NASA检验的是整个电控系统,包括电控传动部分,范围比较宽,只有很少一部分资源被用于检验软件系统,也没有投入足够的人力进行逐行代码审阅。更何况在很多关键问题,比如之前提到的EDAC的使用、堆栈的设计,NASA都直接采信丰田的回复,最终被证明不正确。甚至NASA从来都没拿到过监视芯片的源代码,丰田的说法是“他们没说要啊”。NASA报告虽然没能找到软件系统导致暴冲的确切原因,但没有否定其可能性。与之相比Barr的团队全部都是嵌入式系统专家,投入上千小时,深入程度甚至超过丰田自身对这个系统的理解(比如丰田没看过供应商的OS代码,Barr看了)。
  • 能否100%确定本案就是由软件错误造成的?
    不能。并没有直接证据。诉讼团认为,软件错误造成该事故的可能性比软件错误没造成该事故的可能性大(原文:more likely than not)。
    这里再提一句,2005年款的凯美瑞没有搭载行车数据记录器(俗称“黑盒子”),后来的车款渐渐开始搭载。但是Barr发现这个记录功能并不可靠,完全有可能记录错误信息。比如司机踩刹车了可能会被记录成没踩。
  • 原来检查半天还是找不到直接证据啊?
    这里涉及到一些技术层面的原因,列举如下:

    • 之前提到,2005年款凯美瑞没搭载黑盒子;
    • 没有黑盒子的情况下,唯一可以直接证明软件错误的手段只剩下DTC;
    • 但是如同之前提到,很大一部分DTC的生成由Task X负责;
    • 即使其它Task或者操作系统检测到异常生成了错误代码,而且丰田的代码中竟然能找到特定的语句专门忽略这些错误代码(MISRA第一版中明确禁止的行为);
    • 即使终于有一些错误代码好不容易被记录下来,却被保存在连接电池的易失存储器(RAM)上——事故发生之后车辆被详细检查之前,只要电池因为某种原因断开,这些信息就丢失了。
  • 本案的意义
    之前虽然丰田赔了不少钱,但是从未在涉及人身伤害的案件上承责。所以本案意义在于开先例。美国的法律又特别注重先例,今后丰田的法务部门要头疼了。
  • 本案提到的有缺陷软件涉及了哪些车型?
    全部是美国的车型。Barr的调查重点是2005年款凯美瑞,另外审阅过的包括雷克萨斯ES、Tacoma、卡罗拉和普锐斯等等,生产年份大致在2002年(电子油门元年)与2010年之间。其中凯美瑞、雷克萨斯ES和Tacoma使用的软件系统大致接近(原文:Substantially similar)。另外根据统计,汽车暴冲投诉中与2004年款以后的凯美瑞有关的案件数量激增400%。
  • 太可怕了,这(丰田)车还能开吗?
    我认为不必过度惊恐。首先暴冲事故的出现可能性还是相当低的,有许多案例都被证实是司机操作错误。再者本案也没能直接证明软件缺陷肯定就是暴冲事故原因。万一真的出现暴冲也不是无法挽救,证词中提及了驾驶员使用N档或者P档成功脱险的案例。但是今后有必要留个心眼,注意一下车的档位切换,开车时集中精神对路况进行预判,出现情况的时候冷静应对。要不也可以试试Barr的发现:全部丢掉刹车然后再踩(汗)。



最后的最后,放上本案关键证人Michael Barr的独家访谈:

我:这么看来似乎手动档汽车更安全,你怎么认为?
Barr:很多专家都这么认为,离合器至少可以物理断开动力系统。但是我翻阅卷宗,发现其中有个案例是受害者开手动档凯美瑞载着家人,突然巡航系统失灵,无法取消。他踩下离合,同时试图躲避前方慢速车辆结果失控冲出路面造成单车事故。幸运的是没死人。

我:现在我们都知道丰田的软件很糟糕。可是你对整个汽车行业的软件水平有什么看法?丰田的软件在同行内属于什么水平?
Barr:我没有接触过丰田以外的软件代码。但是请注意,这次发现的最严重问题是丰田在设计源头上没有考虑安全,软件质量反倒没有那么重要。只要一个安全为先的设计,比如刹车和关闭节气门的可靠互动、防止节气门开启降低刹车效率的机制等等,不管软件有多差劲也不会造成致命结果。只是我真不知道软件还能怎么差。

我:终极问题,你开什么车?
Barr:我不开丰田。接触该案以来我没买过新车。老实说我现在非常害怕买新车。我倒是问过一个与车企斗争了三十多年的职业状棍同样的问题,他开宝马。

【全文完】

【更改历史】
v1.01(2013-11-06):后记部分增加为何没找到直接证据的技术原因。

2013百度世界李彦宏主题报告速记全文

各位来宾,各位开发者,媒体朋友们,大家上午好!欢迎大家来到2013百度世界,大家知道百度世界是我们一年一度最大的技术创新大会,所以每年我们会利用这样的机会,向大家介绍百度在过去一年当中最重大的技术创新。而过去的一年,我觉得是跟以前的很多年都非常不一样,市场变化非常的迅速,这是刚刚邬院士也讲了,那么丰富的内容,其实在过去很多很多东西,都是在过去一年当中发生了,或者说在过去一年当中大家才意识到这个问题是问题。

对于百度来说,过去一年也确实有很多很多的创新,我相信很多人进到会场之前有机会去转了一圈,我们的展台有各种各样新的应用、新技术给大家介绍。比如说在地图这方面,我们刚刚推出了全景地图,不仅包括街景,也包括室内的实景。比如说我们把知识图谱的技术开始应用到百度的大搜索里面去,人和人之间的关系,物和物之间的关系,我们越来越把它搞清楚了。你去问“谢霆锋的儿子是谁”或者“谢霆锋是谁的儿子”,我们都可以正确告诉你答案。昨天我还搜了一下“骆家辉的夫人”,我发现在Google上搜“Gary Locke’s wife”找不到,在百度上搜“骆家辉的夫人”、“骆家辉的老婆”都可以得到答案。

再比如我们过去一年语音识别的技术,其实准确率提升非常快,大家从百度语音助手、百度语音搜索这些产品上感受到,这样的一个高准确率的识别能力我们会开放给所有的开发者。同理,图像识别这样的技术我们也会把它开放给开发者。很多人都用过百度魔图,或者PK大咖,看你和明星长得有多像。这个背后的技术就是一个图像识别技术——人脸识别(face recognition),这样的技术我们都会开放给开发者使用。还有百度的云存储,今天我们宣布进入了T时代,每个人可以拿到一个Terabyte。

所以在准备这次百度世界的过程当中,我们也很纠结,我们团队让我介绍这个产品,介绍那个产品,演示这个技术,演示那个技术。后来我说不行,我们只有时间去演示一项产品。今天,我就选择其中的一项技术,我认为比我刚才讲的技术都更加重要的一项技术,跟大家介绍。

在过去的一年当中,我们已经推出了很多很多的移动方面的工具和服务,让我们开发者在使用。去年向大家介绍七种武器,它其实是七种工具或者说服务。我们后来一年当中也陆续增加一些其他的服务,帮助我们吸引了很多的开发者,在百度这样一个开放的生态当中,到目前为止,我们已经聚集了70万个开发者。而应用也是层出不穷,有很多非常非常优秀的应用是运用了百度的云能力各种类型的工具来开发出来。比如说大家熟知的墨迹天气、美图秀秀,现在很火的打车应用比如嘀嘀打车,这些层出不穷的应用都和百度有各种各样的联系,利用百度各种各样的云工具、云开发来获得消费者。

不久之前,我们也宣布了一项比较大的收购,不只是比较大的,其实可以说是中国互联网有史以来最大的收购,价值十几亿,91加入百度后,到上个月为止,我们每天的应用分发是6900万,也就是说中国大概有100万左右的应用,我们每天分发出去的应用量到了6900万,这样的量我们也相信是全国最大的,也就是说,在应用的分发上我们有非常强大的能力,来帮助我们开发者。所以,既提供了工具,又提供了服务,又提供了分发能力,我们做了很多事情来帮助中国的移动互联网生态做的更好,更繁荣,更健康。

基于这样一个大的分发能力,我们如果再来看详细一点,再看得深刻一点的话,我们还可以看到,99.9%的中长尾应用在移动分发当中处在非常不利的位置,这些应用只占到我们应用分发量的30%,而0.1%的最top的几百个应用占到70%的分发量。我相信包括在座很多开发者,包括全中国的绝大多数开发者是处在99.9%中间,这就是一个问题。

所以我们要问,开发者,你幸福吗?

我们也很关注这个问题,所以我们做了一些调查。我来给大家举个例子,这是一个开发者开发的应用“e家洁”,这个应用是做什么,是帮助你去找到一个小时工,它需要用你的位置查找你周围这些小时工,你如果使用之后可以对小时工服务进行评价。这个应用很好,对于需要的人来说这是非常大的帮助。这样的一个应用怎么才能够让它的目标消费者有认知呢?

这样的一个应用,它经过一段时间的推广,发现每获得一个用户它的成本大概是8块钱,这样的成本其实对于一个中小型开发者来说是非常非常昂贵,即使是对于百度公司来说,我们也觉得8块钱太贵了。而且在推广的过程当中,其实很难找到目标人群,你不知道什么人是真正需要这个应用的。由于精准率差,流失率也比较高。

大家很自然想到,作为一个应用,我要在移动商店里面进行推广,可是我们现在看一下移动商店,你要进行推广的话其实是不知道该从何做起,应用商店现在的展示形式,都是把最热门的东西,最新出现的东西给放出来。这样的一种结果就像我们刚才展示的那些数字一样,大者恒大强者恒强,越小越没有展示机会。这是应用商店现在能够给像“e家洁”这样的应用所做的帮助,或者说推广存在的问题。

他们也使用了公众帐号进行推广,公众帐号其实是需要你自己的推广能力才能够获得的,比如说你自己有一个店面,把二维码放那,已经是你客户的人来门店扫一下二维码,这样联系起来。但“e家洁”这种没有店面,他就靠地面推广去发传单,发一些打折卡给人,通过打折获得公众帐号的关注者。即使这样,其实在公众帐号这种体系里面,也缺乏很多原生应用所具备的能力,比如语音能力、拍照能力等等都是不具备的,所以公众帐号也不是一个真正的出路。

原因在哪里?原因是因为我们目前整个移动互联网生态当中最最关键的这一环,就是所谓的应用商店一环是有问题的,用我的话讲是“应用商店有根本性缺陷”(APP store model is fundamentally flawed)。刚才我们展示了作为一个应用商店组织应用的方式,它首先给你展示最TOP的应用是什么,排名下载量最大的应用是什么,第一名、第二名、第三名……每一个类目按照这样来排名,最多你是新应用给你一点展示机会。而当你去搜索的时候你必须要知道这个应用的名字才能搜索到,对于“e家洁”这样的应用来说,输入一个英文字母的e再输入家洁这两个字本身已经够难了,更难的是大多数人不知道存在这样一个应用。

我们觉得对于现在的移动用户来说,应用商店是他们主要的获得应用的入口,这很像十几年前hao123作为我们PC用户上网的入口一样,大家最常用的网站放在hao123界面上,今天的应用商店也是这样的,大多数用户最常用的应用放到比较明显的位置.很多人觉得这很好,但是问题在于,如果你很不幸地属于那些99.9%的不常用的应用,就没办法了,你就只有等死,你有很好的工具,你有很好的服务,但是你没有很好的方法,来触达你的目标消费者,这就是为什么应用商店有根本性的缺陷(fundamental flaw)。我们知道伴随hao123而生长的,还有一个巨大的网页搜索的生态,这个生态在移动上现在也已经达到相当的规模,所以百度现在有海量的需求可以分发给我们消费者。刚才我们讲6900万的每天的应用下载,全中国最大的应用分发能力。但是跟移动搜索的量相比,它其实还是小巫见大巫。我们从分类来看,大家关注的旅游类别,我们有每天百万级的实际应用,医疗健康领域有千万计的应用,家政每天百万的应用,美食也是百万级的需求。这么多的需求,怎么能够让它有效触达我们的开发者?这是我们今天要讲的问题。

而对于一个开发者来说,他的理想是什么?我有一个好的服务,我有一个别人需要的东西,我怎么能够很高效地把它分发出去,并且我能够拥有完美的体验。所谓完美的体验,就是它真正要有原生应用的能力、调取云的能力、调取照相机的能力、定位的能力等等,这些能力都需要有。

我们怎么解决问题,或者说对于开发者的理想,我们怎么帮他们实现?我跟我的团队讲,开发者的理想就是我给你们的任务。过去的一年,我们百度移动云团队就把这个任务当做最高优先级事情来解决,他们克服了种种困难,今天终于可以给大家展示百度解决方案,下面有请百度副总裁、移动云事业部总经理李明远给大家介绍百度的解决方案。

 

d98d08db14124d18a4d5cb14d7b41b2e

【程序员的不同境遇:少抱怨 多解决问题】

很久以前有两个程序,当时的水准都差不多,现在A是上市公司的技术总监,B还在不停的跳槽,反反复复在“小团队主程”和“大公司打杂”的两种岗位之间不停切换。B一直把这些不同归咎于自己没有遇到A那样子的机遇,经常在群里和微博抱怨自己的运气。

那天我终于忍不住了,在他再一次抱怨之后,我开始喷他,我说你就从来没有想过自己的原因么?同样是一个临时小活动,我叫A做的时候,A都会告诉我,他手上现在有什么,大概多久能做完,做完之后就可以做这个活动了。而你永远都是说现在很忙,什么时候做不完不知道,因为总有不可预知的东西,我们这些外行人问时间掐进度都是很愚蠢的。

同样在计算自己的开发时间的时候,A说三天做完就一定要三天做完,做不完的就会周六周日来加班,你说一周做完的工作能拖一个月,而且拖欠那么多工作还永远觉得无所谓,永远准时 6 点走人,质问你的时候,你还振振有词说没人付你加班费。

同样是手上的工作做完了,A会找我问有没有后继的工作,而你只会浪费贷款在那边看肥皂剧,直到有人发现你为止。

同样是大家吃完饭回来,A会立刻开始工作,你会一定要把剩下的午餐时间拿来玩一把游戏,逛一下淘宝。

同样是 QA 反馈问题,A会第一时间走到 QA 电脑前看具体表现,自己来找问题。你只会说“我不知道”,“我没办法”,“怎么可能”,“你看错了”,“你叫别人做吧”。

同样是主美觉得界面上的画面有出入,A要么到主美电脑前问具体原因,要么一副虚心学习的样子把主美拉到自己的电脑前讲解。你呢?你只会抱怨“早干嘛去了?”“早又不说”“这没差多少啊”

项目结项的时候,项目经理专门给A写了一封上千字的手写推荐信,还推荐A去 TX,你觉得这个机遇对A很重要,你没有得到项目经理的推荐,很不公平。难道你真的觉得是项目经理心血来潮随机抽几个人来写的么?你真的没有意识到,如果把你推荐到那些大团队去,推荐人的脸会被你丢光么?

你完全没有明白什么叫团队,什么叫态度。不是坐在一起就叫团队,不是不吵架就叫态度。

你的思想里面永远是——我拿这一点的薪水,那我只要做这一点的努力就好了。而A一直都是我现在只有这一点的薪水,但是我只要能多干额外的工作,早晚会有人给我更多的薪水。

是的,也许你的做法在你看来是完全正确的,你觉得你没有亏欠任何人,是别人没有给你机会给你平台,但是你完全没有想过——既然A这样的任劳任怨,努力学习的人在市场上,而且机会的总量又是有限的,那怎么可能会有人把机会给你而不给A呢?

所以你现在是你,A现在是A,没有什么好抱怨的。

哈佛关于气场的培养

哈佛关于气场的培养:

 

一,沉稳:

(1)不要随便显露你的情绪。

(2)不要逢人就诉说你的困难和遭遇

(3)在征询别人的意见之前,自己先思考,但不要先讲。

(4)不要一有机会就唠叨你的不满。

(5)重要的决定尽量有别人商量,最好隔一天再发布。

(6)讲话不要有任何的慌张,走路也是。

 

二,细心 :

(1)对身边发生的事情,常思考它们的因果关系。

(2)对做不到位的执行问题,要发掘它们的根本症结。

(3)对习以为常的做事方法,要有改进或优化的建议。

(4)做什么事情都要养成有条不紊和井然有序的习惯。

(5)经常去找几个别人看不出来的毛病或弊端。

(6)自己要随时随地对有所不足的地方补位。

 

三,胆识:

(1)不要常用缺乏自信的词句 。

(2)不要常常反悔,轻易推翻已经决定的事。

(3)在众人争执不休时,不要没有主见。

(4)整体氛围低落时,你要乐观、阳光。

(5)做任何事情都要用心,因为有人在看着你。

(6)事情不顺的时候,歇口气,重新寻找突破口,就结束也要干净利落。

 

四,大度:

(1)不要刻意把有可能是伙伴的人变成对手。

(2)对别人的小过失、小错误不要斤斤计较。

(3)在金钱上要大方,学习三施(财施、法施、无畏施)

(4)不要有权力的傲慢和知识的偏见。

(5)任何成果和成就都应和别人分享。

(6)必须有人牺牲或奉献的时候,自己走在前面。

 

五,诚信:

(1)做不到的事情不要说,说了就努力做到。

(2)虚的口号或标语不要常挂嘴上。

(3)针对客户提出的“不诚信”问题, 拿出改善的方法。

(4)停止一切“不道德”的手段。

(5)耍弄小聪明,要不得!

(6)计算一下产品或服务的诚信代 价,那就是品牌成本。

 

六,担当:

(1)检讨任何过失的时候,先从自身或自己人开始反省。

(2)事项结束后,先审查过错,再列述功劳。

(3)认错从上级开始,表功从下级启动

(4)着手一个计划,先将权责界定清楚,而且分配得当。

(5)对“怕事”的人或组织要挑明了说 。

The Tumblr Architecture Yahoo Bought For A Cool Billion Dollars

原文:http://highscalability.com/blog/2013/5/20/the-tumblr-architecture-yahoo-bought-for-a-cool-billion-doll.html

It’s being reported Yahoo bought Tumblr for $1.1 billion. You may recall Instagram was profiled on HighScalabilityand they were also bought by Facebook for a ton of money. A coincidence? You be the judge.

Just what is Yahoo buying? The business acumen of the deal is not something I can judge, but if you are doing due diligence on the technology then Tumblr would probably get a big thumbs up. To see why, please keep on reading…

With over 15 billion page views a month Tumblr has become an insanely popular blogging platform. Users may like Tumblr for its simplicity, its beauty, its strong focus on user experience, or its friendly and engaged community, but like it they do.

Growing at over 30% a month has not been without challenges. Some reliability problems among them. It helps to realize that Tumblr operates at surprisingly huge scales: 500 million page views a day, a peak rate of ~40k requests per second, ~3TB of new data to store a day, all running on 1000+ servers.

One of the common patterns across successful startups is the perilous chasm crossing from startup to wildly successful startup. Finding people, evolving infrastructures, servicing old infrastructures, while handling huge month over month increases in traffic, all with only four engineers, means you have to make difficult choices about what to work on. This was Tumblr’s situation. Now with twenty engineers there’s enough energy to work on issues and develop some very interesting solutions.

Tumblr started as a fairly typical large LAMP application. The direction they are moving in now is towards a distributed services model built around Scala, HBase, Redis, Kafka, Finagle,  and an intriguing cell based architecture for powering their Dashboard. Effort is now going into fixing short term problems in their PHP application, pulling things out, and doing it right using services.

The theme at Tumblr is transition at massive scale. Transition from a LAMP stack to a somewhat bleeding edge stack. Transition from a small startup team to a fully armed and ready development team churning out new features and infrastructure. To help us understand how Tumblr is living this theme is startup veteran Blake Matheny, Distributed Systems Engineer at Tumblr. Here’s what Blake has to say about the House of Tumblr:

Site:  http://www.tumblr.com/

Stats

  • 500 million page views a day
  • 15B+ page views month
  • ~20 engineers
  • Peak rate of ~40k requests per second
  • 1+ TB/day into Hadoop cluster
  • Many TB/day into MySQL/HBase/Redis/Memcache
  • Growing at 30% a month
  • ~1000 hardware nodes in production
  • Billions of page visits per month per engineer
  • Posts are about 50GB a day. Follower list updates are about 2.7TB a day.
  • Dashboard runs at a million writes a second, 50K reads a second, and it is growing.

Software

  • OS X for development, Linux (CentOS, Scientific) in production
  • Apache
  • PHP, Scala, Ruby
  • Redis, HBase, MySQL
  • Varnish, HA-Proxy, nginx,
  • Memcache, Gearman, Kafka, Kestrel, Finagle
  • Thrift, HTTP
  • Func – a secure, scriptable remote control framework and API
  • Git, Capistrano, Puppet, Jenkins

Hardware

  • 500 web servers
  • 200 database servers (many of these are part of a spare pool we pulled from for failures)
    • 47 pools
    • 30 shards
  • 30 memcache servers
  • 22 redis servers
  • 15 varnish servers
  • 25 haproxy nodes
  • 8 nginx
  • 14 job queue servers (kestrel + gearman)

Architecture

  • Tumblr has a different usage pattern than other social networks.
    • With 50+ million posts a day, an average post goes to many hundreds of people. It’s not just one or two users that have millions of followers. The graph for Tumblr users has hundreds of followers. This is different than any other social network and is what makes Tumblr so challenging to scale.
    • #2 social network in terms of time spent by users. The content is engaging. It’s images and videos. The posts aren’t byte sized. They aren’t all long form, but they have the ability. People write in-depth content that’s worth reading so people stay for hours.
    • Users form a connection with other users so they will go hundreds of pages back into the dashboard to read content. Other social networks are just a stream that you sample.
    • Implication is that given the number of users, the average reach of the users, and the high posting activity of the users, there is a huge amount of updates to handle.
  • Tumblr runs in one colocation site. Designs are keeping geographical distribution in mind for the future.
  • Two components to Tumblr as a platform: public Tumblelogs and Dashboard
    • Public Tumblelog is what the public deals with in terms of a blog. Easy to cache as its not that dynamic.
    • Dashboard is similar to the Twitter timeline. Users follow real-time updates from all the users they follow.
      • Very different scaling characteristics than the blogs. Caching isn’t as useful because every request is different, especially with active followers.
      • Needs to be real-time and consistent. Should not show stale data. And it’s a lot of data to deal with. Posts are only about 50GB a day. Follower list updates are 2.7TB a day. Media is all stored on S3.
    • Most users leverage Tumblr as tool for consuming of content. Of the 500+ million page views a day, 70% of that is for the Dashboard.
    • Dashboard availability has been quite good. Tumblelog hasn’t been as good because they have a legacy infrastructure that has been hard to migrate away from. With a small team they had to pick and choose what they addressed for scaling issues.

Old Tumblr

  • When the company started on Rackspace it gave each custom domain blog an A record. When they outgrew Rackspace there were too many users to migrate. This is 2007. They still have custom domains on Rackspace. They route through Rackspace back to their colo space using HAProxy and Varnish. Lots of legacy issues like this.
  • A traditional LAMP progression.
    • Historically developed with PHP. Nearly every engineer programs in PHP.
    • Started with a web server, database server and a PHP application and started growing from there.
    • To scale they started using memcache, then put in front-end caching, then HAProxy in front of the caches, then MySQL sharding. MySQL sharding has been hugely helpful.
    • Use a squeeze everything out of a single server approach. In the past year they’ve developed a couple of backend services in C: an ID generator and Staircar, using Redis to power Dashboard notifications
  • The Dashboard uses a scatter-gather approach. Events are displayed when a user access their Dashboard. Events for the users you follow are pulled and displayed. This will scale for another 6 months. Since the data is time ordered sharding schemes don’t work particularly well.

New Tumblr

  • Changed to a JVM centric approach for hiring and speed of development reasons.
  • Goal is to move everything out of the PHP app into services and make the app a thin layer over services that does request authentication, presentation, etc.
  • Scala and Finagle Selection
    • Internally they had a lot of people with Ruby and PHP experience, so Scala was appealing.
    • Finagle was a compelling factor in choosing Scala. It is a library from Twitter. It handles most of the distributed issues like distributed tracing, service discovery, and service registration. You don’t have to implement all this stuff. It just comes for free.
    • Once on the JVM Finagle provided all the primitives they needed (Thrift, ZooKeeper, etc).
    • Finagle is being used by Foursquare and Twitter. Scala is also being used by Meetup.
    • Like the Thrift application interface. It has really good performance.
    • Liked Netty, but wanted out of Java, so Scala was a good choice.
    • Picked Finagle because it was cool, knew some of the guys, it worked without a lot of networking code and did all the work needed in a distributed system.
    • Node.js wasn’t selected because it is easier to scale the team with a JVM base. Node.js isn’t developed enough to have standards and best practices, a large volume of well tested code. With Scala you can use all the Java code. There’s not a lot of knowledge of how to use it in a scalable way and they target 5ms response times, 4 9s HA, 40K requests per second and some at 400K requests per second. There’s a lot in the Java ecosystem they can leverage.
  • Internal services are being shifted from being C/libevent based to being Scala/Finagle based.
  • Newer, non-relational data stores like HBase and Redis are being used, but the bulk of their data is currently stored in a heavily partitioned MySQL architecture. Not replacing MySQL with HBase.
  • HBase backs their URL shortner with billions of URLs and all the historical data and analytics. It has been rock solid. HBase is used in situations with high write requirements, like a million writes a second for the Dashboard replacement.  HBase wasn’t deployed instead of MySQL because they couldn’t bet the business on HBase with the people that they had, so they started using it with smaller less critical path projects to gain experience.
  • Problem with MySQL and sharding for time series data is one shard is always really hot. Also ran into read replication lag due to insert concurrency on the slaves.
  • Created a common services framework.
    • Spent a lot of time upfront solving operations problem of how to manage a distributed system.
    • Built a kind of Rails scaffolding, but for services. A template is used to bootstrap services internally.
    • All services look identical from an operations perspective. Checking statistics, monitoring, starting and stopping all work the same way for all services.
    • Tooling is put around the build process in SBT (a Scala build tool) using plugins and helpers to take care of common activities like tagging things in git, publishing to the repository, etc. Most developers don’t have to get in the guts of the build system.
  • Front-end layer uses HAProxy. Varnish might be hit for public blogs. 40 machines.
  • 500 web servers running Apache and their PHP application.
  • 200 database servers. Many database servers are used for high availability reasons. Commodity hardware is used an the MTBF is surprisingly low. Much more hardware than expected is lost so  there are many spares in case of failure.
  • 6 backend services to support the PHP application. A team is dedicated to develop the backend services. A new service is rolled out every 2-3 weeks. Includes dashboard notifications, dashboard secondary index, URL shortener, and a memcache proxy to handle transparent sharding.
  • Put a lot of time and effort and tooling into MySQL sharding. MongoDB is not used even though it is popular in NY (their location). MySQL can scale just fine..
  • Gearman, a job queue system, is used for long running fire and forget type work.
  • Availability is measured in terms of reach. Can a user reach custom domains or the dashboard? Also in terms of error rate.
  • Historically the highest priority item is fixed. Now failure modes are analyzed and addressed systematically. Intention is to measure success from a user perspective and an application perspective. If part of a request can’t be fulfilled that is account for
  • Initially an Actor model was used with Finagle, but that was dropped.  For fire and forget work a job queue is used. In addition, Twitter’s utility library contains a Futuresimplementation and services are implemented in terms of futures. In the situations when a thread pool is needed futures are passed into a future pool. Everything is submitted to the future pool for asynchronous execution.
  • Scala encourages no shared state. Finagle is assumed correct because it’s tested by Twitter in production. Mutable state is avoided using constructs in Scala or Finagle. No long running state machines are used. State is pulled from the database, used, and writte n back to the database. Advantage is developers don’t need to worry about threads or locks.
  • 22 Redis servers. Each server has 8 – 32 instances so 100s of Redis instances are used in production.
    • Used for backend storage for dashboard notifications.
    • A notification is something  like a user liked your post. Notifications show up in a user’s dashboard to indicate actions other users have taken on their content.
    • High write ratio made MySQL a poor fit.
    • Notifications are ephemeral so it wouldn’t be horrible if they were dropped, so Redis was an acceptable choice for this function.
    • Gave them a chance to learn about Redis and get familiar with how it works.
    • Redis has been completely problem free and the community is great.
    • A Scala futures based interface for Redis was created. This functionality is now moving into their Cell Architecture.
    • URL shortener uses Redis as the first level cache and HBase as permanent storage.
    • Dashboard’s secondary index is built around Redis.
    • Redis is used as Gearman’s persistence layer using a memcache proxy built using Finagle.
    • Slowly moving from memcache to Redis. Would like to eventually settle on just one caching service. Performance is on par with memcache.

Internal Firehose

  • Internally applications need access to the activity stream. An activity steam is information about users creating/deleting posts, liking/unliking posts, etc.  A challenge is to distribute so much data in real-time. Wanted something that would scale internally and that an application ecosystem could reliably grow around. A central point of distribution was needed.
  • Previously this information was distributed using Scribe/Hadoop. Services would log into Scribe and begin tailing and then pipe that data into an app. This model stopped scaling almost immediately, especially at peak where people are creating 1000s of posts a second. Didn’t want people tailing files and piping to grep.
  • An internal firehose was created as a message bus. Services and applications talk to the firehose via Thrift.
  • LinkedIn’s Kafka is used to store messages. Internally consumers use an HTTP stream to read from the firehose. MySQL wasn’t used because the sharding implementation is changing frequently so hitting it with a huge data stream is not a good idea.
  • The firehose model is very flexible, not like Twitter’s firehose in which data is assumed to be lost.
    • The firehose stream can be rewound in time. It retains a week of data. On connection it’s possible to specify the point in time to start reading.
    • Multiple clients can connect and each client won’t see duplicate data. Each client has a client ID. Kafka supports a consumer group idea. Each consumer in a consumer group gets its own messages and won’t see duplicates. Multiple clients can be created using the same consumer ID and clients won’t see duplicate data. This allows data to be processed independently and in parallel. Kafka uses ZooKeeper to periodically checkpoint how far a consumer has read.

Cell Design For Dashboard Inbox

  • The current scatter-gather model for providing Dashboard functionality has very limited runway. It won’t last much longer.
    • The solution is to move to an inbox model implemented using a Cell Based Architecture that is similar to Facebook Messages.
    • An inbox is the opposite of scatter-gather. A user’s dashboard, which is made up posts from followed users and actions taken by other users,  is logically stored together in time order.
    • Solves the scatter gather problem because it’s an inbox. You just ask what is in the inbox so it’s less expensive then going to each user a user follows. This will scale for a very long time.
  • Rewriting the Dashboard is difficult. The data has a distributed nature, but it has a transactional quality, it’s not OK for users to get partial updates.
    • The amount of data is incredible. Messages must be delivered to hundreds of different users on average which is a very different problem than Facebook faces. Large date + high distribution rate + multiple datacenters.
    • Spec’ed at a million writes a second and 50K reads a second. The data set size is 2.7TB of data growth with no replication or compression turned on. The million writes a second is from the 24 byte row key that indicates what content is in the inbox.
    • Doing this on an already popular application that has to be kept running.
  • Cells
    • A cell is a self-contained installation that has all the data for a range of users. All the data necessary to render a user’s Dashboard is in the cell.
    • Users are mapped into cells. Many cells exist per data center.
    • Each cell has an HBase cluster, service cluster, and Redis caching cluster.
    • Users are homed to a cell and all cells consume all posts via firehose updates.
    • Each cell is Finagle based and populates HBase via the firehose and service requests over Thrift.
    • A user comes into the Dashboard, users home to a particular cell, a service node reads their dashboard via HBase, and passes the data back.
    • Background tasks consume from the firehose to populate tables and process requests.
    • A Redis caching layer is used for posts inside a cell.
  • Request flow: a user publishes a post, the post is written to the firehose, all of the cells consume the posts and write that post content to post database, the cells lookup to see if any of the followers of the post creator are in the cell, if so the follower inboxes are updated with the post ID.
  • Advantages of cell design:
    • Massive scale requires parallelization and parallelization requires components be isolated from each other so there is no interaction. Cells provide a unit of parallelization that can be adjusted to any size as the user base grows.
    • Cells isolate failures. One cell failure does not impact other cells.
    • Cells enable nice things like the ability to test upgrades, implement rolling upgrades, and test different versions of software.
  • The key idea that is easy to miss is:  all posts are replicated to all cells.
    • Each cell stores a single copy of all posts. Each cell can completely satisfy a Dashboard rendering request. Applications don’t ask for all the post IDs and then ask for the posts for those IDs. It can return the dashboard content for the user. Every cell has all the data needed to fulfill a Dashboard request without doing any cross cell communication.
    • Two HBase tables are used: one that stores a copy of each post. That data is small compared to the other table which stores every post ID for every user within that cell. The second table tells what the user’s dashboard looks like which means they don’t have to go fetch all the users a user is following. It also means across clients they’ll know if you read a post and viewing a post on a different device won’t mean you read the same content twice. With the inbox model state can be kept on what you’ve read.
    • Posts are not put directly in the inbox because the size is too great. So the ID is put in the inbox and the post content is put in the cell just once. This model greatly reduces the storage needed while making it simple to return a time ordered view of an users inbox. The downside is each cell contains a complete copy of call posts. Surprisingly posts are smaller than the inbox mappings. Post growth per day is 50GB per cell, inbox grows at 2.7TB a day. Users consume more than they produce.
    • A user’s dashboard doesn’t contain the text of a post, just post IDs, and the majority of the growth is in the IDs.
    • As followers change the design is safe because all posts are already in the cell. If only follower posts were stored in a cell then cell would be out of date as the followers changed and some sort of back fill process would be needed.
    • An alternative design is to use a separate post cluster to store post text. The downside of this design is that if the cluster goes down it impacts the entire site.  Using the cell design and post replication to all cells creates a very robust architecture.
  • A user having millions of followers who are really active is handled by selectively materializing user feeds by their access model (see Feeding Frenzy).
    • Different users have different access models and distribution models that are appropriate. Two different distribution modes: one for popular users and one for everyone else.
    • Data is handled differently depending on the user type. Posts from active users wouldn’t actually be published, posts would selectively materialized.
    • Users who follow millions of users are treated similarly to users who have millions of followers.
  • Cell size is hard to determine. The size of cell is the impact site of a failure. The number of users homed to a cell is the impact. There’s a tradeoff to make in what they are willing to accept for the user experience and how much it will cost.
  • Reading from the firehose is the biggest network issue. Within a cell the network traffic is manageable.
  • As more cells are added cells can be placed into a cell group that reads from the firehose and then replicates to all cells within the group. A hierarchical replication scheme. This will also aid in moving to multiple datacenters.

On Being A Startup In New York

  • NY is a different environment. Lots of finance and advertising. Hiring is challenging because there’s not as much startup experience.
  • In the last few years NY has focused on helping startups. NYU and Columbia have programs for getting students interesting internships at startups instead of just going to Wall Street. Mayor Bloomberg is establishing a local campus focused on technology.

Team Structure

  • Teams: infrastructure, platform, SRE, product, web ops, services.
  • Infrastructure: Layer 5 and below. IP address and below, DNS, hardware provisioning.
  • Platform: core app development, SQL sharding, services, web operations.
  • SRE: sits between service team and web ops team. Focused on more immediate needs in terms of reliability and scalability.
  • Service team: focuses on things that are slightly more strategic, that are a month or two months out.
  • Web ops: responsible for problem detection and response, and tuning.

Software Deployment

  • Started with a set of rsync scripts that distributed the PHP application everywhere. Once the number of machines reached 200 the system started having problems, deploys took a long time to finish and machines would be in various states of the deploy process.
  • The next phase built the deploy process (development, staging, production) into their service stack using Capistrano. Worked for services on dozens of machines, but by connecting via SSH it started failing again when deploying to hundreds of machines.
  • Now a piece of coordination software runs on all machines. Based around Func from RedHat, a lightweight API for issuing commands to hosts. Scaling is built into Func.
  • Build deployment is over Func by saying do X on a set of hosts, which avoids SSH. Say you want to deploy software on group A. The master reaches out to a set of nodes and runs the deploy command.
  • The deploy command is implemented via Capistrano. It can do a git checkout or pull from the repository. Easy to scale because they are talking HTTP. They like Capistrano because it supports simple directory based versioning that works well with their PHP app. Moving towards versioned updates, where each directory contains a SHA so it’s easy to check if a version is correct.
  • The Func API is used to report back status, to say these machines have these software versions.
  • Safe to restart any of their services because they’ll drain off connections and then restart.
  • All features run in dark mode before activation.

Development

  • Started with the philosophy that anyone could use any tool that they wanted, but as the team grew that didn’t work. Onboarding new employees was very difficult, so they’ve standardized on a stack so they can get good with those, grow the team quickly, address production issues more quickly, and build up operations around them.
  • Process is roughly Scrum like. Lightweight.
  • Every developer has a preconfigured development machine. It gets updates via Puppet.
  • Dev machines can roll changes, test, then roll out to staging, and then roll out to production.
  • Developers use vim and Textmate.
  • Testing is via code reviews for the PHP application.
  • On the service side they’ve implemented a testing infrastructure with commit hooks, Jenkins, and continuous integration and build notifications.

Hiring Process

  • Interviews usually avoid math, puzzles, and brain teasers. Try to ask questions focused on work the candidate will actually do. Are they smart? Will they get stuff done? But measuring “gets things done” is difficult to assess. Goal is to find great people rather than keep people out.
  • Focused on coding. They’ll ask for sample code. During phone interviews they will use Collabedit to write shared code.
  • Interviews are not confrontational, they just want to find the best people. Candidates get to use all their tools, like Google, during the interview. The idea is developers are at their best when they have tools so that’s how they run the interviews.
  • Challenge is finding people that have the scaling experience they require given Tumblr’s traffic levels. Few companies in the world are working on the problems they are.
    • Example, for a new ID generator they needed A JVM process to generate service responses in less the 1ms at a rate at 10K requests per second with a 500 MB RAM limit with High Availability. They found the serial collector gave the lowest latency for this particular work load. Spent a lot of time on JVM tuning.
  • On the Tumblr Engineering Blog they’ve posted memorials giving their respects for the passing of Dennis Ritchie & John McCarthy. It’s a geeky culture.

Lessons Learned

  • Automation everywhere.
  • MySQL (plus sharding) scales, apps don’t.
  • Redis is amazing.
  • Scala apps perform fantastically.
  • Scrap projects when you aren’t sure if they will work.
  • Don’t hire people based on their survival through a useless technological gauntlet.  Hire them because they fit your team and can do the job.
  • Select a stack that will help you hire the people you need.
  • Build around the skills of your team.
  • Read papers and blog posts. Key design ideas like the cell architecture and selective materialization were taken from elsewhere.
  • Ask your peers. They talked to engineers from Facebook, Twitter, LinkedIn about their experiences and learned from them. You may not have access to this level, but reach out to somebody somewhere.
  • Wade, don’t jump into technologies. They took pains to learn HBase and Redis before putting them into production by using them in pilot projects or in roles where the damage would be limited.

I’d like to thank Blake very much for the interview. He was very generous with his time and patient with his explanations. Please contact me if you would like to talk about having your architecture profiled.