昨天，技術(shù)圈又出一次重大技術(shù)故障。這一故障，直接導(dǎo)致了國內(nèi)半個互聯(lián)網(wǎng)癱瘓。

[[234574]]

6 月 27 日，據(jù)網(wǎng)友反映，阿里云官網(wǎng)出現(xiàn)大規(guī)模訪問異常，圖片服務(wù)等產(chǎn)品無法正常使用，官網(wǎng)賬號也無法登陸。

這次故障于北京時間 2018 年 6 月 27 日，16：21 左右開始，16：50 分開始陸續(xù)恢復(fù)。官方給出的故障時間大概持續(xù) 30 分鐘，陸續(xù)恢復(fù)時間有一個小時多。

阿里云掛了，技術(shù)圈沸騰了，以下是各路網(wǎng)友的吐槽：

最怕就是在上線交差的時候出現(xiàn)了 Bug。

隨后，阿里云正式發(fā)布通告稱，于北京時間 2018 年 6 月 27 日 16:21 分左右，阿里云官網(wǎng)的部分管控功能，及 NAS、OSS 等產(chǎn)品的部分功能出現(xiàn)訪問異常。阿里工程師正在緊急處理中。

在 6 月 27 日凌晨時分，阿里云給了官方說明，故障起因是上線一個自動化運維新功能時，執(zhí)行了一項變更驗證操作，觸發(fā)了一個未知代碼 Bug，錯誤代碼禁用了部分內(nèi)部 IP，導(dǎo)致部分產(chǎn)品訪問鏈路不通。

阿里云稱，“對于這次故障，沒有借口，我們不能也不該出現(xiàn)這樣的失誤！我們將認真復(fù)盤改進自動化運維技術(shù)和發(fā)布驗證流程，敬畏每一行代碼，敬畏每一份托付。 ”

阿里云近年故障歷史：

• 云盾升級觸及 Bug 造成服務(wù)器大量文件被誤隔離。正是因為這一低級錯誤，影響了大范圍的用戶，造成了用 top 進程、top 命令、apt-get 相繼被滅。
• 阿里云北京機房內(nèi)網(wǎng)故障引發(fā)大面積服務(wù)異常。
• 阿里云香港服務(wù)癱瘓 12 小時主要是因為機房建設(shè)方和運營商電力故障，阿里云直到電力故障發(fā)生近 12 個小時后才得以進入機房搶修。

昨日美國媒體報道，據(jù)美國市場研究機構(gòu) Synergy Research Group 的數(shù)據(jù)，今年***季度，阿里巴巴超越 IBM 成為全球第四大云基礎(chǔ)設(shè)施及相關(guān)服務(wù)的提供商，落后于亞馬遜、微軟和谷歌。

阿里云故障，僅是運維操作失誤？

對于昨日阿里云出現(xiàn)大范圍故障，今天凌晨，阿里云官方微博公布了故障的原因，直接原因是由于"運維操作失誤"，改進措施是"復(fù)盤改進自動化運維技術(shù)和發(fā)布驗證流程"。

能坦誠的公布問題，而不是用系統(tǒng)抖動或者光纖挖斷之類的詞來敷衍大家，這一點值得肯定。

除了公告提到的增強發(fā)布流程驗證之外，重新審視系統(tǒng)整體的隔離保護體系我覺得也值得一做。故障的時間偏長，暴露了對突發(fā)問題處理手段及預(yù)案的匱乏。

一個不斷演進的系統(tǒng)，出現(xiàn)問題不可避免，反復(fù)的強調(diào)或者追求不出問題未必是***的方向，讓團隊具備快速解決問題的能力通常來說更加可行。

出了問題后，只要有相應(yīng)的手段來隔斷問題的范圍（類似大樓里面的防火門），減少對非故障模塊的干擾，通常不會對用戶整體造成干擾。

從昨天的情況來看，要么就沒有防火門的設(shè)計，要么系統(tǒng)有類似的機制，但是處理人員不能熟練地啟用。

如果是前者，則需要重新審視整體架構(gòu)，如果是后者，那就是團隊內(nèi)部需要反思的問題。

寫在***

每一次的故障確實不應(yīng)該發(fā)生，但有時又難以避免。對此，不少網(wǎng)友表示，理解身為同行的程序員們，解決問題比解決人更重要。

但是也有不少人認為：

• 出了故障可以原諒，那客戶的損失該如何算？
• 如果是沒按規(guī)范操作導(dǎo)致的事故肯定是要處罰的，否則這次事故的復(fù)盤就是無價的經(jīng)驗啊。
• 技術(shù)人員肯定得背故障啊，但是這事應(yīng)該要升級，不是說一個技術(shù)人或者開除就算了的。

注：部分素材來源于高可用架構(gòu)，其他素材是互聯(lián)網(wǎng)綜合整理。