关于产品如何定价的模型探讨

昨天跟人聊到这个问题,但是从经验上说,定价似乎需要考虑很多,但也好像不需要考虑一样。定价格有一些已有的规律,比如产品独领风骚然后按毛利去定的、红海市场跟随友商打价格的、为了扩张亏本卖的等等。经验这种东西会很有效,但它也是阻止破圈的罪魁祸首。所以这篇文章尝试建立一个代理人模型从尽可能多的角度去探索,毕竟这是一个系统性的问题,我们不讲经验,一两条经验不足以适配所有问题,干了40年的老板也不一定解决新场景遇到的问题,要不然百年老店不是又比现在多了一些。

当然,我仍然会建立一个合适的动态模型来模拟尽可能多的情况,如果是沙盘推演也没有问题,只是可能局限性比较大,不能把一些极端的变量组合考虑进去。

这里我们抛开单个产品差异化定价策略,即可以把产品拆成很细的定价策略,比如一块盘按照不同iops和容量租出去最大化利益,只讨论一块固有iops和容量的情况,因为这种拆分算利益的话,更适合用最优解公式而不是建模分析,况且现在差异化定价你会别人也会,最后难免都是同质竞争。

以我熟悉的云计算为例,首先我们尽可能多的列出agent,最明显的就是产品、客户、厂商、供应商,但是这还不够,有些过度抽象了。(我们暂且忽略渠道,主要是因为渠道与云厂商体量在实际情况中基本保持一致,所以这点确实可以忽略)

那接下来我们加入更多agent,产品嘛单纯一些只有一类,客户这一类金融行业客户、游戏行业客户、制造行业客户,厂商的话主要考虑外部竞争和内部团队(云计算部门的集团投入政策、销售体系等),即会有几个体量、质量、策略等不同的厂商agent,厂商除了考虑同类供应商,也要考虑它的上下游,比如代工厂、圆晶厂、渠道商这些(方便实现简化保留下游,仅为防止泰国又洪水产品生命周期有影响)。

至此,我们已经在这个世界里已经可以描述一个完整的故事了,某个客户(可控数量)向某个云厂商(可控数量)购买最多N个产品(有生命周期),客户会根据自己的偏好选择厂商,厂商提供的产品受限于供应商(价格极低),如果客户技术能力强或者价格敏感度高可能会直接向供应商下单(供应商参与竞争,适用于OEM产品),最后我们的输出是某个厂商在未来一段时间内的市场表现变化,包括收益和客户占有率。

列出尽可能多的agent以后,我们开始构建每个agent的属性和行为。由于我不想写那么多一个个解释,所以列几个意思一下,以金融客户为例(属性值和动作来源于市场销售记录统计,无法确定的值没关系,模拟的时候机器可以范围内随机探索)。

产品价格敏感性:低(0.2)
产品质量要求:中(0.5)
服务质量要求:高(0.8)
客户直销忠诚度:中(0.0-1)
客户渠道销售忠诚度:中(0.0-1)
IT技术能力:中(0.5)
受他人影响程度:高(0.7)

然后是动作,这些动作暂且适用于所有客户agent。

- 客户的属性随着时间的增长保持不变
- 客户会根据自己的属性偏好选择厂商产品,各个属性加权值决定产品,比如质量要求高的会喜欢产品综合质量好一些的、渠道忠诚度高的会喜欢渠道多的、IT技术能力低的会喜欢厂商服务好的
- 客户的购买行为除了在与云厂商直接,也可以发生在与供应商之间
- 客户的某属性超过一定阈值的时候(比如忠诚度),虽然所有属性加权值不是最佳,但会导致其这次仍然选择上一家
- 客户的忠诚度会随着历年选择厂商的变化而变化

列出产品的属性,这里可以先定义这么几个。

产品价格(可控变量)
已经销售(变量)
产品成本(与供应链相关)
产品质量(随时间、客户增加而增加)
产品厂商(agent固有属性)
生命周期

tbd 然后是厂商的属性

再加一些全局变量进去,比如从Gartner的趋势报告里把云计算、各类产品的每年增长也算进去,主要操控的变量是某个或多个厂商的定价范围(0-100)。

在开始之前,我们根据经验应该是对这个世界有一些经验预期的,包括:

一定范围内,定价不能直接决定市场占有率;
产品做的晚的厂商即使定价再低也只能抢得一定份额的市场;
供应商供货不足时,体量大的厂商更能抗住黑天鹅事件从而保证客户产品交付,从而获得更高的客户忠诚度;
动态选择灵活的定价(销售)策略即使起步晚,也可以抢夺一部分可观的市场;
价格敏感、技术能力强、忠诚度低的客户更容易从供应商处买;
集团策略影响云厂商定价策略选择;
在没被针对的情况下,小厂商初期可以打价格战争夺部分客户后,不会赚甚至是亏,但获取一定客户后再改变价格策略是可以盈利的;
因为不同阶段采取不同的定价策略会影响市场表现,那么作为云厂商在期间的前端销售和供应商谈判策略也不尽相同,比如产品初期的时候很难从供应商要低价,平价甚至亏本抢占市场后可以再向供应商谈判出更低成本价;

