Один інженер залишив частину Google Cloud без мережі: що сталося під час звичайного обслуговування

Звичайне технічне обслуговування в одному з дата-центрів Google перетворилося на багатогодинний збій хмарної інфраструктури. Інженер компанії під час планового розширення мережевого обладнання випадково послідовно від’єднав усі оптоволоконні лінії в частині дата-центру, через що низка сервісів Google Cloud стала недоступною для деяких клієнтів.

Інцидент стався 1 вересня 2026 року в зоні us-central1-b. Як випливає з офіційного попереднього звіту Google Cloud, проблеми почалися о 07:41 за тихоокеанським часом США, а повністю роботу сервісів вдалося відновити о 11:52. Таким чином, збій тривав 4 години 11 хвилин.

Що саме зробив інженер Google

Причина інциденту виявилася незвичайною для настільки великої хмарної платформи. Співробітник Google виконував планове збільшення пропускної здатності маршрутизаторів дата-центру, які обслуговували частину потужностей зони us-central1-b.

Інфраструктура Google спроєктована таким чином, щоб вихід з ладу одного пристрою або окремого оптоволоконного маршруту не призводив до помітних проблем для користувачів. Компанія використовує кілька маршрутизаторів, фізично розділені мережеві траси та незалежні джерела живлення. За нормальних умов така схема дозволяє пережити навіть кілька одночасних відмов.

Однак цього разу проблема була не у відмові обладнання. Через процедурну помилку під час обслуговування інженер почав послідовно від’єднувати оптоволоконні кабелі одразу від усіх мережевих пристроїв у відповідному сегменті.

У Google повідомили, що протягом приблизно 13 хвилин було відключено 100% оптоволоконних маршрутів, які забезпечували зв’язок у цій частині інфраструктури. Дії виконувалися настільки швидко, що система попередження не встигла повідомити інженера про критичну помилку до того, як останній мережевий шлях також був від’єднаний.

Резервування не допомогло через незвичайний сценарій

Ситуація цікава тим, що сама система резервування Google, судячи з попереднього звіту, працювала відповідно до задуму. Вона була розрахована на відмову окремих пристроїв, кабелів або навіть кількох незалежних мережевих маршрутів.

Але архітектура не змогла компенсувати ситуацію, коли під час фізичного обслуговування були послідовно відключені всі доступні канали зв’язку в ураженому сегменті. У результаті частина обчислювальних ресурсів фактично опинилася ізольованою від мережі.

Клієнти не могли підключатися до своїх віртуальних машин, а самі віртуальні машини втратили можливість встановлювати з’єднання з ресурсами за межами відповідної зони.

Які сервіси Google Cloud зіткнулися з проблемами

Інцидент торкнувся не всієї глобальної інфраструктури Google Cloud, а лише частини зони us-central1-b. Інші зони регіону продовжували працювати. Це важливе уточнення, оскільки початкові повідомлення про збій могли створити враження значно масштабнішої глобальної аварії.

Серед сервісів, для яких Google фіксувала підвищену кількість помилок, втрату пакетів або недоступність окремих ресурсів, були:

• Compute Engine;
• Google Kubernetes Engine;
• Cloud SQL;
• BigQuery;
• Cloud Run;
• App Engine;
• Cloud Spanner;
• Cloud Bigtable;
• Cloud Filestore;
• Cloud VPN;
• Cloud Interconnect;
• Virtual Private Cloud;
• AlloyDB;
• Apigee;
• Looker.

Незалежний сервіс моніторингу StatusGator також зафіксував мережеву деградацію Google Cloud 1 вересня та проблеми одразу з декількома продуктами платформи.

Як Google відновлювала інфраструктуру

Автоматичні системи моніторингу практично одразу зафіксували втрату мережевого з’єднання. До усунення наслідків підключилися мережеві інженери Google та команда реагування на інциденти.

Частину сумісних навантажень почали переводити на справні потужності в інших сегментах регіону. Одночасно співробітники дата-центру фізично підключали назад від’єднані оптоволоконні лінії.

Після відновлення фізичних з’єднань мережевий трафік поступово нормалізувався, після чого навантаження почали повертати на відновлену інфраструктуру. Google також зупинила аналогічні роботи в регіоні на час проведення додаткових перевірок.

Для Google це важливіше, ніж просто помилка одного співробітника

Найцікавішою частиною цієї історії є навіть не сам факт випадкового відключення кабелів. Великі дата-центри обслуговують тисячі фізичних компонентів, тому людські помилки повністю виключити практично неможливо. Значно важливішим є те, що внутрішня процедура дозволила одному неправильному сценарію послідовно вивести з роботи всі резервні мережеві шляхи.

Для хмарних провайдерів подібні інциденти зазвичай стають приводом переглянути не лише технічне резервування, а й правила фізичного обслуговування. Наприклад, для критичних операцій можуть запроваджувати додаткове підтвердження дій, обмеження на кількість одночасно відключених з’єднань або автоматичне блокування процедури після втрати певної частини резервних каналів.

Саме тому історія з Google Cloud показова: навіть надзвичайно складна та дорога система резервування не гарантує абсолютної відмовостійкості, якщо існує процедура, здатна одночасно вивести з роботи всі її рівні захисту.