Category Archives: 科技评论

[得到大学课程作业] 如何设计云服务的计费策略?

  不仅游戏,所有提供虚拟产品的场合都需要应用“造物者”思维模型,制衡各方利益,引导体系演进。我曾负责设计过一个复杂云服务产品的计费策略,深有体会。

  简单介绍一下,这个云服务主要用于对上千张表、上P的数据进行复杂的计算。典型的一次计算任务,往往占用上万节点几十个小时,说耗费的存储、计算和下载流量成本超过几十万元。麻烦在于,系统不是独占的,往往有上百个用户的不同计算任务混在一起。

  如何计费?常规思路往往从技术实现角度拆分,把一次计算任务占用的进程、内存,以及中间IO交换的数字都拿出来,分摊到对应的CPU、内存、网络设备和磁盘的折旧成本去。然后再加上一定的利润率。

  然而,想深一点的话,这种计费策略并不好:

  1> 从用户角度看:“运行时间”这个变量用户失去控制。海量数据的分布式计算有特殊之处:很可能第一次运行用10分钟,重跑一下,调度到另一个节点,就用了12分钟。相同的计算任务,有时收1块,有时收1.2块,用户疯掉了。

  2> 从平台角度看:如果技术团队优化了底层系统,把计算速度加快1倍,收入就少了50%。这会让平台方丧失优化动力。

  于是退回原点,先定义什么是好的计费策略:

  1. 基于统计,简单可解释:基于统计;尽量简化;输入参数用户可控;

  2. 可预期,可重复:实际运行前就能算出花费;同样的任务重跑,价格不变;

  3. 正引导性:各个角色做好事(优化自己的代码)不受惩罚,最好获得奖励。

  一个例子是手机话费:两个人面对面手机通话,与一个在城南一个在城北通话,实际成本肯定不一样。如果运营商按照通信链路经过了几个路由器、几次转发来计费,用户就晕倒了。所以手机计费策略采用阶梯的、区域的、分时的模型,符合上面3条原则。

  最终的计费模型主要由“输入数据量 * 复杂度”组成,其中“复杂度”是一个简单的阶梯表,完全取决于用户计算作业的难易程度。(更多参考 http://wangleheng.com/2014/07/odps_meter_money/

  几乎同时,谷歌公司推出了同类产品Google BigQuery,计费方案和我们几乎一样。他们甚至在官网上贴了一篇BLOG,详细描述了计量计费模型的“设计哲学”。大家彼此完全独立思考,得出的方法论和最终模型却殊途同归,这很有趣。

  总而言之,无论是复杂云服务、电子商务平台……都需要谨慎设计利益策略:尽可能简化规则,保证统计公平性,对“好事”建立正反馈。必要时,不妨参考经典电信服务的计量计费策略。

[得到大学课程作业] 投资者思维的局限性

  这一期4个思维模型都和投资者有关,重点都是建立模型并遵守纪律。如果在复杂背景下进行跨领域博弈,这都是好工具。然而,大多数人不是职业投资者,最好弄清楚模型的适用边界,保证独立思考,以防东施效颦。

  亲身经历,作为创业企业的联合创始人,我就有几次郑重提醒自己的CEO:你负责融资,和VC打交道很多,似乎被他们的模型“过训练”了。

  举个例子,这些年很多风险投资人都在强调“网络效应”的概念:不仅仅企业和客户存在买卖关系,客户之间也能互相连接,进而增加系统粘性。对资本而言,这种生意可以通过烧钱进行催化,最终通过网络规模建立垄断。很多投资机构把“是否有网络效应”写入模型,以决定标的估值。

  “网络效应”的思路适于 toC 基础服务。进入其他领域,例如 toB 企业级服务,情况就变了:

  1. 从业务逻辑而言,企业不太可能因为同业或上下游的公司在用某个软件,就非用它不可。甚至恰恰因为是同类企业,所以存在关键需求的差异:竞争对手强调品牌营销,我强调供应链降成本……这意味着,对手的软件供应商未必合适我,应该寻找符合自己战略的解决方案。toB 采购更强调“标杆效应”:供应商的方案与企业本身的策略一致,且已有成熟的落地案例。

  2. 从产品逻辑而言,“网络效应”本质还是增加迁移成本。但并非只有这一条路能增加产品粘度。大多情况下,做好功能和服务,解决客户问题,让他没有离开的动力,就够了。尤其是toB 场景,没有企业会乱折腾,轻易迁移软件系统。

  回到投资者的角度。他们喜欢建模,简单点说,就是外行总结过去的成功经验,以筛选更多投资机会。模型就意味着抽象概括。投资者有机会多次下注,只要掌控概率就够了,创业者却是All in,因此必须洞察每个关键细节,细节是魔鬼。

  淘宝免费,不符合“产品必须收费”的陈规;京东做物流,不符合“尽量做轻”的陈规……随后,投资人跟随成功创业者修改了自己的模型,然后又对下一代创业者说:“你必须XXX,我才投你”。

  总结一下,专业人士要相信自己在客户现场获得的洞察,不要屈从陈规俗见,不要被投资界的模型过分“驯化”,导致动作走样。我们最该从巴菲特和索罗斯那里学到的,正是独立思考本身。

[得到大学课程作业] 阿里云:一次成功的转型

一、背景

  阿里云目前占国内云计算市场50%以上,全球三强,近几季度保持高增速。

  然而2010年常见说法是:百度擅长技术,腾讯擅长产品,阿里擅长运营。阿里的技术形象并不吸引人。

  如何从电商公司转型为数据公司?这期间,我恰好在阿里云大数据团队做产品经理,分享一点“转型者”的亲身体会。

二、做了什么

1. 明确“数据为王”,巧妙包容原有主力业务

  2010年马云在国外讲演,“我们的云和别人不一样,核心是数据。”今天看来,他在试图解释“大数据”概念,此时big data这个词还没有在美国诞生。阿里内部很早建立共识:判断一件事是否重要,标准是“数据”。

  “数据为王”的战略与“让天下没有难做的生意”企业使命不矛盾。同时新的价值体系能包容原有业务:什么业务能产生含金量最高的数据呢?淘宝、支付宝……因此原有主力团队也会兴奋的加入进来,重新从数据的角度讲故事。

2. 用各种方法保护新业务

  早期阿里云不成熟。广为人知的事是2012年内网几千层楼的帖子,对王坚博士万炮齐轰。当时公司做了几件关键的事:

  1> 把阿里云和其他团队隔开。(如果微信团队没和总部隔开会怎么样?)

  2> 培养生态系统。团队被反复强调的纪律是,如果客户在做同样的研发,不要抢饭碗,往后退,一直退到没人愿意做的苦活累活。只要他们愿意迁移到云上来。

  3> 最难的时刻动用组织手段。例如让陆兆禧当CDO(首席数据官),内部都知道老陆已被定为下一任CEO。

  最终,发动所有协作力量,把主要数据和业务都迁移到了云上。

3. 构建数据中台,上云没有回头路

  业务上了云,如何保证局面不后退?最关键的是建立数据中台。前台业务产生的核心数据,全部收拢到一处。业务只有留在云上,才能获得基础设施和关键数据的支持。具体内容媒体报道很多,搜索“5K项目”。

三、结论

  阿里云是一次成功转型。个人认为以下因素是关键:

  1> 明确“数据为王”的新价值体系,巧妙包容原有业务;

  2> 用各种手段保护新业务,建立协同;

  3> 建立数据中台,让业务没有回头路。

  转型的复杂性要高于初创。要谨慎设计,要耐心推进,要在艰难时刻顶住压力。

用移动数据预测特斯拉产能

  之前介绍过Bloomberg通过网上抓取VIN(车辆识别码)估算Tesla Model 3的每周产量(今天的公众号也会转发)。最近又看到Thasos的另一种手段。

  Thasos Group分析了特斯拉厂房范围内的手机信号,显示通宵轮班在6月到10月之间增加了30%,他们与对冲基金客户分享了数据。特斯拉7月宣布 Model 3产量几乎翻了一番,这一消息使得该公司股价上涨9.1%,而Thasos的客户则能提前预测这一结果。

  8月份,特斯拉在美国市场的销量超过了奔驰、宝马和奥迪。北京这里特斯拉也开始满街跑。这特别像诺基亚被iPhone干掉之前的情形。不管短期内有多少问题,长期看特斯拉一定会更好,这是本质决定的。

  看了一下官方网站,Thasos拥有一个高品质的手机位置数据库,可以做很多事。例如为梅西百货(Macy’s)、诺德斯特龙(Nordstrom)、Dillard’s(狄乐百货)和西尔斯百货(Sears)进行同店销售额和同店交易额的增长预测,平均误差不超过0.7%。Thasos从大约1000个APP获取移动设备的地理位置,这些APP一般都是位置相关的产品,例如天气预报或行车路线。

大航海时代的全球人才竞争,两条史料

  里斯本国家档案馆记载,1627年3月6日,负责印度果阿的火炮生产的葡印商人,亲自就两名铸铁经验丰富的中国技师的行踪禀告葡萄牙国王,希望能够获得准许对关键工程技术人才予以优待。

  康华丽号风帆巡洋舰1812年在印度建造。总工程师Jamsetjee Bomanjee是印度人,出身造船世家,已是第5代担任首席造舰师(Master Shipbuilder)。30年后清朝在康华丽号上签署《南京条约》,Jamsetjee Bomanjee的儿子已当上第6代首席造舰师。

  可以对比之前提到过的,徐光启和戚继光时代的几何和火器。归根到底,最大的问题并不是武器制造,而是系统对人才和知识的兼容性。

共享单车和店面租金

  链家的数据分析很有意思:随着共享单车的出现,地铁口周边的不动产租金在下降,三公里半径的租金却在上升,逐步跟地铁周边的租金拉平。

  有一个反过来的例子,美国Thasos group利用移动数据对商业不动产进行金融分析。Thasos拥有一个高品质的手机位置数据库,从大约1000个APP获取移动设备的地理位置。拥有这个数据以后,就可以对商业地产的人流、销售、租金进行非常准确的评估和预测。

Tesla Model 3的生产率

  特斯拉产能爬坡,已经快变成娱乐事件了。马斯克又是换供应商,又是搬到工厂睡,又是大裁员,又是在大帐篷里搭建新流水线,又是怼投资人……来回折腾。

  Bloomberg有个叫 Tesla Model 3 Tracker 的页面挺好玩,开发的程序员是Tom Randall和Dean Halford。

  他们从各种网上来源,例如高速公路安全管理页面、社交网络、特斯拉用户论坛……抓取新增的特斯拉汽车的VIN(车辆识别码),估算Tesla Model 3的每周产量。此前曾有Tesla内部员工说这个数学模型估算的还挺准的。

  从下面这张图可以发现,此前几个月Tesla Model 3的产能一直在稳步上升。2月底的时候达到了每周917台,但是最近两周生产率突然剧烈下降,本周跌到了599台。到网上搜了搜,上周Tesla Model 3生产线升级,刚刚新增了自动安装电池的设备,还在调试中。

  7月3日更新:今天突然满屏幕都是Model 3产能终于超过5000台/每周的消息。查了一下,Q2共生产28578辆,交付18440辆。最后7天下线超过7000台(各种车型总和,不只是Model 3)。

GeneDock研发团队的一些方法论

  逼着自己上来写BLOG。最近工作强度非常大,回到家吃完饭洗完碗,真的手指尖都不想动一下。不过工作有进展,人有成长,心情还不错。今天冒着大雨回家,浑身湿透,但是心里一动:“两年前的今天我心情很糟,现在虽然累得像条狗,却很充实,看来这次创业是对了。”

  创业以来,感觉还算顺利。所谓好运气,部分源于GeneDock团队有一套自洽的逻辑。创业和投资说到底拼的是世界观,你对现实世界的某个局部有独特的洞见。这里面有些关于技术产品,有些关于团队管理,有些关于商务销售。

  这篇BLOG再总结一下GeneDock研发的方法论。算是呼应一年前的那篇《思考:如何开发应用平台》,对其做一些补充或再次强调。

一、彻底信仰API

  Alex Iskold说:“API代表公司的业务本质……思考API实际上就是思考公司的未来……”

  绝对赞同,一年多前我在社交网络发过一条对国内一些所谓基因云的吐槽:“不是做个Web页面就有资格叫云计算的。前端若不提供RESTful API、编程语言SDK以及UNIX风格的CLI工具包,后端若没有可拓展的分布式架构、防单点故障的failover机制……就别觍着脸自称云计算了,这只是一个网站而已”。这话似乎刺痛了某些人。

  GeneDock刚刚对外开放了第一批Workflow和Task有关的11个API。欢迎大家试用,这里是API-Reference文档。如果单从Web Service的设计这一点看,我们的产品领先于国内外友商。

二、To B 的产品逻辑:别抖机灵

  To B 产品和 To C 产品有很多业务差异。To B 是给专家甚至专家团队用的软件,本质上在卖你对行业的独特洞见,在卖你的工作哲学。例如,当年SAP的ERP软件最成功,因为他们最理解德国制造的业务逻辑;再如,Salesforce在卖的是销售团队的方法论;而GitHub实际在卖他们对软件工程的理解:Bug管理、版本管理、Code Review……

  另一方面,To B 和To C 其实都是给人用的软件。从设计和研发的方法论来看,并没什么本质区别。GeneDock产品经理何荣惠(在阿里云的时候程序员们昵称“神仙姐姐”)在知乎回答过“to B 的产品经理和 to C 的产品经理有什么差别?”,我觉得写得很好。

  总之。To B 产品,抖机灵没用,保持克制和敬畏。躬身入局,琢磨清楚基因数据传输、存储、分析、应用的所有业务场景。

  我们刚刚上线的企业账号功能,对很多团队都有用。GeneDock官方BLOG对此有描述,推荐大家看一下。

三、坚守软件工程底线

  GeneDock只雇用最好的程序员。好程序员必须能熟练应用软件工程的成功方法论。

  至于什么是好的软件工程,一年前都写过了:“好的软件工程实践,决定了技术团队的层次。Github用的怎么样、Bug管理怎么样、代码审核是否严格、发布升级是否自动化、有没有单元和集成测试……到一个技术团队里呆几个小时,鼻子闻一闻,就知道几斤几两。技术团队如果这些基本功不好,摩擦力会越来越大。”

  不只是提高自己内部生产率,GeneDock还想把数据生产的最佳实践推广到整个行业,成为生物信息行业的GitHub。我们正在优化配置和调试的体验,总结GeneDock生信团队的流程规范。后面会不断放出软件工程培训文档和配套工具,让生物信息程序员们效率更高,更专业,工作更有价值。

GeneDock架构师介绍分布式基本原理

  GeneDock首席架构师陈昕刚刚在公司网站上发表了一篇BLOG,介绍了有关分布式系统的基本知识,例如一致性问题、FLP不可能性原理和CAP定理。推荐大家看一看,了解客观限制,免得试图制造永动机。

  原文地址如下:https://www.genedock.com/blog/2016/05/27/20160527_distributed_system/

Max Levchin

  继续八卦,这次是Max Levchin。他是Paypal黑帮的关键人物,23岁的CTO,重要性仅次于Elon Musk和Peter Thiel。

  之前在《支付战争》的读后感里提过他。我又去翻了翻Founder at Work,原来第一章就是对Levchin的采访。其他信息来源包括维基百科,以及他在Quora上回答的问题

创业者  支付战争

  Levchin 16岁从乌克兰移民到美国,数学天赋极高。他擅长安全加密算法,所以创立了Fieldlink公司,想做移动设备的安全技术供应商。后来找到Peter Thiel当合伙人和CEO(Levchin只喜欢和聪明人共事,Peter Thiel小时候得过加州数学竞赛第一名)。Levchin对Paypal创业的回忆很少涉及那些著名的运营手段(直接给新客户10美元补贴等),也没怎么提Elon Musk和Peter Thiel之间的宫斗戏(稍微说了说Elon Musk逼研发团队改用Windows,结果导致政变),他讲得最多的是如何对付金融欺诈,这在《支付战争》里几乎没被提到。

  2001年Paypal因为信用卡诈骗每月损失1000万美元,而且比率还在不断上涨。这引起了团队的恐慌。Levchin自己一度有些绝望,然后开始全力应对。最终Paypal开发出一整套防欺诈的工具,称为IGOR。很多今天已经习以为常的互联网防欺诈手段,都源于那时候Paypal申请的专利。例如现在常用的CAPTCHA技术:多次输入密码错误后,会显示一张只有人类可以识别的图片,要求用户按照图片内容输入验证码,防止黑客利用程序暴力破解密码。

  按照Levchin的说法,竞争对手eMoneyMail就是因为无法控制商业欺诈,损失比率达到惊人的25%,不得不退出。而《支付战争》的作者似乎没有意识到这一点,他认为Paypal就是业务增长速度正面碾压了eMoneyMail,所以对方放弃了。可能两边都没说错,技术团队和市场团队不同的视角而已。Levchin评价《支付战争》总体还是很有趣的,虽然个别地方错误。

  感觉最近新闻很多的Palantir的技术框架应该就源于IGOR。Palantir是Peter Thiel投资的创业公司,利用金融领域反欺诈的大数据工具,帮助美国政府进行反恐,据说在追杀本拉登的行动上出了力。大名鼎鼎的棱镜监控系统获取的海量元数据,需要有合适的数据技术进行处理。

  Paypal被收购后,Levchin花了很多年创业做Slide,不成功,最后卖给了Google。他又回到最擅长的互联网金融领域做了Affirm。他在Quora回答在Paypal积累的经验对Affirm创业有何帮助:“People underestimate the complexity of legacy payment infrastructure. Solid knowledge of that helps a bunch. More broadly, the greatest lesson is always the same: people is what makes or breaks every company.”

  去年他又推出了Glow,一开始还以为是类似“好孕帮”一样的助孕APP,好诡异。仔细一看:”夫妇可在备孕时每月连续往这笔基金内存钱,每月50美元,连存10个月。如果10个月之后Glow还没能帮助你成功受孕,这个基金则会资助你后续的检查和治疗……Levchin把Glow的未来定位为一家健康保险公司。而现阶段要做的就是收集数据、改进算法,帮助更多夫妇成功受孕”。 牛,原来还是玩金融,这智商税太有才。