必发bifa将核心业务搬到云上，车企仍有疑虑。滴滴出了这个娄子，对车企的“上云热情”，可能起到反向推动作用。

　　自从去年被国内监管机构处以史上最高的80亿元罚金以来，滴滴一直比较低调。没想到11月27日22时到28日10时的系统闪崩，11多个小时无法全面恢复，又让其成了显眼包。

　　虽然2022年之前，滴滴几乎每年（除了2017年）都出现服务故障，但没有一次像这次时间如此之长、波及如此之广，而且所有业务板块均被击穿、后台服务全部宕机，就连官网都呈现空白页面状态，客服热线也无法接通。全国各大城市的司机和客户，均体验到千奇百怪的服务错误。

　　11月28日上午，就有人认为，滴滴这种复杂的LBS（基于地理位置数据而提供服务），只有在“基础层”崩溃，才符合全面瘫痪、多次试图拉起未能成功的故障模式。黑客攻击只能访问到应用层，很难突破业务之间的隔离，更无法访问基础层。

　　所谓基础层，就是指云服务器当中负责数据存储、处理和传输的部分必发bifa。简单说，就是互联网数据中心（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/车/天）都搬到云上，会带来巨大成本，带宽也不支持。更好的方式，则是利用边缘计算，在本地（车端）就对数据实时提炼、处理和计算，将特征值上传云端，而车端则建立边缘数据库（即原始数据的压缩筛选）。

　　可见，即便对于自动驾驶模型训练的需求而言，即时性要求同样不高。而智舱服务即时性要求更是软性的，可以利用缓存、预载来过渡，即便娱乐性功能崩了，也不会带来太大损失。

　　自动驾驶此前曾经拼命鼓吹的云端指挥系统，则因为现在智慧交通基础设施尚不存在，属于画饼阶段。而高精地图+本地智能的模式，本来对云服务的即时性有一些要求，但现在这条路径大部分被无图模式取代了。

　　至于集团云、供应链云（暂时用百度的名字指代）必发bifa，对实时性要求也比较低。这样看来，汽车企业云服务，就算运维崩了，也不会遭遇滴滴那种级别的财务和品牌声誉损失。

　　不过，汽车云有自己独特诉求。汽车企业不愿意将核心运营与服务，统统采用云计算。这相当于将核心数据交给外包方掌握，这一部分难免持谨慎态度。主机厂的方案，可能是私有云+公有云的混合方式，核心运营数据放在私有云上。

　　理论上，无论公有云、私有云，还是混合云，都采取密钥和防火墙保护用户数据必发bifa。但是如果自己的IDC崩了，就意味着灾备也没起作用（灾备有效拉起，客户就根本感受不到），只能组织人马抢修。

　　滴滴这种花了10多个小时才稳住阵脚，说明在运维人力和技术上，存在管理漏洞。

　　很多人都说滴滴或者阿里最近连续出事，可能是将资深技术人员裁掉了。这种说法当然只是猜测，但出现历史上后果最严重、损失最大的系统崩溃，不会只是技术原因。预案没有起作用，充分说明了管理因素是主要的。

　　可以预见，2024和2025两年，车企的双智服务，即时性要求上升并不快，除非出现新的服务模式。而将企业核心业务搬到云上，车企仍有疑虑。滴滴出了这个娄子，对车企的“上云热情”，可能起到反向推动作用。至少与客户即时体验强绑定的云业务，步子暂时不应该迈得太大。【版权声明】本文系《汽车人》原创稿件，未经授权不得转载。

　　声明：本文由入驻搜狐公众平台的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。