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

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

  简单介绍一下,这个云服务主要用于对上千张表、上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> 建立数据中台,让业务没有回头路。

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

列书单.2018.11.21

  最近几个月比较清闲。一开始,恶补以前错过的电视剧和综艺节目,眼睛都快看瞎了。没多久就觉得无聊,于是去书架上翻,找到很多买回来却没打开的书。

  读了阿兰·德波顿的《哲学的慰藉》,东野圭吾的《风雪追击》,雅各布·阿伯特的《查理二世》,约翰·肯尼迪·图尔的《笨蛋联盟》,珍妮·特洛尔的《查理·芒格传》,道格拉斯·E·理查兹的《超脑II强化》,杨照的《故事效应》

            

  说回目前的状态。每周有两三天出去约朋友喝咖啡聊天,其他时间宅在家里:睡到自然醒,洗澡,冥想,读书,听音乐……经常一整天都懒得吃饭,只喝清水(老婆说快成仙了)。到了周末,给闺女买个糖葫芦,用摩拜单车驮着她在街上乱闯,父女两个傻乎乎哈哈笑,路人注视下,寒风中,呼啸而过。

  很快又要回到战斗状态,继续参加创业了。这次间隔休憩是一段珍贵的记忆。

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

  之前介绍过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一般都是位置相关的产品,例如天气预报或行车路线。

GeneDock做什么?

1. 为什么选择基因数据作为创业的起点?

  2014年,厦戎和我创立GeneDock(聚道科技),希望用数据技术改变临床诊疗,这个使命始终没变。

  创立那年,中美两国允许基因测序技术进行临床试点,通俗点讲就是医生可以依据基因数据给人看病了(此前十几年,人类基因组计划等项目处于科研阶段,还没有成熟到可以应用于一线临床)。所以我们先从基因数据的处理下手。

2. 最初面临什么业务场景?开发了什么产品?

  GeneDock最早的客户是基因检测技术公司和科研机构,典型的业务场景是这样的:每天,不同城市的测序实验室产生上T的基因数据,先进行生物信息处理,再把数据和报告交付给下游客户,交付周期有商业承诺。领导数据生产部门的CIO往往面临很多复杂问题:

  • 首先,原始的测序下机数据无法直接应用,必须经复杂的拼接比对计算方能获得基因突变信息,而且还要对突变进行注释和解读。这就需要调度巨大的计算能力,管理庞杂的分析流程,维护复杂专业的参考数据库和样本信息。
  • 进一步,需要进行细粒度的业务划分和配置:实验团队、生物信息团队和遗传咨询团队处于上下游的不同环节,不同角色应该给予不同权限;而不同的检测种类,也会导致分析步骤的巨大差异,需要专门的分析流程、报告模版配置和数据隔离。
  • 同时,需要对各检测种类的不同处理步骤进行成本统计;对关键数据的使用和修改进行安全审计;对业务全局信息提供仪表板和显示大屏。
  • 更复杂的情况下,客户经常把一部分数据生产工作外包,例如基因测序外包给大的测序工厂,或者遗传解读外包给专门的医疗信息团队,这就必须对跨组织的数据交付、数据质量进行管理,对安全进行审计,对业务进行定期结算。

  针对以上场景,从2014年开始研发名为SeqFlow的基因数据生产线。这个产品首先是支撑海量计算存储的数据平台,对稳定性、算法优化、高吞吐和弹性拓展能力的要求都很高,以保证客户业务的质量、交付周期和成本控制。在此基础上,SeqFlow还增加了企业级的管理大屏、项目管理、权限隔离和数据审计功能,以便管理者对基因数据业务进行高效管理。

3. 研发SeqFlow的关键点是什么?

  SeqFlow的研发重点在于硬核技术,举个例子:分布式调度方面需要把计算任务表达为有向无环图(DAG),这个DAG是瘦长型的,步骤很多,最复杂的癌症肿瘤数据需要上百个步骤,很多步骤依赖成熟的算法包。这就导致常见Hadoop、Kubernetes等框架都无法满足需求(其实今天的Kubernetes是可以用的,但是4年前Kubernetes和其他几种类似框架都不完善,测试时发现了很多致命Bug)。所以我们就自己从头开发了一套分布式计算框架,刚好可以加上很多企业级服务的特性,例如冷数据压缩、项目隔离、Policy鉴权、管理大屏、数据审计机制等。

  刚进入这个领域的时候,市场上30X的人全基因组数据的常规处理价格是800元。2016年的时候,GeneDock发布了全球第一个价格低于100元的人全基因组数据处理服务,同时,这个服务承诺很高的并行处理通量,以及低于万分之一的失败率。我们为整个行业的发展构建了工业级的高性价比、高吞吐量、高稳定性基础数据生产平台。目前,SeqFlow上生产的客户包括泛生子、艾吉泰康、微基因和华大基因等行业领头羊。

