谷歌雲的自動重啟機制失靈，導致網路和 ComputeEngine 宕機 93 分鐘！

到頭來還得靠活生生的人來救駕！

不妨說說還是人來得可靠的又一個案例：谷歌近日承認，2018年1月18日谷歌雲的us-central1和europe-west3這兩個可用區中的計算引擎（Compute Engine）停運了93分鐘，根本原因出在了自動化失靈上。

谷歌將那次停運歸咎於「網路編程失效」，表示Autoscaler（自動擴展器）服務因此沒有正常運行，因而無法擴展實例組。該軟體失效意味著，新的虛擬機或剛遷移的虛擬機無法與其他可用區中的虛擬機進行聯繫。

這個雲計算市場的有力競爭者解釋了這次宕機事件，透露「傳播剛創建和遷移的虛擬機的谷歌計算引擎網路配置這項任務由兩個組件來處理。第一個組件負責提供虛擬機、網路、防火牆規則和擴展決策的完整列表。」

「第二個組件為特定可用區中的部件提供更新數據流。」

在停運期間，第一個組件沒有發送任何數據。缺少這種信息意味著，其他受影響的可用區的虛擬機無法搞清楚該如何聯繫其他虛擬機。Autoscaler服務也依賴來自失效的第一個組件的信息流來擴展實例組，由於沒有收到來自該組件的更新信息，它無法為受影響的可用區做出擴展決策。

那麼，為什麼那第一個組件失效？谷歌稱這個問題是「進程被卡殼了，結果沒有為計算引擎控制面板發送更新數據」。換句話說，原來的進程掛起了。

本來這通常不是個問題，但「自動故障切換無法強制終止進程，需要手動故障切換才能恢復正常操作。」

是的，你明白了：自動化機制失靈了，最後還是人收拾了殘局。

或者就像谷歌說的那樣：「傳播網路配置信息的任務出現停滯時，工程團隊收到了警報，他們在故障後手動切換到替換任務，以恢複數據持久層的正常運行。」

谷歌鄭重承諾，將來，「如果配置數據過時，它會停止虛擬機遷移」，並且「數據持久層會在長時間運行的進程期間重新解析對等體（peer），以便故障後切換到替換任務。」

聽起來谷歌還是要走自動化的路子。所以老兄，切忌太過沾沾自喜了。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！