這是4月2日17:30~19:30之間發生在阿里雲上的故事。
標題中的“看不見”是指阿里雲的監控系統沒有監控到；“CPU在坐過山車”是指CPU占用的瞬間波動（見下圖）；“磁盤IO在蹦極”是指磁盤IO的瞬間波動。
（圖1）
4月2日17:30左右開始，訪問博客園首頁有時會遇到502 Bad Gateway錯誤，如下圖：
這是由阿里雲負載均衡SLB返回的錯誤信息。
發現這個問題后，我們立即登上負載均衡中的2台雲服務器，查看Windows性能監視器發現CPU占用波動很大（見之前的圖1），有如坐過山車，瞬間沖到100%（如果在這時訪問網站就會遇到502錯誤），然后又回落。接着，打開阿里雲網站上的管理控制台，查看系統資源監控，奇跡出現了——阿里雲監控顯示CPU占用平穩，最高也沒超過60%。
當時以為是阿里雲監控系統出了問題，於是向阿里雲提交了工單。
18:00左右，我們與阿里雲客服都未進行任何操作，CPU占用突然恢復了正常。
CPU坐完過山車后不久，18:30左右開始，我們收到用戶的反饋，說在博客后台發布博文時出現提示：“Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.”（數據庫寫入超時）。我們對這個錯誤記憶猶新，3月14日經歷過（詳見雲計算之路-遷入阿里雲后：20130314雲服務器故障經過），那次是由於雲服務器所在的集群硬盤IO負載高引起的。我們斷定這次肯定還是雲服務器磁盤IO的問題。於是又進入阿里雲網站上的管理控制台，查看系統資源監控以驗證磁盤IO是否高，奇跡又一次出現——阿里雲監控顯示磁盤IO正常。
19:30左右，"Timeout expired"錯誤消失。
我們又向阿里雲提交了工單，阿里雲客服依據監控數據，認為阿里雲自身的系統正常。我們當然不認同，我們的應用本身不會引發這個罕見的"Timeout expired"錯誤，而且這段時間數據庫寫入操作並不多。
我們查看了這段時間數據庫中的數據，發現也有不少博文正常發布了。說明當時如果磁盤IO有問題，應該是處於一種波動情況。用戶在波峰時提交，就會遇到數據庫寫入超時故障。
可奇怪的是為什么阿里雲監控系統監控不到磁盤IO的波動？更奇怪的是兩次問題，阿里雲監控系統都沒監控到。
。。。
第二天，接到阿里雲客服的電話，說我們在阿里雲網站的管理控制台上看到的監控數據是5分鍾采一次樣，阿里雲客服看到的監控數據是1分鍾采一次樣（兩處的監控都沒監控到）。對於瞬間波動，阿里雲監控系統的確很難監控到。
接了電話之后，我們分析了一下，然后豁然開朗。
阿里雲監控系統每1分鍾巡視一下我們的雲服務器， CPU坐過山車、磁盤IO蹦極發生在秒級。阿里雲監控過來巡視時，CPU已經或者還沒坐過山車，磁盤IO已經或者還沒蹦極。這種瞬間波動情況正好躲過了阿里雲監控系統的監控，就好像CPU、硬盤IO和阿里雲監控系統玩起了捉迷藏。
雖然問題只發生波動的瞬間，但確確實實多位用戶遭遇了這個問題，這就是一種故障，是故障就要找出原因。我們不害怕問題，害怕的是不明不白的問題。
於是，我們將分析情況通過工單反饋給了阿里雲。
一段時間之后，阿里雲客服的回復終於讓真相大白：在那段時間，雲服務器所在的物理機出現了硬件故障，后來緊急修復了故障。