饿了么“短平快”创新项目的架构取舍之道

史海峰 2018-09-10 11:11:24
本文根据史海峰老师在〖2018 DAMS中国数据资产管理峰会〗现场演讲内容整理而成。

 

(点击“此处”可获取史海峰演讲完整PPT)

 

讲师介绍

史海峰,饿了么高级总监,曾在神州数码、亚信联创长期从事电信行业业务支撑系统集成工作,参与移动、联通多个项目,具有丰富的大型业务系统研发实施经验。曾在当当负责总体架构规划、技术规范制定和技术预研推广,并负责技术委员会组织管理工作,发掘最佳实践、推动技术革新,组织内外部技术交流。负责饿了么技术创新部,2017年推出NOW无人货架,切入新零售风口。

 

大家好,我今天的分享主题是“从0到1:创新项目架构取舍之道”。大概一两年前,饿了么的CTO在会上问大家,你们觉得像饿了么这样级别的互联网公司,最重要的资产是什么?作为一个技术领导者,有没有考虑过这个问题?到底是数据、代码、客户、人才、系统?其实到最后会发现每一种资产都很重要,还有创新能力也非常重要。

 

我今天也会提到一些这方面的考虑,主要内容是以下四点:

 

  • 创新项目从0到1架构演进策略:一个项目从0到1,你要上来就搭个大的架构还是慢慢来?顾虑是对手可能比你还敏捷,中间有很多环节顾不上,别人上的我也要上,那怎么办?

  • 成熟技术体系中如何快速创新:饿了么这么大一个公司,已经拥有成熟的体系,如果想做一些创新,怎么才能实现?

  • 敏捷迭代中的技术债如何偿还?

  • 技术怎么与创新业务齐头并进?这两点都围绕技术问题展开,情况是开始可能技术不够成熟,后面功能越来越丰富,数据越来越多,是不是可以做技术驱动业务的事情?

 

一、案例引入

 

我们用一个案例来分析:去年饿了么做了无人货架这个业务,无人货架是2017年新零售行业的一个风口,很多公司的办公室里面都有。去年的9月份开始,到现在不足一年,所以还有很大的发展空间。它的作用是放在办公室里面,如果你饿了,想吃点什么喝点什么,走过去扫码就可以。

 

为什么它是新零售的风口?跟你在路边买水果直接扫码有什么区别?我们展开来讲:

 

  • 无人货架模式定位在办公室里,这是一个封闭的公共空间。如果想吃饭可以叫饿了么,但是想吃点零食或者喝点水,无人货架三十秒之内就可以拿到手,而且不用考虑我什么时候去买去囤,因为随时都可以。

  • 货架面对空间里这么多的人,核心问题是怎样最大程度地满足需求,以及在此基础上是否能给一些新的口味。甚至再进一步,在这些流量上能不能做一些拓展,架子上没有的东西是不是也可以卖,比如新鲜水果。很多公司可以看到有冷柜和热柜,热柜负责保温的,标准化的场景是可以热乎着吃,放个豆浆、包子等。所以无人货架是一个很好的零售业务场景。

  • 我们可以对接企业的需求,比如老板看大家挺累,我们来喝个下午茶,买光架子上的零食水果,大家随便吃也没多少钱。所以这个模式有很多展开空间,未来行业里,会有更多的玩法。

     

二、创新项目从0到1架构演进策略

 

 

去年8月6日业务团队提出要试水项目的时候,我们知道一些创业公司做的风生水起,甚至一些大公司比如京东、顺丰、苏宁都已经开始进入这个领域,包括后来的猎豹。这个业务上我们是后来者,后发优势就是你知道别人是怎么做的,但面临的压力也很大。试水期间(8月6~23),我们做了商品调研、业务场景调研,也提了一些解决方案,跨部门协作开发,还做了Demo在公司里试用。

 

9月6日无人货架项目立项;9月20日V1.0.0产品正式上线。整个过程看起来还比较顺利,业务总体反馈也都比较好。但是当时这个项目没有任何后端体系,比如营销后台、运营后台、供应链等,就是业务团队去买一堆货,自己往上面放,这种模式完全不可控,不具备扩展性。

 

11月20,我们打通了饿了么当时原有的供应链系统。到今年3月5,对接饿了么新零售地网供应链系统,采购仓储物流这些都打通了。CRM、预售、拼团、鲜食等都是今年上半年我们做的一些拓展尝试,下一步也会做智能货柜。

 

三、成熟技术体系中如何快速创新?

 

我们说一下成熟体系和创业公司的区别是什么。

 

 

饿了么拥有一个大型、成熟、弹性、多活的技术体系。日订单量千万级别,整个技术团队上千人,系统指标要求很高,所以基础设施必须完善,不可能靠人力天天操作;架构设计有严格的评审机制和一套规范的操作流程。2017年饿了么做了一个行业比较牛的“异地多活”,在两个机房之间可以调度流量,并做日常演练。最后就是容器化、混合云、计算力外卖等,这些关键词大家可以网搜一些文章了解一下。面对这样的体系,我们刚才说的无人货架这种短平快小项目如何应对?

 