4. GeneDock为何向医院客户拓展?

  基因测序技术刚开始临床试点时,大多数医院对它不熟悉,所以把业务外包给第三方检测公司。随着人才和数据的积累,顶级医院开始筹建自己的分子诊断中心:招聘团队,购买软硬件,建立实验室……要在院内完成整个基因检测的闭环。因此,他们也就逐步有了数据平台的需求。

  经过几年的探索,GeneDock从2016年开始全力开拓临床客户。和工业界的生物信息工程师不一样,医生不会写代码,这就要求我们从PaaS上到SaaS,把诊疗场景的产品做透。具体场景包括门诊电子病历收集、实验室管理、生物信息数据处理、位点和诊断报告系统,以及在此基础上构建的数据仓库和人工智能系统,最终实现临床辅助决策支持系统(CDSS)。

5. 基因数据与临床结合,面临哪些核心问题

  临床诊疗是非常专业的领域,场景更加复杂。所以研发难度不仅限于技术实现,而在于能否拥有清晰的业务洞察,设计出专业而易用的产品。得益于早期客户的信任和帮助,团队有机会一次次跟随专家出诊和试验,逐渐理解遗传诊疗过程。举几个例子:

  • GeneDock以前开发过科研病历,以为这套系统可以直接搬过来应用于一线门诊。后来才意识到不对。科研病历往往简化时间维度,把几百个字段平铺开,而门诊病历必须体现诊疗探索过程:根据症状,按指南检测,每一步检测带来更多信息,又决定了下一步的检测治疗方案。
  • 门诊节奏非常紧张,有时医生甚至几个小时没法喝口水,临床数据系统必须提供友好的半自动化录入和专业的检索统计。
  • 涉及基因数据的疾病,往往是遗传相关的。这就需要一套非常专业易用的家系图管理系统,通过家系信息把病历信息、实验样品信息、生物信息流程、检测报告、诊断信息都串联起来。
  • 在实验环节,样品无论外送或自做,都需要精密的实验步骤管理和质量控制,各个医院操作规格不同,又需要自主配置,具体实验室环境下,实验员一旦进入无菌操作环节就必须一气呵成完成操作,这时候突然要求他摘下塑胶手套到电脑键盘敲入信息是不现实。这就需要对场景和交互进行细致理解和思考。

  关于更具体的场景和技术方案,我在很多公开场合分享过。例如2018年初在顾大夫沙龙做的报告《面向临床的基因型和表型数据管理》。今天的公众号会转发那次活动的总结,其中包含了我的PPT。

6. GeneDock的系统已在哪些医院投入实用?

  随着对临床诊疗的理解逐步深入,面向遗传疾病诊疗的数据系统逐步打磨完善,完整覆盖了从门诊病历、实验流程、生物信息分析直到生成诊断报告的完整诊疗流程。GeneDock的数据平台已经陆续在陆军军医大学第一附属医院、四川大学华西医院、上海新华医院、厦门大学附属中山医院、中国医学科学院肿瘤医院、中信湘雅生殖与遗传专科医院、江苏省苏北人民医院、首都医科大学宣武医院等多家客户处投入实用,还有更多顶级医院正在落地。

7. 目前AI是热点,GeneDock有什么成果?

  在清洗好的海量基因数据和临床数据基础上,我们和临床科研专家一起合作,利用统计机器学习方法训练出了非常有效的人工智能算法模型,能够从成千上万遗传变异位点中,自动选取出最有可能导致疾病的遗传病因。

  在2018年的美国人类遗传学会(ASHG)年会上,陆军军医大学第一附属医院(重庆西南医院)医学遗传中心与GeneDock合作开发的遗传性耳聋基因变异功能预测模型DVPred刚刚发布。这个模型明显提高了预测准确度,ROC曲线的曲线下面积(AUC)达到0.998,在遗传性基因变异功能预测方面表现出更高的准确性,灵敏度高、特异性强。

  我们正在和客户继续研发,希望类似“大数据宝宝”的案例越来越多,让更多的患者真正受益于数据技术和人工智能技术。

