冷技术热思考

其他

你用的公有云都没做过测试

前两天腾讯云遭遇重大故障,影响范围很大,几乎所有API服务不可用,和之前阿里云的严重故障类似。这个事情当然马上引起了业界广泛的分析和讨论,比如冯若航就迅速分享了他的看法(腾讯云:颜面尽失的草台班子),我也说下我的理解。我的理解主要来自于我做云和做软件的经验。我是从2012年开始带领团队开发网易云。我们主要服务的是集团的非游戏业务,如云音乐、新闻、等,云课堂、Lofter、云信/易盾/七鱼等,也少量服务过外部客户。尽管我们的平台较为专注且应用规模较小,因此故障率相对较低,但也没能幸免每隔四五年来一次较为严重的故障。同时,我也带团队开发多种软件业务,如网易数帆,涵盖大数据、云原生等方向。这些软件都私有化部署在客户环境。尽管我们主要服务中大型客户,但客户数量也有数百家。一边做云一边做软件,我就发现云平台和一般软件有本质区别。云计算平台虽然也是软件的一种,但其部署和服务方式与传统软件截然不同,这种差异就使得云计算平台的稳定性面临巨大挑战。核心是,公有云是没法测试的。公有云的系统规模极其庞大,不可能建立一个等同规模的测试环境进行全面测试。公有云系统还特别复杂,本身很复杂,还要集成那么多的软件和硬件。这么复杂的系统又没法测试,有时来个大故障也就情有可原了。说到复杂工程,大家常说一个词叫火箭科学。大家都认为火箭是非常复杂的,很不好做,马斯克造星舰到现在还没有成功,NASA之前搞航天飞机炸了两次后来也就不敢搞了。但是火箭虽然复杂,但毕竟是可以测试的。你发射一次有问题,找到问题在哪里,改进,然后再发射。这样经过多次你的火箭就越来越可靠,故障率就越来越低。但公有云你没法这么做,因为公有云的特点决定了它的生产环境对该厂商而言是全世界最大的,你不可能去构建同等规模的系统来做充分的测试。我不清楚现在这些公有云厂商会构建一个多大规模的测试环境,总之肯定会远远小于实际的生产环境。因为生产环境一年的成本几百亿,搞一个跟它同样规模的测试环境,云厂商早就破产了。所以如果类比火箭来看,公有云就相当于你在测试的时候用的是在自家后院发射的那种小火箭,然后接下来就把这个小火箭放大个100倍,然后就拿着它去做载人登月。这个比方听起来有点吓人,但道理我觉得就是这么个道理。我这个逻辑也可以解释为什么公有云出问题的经常是那种全局性的管控系统,就是因为这些系统最难做同等规模的测试,因为它是全局性、全球性的系统。我们在看一个工程失效的时候当然有很多视角,比如有的人会比较倾向于把它导向到最近精简压缩人员比较厉害,搞降本增效结果变成了降本增笑上。这当然也是原因之一,因为复杂工程系统的维护还是要有专业的团队,也需要这个团队尽心尽力,因为他要不断地去巡检,解决技术债,防微杜渐。但更根本的原因,我认为还是公有云没有办法做很好的测试。
4月9日 上午 10:29
其他

Shape Up:看看别人家公司怎么做到不加班还动不动放长假的

Seller。但是之前的书碎碎念比较多,方法不是很系统。现在这本《Shape
4月1日 上午 9:00
其他

a16z:2024年GenAI市场将爆发

