影響范圍：
所有使用了阿里雲盤，並啟用了多副本或主從切換的服務，如：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小時。。。