别把虚拟化当成云服务：从滴滴故障说起

盘诚微信公众号同步发布：https://mp.weixin.qq.com/s/AmJEDeyufAPIdC0_uh59cQ

昨天晚高峰，大家的朋友圈是不是也被滴滴刷屏了？不是因为有什么优惠活动，而是整个服务突然就“瘫痪”了。行程没法开始，订单无法结束，连付个钱都成了奢望。试想一下，下班高峰期，多少人困在街头，只能盯着手机上那个转个不停的加载动画，心里估计已经把平台骂了千百遍。事后，官方将原因归结为“云厂商网络专线故障”。你看，即便是这样的行业巨头，在云面前也不得不低头。这也让盘诚想起常对学生们念叨的那句话：千万别把虚拟化当成云服务，那充其量只是把机房搬到了一个你看不见的地方。

云的便利自然是不用多说的。弹性伸缩、按需付费、全球部署，每一点都充满了吸引力。你再也不用为了应对某个可能出现的流量高峰，提前半年甚至一年焦头烂额地去采购服务器，也不必日夜操心机房的空调、电费、带宽和运维团队。如今使用云，就像家里用电一样，打开开关就能用，按用量付费。这无疑是伟大的进步，也是现在鲜有创业公司愿意再自建或托管机房的原因。但我们心里得清楚，云的核心价值在于“服务”，而不仅仅是“租用了一台台虚拟的服务器”。

很多人其实存在一种误解，觉得只要购买了云主机和存储，就等于拥有了高枕无忧的高可用服务。事实并非如此。所谓的虚拟化，主要是将一台物理服务器切割成多台虚拟机，以此来提高资源的利用率。 你买到的云服务器，通常就是其中的一台虚拟机。而真正的云服务，应该蕴含着更高级的能力，比如自动故障转移、负载均衡以及跨区域的容灾备份等等。遗憾的是，很多时候我们付了云服务的钱，得到的却只是一个虚拟化的空壳子。

还有一个很现实的问题：当底层的物理网络出现故障，比如光缆被意外挖断，或者像这次滴滴遇到的专线故障，那些虚拟机自己是不会“聪明地”逃到安全地带的。它们会被死死困在那台出问题的物理设备上，或者因为网络隔离而成为一座孤岛。这个时候，依然需要依赖人工运维。工程师们必须在警报响起后，迅速判断故障的影响范围，手动切换流量，并尝试重启服务。这个过程，和在自家机房里冲进去拔插网线、重启交换机，本质上并没有什么不同。如果自动切换的策略考虑得不够周全，贸然涌入的流量甚至可能冲垮其他正常的业务，引发连锁反应。我们想象中那种高度智能、全自动应对的云，在复杂的现实故障面前，往往会显露出它脆弱的一面——它的背后，依然需要大量人力的支撑。

所以啊，千万别迷信云的“智能”与“万能”。它本质上就是一个工具，一个更灵活、更高效的工具，但绝非一劳永逸的解药。滴滴这次的故障，恰好印证了这一点。即便是顶级的云厂商，也无法完全规避物理世界的所有意外。作为开发者，也作为用户，我们得保持这份清醒：在设计系统时，就要为最坏的情况做打算，制定详细的容灾计划；在选择服务时，务必看清对方提供的究竟是单纯的“虚拟机”，还是配备了高级保障能力的“真云服务”。 不要被华丽的宣传所迷惑。真正的高可用性，是写在严谨的代码里，刻在可靠的流程中，通过一次次演练打磨出来的，它无法仅凭金钱购得。