分析一下其中优劣:

 

  • 首先要求一定是快,而且需求可能变。今天这么玩,明天一拍脑袋那么玩,即敏捷迭代,快速试错,灵活响应。你不能跟他说你能不能有点谱,因为大家都不知道该怎么玩。那优势在于饿了么有非常完善的机制,高水平人才充足,比如我们想成立一个团队,拉起来很容易。业务立项会分到某一个技术团队,前后端测试、项目管理等的磨合过程中,团队配合度已经很好。不必从0到1建设一个新的产品技术团队。

  • 但是劣势就是我们有太多条条框框,由于饿了么体系很大,架构规范严格,不可能自己再做一套用户体系,不可能自己做支付,一定得对接公司的。那就得跨团队沟通。做这样一个试水的创新项目,跟公司整体项目的级别一定是不匹配的。有时就是需要去刷脸,才能把这些提上去。

  • 最后,如果我们今天数据出了一个bug,想把数据修一下,不行。按照严格的操作流程,这个事情不能你去操作;而且要进行评估:风险有多大,一次要多少条,会不会对性能有影响。这个时候可能业务团队已经忍不了,所以其实是优势劣势并存的。

 

我们要把这个事情做成的话应该怎么办?首先得有一支能打的团队:召之即来、来之能战、战之必胜。我们搞的是一个独立的项目,全新的系统,但是所有参与项目的人,都是从各个团队拉过来的。团队都坐在一起,在“小黑屋”里,环境相对来说封闭,能更专心,更高效,更团结一心。以创业的状态进行,把所有的任务都排好然后开始开发,最后所有的任务都是完成状态。

 

上帝用七天创造了世界,我们最终用六天把这个项目做好了。期间有什么事情?除了刚才讲的攒人,还有对架构的取舍。

 

 

 

  • 微服务:虽说一开始没有那么多要拆分的微服务,但是毕竟是互联网主流架构,要把系统做得特别灵活,为了能拓展。但也不需要考虑那么远,所以有考虑,以后再说;

  • 技术栈:饿了么现成的拿过来用,大家都熟,再选择其他技术栈是不太可能的;

  • 自有的IDC:很多创业公司都是在阿里云上做起来的,我们当时也考虑说是不是干脆找个阿里云。阿里云都在自己手里头,想怎么玩怎么玩,不用关心公司的条条框框。但是最后想了一下,还是要用自己的系统。因为比如你要跟公司的用户系统、公司的用户系统、支付系统打通,你不能说我外挂一下,除非自己做。不能自己再做一套基础的体系,成本太高了。跟很多创业公司不同,他们往往数据库只有一个,反正用户数据少,能活着就行,但我们在一个体系里面,这些技术是现成的,我们要用;

  • 异地多活:有没有必要呢?有必要,但是暂时可以绕过。因为我们一般切换服务的时候是在晚上,是有人在办公室甚至熬夜到两三点钟会用无人货架,但是毕竟不是常态。我们先不考虑多活,因为实现多活更复杂;

  • 中间件:一定是公司现成的,包括数据库的中间件,数据的备份等;

  • 测试环境:也是公司现成的,同上;

  • 持续部署:需要知道谁发了什么版本,而且要有工具想回滚就能回滚;

  • 容器化:暂不考虑,我们直接来台虚拟机当成裸机来用也OK,容器化有更高的技术复杂度,我们现在只要做一个简单的业务跑起来;

  • 日志监控:日志监控这个体系是公司现成的,对当前的业务有很大帮助。当时我办公室的电视上接了个监控视图,有天早上一看,业务量爆增,我说这一定有问题,查了一下发现有人在爬我们的数据,这种情况如果没有监控,你根本就不知道。

   

四、敏捷迭代中的技术债如何偿还?

 

同样的我们欠了很多债,下面分析一下:

 

  • 业务层:包括一开始只是设置价格就进行销售,没有做营销、促销,运营的策略等。比如说在不同架子的相同的位置上摆不同的货,这些都是后来做的,一开始没有考虑,都是放上去就OK。供应链,业务级的监控,权限(运营、业务操作等这些权限),一开始也没有做那么多,是后来补上的;

  • 应用层:反爬、埋点、缓存、搜索、多活等这些也是这样。多活,刚才说了,影响不大但是是有影响的;

  • 数据层:我们一开始对用户的行为数据没有埋点收集(比如,他进来浏览了多少东西然后跳出了,或者他点了什么是不是失败的),当时没有考虑那么多。但毕竟有个基础的东西在,比如最后一个爬虫,我们做好了也可以爬别人,看看其他公司的怎么样;

  • 系统层:容器化暂时不用。

 