最后我们来看看模拟的动态情况。

tbd model simulation

tbd 由结果我们先看到几种现象。。。

tbd 然后我们把自己的实际情况带入进去。。。

tbd

tbd 看的多了,再结合dikw模型,结论就是直觉可能就是对的。但是要给人展示数字,我们可以从各种渠道快速填充数字,从数字到推论,只是让人觉得你可信,至于你自己信或不信,就是另外一码事儿了。。。最后我们要把数字与经验结合起来,就是出几个概率数字,即未来几年内我们应该采取怎样的定价策略(保持毛利、争夺市场、自动动态调整)然后有百分之多少的概率占去多少这个产品的市场获得多少利益,根据概率做选择,虽然无法确信,但也不会犯错,平平淡淡才是真。

关于产品的一点思考

最近在做一些小东西,但是也没匀出来时间写点啥,趁机整理整理吧。当然不能太抽象,太抽象就容易形而上学,而且让人觉得学究派。

一个系统甭管是啥,但凡需要作为产品输出,那就要有一些属性的,现代汉语对它的释义也挺准确的——“生产出来的物品”。

作为大千产品的用户,我有一些直观的体验,自己在做的时候也努力带给别人同样的体验。

暂时先总结这么几个。

需求优先:先满足我的原始(original)需求,即我这个需求的动力是什么,然后再扩展。

低学习成本:一定不要让我在使用的过程中老是咨询厂家、翻看说明书,对to B而言就是你不要老让厂商帮你运维。

无入侵:产品提供的服务不要给我造成额外困扰。

行为尊重:用户做的动作里哪些是需要的,哪些是多余的,产品行为里哪些是别人要看的,哪些别人甚至都不需要知道,想的越多,客户越觉得被尊重。

不要自大:厂商不要自大,做一个领域,和做这个领域的产品,是两码事儿。见过自诩很懂某领域的人,但是做的工作极难批量复制,那不叫卖产品叫卖人天。

不要遵守原则:只要保证客户人财安全,你可以随意创新,不要管别人的这黄金法则那必胜定律,用户的认知从长远来看可能都是错的。

测试即产品:毫不夸张,没有靠谱的测试团队那产品必然不行,不要吝啬在测试上的资源,他们可以以较小成本帮你发现成数以万计个潜在问题,也不要把客户当测试,你会很难堪。

隐藏复杂性:产品内部的行为可以很复杂,但是对客户呈现的一定是简单直白的行为,没人关心你的内部实现。

社会责任感:无论to B还是C的生意,做的东西要有严谨生命周期、升级策略、迁移方法,要不然就是对客户不负责像Google那样丢失B/C类用户的甩手掌柜。

实时操作系统中应用K8S

背景

实时Linux系统配K8s,满足大规模、边缘、嵌入式场景,雷达、舰载、攻防。。。主要是这个场景下想象空间比虚拟化大点。

准备

OS:RHEL 8.4 with rt kernel

测试

懒了,直接上测试结果以演示容器配RTLINUX是否值得投入。

 

阶段性总结

距离上次把自己埋起来表达也很久了。现在都不敢自己随便说,看的人多了就拘谨。反正不管了。

中间这几年明显感觉学习、创造和总结的少了很多,这也是焦虑的来源之一。

那再做几个决定吧:

1. 把公众号拾起来,随便写点啥。

2. B站开个号,随便编点啥。

3. 这个博客继续用,毕竟还是要总结的,总结出来的东西我会同步到GitHub的文档里。

La fin.

动手做自己的Nitro SmartNIC(FPGA/ARM-based Bare Metal Hypervisor)

0. BackGround

裸金属服务很酷,甲方都想要。BlueField 1/2、AWS Nitro、Aliyun X-Dragon MOC之类的智能网卡也不错,虽然ZStack软件已经实现了类似功能,但是这篇文章仍然会探索一个如何低成本(不到100块)的“智能网卡”方案(要不然前期的调研都白瞎了)。

做弹性裸金属并不难,但是要高性能的同时又要安全,而且在私有云、产品化的语境下,我们就需要好好思考一番了。

1. 功能定义

1.1. 带外管理

带外管理也不是个问题,如果:

  1. 服务器自带BMC。
  2. 你有能力让服务器厂商给你定制,因为你需要定制BIOS部分功能以让其在启动时认到智能网卡提供的虚拟设备。
  3. 自己做OpenBMC。

但是,由于多数用户没有让服务器厂商高度定制服务器的能力,因而我们需要在“无米”的状态下做“炊”。

1.1.1. Power Management

1.1.2. Physical Host Communication

1.2. Device Emulation

存储

存储侧我们目前可以直接提供的baremetal设备有 SCSI(iSCSI)、NVMe(oF)、VirtIO等。

由于产品化必须考虑到适配各种硬件的问题,所以我们不会定制修改BIOS,这里只要一个小小的trick即可让服务器从智能网卡提供的vda或者其他接口的“虚拟”硬盘启动,从而保证云平台存储资源可以以较高性能提供给baremetal。

网络

