Крупный сбой в инфраструктуре Google Cloud 1 сентября 2026 года произошёл по неожиданно простой причине: во время планового обслуживания инженер последовательно отключил все оптоволоконные соединения сетевого оборудования в одной из зон региона us-central1. На это потребовалось всего 13 минут. В результате объём проходящего через затронутый сегмент трафика упал на 100 %, а часть виртуальных машин оказалась недоступна извне.

Инцидент наглядно показал, что даже сложная отказоустойчивая инфраструктура с резервными маршрутизаторами, независимым питанием и несколькими сетевыми соединениями остаётся уязвимой перед человеческой ошибкой. После определения причины специалисты Google перенаправили трафик через работоспособное оборудование, а затем физически восстановили отключённые соединения. В общей сложности проблемы продолжались более четырёх часов.

Что произошло в Google Cloud

Сбой затронул инфраструктуру Google Cloud в Айове и начался 1 сентября в 07:41 по тихоокеанскому времени. Нормальная работа была восстановлена к 11:52 PT.

В опубликованном разборе происшествия Google объяснила, что причиной стала ошибка при выполнении стандартной процедуры технического обслуживания. Инженер работал с сетевым оборудованием и начал отключать оптоволоконные соединения.

Проблема заключалась не в отказе одного кабеля или маршрутизатора. За 13 минут специалист отключил 100 % оптических соединений, относящихся к обслуживаемой инфраструктуре.

Действия выполнялись настолько быстро, что существовавшие механизмы обнаружения проблемы не успели остановить процесс до того, как связь была потеряна полностью.

Трафик упал до нуля

Последствия оказались весьма серьёзными. Google сообщила, что в наиболее тяжёлый период инцидента объём трафика через затронутую часть сети снизился на 100 %.

Для клиентов это выражалось в недоступности некоторых виртуальных машин и резком увеличении потерь пакетов. Сетевые маршрутизаторы, обеспечивавшие внешнее подключение, фактически перестали выполнять свою функцию после отключения оптических линий.

При этом сами виртуальные машины продолжали работать. Более того, некоторые ресурсы внутри зоны всё ещё могли обмениваться данными между собой. Основной проблемой стала именно потеря внешней сетевой связности: пользователи больше не могли нормально обращаться к своим системам.

Получилась довольно неприятная ситуация — вычислительные ресурсы существуют и продолжают работу, но добраться до них извне невозможно.

Почему не помогло резервирование

Современные облачные дата-центры проектируются с расчётом на отказ отдельных компонентов. Google использует резервирование маршрутизаторов, независимые источники питания и несколько оптоволоконных соединений.

Архитектура способна переживать одновременные отказы нескольких элементов. Однако в данном случае проблема возникла на другом уровне: инженер последовательно устранил сами резервные пути связи.

Иными словами, резервирование работало до тех пор, пока оставался хотя бы один доступный маршрут. Когда физически были отключены все соединения, переключаться инфраструктуре стало попросту некуда.

Именно поэтому человеческий фактор оказался способен обойти защиту, рассчитанную на аппаратные и сетевые неисправности.

Как Google восстанавливала работу облака

После обнаружения причины специалисты компании начали переводить трафик с отключённого оборудования на исправные мощности в других частях региона.

Это позволило постепенно вернуть клиентам доступ к ресурсам ещё до полного восстановления первоначальной конфигурации.

Параллельно инженеры подключали отключённые оптоволоконные линии обратно и возвращали сетевую инфраструктуру в штатное состояние. Полное устранение последствий заняло несколько часов.

Таким образом, для восстановления потребовались сразу два процесса: программное перенаправление трафика и физическое возвращение кабельных соединений.

Google собирается изменить процедуры обслуживания

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

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

Это важный вывод из происшествия: полагаться только на инструкции недостаточно. Если неправильная последовательность действий способна отключить целую часть облачной инфраструктуры, защита должна существовать не только на бумаге, но и непосредственно в технических процедурах.

Человеческий фактор остаётся проблемой даже для крупнейших ЦОД

История Google Cloud далеко не уникальна. Ошибки сотрудников регулярно становятся причиной серьёзных инфраструктурных происшествий.

Летом 2025 года действия австралийских военных привели к масштабным радиопомехам на побережье Новой Зеландии, затронувшим Wi-Fi и другие беспроводные системы. В другом громком случае проблемы с инфраструктурой австралийского оператора Optus привели к недоступности экстренных вызовов, после чего выяснилось, что существенную роль в развитии аварии сыграли организационные и технические ошибки.

Исследования Uptime Institute также показывают характерную тенденцию: крупные сбои инфраструктуры происходят реже, однако последствия серьёзных аварий могут оставаться весьма значительными.

Иногда резервирования действительно недостаточно

Случай с Google Cloud хорошо демонстрирует пределы классической отказоустойчивости. Можно установить дополнительные маршрутизаторы, провести несколько независимых линий связи и предусмотреть резервное питание, но всё это мало поможет, если процедура обслуживания позволяет последовательно отключить каждый элемент защиты.

Поэтому главным последствием сентябрьского сбоя, вероятно, станет не просто очередное напоминание сотрудникам внимательнее читать инструкции. Для гиперскейл-инфраструктуры гораздо надёжнее построить процессы так, чтобы критическую ошибку было технически сложно или невозможно совершить даже при неправильных действиях человека.

А история о том, как часть инфраструктуры одного из крупнейших облачных провайдеров мира удалось изолировать от внешней сети за 13 минут обычным отключением оптоволоконных кабелей, наверняка ещё долго будет фигурировать в качестве весьма наглядного примера человеческого фактора в IT.