a16z上周发的关于今年GenAI市场的报告(https://a16z.com/generative-ai-enterprise-2024/)很值得一读,以下是主要信息:1、2024年企业在GenAI的预算增加近两倍,模型
3月31日 下午 4:43
其他

ChatGPT让现在的软件都土掉渣了

我们家有两个娃,每次我们想要出去时订个酒店时都好麻烦。我在某程上找,我先看有没有家庭房,但家庭房很少,而且有些家庭房实际上只能睡得下两大一小。普通房间能不能睡得下四个人,那可是得查看很多信息,如床的尺寸、是否可以加床,是否可以睡沙发等等。每次订个酒店都要好久。我想很多有俩娃的家庭也有类似的烦恼吧。这样的事情如果交给ChatGPT去做会怎么样呢,结果令人震惊,ChatGPT把方方面面都想到了,比我想得还要周全。今天ChatGPT已经有插件通过Expedia订酒店,它可以帮我查看、分析酒店和房间的所有信息,帮我找到最合适的选择。我无比期待在国内也能有类似的服务,要么是某程自己做一个这样的功能,要么某巨头搞一个同样智能的入口,然后用插件连接某程。这是软件交互的革命,有了这样的交互,现在的软件这种让你不停的点点点、看看看、退退退的交互都土掉渣了。Bill
2023年4月3日
其他

GPT-4革命:对话即编程,人人都是程序员?

昨晚OpenAI发布了ChatGPT插件机制,这让ChatGPT成为一个超级入口和超级计算机,能够调用其他服务。尽管大众对ChatGPT的理解是见多识广、能说会道、善解人意还很会道歉,但如果大模型的能力仅限于这个水平,那它也只能帮忙写写东西,陪着聊聊天,做不了多少真正严肃的工作。程序员则认为,ChatGPT可以自动生成代码,但因为生成的代码仍需要人类review和修改,所以它只是帮助程序员提高效率的工具,不能替代程序员的工作。然而,ChatGPT的影响远不止于此。它是软件开发的彻底革命,让所有人都可以使用自然语言作为编程语言,这将带来全新的程序员群体。这意味着未来不仅仅有专业的程序员,还有更多具备其他领域专业技能的人也能轻松使用ChatGPT来完成编程任务。这样一来,将会出现更多非传统程序员的创新思维和想法,对整个行业的发展也将产生深远的影响。「GPT-4革命:对话即编程」GPT-4出来后,我就一直在试能否用它来编程。我指的是直接用它编程和执行,而不是用它来生成代码。通过几天的实验,我发现只要教它规则或过程逻辑,它往往都能比较好的掌握。比如,你可以教它算24点。再比如,你还可以教它打牌。虽然它的牌技还比较差,虽然它算24点还很慢也经常算不出来,但它是能按照你说的思路去做的。无独有偶,我关注的南瓜博士也惊呼GPT-4太逆天,因为它之前基于GPT-3.5调教了非常久的“谁-在哪里-干什么”游戏,在GPT-4里非常轻松的就实现了。可能很多人还没有看出来这意味着什么,觉得这只是教它玩几个游戏而已。但实际上,这件事意义重大,因为它意味着我们终于有一天可以直接使用自然语言来编程了。我们可以看到,在
2023年3月24日
其他

还应该跑马吗?关于运动时间与寿命的(伪)科学分析

这两天朋友圈、群里都在感叹和讨论丁耘事件。不认识丁耘,但听华为来的同事说绝对是牛人。前有孙剑,现有丁耘,真是天妒英才。虽然孙剑和丁耘都不能明确的说就是因为跑步过量走的,但这么短时间就出了两例,大家基本上都这么认为了。有人说跑马容易猝死还用证明吗,要知道当年第一个跑完马拉松的人就是跑完就挂了的。当然,这两天有些公众号就开始发关于运动和健康的文章(比如我关注的慧跑的这篇:争议:高强度运动会增加猝死风险吗?),但这些文章看似非常的科学,因而也非常的复杂,有些结论也反直觉,比如上面这篇文章就说运动量越大健康收益越大,连个上限都没有。其实,如果不追求太科学的话,运动和健康(简单说就是寿命)之间的关系完全是可以根据一些非常简单的假设推导出来的。思路很简单,只要我们相信人一辈子心跳次数固定这一传说,再得到点运动量和心率之间的关系,就可以估算。众所周知长跑运动员心率低,跑步一年来静息心率也是肉眼可见的明显降低,所以运动量和心率肯定有某种关联关系,而这个关系就决定了运动对寿命的影响。运动量和心率之间的关系没找到权威数据,不过可以根据几个数据估算一下。一是自己静息心率从一开始的65下降到了51,下降了14(见下图1);二是据说专业的长跑运动员的静息心率只有40左右。我的跑量大概是一年500公里,在加上一些徒步之类的,核算下来每周运动时间大概1.5小时,专业长跑运动员据说周跑量高达200公里,每周大概12小时。另外猜测运动量和心率下降幅度很可能是个对数关系,因为对数函数的曲线前期升得快,后面就快速的趋向平缓,比较像。图1:跑步一年的静息心率曲线也就是假设心率下降幅度h和每周运动时长t之间的关系是:h=a+b*log(t),然后根据h(1.5)=14,h(12)=25,就可以求解出来a和b,得到运动时长和心率下降幅度的关系曲线如下。图2:运动时间和静息心率下降幅度的关系根据上图,运动时间越长,心率下降幅度越大,是不是运动时间越长寿命就越长呢,常识看显然不是的。问题出在运动的过程中心率是明显更高的。我估计运动会增加“运动时长(分钟)*120”次超过正常的心跳。120是考虑到运动期间及前后的综合影响,其中假设慢跑过程中心率比平常高80次,但运动后还需要花比较长的时间才能完全回复到正常心率(如果运动量过大,可能第二天都没完全恢复),这部分的影响折算到运动时长算每分钟40次。所以,可能到某个点继续增加运动量,运动带来的直接心跳增加超过静息心率的下降,这样这时再继续增加运动时长,总心跳数反而会增加。根据以上的假设,可以计算得到每周运动时间和减少的心跳总次数关系如下。所以,每周运动5-7个小时,总的来说降低心跳总数的效果最明显(超过16万次),超过这个时间反倒效果没那么好了。图3:运动时间和每周心跳数增量的关系每周省下来的这些心跳数,按一辈子心跳次数固定的传说,当然就可以用来让你多跳几年了。再假设按照这样的时间坚持运动30年,可以多活多少年呢。具体过程不说了,可以算出下面这张图。这样看来,每周运动5-6小时效果最好,可以延寿10年!图4:运动时长是总寿命增量的关系但是是不是都应该每周运动5-6小时呢,其实没必要,因为就算每周运动1小时就可以延寿6年了,像我这样每周1.5小时就可以延寿超过7年啦。在我看来,每周运动一两个小时就差不多了,没必要追求太高。计算下边际效益可以看的更明显。如下图,随着运动时长增加,再继续增加运动时间对总寿命的边际效益是明显下降的,3小时以后已经很弱了,超过6小时就会变成负数。图5:运动时长和总寿命边际效益所以,每周运动1-2小时就很好,3小时就非常好,5-6小时是极限,超过6小时就得不偿失了。当然,就算每周运动超过10小时,相比完全不运动,还是有利的,只是不如每周运动2-3小时来的好。我的打算是,每周不超过2小时,每次不超过10公里、1小时,曾经还想跑个半马,现在看要不半马就不要跑了吧。爱因斯坦假设光速不变得到了相对论,我假设心跳总数不变得到了运动和生命的奥秘。强调一下,本文说的运动只是指慢跑这样的有氧为主的运动。最后声明以上分析都是伪科学,虽然俺自己还是很信的,因为写完回头去看了下慧跑的那篇文章,说运动最积极的人每50年可以延长7-8年寿命,这个和我算出来的一辈子增加10年,有啥差别吗?(顺便给网易有数打个广告,文中的图表都是用有数做的,个人用户永久免费)
2022年10月9日
其他

达梦为什么这么赚钱

题图来源:达梦官网过往我的文章主要都只讲技术,这篇对一家基础软件的企业做点业务研究,毕竟做网易数帆业务是我目前的主要工作。达梦是老牌国产数据库厂商,当年(2003)做国产数据库开发的时候,达梦就是四大之一(其它还包括神舟、人大金仓等,我就在神舟),现在终于接近上市了。达梦的招股书出来有三个月了,泄露了很多秘密,比如飞总就发现达梦的研发人员占比只有三成,平均年薪只有20多万(招股书揭秘:达梦程序员,不如导盲犬。。。)。今天我也来挖一挖,不过我主要是想看达梦是不是真的很赚钱,为什么这么赚钱。01达梦并非看上去那么赚钱根据招股书,达梦2019-2021三年的营收分别为3.02、4.50和7.43亿元,利润分别为0.89、1.49和4.44亿元,营收复合增长率57%,利润率高达59.8%,看起来超级能赚钱。但实际的利润率并没有这么高,要扣除以下两个因素。一是需要扣除政府补贴(21年有1.3亿),看扣非利润,21年为3.48亿,比营业利润少了将近1亿。这个数据是招股书中明确披露的。二是要扣除21年过于激进确认收入带来的影响。21年应收账款大增,前两年应收占比都在1/3左右,但21年应收高达3.48亿,占比47%。完全有理由怀疑这是为了上市更激进的推动验收确认收入。对于达梦这样标准化程度比较高的软件来说,推动客户尽快确认收入不太难,因为确认收入只是需要在验收单上盖个章,并不需要付出真金白银。达梦通过这样的方式可能增加了多少收入呢?根据前两年的数据,我们假设正常的应收占比仍为1/3,再假设21年超常规确认的收入为X,那么就有7.43-X=3(3.48-X)可以算出X=1.51。如果我们扣除这部分收入,将达梦还原到可持续的财务数据,那么实际上2021年达梦的营收应该是5.92亿,利润应该是1.97亿,利润率应该是33%,营收复合增长率应该是40%,并且21年的营收和利润增速是有所下滑而非上升的(但营收和利润增长仍超过30%)。达梦这样的处理让21年的财务数据非常漂亮,但让今年保持增长态势极难,特别是又遇到疫情,很可能今年的数据会比较难看。02达梦仍然算非常能赚钱虽然上面分析了达梦的盈利能力很可能并没有看上去那么漂亮,但达梦仍然算是一家非常能赚钱的公司。首先,和同样做数据库的同行相比,达梦的营收排名第一,利润更是一骑绝尘。国内做数据库的其它厂家主要有人大金仓、通用数据、优炫软件、神舟通用等,其中优炫亏损过亿,人大金仓和神舟通用利润分别为3129万和1638万,利润率分别只有9.2%和13.6%。通用数据没有公开数据,但估计不会太好。所以,就算按之前调整后的利润1.97亿,利润率33%算,达梦的赚钱能力也是远超同行。(注:这里神舟通用的数据采取的是达梦招股书里披露的同行对比数据而非神舟通用自己招股书的数据,因为神通的业务包含了大量的系统集成和技术服务,虽然公司总营收大过达梦,但估计数据库业务达梦的营收远超神通)其次,和同样做其它类别基础软件的大同行相比。老牌的中间件厂商普元和宝兰德营收均远不如达梦,利润率都不到10%,只有东方通营收略高,利润率29%和达梦可比(不过东方通中间件业务占比不足40%)。新生代的青云和星环营收也远不如达梦,利润更不用提了,亏损率都超过50%。前几年炒的最热的AI四小龙更不用提了,虽然营收盘子大,但亏损更大。以商汤为例,去年亏损超过100亿,虽然部分是因为期权成本造成的,但单算业务肯定也亏很大,而且期权成本这么高本身也是问题。其它基础软件厂商财务比较健康的大概只有帆软了,年营收11.4亿还有利润。帆软的利润没有公开数据,但估计利润率应该没有达梦高。所以,在整个基础软件行业,达梦的赚钱能力属于超一流水平,基础软件营收仅次于帆软,利润率则最高。泛行业来看,33%的利润率可以吊打包括互联网在内的一众行业,和茅台、银行、证券这些巨有钱的公司和行业同一水平。因此,达梦仍然算是非常能赚钱。03达梦为什么这么赚钱达梦盈利能力为什么这么强,行业不少人都会说是因为信创。这点没错,达梦的党政客户营收占比近60%,其次为能源和金融,分别占比13%和11%,其它行业只占16%。招股书显示,达梦的党政客户包含了商务部、外交部、司法部、公安部、工信部、财政部等国家部委和各级人民法院、各级人民检察院。金融的营收2021年之前非常低,2021年增长超过10倍,这也是因为信创的驱动。可以说,如果没有信创的政策驱动,达梦的业绩这两年绝对不会起飞。但同样是信创,其它数据库厂商就远没有达梦的数据漂亮,并且据了解在这一波信创之前,达梦的营收在国产数据库厂商中也是相对较高的。另外,这两年因为信创另一家知名的国产数据库厂商人大金仓的营收也起飞,从2019年的不到1亿增长到2021年的超过3亿,但利润率不足10%就远不如达梦。所以,这背后还有更深层的原因,我认为主要是达梦坚持标准化,构建了很好的渠道销售体系,同时成本控制优秀。达梦的业务标准化程度较高,软件授权业务营收占比超过80%。因为标准化程度高,达梦可以主要通过渠道销售,其中软件授权业务渠道销售占比超80%,且这一比例在近两年还在显著提高(2019年是60%)。中建信息为最大的总经销商,2021年贡献营收2.2亿,占比约30%。因为通过渠道销售,达梦的销售费用率可以做到29%(按调整后的总营收5.92亿计算)。这一比例看似不低,但达梦的销售费用还包含了技术服务部门的售前售后成本,而技术服务平均人数385,远大于市场销售平均人数的171,因此如果单纯算市场销售人员的薪酬费用率估计只有10%出头,是非常低的。最后,达梦非常注重成本控制。除了上面已经说的达梦的销售费用率很低,还严格控制研发投入。达梦的研发人员数量占比为31%,研发费用率只有20%(按调整后的总营收5.92亿计算),对于基础软件厂商来讲这个比例也是非常低的。软件企业的研发成本高是个典型问题。如果软件不够标准化,定制开发多,研发成本就会很高。又因为研发人员甚至基层团队无法直接核算ROI,更难在当期评估收益,很容易导致研发投入在性价比不高的地方。这些原因都导致研发成本的控制和优化是一件非常困难的事情,但这件事情上达梦做的很好(当然,也有可能达梦控制的过头了,研发强度不够会影响公司的长期竞争力)。从业务角度看,凡是财务健康度高的,研发成本都控制的较好,如上面说的东方通研发费用率为28%,帆软听说研发人数占比也不高。那些亏损的公司则往往研发成本很高,如星环的研发费用率为42%,商汤的研发费用率更是高达77%。除此之外,达梦的管理费用率也只有10%左右,14名高管的平均薪酬是200万,属于应得的水平。有人可能觉得这样的水平也挺高了,但要知道某些企业虽然巨亏,但TOP
2022年9月30日
其他

我们为什么做NDH

前几天我们发布了个小产品叫NDH(官宣!网易数帆自研大数据基础平台,筑牢自主可控“数字底座”),大致来说就是一个网易版的Hadoop,类似CDH,没想到引起了IT大网红飞总的深深思考(Cloudera一己之力证明的火炕,网易却毫不犹豫跳进来。。。)。飞总为了证明我们是一群聪明人,不会做Hadoop发行版这种傻生意,blahblah帮我们想了很多理由。飞总不愧是飞总,技术上一针见血(我们有Impala和Kyuubi),融资上市抬估值的逻辑更是把我唬的一愣一愣的。借此我也谈谈我们为什么做NDH。首先,其实NDH并不是一个全新的产品。我们内部已经做了很多年了,音乐、严选、传媒、有道等BU都大量使用,对外也卖了5年了,只不过之前都是和我们的数据开发平台一起打包卖的,这次无非是把NDH这一层独立出来。其次,把NDH独立出来可以说是我对架构开放的偏执态度的必然结果。我之前给有数的团队提了一个要求,产品要模块化,拆分成多个客户可以单独购买的子产品,这样客户就不会被逼着买全家桶。很多客户已经有CDH、FusionInsight,总不能逼着客户为了用我们的数据研发或数据中台又得搞一套Hadoop集群吧?所以我命令团队一定要拆。这一拆就拆出个逻辑数据湖的概念,就是我们的数据研发和数据中台都可以架设在客户已有的CDH、FusionInsight、Vertica、Oracle甚至MySQL(对的,甚至有在MySQL上做数据中台的,这个我一开始都想不到)上实现。这样出现了一些客户用了我们的逻辑数据湖,底层是CDH或FI。但客户用着用着,也被我们团队游说(我们不会逼客户,但游说还是会游说的),觉得CDH貌似挺贵也有风险,我们服务又不错,所以也想把底层换成我们的。这上门的生意总不能不做吧,所以NDH独立成产品也就是必然的了。架构开放应该说是我作为架构师的偏执吧,因为生意角度证明不了,你说20多年前Bezos要求系统之间都得通过API是不是一种偏执?最后,虽然Hadoop发行版长期看不大像是一门很好的生意,但我们认为NDH无论短期还是长期看都会是一门不错的生意。短期的理由飞总在文章里已经说了,主要是我们可以接手CDH的老客户,还有Impala和Kyuubi的优势。长期看NDH会演化成一个越来越强大的面向分析的数据存储和计算平台,能够比较好的同时满足批处理、交互式查询、数据仓库、流处理这三方面的需求,并且保持开放架构(具体来说就是存储和格式统一)和迁移过程的平滑。平滑演进特别重要,我们为什么做Kyuubi?主要就是为了从Hive到Spark能够平滑,从YARN到K8S能够平滑,将来我们还可以平滑的不断过度到理想形态。这会是一个非常漂亮的架构,自然也会成为一个很好的赛道。Cloudera势头不行不表示整个赛道不行,是因为Cloudera在技术上落伍了,比如MapReduce被Spark取代,Hive被SparkSQL取代,同一个赛道的Databricks、Snowflake,那可是红得很。虽然这个过程会比较长,也有很多挑战,但我们在云原生数仓和基于Iceberg的湖仓方面已经做了不少工作,让我相信是可行的。我们也会秉持我们的开源理念(我们怎么做开源),基础内核技术会开源出来,下个月我们就会开源一些东西,敬请期待。当然到那个时候,NDH这个名字也要升级了。虽然飞总无责任猜想我们是不是为了估值,但NDH这个名字我觉得对资本应该是没啥吸引力的吧,但客户好理解。再说些题外话,我觉得把手头的生意做好,胜过去追求所谓的大家眼中的“好生意”。就像我在前一篇文章里说的(中国做企业软件这么难,怎么办),虽然中国做企业软件是难,但既然在这个赛道,也必须努力干下去。有数在大数据这个赛道,NDH这个事情做了这么多年了,那NDH就是我们手头的生意,既然做了,就要想办法做的更好,这次正式发布NDH无非是想做的更好。这大概也算是我司气质了,大家看我们做严选还养猪,这些生意又累又重,又不是什么平台模式和风口,显然不是“最好的生意”,但是不是“足够好的生意”呢,应该是吧。既然有足够好的生意可做,那就先把它踏踏实实的做好。
2022年6月26日
其他

中国做企业软件这么难,怎么办

和鲸科技的板哥写了篇非常好的文章讨论中国的软件公司为什么做不出产品,核心观点是中国软件厂商面临的不是一个好的市场,因为需求高度复杂,竞争高度激烈,甲方“既要,又要,
2022年6月25日
其他

所有专业服务部门都是阶段性存在

今天看到Meta已经拆散了AI部门。负责AI的副总裁离职。大牛LeCun负责的AI实验室FAIR转到元宇宙Reality
2022年6月4日
其他

我们怎么做开源

图:数帆开源全景图今年数字+大会上我们第一次比较系统的推出了我们的开源计划(https://sf.163.com/opensource),将“架构开放、内核开源”作为我们的核心战略,尽可能的减少客户绑定,引起媒体的广泛关注。媒体经常会问我们开源怎么赚钱,一些同事也问过我同样的问题。网易数帆是一家商业化组织,为什么要做开源,而且还把项目捐赠给基金会(今年我们把Kyuubi项目捐赠给了Apache基金会),放弃控制权,难道数帆是活雷锋吗?我想不如写篇文章把我们的背景,对开源的思路向业界和同事们更彻底的说说明白。因为工作原因我只会讲面向企业的基础软件方面的开源。这应该也不是我们一家公司遇到的问题,记得阿里的李飞飞老师在一次采访中也说开源其实内部也有很多讨论和争议,所以我们的思路可能也有些参考价值。「背景故事」在切入正题之前,得先介绍几个背景故事,因为这些故事对我们开源战略、策略的形成有很大影响。故事一:国产数据库。2003年,我们浙大数据库课题组的一行人承担了国产数据库的研发工作,我负责执行器。我们的基础是PG。因为我们把存储和事务层完全重写了,我的执行器自然也要大幅修改来对接。我嫌PG的代码写的不好,可读性差(特别是mergejoin的next方法1200行贼难读懂),性能也不好,因此大刀阔斧把整个执行器全部重写,可读性好了,性能也高了,当年在科技部的评测中遥遥领先位居第一。这看似是好事,但过了不到三年大家都向我抱怨说因为我的重写,PG新版本的特性完全没法移植。这件事对我震撼很大,让我意识到和社区脱节可能带来严重后果。故事二:NEMR。2007年公司业务有了大规模数据分析的需求,看了Hadoop发现太不成熟,当时团队提议不如自研一个,就立项做了NEMR(NetEase
2021年11月8日
其他

细品中台

两年前正当中台概念爆发的时候,我曾经写了三篇文章(什么是中台、怎么建中台、网易杭研的中台往事)对中台做了一次梳理,这两年,中台仍然持续是热门话题(虽然没有更热),我们及行业对中台的理解和实践也有了长足的进步。从我们而言,两年前我们的中台和支撑技术(如网易轻舟和有数)只能说有了基础,这两年都成熟很多。我们也服务了一些外部客户,获得了一些非互联网行业中台经验。这些内外部经验我们进行了总结,出品了极客时间《数据中台》专栏。从行业而言,有了滴滴、头条、美的等更多的行业案例,也有更多的行业专家针对中台话题发表了更多思考。如王健老师出品了极客时间专栏《讲透中台》,在我看来应该是在业界第一次完整的提出中台的建设方法论;钟华老师新写了《数字化转型的道与术》,把中台融入到企业数字化转型的大框架内;企业服务领域的老江湖用友也出了《数字化中台》,全面阐释业务、数据、智能、技术等中台体系;刘天(三爷)老师写了《中台产品经理宝典》;付晓岩老师、老K等也都发表了相关思考,就连刘润老师也止不住的把《尴尬的中台》每年旧文重发一次(似乎只字未改)。至于业界实践最多的数据中台,厂商出书已经形成一种风气,似乎不出书就显得不够格(我们没出书但也出了极客时间专栏)。这段时间,我一直在梳理两年来我们和业界的相关进展,思考,总结,以下就是工作成果。全文约两万字,分上下两篇,上篇是中台篇,介绍中台相关的通用话题和业务中台,下篇是数据中台篇,专门介绍数据中台。只对数据中台感兴趣的朋友可以跳到下篇。两年前读过的老朋友完全不用担心内容重复,和刘润老师不同,虽然我的核心思想是一脉相承的,但内容囊括了这两年的很多进展,总体丰富很多。王健老师也是这样,虽然两年前写了系列文章,但专栏进一步提出了方法论。钟华老师的思考则是突破了中台上升到企业数字化转型的大局观。我们都在要求自己进步。「中台篇」01中台是怎么来的大家都知道中台是阿里提出的,问题是阿里为什么会想到中台这一招。关于这个缘由,有正史和野史两个版本。1.
2021年7月25日
其他

搞ERP的和搞低代码的别鸡同鸭讲,还是走着瞧吧

ERP界大咖果总写了一篇炮轰低代码的文章《低代码,不要以比“中台”还快的速度臭大街》,引起了一些朋友的共鸣。果总的理由主要是两条:1、企业做好数字化重要的是管理和业务经验,技术不是本质;2、低代码不是啥新鲜玩意,几十年前的VB、Delphi、PB等早就是低代码了,也没见他们干掉ERP啊。果总炮轰低代码可能是因为也不知道哪位搞低代码的把某大企业的高管忽悠的不行不行的,以为有了低代码分分钟就可以自己搞系统,不用整ERP了。结合最近Tesla用低代码25个人4个月就自研一套ERP的消息满天飞,这当然就动了ERP的奶酪了。果总当然要为ERP出头反击了。我觉得啊,果总反击的确实挺有道理,但无关宏旨。未来还是有ERP,ERP作为企业管理最佳实践,自然不会消亡,就连我司这样的互联网企业也是会买些ERP模块的,但未来更是低代码的。ERP没什么不好,只是新的时代开始了而已。ERP,曾经是一个企业最核心的信息化系统。但是现在我们看数字化程度高的企业,有几个认为ERP是最核心的系统的。消费互联网企业,花在C端应用上的软件研发投入十倍、百倍甚至千倍于在ERP上的投入。这些C端应用,可是ERP所能提供的么?产业互联网的贝壳,他的核心是ACN网络,请问哪家ERP厂家能卖一套ACN网络ERP给贝壳的么?ERP厂商很懂管理,你懂怎么管理几十万房产经纪人吗?再看银行,软件研发投入巨大,都纷纷成立科技公司了,他们是靠ERP来展业的吗?ERP,正如老兵不死,但会慢慢凋零。凋零的意思是那朵花还在,但不再绽放色彩。坚定的看好低代码,不是因为我觉得用低代码就可以分分钟自研ERP。软件定义世界,企业有大量大量的地方可以用软件来改进提升,都是低代码的菜,何必去掺和ERP的事。比方说音乐版权采购的小组就会整个小系统来方便管理版权;音乐会员运营部门会整个小系统来做会员运营;测试部门需要个小系统来管理测试手机;企业文化部门要整个小系统来管理与用户在一起的案例;技术委员会要整个小系统来管理专利的申请和评选。企业不是没软件需求,而是被高昂的软件研发门槛和成本抑制了,其实每个管理者都很可能借助软件来做一些管理。低代码可以把这个门槛一下子打开,会不会有巨大的软件需求增量爆发出来?我觉得很有可能,据资料说微软每个月都有8万员工在用Power
2021年1月15日
自由知乎 自由微博
其他

我已经不能理解阿里说的中台是啥了

阿里是中台这个概念的创始人,阿里人在中台这个方面,也扎扎实实的写了两本很不错的书。所以国内搞中台,肯定都会先看看阿里是怎么说的。我们的实践表明,对于比较复杂的组织和业务,中台是好使的。确实能加快前台的创新。但是做中台很不容易,数据中台相对好一些,但是一般也要半年才能明显出效益,业务中台尤其难,一年出明显效益算是很不错了。很多时候是压根下不了决定去做业务中台。本来我们提出了一个好的概念,搞的国际权威机构(如Gartner)都对付不了,在当前这个国际形势下,要说是国人在组织管理理论的一大突破也不为过。但是这两天阿里说要3年帮客户建100万中台的说法,着实让我们理解了半天。最后结论是,理解不了,因为错了。阿里这次推出的中台支撑产品,除了原来的Dataphin和Quick
2020年6月10日
其他

人生不过几次关键的选择

40岁快要过去,平均而言人生进入下半场。有必要总结一下,继往开来。为什么今天我在这,其实回望也就几个关键选择。1、选择读高中上大学,而不是读中专。那个年代我们农村的学习尖子喜欢读中专,因为很快就可以工作赚钱。但是我从来没有读中专的想法,因为爸爸和哥哥都是大学,而且我觉得自己怎么可能考不上大学呢?实际上那一届考上重高就我一个。2、选择到浙江大学信电系,没有去清华大学化学系。因为我高中学习也很好,所以浙大和清华都给了我保送机会,但是浙大允许我随便挑专业,而清华必须化学系。我不喜欢化学,喜欢电子,就选择了浙大信电系。3、选择从信电专业转到计算机专业。幸运的是入学后通过的选拔进到了混合班,给了我两年之后重新选择专业的机会。一上大学学习C语言就非常喜欢编程。我感觉只要会编程,一个人用一台电脑理论上可以做出任何的东西,感觉就是一个造物主。上机排不上时间或假期回家没电脑就在纸上写程序,记得大一寒假回家手写五子棋人机对战程序,有五百多行,寒假回来,就兴匆匆的冲进机房输进去。大一下混合班有了专属机房,基本上都有位置。周末两天都是早上扛着两瓶矿泉水和一袋面包,在机房待一天。互联网也给我感觉有很多很多的应用。当时下铺的兄弟是杭州人,家境好,有一台奔腾MMX电脑,我们集体到他家观摩,让我们艳羡不已。大二一开学,我们寝室七个人又集资买了两台电脑(那时一台电脑也要6000多,实在是贵),拨号上网可以看搜狐、收发邮件,后来还有了九天音乐,这让我觉得互联网很牛。我是摇滚乐爱好者,之前只能买磁带,选择很少,九天音乐的曲库之丰富真是让我赞叹。这样,大二结束重新选专业时,我选择了计算机。4、选择做数据库方向,并为此换了个导师。大三时接触到数据库的课程。我学了课程教材,意犹未尽,又去买了在数据库实现方面讲的更细的教材。学校课程还要求几个人组队做一个数据库原型系统MiniSQL。学完、做完之后,我觉得这个领域我非常喜欢,比之前也琢磨过的图形学还喜欢,因为数据库工程性很强。但当时跟的导师不做这个方向,还让我去做很多纯粹应用性的开发。我很喜欢孙建伶老师讲的数据库课,也知道孙老师实验室一直做数据库方面的研究,我就下定决心转到孙老师门下。原导师脸色及其难看,估计很少遇到这样的学生吧,在那个年代。如果我不换,后面就不会有进入到航天系统去做国产数据库那样的机会。5、选择没出国。混合班有一半人都出国了,我选择做土鳖。一方面是因为我搞不拎清出国的意义,我在国内也能买到一样的电脑和软件,能上全世界的互联网呀。另一方面,我觉得选择去哪不要看总量,看增速,中国发展多快。人生如炒股,道理瞬间明白。我想透了这个道理,就从来没浪费时间在新东方上。6、为了做实际的数据库开发,选择读研究生,并且后来继续读博士。本科毕业时我还没机会真正的去做实际的数据库系统,而我所在的实验室有机会去做。所以我选择继续读研究生,等等看,但一开始没有选择读博,因为我不知道是否真有机会。幸运的是研二我们课题组跟航天开始合作去做真正的大规模的数据库系统,我负责做执行器。项目刚开始做,就要选择是否硕转博。为了继续做这个项目,我选择了继续读博。这个项目直到2014年初才告一段落,我们做的神州OSCAR数据库以远超第二名的成绩拿到的评测第一名,这让我非常的自豪。7、选择加入网易杭州研究院。本来我想可能去Oracle、微软,因为他们做顶级的数据库及其他系统软件。非常幸运的是,因为同学的介绍,我把简历投给了网易。其实那个时候我以为网易就是一家游戏公司,而我是一个除了《盟军敢死队》之外几乎不玩游戏的人(不过盟敢我玩的好),所以兴趣并不大,仅仅是因为同学让我投个简历,后来HR让我去广州面试也没去。那时在北京做项目996,哪有时间。但没想到,丁后来到北京时找我聊,好像也不是面试,主要就是描绘愿景。他说想在杭州成立一个研究院,互联网相关的所有的事情都可以尝试。比方他说未来每一辆自行车都会联网,我印象很深。我听了之后,觉得我去Oracle或者微软是学习,到网易我可以折腾新东西,而我喜欢折腾新东西。网易杭州这边虽然只是丁的一个设想,毛都没有,但是在互联网这么大的一个范围里面,肯定有很多机会。8、最后一个选择就是我选择一直留在网易杭研,一直在目前的岗位上。我的工作从来没变过,就是持续了解业务需求和学习技术,并带队做出实用的系统促进业务发展。这让我可以一直专心的去学习整个互联网技术的各个领域。我在杭研如果从最开始和丁接触算,已经超过了14年。我觉得我前面的所有选择非常重要,但似乎是为了这14年的坚持做储备,因为从初中毕业到决定来网易,才11年。上面说的是学习、工作和事业。家庭的选择也很重要,我很幸运的是我选择了一位非常好的妻子,我觉得她是很正直、很善良也勤奋的一个人。养育孩子,我觉得也是帮助自己成长,让自己能够持续保持学习。父亲有职责在学习和新知上做孩子的榜样,当年我父亲就是我的榜样。他会引入村子里别人从来没种过的蔬菜,又很善于动手,钟表自己修,家具自己做,船都自己做,还会设置很多新奇的手段捕鱼捞虾。但是父亲从来不具体管我的学习(母亲也不管),父亲反而经常说不要死读书。大儿子快要11岁了,越来越可以一起学习了。我们一起看《环球科学》、《万物》,不久前开始每周我尽量挑选一些前沿的科技资讯打印出来给他看。我取了一个名字说这叫源氏物语。吾儿知识虽然丰富,但不知道源氏物语是什么。选择这些素材的时候,我就在学习。我还把《盟军敢死队》游戏传给他,居然变成吾儿最爱的游戏,甚至超过《我的世界》。我们又选择了在去年生了第二个孩子,虽然现在还懵懵懂懂,但是等到他上小学之后,他又能够吸引我和他共同学习,我觉得这样的选择对我来说也是有益的。养育孩子,也能够让自己的知识保持年轻。我很多年前就选择了我的人生理想:做一个有现代素质素养的人。我不学习新知,就对不起我的理想。我也选择不大学习旧闻,不大认可、不大喜欢所谓的经典。这是需要勇气的,这会让自己显得很没文化。当别人引经据典的时候,我只会发一句感慨:卧槽,牛逼!当年听完丁对研究院的描绘。我觉得,卧槽,牛逼啊!所以我就来了,并一直在。人生,干脆。我要感谢时代让我有自由择业的机会。之前大学毕业国家是包分配的,但是等到我那一年就不包分配了。我听了这个消息很开心,因为这样我就能想做什么工作就能做什么工作了。草就于太平洋上空,去参加AWS
2019年11月30日
其他

Rockset:最具潜力、最值得加入的大数据初创公司

Rockset是一家在国内还几乎一无所知的云原生系统软件初创企业,当然云原生系统软件这个名词现在还不流行,那么可以称Rockset为一家大数据企业。在微信上搜索Rockset,只有两篇文章,加起来阅读量才两千出头。其中一篇将Rockset位列今年最具潜力的20家科技初创公司之一,另一篇将Rockset列入今年最值得加入的25家公司之一。这是一家什么样的神奇公司?我找到Rockset并深入去研究它,是因为我在定向研究云原生系统软件这个主题(可以参见之前的公众号文章再谈云原生时代的系统软件),自然的关注云原生的KV系统,这样就发现了RocksDB
2019年8月22日
其他

数据库泰斗DeWitt:Shared-nothing架构落幕,Shared-storage架构归来

前阵子对云原生系统软件的主题做了一些研究思考,觉得有了比较清晰的思路后,我开始进一步研究业界对这个问题的看法。之前我曾经提出一种观点,在云时代应该重点考虑shared-storage架构,现在发现数据库界泰斗级人物DeWitt也有类似的观察和发现。David
2019年8月12日
其他

网易杭研的中台往事。网易杭研,中台的长期实践者!

网易杭研的中台往事。我们面临的是一个VUCA的时代,控制论告诉我们及时反馈、调整才能到达目标,越来越多的市场变化因素使得顶层设计和长期预测变得几乎不可能。建设好中台,以便组织能更快速的响应变化,是对的方向。这是中台系列的第三篇,第一篇《什么是中台,什么不是中台》厘清中台概念,第二篇《怎么建设中台》介绍了建设中台的方法,这篇介绍网易杭研在中台道路上十多年的探索和经验教训,并补充在中台组织管理方面的方法。今天的网易已经到了大学毕业的年龄,游戏、零售、音乐、教育、门户、邮箱、网易云等业务板块都有了明确的形状。时间倒流回到14年前,那时的网易8岁,才上小学二年级。当时的网易,已经有最大的中文邮箱和广大的邮箱用户,三大之一的门户,还有开创了风气之先的现金流业务
2019年8月8日
其他

怎么建设中台。业务中台和数据中台的组织、支撑技术和方法论

敏感数据的脱敏处理、数据加密(特别是将数据托管在第三方平台之上时)、数据泄漏防护(比方说一种常见的方法是限制将数据下载到本地的数据量)等技术。发展到高级阶段甚至可能还需要联邦学习、数据沙盒等技术。
2019年8月5日
其他

再谈云原生时代的系统软件,创造一个开放、无锁定、低成本的技术体系

公有云和K8S将成为未来系统软件的标准底座,系统软件将面临非常不同的技术环境,也要考虑公有云垄断资源之后的市场环境。系统软件应采取多云、开源的市场策略,采取跨区域复制、replication-free、share-storage等设计,充分借助云环境优势。系统软件可望出现一波云原生的创新高潮,并带来一个更加开放、无锁定、成本更低的技术体系。未来云原生设计的系统软件可望将存储成本降低75%至90%。前文云原生时代的系统软件介绍了云计算的发展趋势及其为系统软件发展带来的技术环境上的变化,汇总了技术趋势,但对技术落地思路、经济模式等方面未做全面覆盖,本文希望能够从更多的视角再谈一谈这个话题。云原生下的技术环境1虽然云原生没有标准的定义(甚至云都没有),但云做了这么多年,技术架构和市场格局大致已定,所以我们只需要看当前实际情况来分析云原生的技术环境具备哪些主要特征,并分析如何应对。首先我认为未来主流的云原生技术架构是趋同的,就是当前主要几家公有云厂商的架构,原因在于:公有云很快会成为主流。欧美早就是主流,就连中国这样一个很多企业不敢上公有云的地方,据最近信通院的统计,公有云也很快会赶超私有云。另外公有云的增长率大幅超过私有云。未来可能一些超大的企业仍会部署私有云,但技术特征会跟公有云的架构一致,因为这个世界很难再造出一套不一样的大规模云架构。这些企业很可能是AWS
2019年8月1日
其他

什么是中台,什么不是中台。所有的中台都是业务中台

搜索推荐中台:这两个中台比较像,因为搜索和推荐的技术比较相似。这两个中台一般是为推荐和搜索系统提供一套相对标准的工作流程,同时支持流程各环节的可定制能力,从而支持多个前端推荐搜索业务的快速开发。
2019年7月30日
其他

云原生时代的系统软件

系统软件发展将走入云原生时代1据最近信通院的统计,就连中国这样一个很多企业不敢上公有云的地方,公有云的体量都很快就会赶上私有云,当然欧美公有云早就更占主流了。增长率方面,公有云也早就大幅超过私有云。此外,私有云市场还很可能被AWS
2019年7月22日