网络多数情况下是问题但又不是问题,我们选择智能网卡的原因是因为它可以解决大多数问题。虚拟网络资源直接给物理机的目的可以很容易地通过SDN交换机实现,但是我们既然用了一个智能网卡设备那么就应该通过它来回避各种外部环境仍然需要定制的问题。以BF2为例,它内部集成的ovs-dpdk以及Mellanox传统的内部虚拟交换技术加持,我们可以给baremetal一个“虚拟”接口,但是所有流量都在云平台的管控下,用户极难自行修改。

如果不选择智能网卡,那么只有SDN交换机和系统内SDN两种方案,SDN交换机甚至比智能网卡的适配都简单,技术不是难点,同智能网卡一样你很难说服客户的采购来一套裸金属专用的SDN交换机,更不要说这个交换机不在他们的网工管辖范围内了。

那么只剩系统内的overlay网络接入方案了,Linux一直不是问题,Windows系统需要agent做一些小工作才可以,即使用户自己改了,我们也可以“内挂”anti-spoofing。

1.3. Hypervisor Simulation

2.1. Proof of Concept

2.1. ARM or X86

我们先做一个OpenBMC的原型机,准备如下材料:

笔记本;
树莓派;
适配采集卡;
杜邦线;

当然,一台服务器也是必要的。。。不会吧,你家里连台服务器都没有?你还做锤子钢铁侠哦?赶紧上咸鱼500块买个二手服务器吧,不想做钢铁侠了还可以卖掉。

2.2. ARM-FPGA SoC

虚拟桌面中通过RDMA进行GPU跨节点调用从而加速渲染

许久没关注过VDI了,一直坚持的观点就是协议要牛逼,否则就是渣。

VOI、IDV都不太行,GPU本机显示还是有些小问题,要么远程的,要么就没有虚拟化。

直到离开VDI行业三年多后发现还有这个炫酷的东西满足了当时我对单机虚拟化的期望,https://looking-glass.io,虚拟机与宿主机可以共享显示(iGPU),或者独占显示但是键鼠仍然与原生一致。

PS:ArchLinux社区万岁,这是原文

之前Intel的老板说用iGVT可以,但是仅限于Intel集显,没有可复制性。现在发现这玩意儿以后,关于边缘计算的场景真的又可以展开一些了,朋友,之前机场工控机虚拟化管理还要大屏的需求我们再聊一聊?

原理说复杂也不复杂,作者思路从被广泛采用的桌面截取(OBS、DX API、NVIDIA Stream)到共享内存(IVSHMEM),纯内存交换。

很有意义,远程桌面协议换成共享内存协议,然后可以进一步用RDMA,再配上virtio-gpu,就可以跨节点渲染了,虚拟化版本的virgl。

 

NVMe in the Cloud(ZStack),(适合)云原生的存储

NVMe作为新的存储协议,更能将新的存储介质的性能发挥出来,与此同时,与SCSI存储对等的NVMeOverFabric和NVMeOverTCP也已经开始在数据中心中崭露头角。
传统云平台中的对这些存储设备的使用是没有任何问题的,但是在不改变存储对接架构的情况下发挥出其原生性能则是一个挑战。
关于瓶颈的问题,我们可以从不同的存储对接路径去分析。

当然,不同于公有云的机器完全自定义,硬件自己随便攒,私有云为了要达成产品化需要考虑的因素比公有云更为繁杂,并不是随便买了一款硬件就能包装一下提供服务的。

NVMeOverTCP的好处除了其性能之外,还有就是万兆以上线速,有多少来多少。

硬件测试设备:LightBits

软件测试方法:https://blogs.oracle.com/linux/nvme-over-tcp

测试客户端:100Gb x 2、25Gb x 4

测试云平台:ZStack 3.8,io_uring,spdk

Direct to Guest

NVMeOverTCP的特点就是,用户以极低的改造成本即可获得高性能、低延迟的高性能存储,以现在的单盘IOPS

PassThrough

DirectConnect

Via Host

Cluster Filesystem

Share Block

Windows中使用overlay网络

引言

21世纪了,智能网卡还是贵,交换机客户没法直接买,软件技术栈都好找,性能再加强,ebpf不错,要是Windows的Linux子系统里支持这个那软裸金属方案至此可以画上一个句(分)号了。

关于如何在Windows裸金属中给用户交付流畅且易配置的云平台overlay网络,从而跟虚拟化打通,也是个最近要考虑的点。

SDN交换机与智能网卡

我们可以用国内品牌,他们也提供ovs接口,but,对于小体量的客户或者采购严格的客户就很难,仅适合自有IDC且有决心的客户。

为了使用一个功能,软件绑定就算了,硬件你还要我买你的,固定资产无法二次利用,别想了。

GRE/VXLAN(Windows)

Windows从08/12后自带了NVGRE,VXLAN的话是从16开始支持,听起来也不错,所以这个对于新晋用户是可以接受的

OVS

Windows下有ovs,但是仅支持2012后的,这样就没法解决Windows2008的问题(再过几年就不用操心这个问题了),当然主要的问题还是没有官方背书。