反向思考：阿里云这次故障里，有哪些措施面对故障发挥了好的作用？

首先，强调下中立理性思考的立场，虽然我做阿里云推广，但不是为了说阿里云好话推广阿里云。
我是做技术出身，毕业后待过 2 家公司都不出实习期就离职了，后来在一加汽车服务公司做 GPS 平台 5 年多，这期间经历过项目发展过程的多种问题，因此本文不是在说谁好谁坏，我个人经历的项目，并发设备经历过从 0 到 10 万，从物理机房到物理机房虚拟化，再到全云平台。深刻体会过每次故障处理过程的困难。借此机会探讨下如何涉及、部署这种高并发项目，今天侧重部署方面，谈谈

先用我自身举例，经历过的几个故障有（自建物理机房时期）：
1，运营商跨网故障，移动手机卡发往联通机房时候，在省节点跨网交换数据处中断。最终找移动解决，耗时接近 3 天。后来针对线路特点，加了个移动光线，移动卡发回的数据，走移动线路，用户访问网站走联通线路，解决方式算是有效，最后上云直接依赖 BGP 线路
2，物理机房时期：本市修地铁，挖断了联通光纤，半夜 3 点左右，我的外部监控发出报警，早上大约 5 点修复。我当时能做的只有打完联通某些部门电话后（而且没有客服电话，是我联系业务中，存下的某些部门电话），坐等。。。
3，地域性 dns 故障，某个城市到我们机房省份，经常出现不上线的情况，其他城市正常。最后没有什么有效解决方案，通过配置，客户端设备改为不再使用域名，换成 ip，从此绑在了 ip。负面结果是后来上云总是没法彻底迁移设备数据。
4，线路距离故障，某个省到机房总是很高延迟，经常飘红。没有效解决办法，这个故障的最终用转移到云上，华东机房方式解决。实现全国范围综合延迟都兼顾。
5，gps 业务的特点，高并发写入，硬盘写坏了好在 raid10 的存在，接近 1T 的数据库还健在运行，最终只能停机更换硬盘，半夜对外中断服务，周期很长。（最快的解决方法就是转移到另外一台机器，1T 数据万兆网卡内网传输，光拷贝过程就用了很久）

目前，关于本次阿里云故障，我总结到的有：
1，再高的可用性，都是存在不可用的时段。
我们自己的小网站不必多说，稍微一点维护，就要先关掉网站，这期间的时间都算所影响在线时长。本次阿里云故障假设按照半小时算，今年假设再没有其他故障，可用性就已经跌落到 4 个 9，99.99%
2，赔付协议很多人在故障期间都提到了怎么赔偿问题，居然真的有人说不会赔偿，显然不太可能，赔付协议是个很早就制定好的。防止的就是这种情况出现，而且今年还重新修订过一些细节。
3，网站首页单独负载
很多人都留意到了，阿里云故障期间，首页可以正常打开，只是其他功能和子页面故障，推测是针对首页高访问的一个优化方案，似乎是独立发布了首页，这个算是我在本次故障中的最大发现
4，
5，
6，
。。。