对于现在这个架构,我们做的取舍其实是一种选择,以最快满足业务上线,具备基本功能为目标,而不是一拍板就定了。

 

五、技术怎么与创新业务齐头并进?

 

再往下延伸,要考虑几个问题:

 

  • 调整策略,从突击队到正规军:现在我们已经有上万的点位,已经有稳定的业务,那后面如果想怎么着就怎么着,想怎么变就怎么变,想怎么玩就怎么玩,想怎么抓数据就抓数据,这个一定是有风险的。一开始,从0到1搞起来,这个阶段有点损失没关系。但是一旦业务、技术、运营都是稳定团队的话,就需要转换你的战略。不再用突击,要用正规军的方法;

  • 控制节奏,提高协同效率:我们会调整我们项目的结构,提高协同的效率,大家提前做沟通,做一些规划;

  • 合理分配资源,偿还技术债;

  • 架构规划,模块拆分;

  • 沉淀数据,智能运营:把这些数据收集起来,一个业务没准两三年以后能有更大的市场,那这些数据沉下来就是有价值的。比如前两天饿了么就在准备重启一个去年被停掉的项目,那个项目之前运行了大概两年,一旦老板决定重启,我们所有的代码、数据都还在,可以随时使用。不过要想重启,可能最大的问题是人,就是原来那些人去做其他项目了,有多少人还留在这个团队都不好说。但数据代码的资产都还在,很快就能拉起来;

  • 做减法,保持架构健康度:之前做这么多需求,业务团队有这么多想法,现在都还有用吗?不见得。很可能一个东西上来之后发现用户不买账,但它还是系统的一部分,依然天天运行着,还要考虑他的运维等,这时候做减法更能保持架构的健康度。

 

六、总结

 

所以总结一下:在风口创新里面,快一定是第一位,天下武功唯快不破。既然技术要去支持业务,那绝对不能拖后腿;但从0到1并不需要想那么多,以MVP为第一目标,不追求技术先进、架构完美。

 

还有,既然我们是一个比较成熟的体系,而且相对来说更有经验,那么我们要适度地前瞻一些。把产品、把架构设计得稍微好一点、灵活一点,将来拓展就不用改太多,不用推翻了就要重来,然后针对不同阶段、不同策略,适时做一些调整。

 

最后,技术上,先支持业务,深入理解业务,再驱动业务。一开始业务人员让你干什么你就干什么。接下来你还要深入理解,然后才能和业务的同学平等对话。如果业务是比较轻量级,2C的,这种情况下大家要互相沟通。如果你已经做的量级非常大,可能从业务、从运营的角度来讲,难以了解全国情况,比如我们做的O2O,基于地理位置不同,各地都不太一样。全国各地业务什么特点这都不好说,需要有一个强大的体系把数据收集起来,去做数据分析,去做策略指导业务,而不是靠一个人即兴的想法。所以我们要做到更好,就需要更多的数据,根据这些数据来分析用户,可以去看我们业务的趋势,能做一些更好的指导,接下来可能成为用技术驱动业务。不是说用人员驱动业务,而是一套比较大的系统,这个系统能够驱动业务,把公司业务能力固化在体系里。

 

最近一个在政府单位工作的同学和我聊起创新,创新很重要,但更重要的是有没有一个合理的体系,换句话说就是不能指望某个人力挽狂澜,不是一个有志之士想激发创新,就能创新。要靠一个公司或者一个组织,要有活力,要能保证多样性,要能够实时变化,这需要一套体系。所以在座的各位手里都有那么多数据,希望我们可以给后面的人留存更多的资产,能给我们后面的业务给予指导和帮助。

 

Q & A
 

 

Q1:快速迭代的时候,你的时间有限,像这种时间控制里面有什么东西?

 

A1:没有更多的选择,但是一旦你迭代的节奏调整过来,每个迭代多少大家都是有数的,而且一个比较好的团队有这个优势,开发一定要自测。

 

Q2:货架的数据是从哪些维度进行收集?

 

A2:比如登录网站,或者打开一个APP,你是在什么样的环境下(4G、3G、WiFi还是其他的),还有比如你使用什么样的手机、登录进来之后你先点了什么,这些都是可以记录的。最常见的,如果你前面的页面做得不那么友好,可能用户找不到他想要的东西,因为手机屏幕很小,需要翻页,那么怎么翻是合理的?一定是按照货架上的顺序吗?不见得。一开始大家都在乎货架上的顺序,从上到下第一层、第二层、第三层、第四层,但是我可能上来就想拿最底层的。或者说如果有促销,那把促销的东西放在最上面,让人看到,给他引导。这些东西可以通过你的布局操作,但前提是有数据,你才能进行设计,不然你不知道他是不是按照你预想的来做。

活动预告