該表格倒數(shù)第二行是指年宕機時間，即該等級的數(shù)據(jù)中心在一年內(nèi)能夠容許宕機的時間長度，單位為小時?？梢钥闯?，對于最高等級Tier 4來說，一年僅容許0.4小時的宕機時間，也就是24分鐘，對于Tier1來說，也不能超過28.8小時。

但是，大多數(shù)數(shù)據(jù)中心（包括很多知名企業(yè)的大型數(shù)據(jù)中心）都在一次宕機內(nèi)就完成了一年的“目標”。

結(jié)合著這一點，我們來回首一下近期影響較大宕機事故：

4月21日，亞馬遜云計算中心宕機

亞馬遜在Virginia的云計算數(shù)據(jù)中心服務(wù)由于誤操作宕機，導致大量依賴其云服務(wù)的企業(yè)利益受損，其中包括手機服務(wù)網(wǎng)站FourSquare、新聞網(wǎng)站Reddit等等。這次宕機事故，不但讓亞馬遜及其客戶受到慘痛的損失，更帶來了人們對云計算服務(wù)的信任危機。

8月8日，亞馬遜云服務(wù)由于雷擊再次宕機，不過這次僅持續(xù)1個小時。

5月26日， Skype宕機

網(wǎng)絡(luò)電話服務(wù)軟件Skype發(fā)生宕機事故，很多用戶無法登陸軟件或者撥打電話。無處發(fā)泄的用戶只得在twitter上表達不滿，更有用戶將其怪罪于微軟收購Skype的行為，因為主要是Windows版客戶端出問題。在同年6月7日，Skype再度發(fā)生宕機事故。

6月9日，Twitter宕機

Twitter當天早晨因為不明技術(shù)問題，導致API受到影響，但是宕機僅持續(xù)了一個多小時就被解決，所以并沒有造成太大影響。去年Twitter曾經(jīng)發(fā)生過多起宕機事故，最久持續(xù)6小時，而今年情況大為好轉(zhuǎn)，宕機時間較少，而且一旦發(fā)生，就能馬上解決。

7月14日，藝龍旅行網(wǎng)宕機

今年最大的一起宕機事故，事故緣于EMC存儲設(shè)備，但就其根本，據(jù)說是藝龍本身的存儲架構(gòu)不完善，才導致了如此長的修復時間。由于存儲災備的不完善，備份沒有起到應有的作用。否則EMC出現(xiàn)故障，也不至于宕機26個小時。

7月15日，谷歌App Engine宕機

谷歌應用引擎Java服務(wù)出故障，導致宕機1小時，這個問題日期相近的藝龍宕機事故來說不是特別引人注目，但是故障原因基于云計算，把應用程序轉(zhuǎn)到網(wǎng)絡(luò)上，出現(xiàn)了一些問題。最近云服務(wù)頗受歡迎，但是安全問題還是一把達摩克利斯劍。

8月3日，雅虎郵箱宕機

用戶12小時無法訪問雅虎郵箱，一開始并沒有得到雅虎的重視，隨著反映問題的用戶越來越多，才開始作出回應。原因不明。

zhabin