Monthly Archives: March 2019

[得到大学课程作业] “造物者思维模型”:设计云服务的计费策略

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

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

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