跳转至

2022

ZStack的产品化之路

在浅黑科技《ZStack:这群做云的人有点“轴”》一文中,作者史中提到,这是一篇国产云计算佼佼者ZStack的创业史,文中记录了因为热爱而聚集起来的最早一批ZStacker,他们生活没有退路,但热爱未有止息。

实际上,这群人不止是做云“轴”,还很有趣呢。比如什么猫本轴海带,70后知识储备的90后......让我们走进《ZStacker说》专栏,一起看看这些有趣的ZStacker叭。

第四期人物故事:ZStack解决方案与产品架构师 蒋迪,一个70后脸的90后(笔者自定义标签),曾主导设计ZStack Mini、GPU池化、智能网卡适配、弹性裸金属等重点产品和功能原型。

今年是我工作的第10年,距离我第一次体验ZStack约莫过去了6年,在ZStack大家庭也近5年了,对私有云产品也有一些自己的拙见,希望可以借着这篇文章分享给大家。

又不是不能用

我的第一份工作就是做基于KVM的VDI,当时虚拟化平台的选择有很多,那时国外某开源云架构在国内正如火如荼,所以我也考虑过使用它作为基础虚拟化平台,但当我按照它的文档吭哧吭哧搭出来用了两天后我就决定放弃了,因为当时从文档、部署、功能、运维、升级等等各个角度来看,它暂时没有作为产品的良好基础。

但后来发现各地项目一提云就是它,我觉得或许是我自身的问题,于是咨询了几个朋友,得到的答案都是“管它好不好,大家都在用,项目多你怕啥”。经过再三考虑,本着对产品化的一丝朴素坚持,我最终还是决定放弃它了,后来事实证明这个选择也算正确。

傲娇的产品化与共同成长的客户

中间我把早几年积累的经验和知识总结成了一本书——《KVM私有云架构设计与实践》,机缘巧合这本书让ZStack的两位创始人张鑫和康总看到了,就邀请我来到ZStack。来到ZStack以后,除了见识到作为一个创业公司5年内从几十人到数百人规模的成长历程外,也对to B的企业产品有了更深刻的理解。

在ZStack的头两年我作为售前,会跟着不同销售全国跑,一起开疆拓土,比原先在研发岗有更多机会接触不同的一线客户,了解他们的各种使用场景。期间项目商机虽然很多,但ZStack作为一款不具备行业属性的私有化的IaaS标准产品,起初在某些项目中是有些吃亏的。那段时间国内OpenStack公司已经把客户市场教育的差不多了,经常有客户会问:你能不能定制,不能;你能不能代运维,不能;能不能提供PaaS和大数据,不能;我想搞个跟AWS一样的云你们能接吗?哈哈今天天气不错。

ZStack最让我欣赏的就是这种不做项目制、搞标准化的产品“气质”,有些傲娇但是又有自己的矜持,这为后面一些典型案例奠定了一个长久的基础。比如在做某手机一线供应链客户时,他们会拿ZStack对标V记产品,对产品该长什么样有自己的认知,对细节的把控也很强。比如:做个配置修改你让我登陆Linux改配置文件?对接商业SAN存储你让我选你们适配过驱动的?产品不支持在线升级?安装部署得你们上门?服务器还得用你们都兼容过的?对不起出门左拐厂牌交给门卫。

在甲方这样独立、自主的理念要求下我们PK掉一众竞争对手并成功进入他们的生产环境。在后续的跟进中他们也提了很多中肯的建(需)议(求),并对ZStack表示高度肯定,也理解我们并不会把所有建议都做到产品中的“傲娇”态度,因为在其他客户场景中可能难以适用。拥有像这样相互认可并一起成长的客户,我觉得对产品打磨十分关键。

后来的很多项目证明这种产品“傲娇”是利远远大于弊的,前面客户提的需求和建议在我们向其他客户输出标准产品时提供了很多潜在帮助,在这几年的信创项目中体现得更为明显,最典型的几个比如国密产品标准化、密评功能模块化等。

做好技术产品化交付的“最后一公里”

云计算是IT技术的集大成者之一,比如AWS上不断有一些既陌生又熟悉的新产品出现,像物联网、量子计算、机器人、卫星通信、AR/VR等。公有云可以把这些东西以成熟的产品交互呈现给用户,然后由公有云厂商承担复杂的后台运维,但私有云很多场景下并不能这样。有些大项目乙方可以代运维,但是头发尖的客户能有多少呢?更多不断涌现且可持续性发展的往往是一些所谓的小项目,而这些项目的运维往往是用户或者渠道商,所以私有云面向的最终用户应该有两种,一是最终用户,二是运维人员。因此,我们做产品要把实现的复杂性隐藏掉,从而让用户集中关注他最该关注的事儿上。

