汽车头条App
汽车头条公众号
当前位置: 首页 正文
将核心业务搬到云上,车企仍有疑虑。滴滴出了这个娄子,对车企的“上云热情”,可能起到反向推动作用。
文 /《汽车人》黎野
自从去年被国内监管机构处以史上最高的80亿元罚金以来,滴滴一直比较低调。没想到11月27日22时到28日10时的系统闪崩,11多个小时无法全面恢复,又让其成了显眼包。
史上最大故障的原因
虽然2022年之前,滴滴几乎每年(除了2017年)都出现服务故障,但没有一次像这次时间如此之长、波及如此之广,而且所有业务板块均被击穿、后台服务全部宕机,就连官网都呈现空白页面状态,客服热线也无法接通。全国各大城市的司机和客户,均体验到千奇百怪的服务错误。
这一夜,对滴滴的运维和管理层来说,是非常混乱且困惑的。
11月28日上午,就有人认为,滴滴这种复杂的LBS(基于地理位置数据而提供服务),只有在“基础层”崩溃,才符合全面瘫痪、多次试图拉起未能成功的故障模式。黑客攻击只能访问到应用层,很难突破业务之间的隔离,更无法访问基础层。
所谓基础层,就是指云服务器当中负责数据存储、处理和传输的部分。简单说,就是互联网数据中心(IDC)。没错,在当今时代,IDC是至关重要的基础设施。只要想到一个人的绝大部分可投资资产,都存储在某些数据中心,就知道这类部门的重要性。
果然,滴滴官方11月29日再次致歉,并表示“初步确定事故起因是底层系统软件发生故障”。这样就和外界技术分析的看法接近,至少对故障模式给了大致合理的解释。
滴滴云在2018年就成立,在2020年之前,滴滴同时向腾讯云和阿里云采购“云服务”。而在2020年之后,滴滴更多将业务转移到滴滴云上,并对外提供云托管服务。今年3月底,滴滴云停止公有云服务,变成彻底的私有云。如今,就是这个私有云出了问题。
虽然滴滴官方释放的信息很少,但截至29日晚,外界猜测的故障路径,大致有两种得到较多赞同:第一种是做系统更新,激活了某种潜在隐患,将云底座、IDC都带崩了,而运维方明显预案不灵,回滚失败;第二种是IDC的数据库批量挂掉,数据一时难以恢复,作为预案的“异地多活”灾备也没起作用。
此时已经是半夜,大多数运维下班了。留下值班的人员可能缺乏经验,慌了手脚,一方面向上汇报,另一方面疯狂摇人救场。
据说搞笑的是,一些运维人员先试图在自家平台上打车未果,只能协商好报销标准,在其它平台上打车赶往云服务中心。
既然创造了滴滴史上排故时间之最,就不能再以“故障复杂”来搪塞。有没有一种可能,对IDC底层机理了解最深、任职时间最久的那一批运维,已经因为各种原因离职了。眼下的大娄子,只是新手大礼包。这可能对“世界是草台班子”做出了诠释。
有意思的是,11月12日和11月27日,业内云服务的老大“阿里云”分别出现了崩溃和故障。
有人说,此次故障对滴滴业务加速上云,起到了推动作用。这很难理解,不管是自建的私有云,还是托管在公有云,如果业务对即时性要求很高,都搬到云上是不是风险太集中了,本地服务器要不要考虑一下?
车企大规模上云的时机
和这种打车平台几乎就诞生在云上不同,汽车业虽然对“云”喊了很久,但直到这两年才大肆投资建设云端资源。
阿里云透露,其“汽车云”在国内服务超过70%的汽车企业。一汽、长安、长城、吉利、小鹏、地平线等均已上云。当然,这些客户并不专一,分别在多个公有云托管业务和数据。这可能也是鸡蛋不放在同一个篮子里的意思。
阿里云这么讲,为了彰显自身在公有云服务的地位,是有水分的。企业上云,区别大了去了,有的只作为数据备份,有的则将关键业务和数据都搬到云上,从研发生产供应链,到客户实时产生的数据,都在云端存储和处理。
迟至2022年9月,百度才开始推出三个汽车云:集团云(研产服)、网联云(自动驾驶、智能座舱)、供应链云。
阿里的“汽车云”,也几乎在同时分化为自动驾驶云、智造云、营销云三大板块。
在2022年,百度、阿里、腾讯、华为、抖音,都推出了汽车云业务,纷纷拉拢汽车企业上自家的船。全球云巨头微软和亚马逊也在兜揽类似的生意。
在自动驾驶云需求上,华为云以26.9%的市场份额(2022年数据)占据首位。华为云(名为“八爪鱼”)与本地算力(MDC)以及车载OS共同形成车云协同系统。
也就是说,直到近一两年,对车企而言,云业务才变得时机成熟且不可或缺。
云服务本质都是虚拟化
目前,智能汽车云服务已经落地的应用场景,主要有自动驾驶、车联网、车路协同及以数字营销为代表的数字化转型场景。
不管起什么名字,所有的云服务,其基本原理都是虚拟化。即将存储、计算、网络和应用等,都让其看起来是在本地服务器上的独立实体,实际上都是在共享的物理资源上运行。这也是云服务的本质。
在虚拟化的基础上,才能实现“软件即服务”(SaaS)、“平台即服务”(PaaS)、“基础架构即服务”(IaaS)。
不用管这些令人头晕的缩写,可将云服务看做一个对外租赁办公家具的服务。SaaS相当于直接提供家具,并帮助用户摆放到位,客户啥都不用管;PaaS相当于给客户提供了一批宜家式的零件,客户可以按照说明书自己组装一下使用;而IaaS则相当于给客户提供了工作台和工具,客户必须自己在板材上加工修型钻眼,完成金属件的安装,以便组装成家具。
显然,选择IaaS模式,客户拿到了计算资源(开发工具),需要自己具备一定开发能力。
即时性要求不高
面对公有云服务商,车企通常会选择SaaS和PaaS,很少选择IaaS。需要明确的是,数据虽然是“汽车云”业务的推动因素,但即时性要求并不是特别高,肯定没高到滴滴那种依赖程度。
对于自动驾驶来说,去年开始流行利用云来标注训练大模型、仿真测试。这里面的前提有两个:一个是能够上传车联网数据的车变多了,数据多到足够训练出大模型;另一个是大模型取得一系列理论和实践的突破,在各行各业都有成功运用经验。
显然,这两个前提在去年才都齐备。
当然,即便是驾驶数据,即时性要求也没那么高。原因是如果将车端所有数据(>1000GB/车/天)都搬到云上,会带来巨大成本,带宽也不支持。更好的方式,则是利用边缘计算,在本地(车端)就对数据实时提炼、处理和计算,将特征值上传云端,而车端则建立边缘数据库(即原始数据的压缩筛选)。
可见,即便对于自动驾驶模型训练的需求而言,即时性要求同样不高。而智舱服务即时性要求更是软性的,可以利用缓存、预载来过渡,即便娱乐性功能崩了,也不会带来太大损失。
自动驾驶此前曾经拼命鼓吹的云端指挥系统,则因为现在智慧交通基础设施尚不存在,属于画饼阶段。而高精地图+本地智能的模式,本来对云服务的即时性有一些要求,但现在这条路径大部分被无图模式取代了。
至于集团云、供应链云(暂时用百度的名字指代),对实时性要求也比较低。这样看来,汽车企业云服务,就算运维崩了,也不会遭遇滴滴那种级别的财务和品牌声誉损失。
滴滴闪崩加深车企疑虑
不过,汽车云有自己独特诉求。汽车企业不愿意将核心运营与服务,统统采用云计算。这相当于将核心数据交给外包方掌握,这一部分难免持谨慎态度。主机厂的方案,可能是私有云+公有云的混合方式,核心运营数据放在私有云上。
理论上,无论公有云、私有云,还是混合云,都采取密钥和防火墙保护用户数据。但是如果自己的IDC崩了,就意味着灾备也没起作用(灾备有效拉起,客户就根本感受不到),只能组织人马抢修。
滴滴这种花了10多个小时才稳住阵脚,说明在运维人力和技术上,存在管理漏洞。
很多人都说滴滴或者阿里最近连续出事,可能是将资深技术人员裁掉了。这种说法当然只是猜测,但出现历史上后果最严重、损失最大的系统崩溃,不会只是技术原因。预案没有起作用,充分说明了管理因素是主要的。
这种崩溃,对托管服务的企业客户而言,意味着巨大的杀伤和不信任。
可以预见,2024和2025两年,车企的双智服务,即时性要求上升并不快,除非出现新的服务模式。而将企业核心业务搬到云上,车企仍有疑虑。滴滴出了这个娄子,对车企的“上云热情”,可能起到反向推动作用。至少与客户即时体验强绑定的云业务,步子暂时不应该迈得太大。【版权声明】本文系《汽车人》原创稿件,未经授权不得转载。
评论 0
作者信息
更多资讯推荐