8. 创业四年下来,你个人有什么总结?

  反思当然很多了,有一些是关于沟通、招聘和管理的,不多说。

  关于复杂系统的工程研发,这两天重新看了自己2015年梳理的博客《思考:如何开发应用平台》。感觉当时写得还不错,现在回头再看,很多观点都被验证了。当然,侃侃而谈是一回事,事到临头真处理好不掉进坑里,又是另外一回事了。有些东西必须躬身入局经历一番才算真懂。这一期公众号,这篇老文章也会发出来。

  总而言之,能构建起一支专业的软件工程团队,很有成就感。

9. 完成了B轮融资,接下来重点是什么?

  GeneDock会和越来越多的专家团队合作,对更多业务领域进行探索。不仅限于简单遗传模式的疾病,也开始涉及癌症、帕金森等复杂疾病,逐步覆盖生殖三级防控(婚前、孕前和产后)的各个阶段。

  具体到眼前这个阶段,随着标杆客户案例的建立,已经很多公司和医院的业务开始落地。项目交付能力至关重要,这取决于整个团队的软件工程水准:从需求分析、产品设计、研发迭代、测试发布、部署上线……要有一整套成熟高效的工程体系。这方面是GeneDock团队的强项。当然,团队还需要补充很多人才。

10. 对于想加入GeneDock的人有什么建议?

  随着B轮融资的到位,资金不再是问题,我们需要更多的程序员、基因数据工程师、人工智能专家和分子遗传学专家,对临床和基因数据进行充分的挖掘和建模。更详细的职位描述,欢迎访问 https://www.genedock.com/joinus/

  除了具体技能,个人想提醒的是,创业公司都会有一定的不确定因素。投简历之前一定要想清楚:心态上来说,创业变数多,需要有很强的抗压能力;能力上来说,需要你独当一面,有很强的落地执行力。GeneDock初步打开了局面,现在加入对个人而言有很广阔的成长空间。欢迎入伙!

开通了一个微信公众号

  开通了微信公众号,在微信搜索“王乐珩”就能找到。会把BLOG上没过时的部分内容搬过去一些。以后新写的文章都在BLOG和公众号上同步发表。

  创业维艰,2018年到目前为止只写了2篇BLOG。去年全年也只写了6篇。前几个月很多朋友应该都看到新闻了,GeneDock刚刚B轮融资成功,团队的不懈战斗终于换来了一个重要里程碑。接下来我会进入一个调整阶段,可以放松下来产出更多有价值的文字。感谢十多年来关注我BLOG的读者。

  这里分享3张和太空有关的照片。

2017年4月8日,北海公园上空两颗铱星闪光

2017年4月8日,北海公园上空两颗铱星闪光

  铱星原本是一个很宏大的民用商业计划,要在全球任何地方都提供高质量的收费卫星通话。商业失败后,整个铱星系统被美国国防部收购,变成了军用通讯系统。为了提高可用性,美军给大部分铱星系统的卫星在距离很近的位置配有另一颗备用星。两者轨道平行,肉眼看起来像是双子流星划过。2017年年初,SpaceX的猎鹰9号一箭发射10颗铱星成功,整个合同还要发射60颗。

2018年2月15日,机遇号拍摄火星上的日出

2018年2月15日,机遇号拍摄火星上的日出

  这张照片由机遇号火星车拍摄,这是机遇号的第4999个火星日。原本设计寿命为90个火星日的机遇号,在火星上工作了超过5000天,行驶路程超过45公里,传回了大约22.5万张照片。

1969年,玛格丽特在调试阿波罗飞船的软件

1969年,玛格丽特在调试阿波罗飞船的软件

  阿波罗8号环绕月球任务中,宇航员一时疏忽按错键,清空了所有巡航数据,飞船分分钟迷路。传奇女程序员玛格丽特(Margaret Heafield Hamilton)带领团队连夜奋战9个小时,审核代码、修复问题、重传数据。阿波罗8号得以成功返航。

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

  里斯本国家档案馆记载,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)。