影响范围：
所有使用了阿里云盘，并启用了多副本或主从切换的服务，如：MySQL、Redis、MongoDB、DRBD、Hadoop 以及用户自行开发的应用程序等。
表现症状：
当发生网络分区等云盘不可用故障时，上述依赖于云盘的服务无法正常完成主从切换和故障转移等操作。所有用户的请求都将被无限期挂起，系统无限期不可用。
故障原因：
不同于物理磁盘和 RAID 卡等真实设备，ECS 实例在其挂载的阿里云盘不可用时，不会向上层文件系统和应用程序汇报 IO Error，而是对该 IO 请求进行无限次的循环重试。导致上层文件系统和应用程序发生 IO Hang 并永久挂起直至阿里的运维团队成功排除故障。在这段可能几小时甚至数天（参考阿里云香港等机房故障的恢复时间）的时间周期内，系统不可用。
注：阿里云盘可用性 SLA 为 99.95%，年均不可用时间 4.5 小时左右。详见：https://help.aliyun.com/knowledge_detail/40683.html 中的“2.8. 服务可用性”小节。
最新进展：
阿里云在我提交的工单（工单编号: B974JAC），以及我与其产品经理、技术支持和研发技术等的多方电话会议中均确认了存在此问题，但拒不承诺会解决此问题，理由是：“这个问题目前为止就您一个人反映过”。这是电话会议中他们的原话。
我相信除了小白用户以外，只要部署了高可用集群的兄弟们都能非常明确地明白此问题的严肃性和严重性。
此问题归根结底是由于云盘未遵循真实物理设备的行为规范而造成。阿里云的表现却非常让人失望：
1.在开始先是打太极拳，说这些信息涉及公司机密，不能透露。在我反复追问并投诉：我只想了解在云盘不可用时，我的应用程序发出的读写请求能否返回 IO Error。这种需要暴露给应用的接口行为为何属于公司机密？以后，终于才有人着手回答我的问题。
2.问题回答的非常含糊，不断试图用其数据可靠性 99.9999999% 来混淆其 99.95% 的服务可用性。
3.推卸责任，建议用户使用一个可能引发数据丢失、数据错乱、系统崩溃等未定义行为的第三方驱动来解决问题。那不是把问题越解决越严重么？把一个一段时间不可用的问题生生“解决”成了数据可能永久丢失和错乱的问题？
4.继续推卸责任，建议用户重新编写其应用程序，将其中所有磁盘 IO 都转发到一个专用线程执行，在加上另一个线程来实现超时强制关闭。首先，问题的根源是阿里云盘的行为不符合业界规范，凭什么要用户来为此买单？其次，用户除了自己的应用需要访问磁盘以外，还会用到其它第三方产品，如：Oracle、SQL Server、MySQL、MongoDB 等等。第三方产品千千万万，有开源的，也有闭源的，用户改的过来么？
最后，对于大部分产品来说，所谓“将所有磁盘 IO 都转发到一个专用线程执行”工作量是非常大的，这最少意味着将同步语义转变为异步语义。更有甚者，MongoDB、Varnish、SQLite 等很多 DBMS 类产品均使用了文件映射机制来优化文件缓存和加速 IO 访问效率。在以文件映射方式来访问磁盘时，磁盘 IO 被转换成了内存读写，这时难道让用户专门建个线程去处理内存访问请求？那文件映射还有意义么？
如此种种，在经历了近一个半月的艰苦沟通之后，阿里云才算承认“这确实是个问题”、“您说的确实有道理”，但仍然拒不改正，理由就是可笑的“别人没提过”……
为此，我恳请各位多多转发，并向阿里云提出意见，敦促他们尽快改进！
附上截止至发文时的完整工单截图：http://baiy.cn/tmp/io_hang_bug.png
2017-3-1 补充：担心已变为现实，此问题今天凌晨在阿里云杭州可用区 C 发生，以下是我收到的官方故障通知邮件：
2019-3-3: 一直拖到现在仍未解决：http://baiy.cn/tmp/B974JAC.png，其组织官僚气息严重，先是不断推诿责任，后来终于承认有问题了也各种拖，迟迟不 fix。。。这下终于拖到出大事了吧 。。。2019-3-3 阿里云大面积宕机3小时。。。