谈谈我对公有云故障的看法

今天，某云故障，圈子里又是哀嚎一片，我翻了下，看热闹的叫得最凶，但没几个有观点的。

我们的部分业务也受到了影响，所以，我的感受会更深一些，再加上前面几朵大云轮着挂，也让我不得不去再次反思面对这样的不确定性，我们应该怎么办？

简单分享下我的想法：

公有云自身服务的容灾和应急做的不够，这个直言不讳，云厂商至少目前，做的就是不到位。

单个机房故障，原则上，在这个机房里的云服务应该能切换到备用机房，服务影响实际是可控的，可能也就故障+切换这短时间的影响，但是对于业务而言，不会因为对该服务的依赖造成持续不可用这样的严重后果。

特别是是对于云存储、CDN、直播、负载均衡、网络接入等这样非常独立的云服务，应该属于基础必备能力才对。

但是从最近几轮各大云连着挂的情况看，在产品容灾能力完备性上做的还不够，部分服务自身都无法容灾切换，当然问题还远远不止这些。

上面情况是简单的，但是如果是对于数据库、消息、缓存等，这些跟业务逻辑强耦合，对数据时序性、数据完整性、数据一致性要求特别严格的服务，就不仅仅是要求云厂商能做到服务容灾和应急，这就要业务架构上也能够做适配才可以。

所以，业务上，要Design for Failure，如果在成本上可以接受的话，就一定要做到“尽量地”可控，这一点更多的要在自身的业务架构上下功夫，稳定性、自动化、预案、响应等等。之前讲过很多，不细说了。可以看我的极客时间专栏或我的图书，二维码和链接在最后。

其实很多公司和企业双活或容灾做不起来，并不是不想做。

一方面，成本投入会加大，这要取决于公司的决策、资金以及预算。

另一方面，也取决于技术团队的能力和积累，只有能力，不熟悉业务，或者只懂业务，技术能力跟不上，都不行，这也会对团队稳定性、人才储备和人才梯队又有要求。

从这里，我们就会发现，稳定性、高可用、容灾等等这些提了这么多年的难题，在真出问题的时候，还是会原形毕露。没有银弹，不是有了云，问题就解决了，也不是全都抛给云厂商就可以了。

这种情况下，业务和云一定是要融合成一体去看，不能割裂来看，稳定性、高可用和容灾一定是跟云服务的整套体系配套去建设，双方既然绑到了一起，那就必须绑的更紧密些才可以。

再就是自己的事情，更多的还是要靠自己，得要自己上心，自己琢磨清楚，不然别人再怎么帮也没用。

我比较反感的几种言论：

第一种，一出问题就骂各种云不靠谱的，发泄情绪发发牢骚就算了，有时候我觉得不爽了，我也会喷，但是更重要的，是想想面对这种问题我们应该怎么办。

反问一句，云现在遇到的问题，我们自运维IDC的时候，就没有了吗？

第二种，动不动就建议多云建设的，说鸡蛋不能放到一个篮子里的，特么的一个篮子都还没玩顺溜呢，再多几个篮子，能拎得动不？到时真多云了，不同云之间的服务异构问题，就能搞疯一群人。

不搞多云怎么办？这个仔细想想，我觉得不难有答案。