在云时代，如何应对云端资料存储突发故障？

说实话，AWS的S3是我见过的可靠性最高的公有云对象存储服务，基于AWS的“Design for Failure”原则S3面向故障恢复做过充分设计的（详细可以去了解一下AWS的7大设计原则）。但这次人为的故障场景确实没有被覆盖，从而导致了大范围服务不可用，后续aws也作出了改进方案（最小资源数、部分重要服务最小化方便快速启动恢复等）。从整个事件的发生和后续处置和改进过程来看，公有云服务持续在各种故障和怀疑声中加速前行。另外，还需要回顾一下公有云中关于基础设施层的两个关键抽象概念：Region区域、Avaliable Zone可用区，区域是一个提供服务一致性的能力抽象；可用区可以理解为就是物理相互隔离的网络、供电等基础设施区域，作为故障隔离的边界。不同的AZ之间相互独立不受影响，而在同一个Region内的不同AZ之间的服务能力是一致的（最关键的是网络延迟很小，这个很重要）。而对于AZ内存储服务基本上都会有高可用的技术方案支持，比如数据多副本、镜像等等。

终于可以跟这个问题有些关系了：）

一、我想说的是为了避免云端存储故障带来的影响，要先问问自己要面对哪种级别的故障，RPO和RTO的需求到底是多少（书面一点叫业务影响分析）。我理解合理利用公有云本身的高可用设计远比跨云做数据容灾来的容易（很多是物理限制，比如AWS到阿里云网络延迟和带宽成本谁解决的了），最简单的就是跨AZ部署自己的应用和数据做到负载均衡，数据跨AZ进行准实时的异步复制、备份都可以；至于跨Region或者跨公有云（AWS到青云、阿里云、企业自己的私有云等）以目前的技术限制都无法实现理想的RPO，也就是说除了问题数据丢的量和恢复时间都无法达到预期。

二、数据的可靠性远大于可用性，就这次AWS S3故障而言只是影响了可用性，没有真正的丢失数据，这已经是很好的结果了。就像墨菲定律说的会出错的总会出错，小到单个企业都会有大大小小的生产事故，更何况大规模运营的公有云。所以，选择提供高数据可靠性的服务商和技术，增加自己在业务架构层面的高可用设计是我认为比较好的方法。所谓业务架构层面高可用设计我觉得除了面向跨AZ进行业务部署和逻辑架构设计，实现水平扩展的分布式架构。

最后，还需要补充业务连续性计划方面的手段，比如应急情况客服安抚、赔偿、挽回声誉等等。因为技术还在不断进步和完善，总有我们预想不到的问题发生，需要我们配以非技术手段应对。

以上是个人观点，逻辑稍乱，请见谅。