既然认定了市场,那做出的产品就要去迎合这个市场的用户,做某个领域的技术和做某个领域的产品是两码事儿,怎样在提供技术的同时又充分体现“人文关怀”也是一个“匠人”活儿。比如ZStack Mini的定位是面向工业一线场景,那么我们产品设计时要考虑到一线人员的实际IT能力,所以交互一定要足够具象,比如硬盘在哪个位置、虚拟机启动在哪台物理上、USB设备插在哪一个口上等等一些细节问题,有了这个基础才能让用户在使用尽管看起来陌生的虚拟化容错技术时有一种“一切尽在掌握中”的感觉。

另外在做异构计算的产品适配时,针对像GPU、DPU、智能网卡这些用户比较容易体验到IT工程技术发展成果的设备,我们除了要考虑把技术集成到ZStack并合理的提供出来,更要花费大量的精力思考如何把这些技术做得易用,包括安装、配置、升级等等。

举个例子,业界比较看好的vDPA方案,它能让用户在获得与SR-IOV方案媲美的虚拟网卡性能的同时,解决SR-IOV虚拟机难以热迁移的问题。听起来十分美好,但是实际落地时事情远非按照文档把技术堆出来给用户就完事儿这么简单。我们需要考虑DPDK相关驱动和配置什么时候下发安装、OVS网络要不要与已有LinuxBridge集群主机复用或者允许热升级,如果客户要外接控制器我们应提供怎样的接口、如果使用网卡软vDPA那么牺牲的一个CPU核应该怎样向用户呈现或解释、更换网卡时平台配置是否要自动适配等等,这样一些看起来与主要提供的技术目标关系不大且很繁琐的特性,正是走好技术产品化交付“最后一公里”要克服的困难,也能让用户切实感受到被尊重。

信创不仅仅要“能用”,更要“好用”

关于产品其实我有一箩筐想说的话,但在今天的国际形势之下,更想聊一聊信创的问题。大家看新闻应该都知道,最近俄罗斯也打算搞“局域网”了,他们很早就规划逐步用国产替代基础设施中依赖的进口软硬件了。“以人为鉴,可以明得失;以史为鉴,可以知兴替”,信创软硬件被应用到关键基础设施已经成为趋势。但如何选择产品呢?我的答案是:不仅要“正确”,更要“好用”。

在这两个原则的框定下,ZStack自研的产品核心以及长期以来坚持的产品化路线刚好能够把它推进这个象限。这句话怎么理解呢?因为基础设施的很多技术确实存在地缘壁垒,信创初期十分艰辛,做出来的东西可能仅仅达到“能用”的程度,但随着市场的发展,这些产品不仅在功能上能满足,在性能上也开始有指标超过国外同行了。私有云产品市场也是如此,初期确有很多国外开源云架构换皮产品来充数,仅仅达到“能用”的标准,但随着客户要求的不断提高,这些厂商开始有心无力。事实证明,非自研的架构核心改起来都非常费劲。

而从我有限的角度来看,ZStack可能是市面上为数不多全部适配了主流信创CPU与服务器的私有云软件产品公司,甚至在不支持硬件加速的虚拟化芯片问题上,ZStack也可以通过“弹性裸金属”让这些服务器顺利“上云”,达到让物理机享受与普通云主机一样的云盘、云网络并同池管理的目的。加之公司有强劲的QA团队保证(插一句,ZStack的QA人均超过10台物理服务器,比研发都“富有”,他们的理念和技术也很硬核),ZStack的信创版本质量也能得到充分保证。在目前的信创实际项目客户看来,ZStack的云产品已经远超“能用”的标准,而在“好用”的赛道加速奔跑了。

产品如何定价的模型讨论

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

当然,我仍然会建立一个合适的动态模型来模拟尽可能多的情况,如果是沙盘推演也没有问题,只是可能局限性比较大,不能把一些极端的变量组合考虑进去。设计的时候尽量遵循ODD原则(overview, design, detail),以保证覆盖现实情况的同时模拟出更多意外。

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

设计

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

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

梗概

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

属性与动作

客户

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

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

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

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

产品

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

1
2
3
4
5
6
7
8
9
产品价格:可控变量,即客户每天使用需要付出的价格  
产品状态:在厂、待售、使用、结束(这里假设每个产品从售出便不会再次回到产品池)  
产品用户:产品用户
已经销售:是否已经销售到客户
产品成本:与供应链相关
产品质量:随时间、客户增加而增加,有一个逐步完善的过程
产品销售厂商:产品销售厂商  
产品生产厂商:产品生产厂商
生命周期:产品从售出开始则开始消耗

厂商

然后是厂商的属性。

1
2
3
销售策略:盈利、求同、激进  
产品最大数量:对应厂商体量  
产品成本:与供应商有关

供应商

最后就是供应商的属性,为了减少复杂度,这里我们只有两类供应商,即可直接面向客户以及不可直接面向客户。

1
2
3
4
销售策略:盈利(供应商不赚就是亏)  
产品供应周期:每天能够生产的产品数量  
产品生产成本:可变量  
可直销:是、否

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

周期事件

TBD 一个周期内,会发生哪些事件呢?

产品:
客户:
厂商:
供应商:

模拟

预期

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

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

行为空间模拟

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

tbd model simulation

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

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

tbd

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