23 июля западный регион Azure (West US) потерял сетевую связность на пять часов. Все службы Microsoft в регионе, требующие входящего или исходящего трафика, оказались недоступны. Только те, что работали целиком внутри региона, остались незатронутыми — но таких сервисов, естественно, единицы: любой облачный ресурс рано или поздно должен обмениваться данными с внешними системами, клиентами или другими регионами.
Что произошло
Microsoft опубликовала Preliminary Post Incident Review (PIR). Инцидент начался в 14:44 UTC (7:44 утра по тихоокеанскому времени) и длился до 19:41 UTC — почти пять часов. Причина — ошибочное удаление набора IP-маршрутов при изоляции устройства для планового обслуживания. Перед началом работ Microsoft убедилась, что работает хотя бы один из двух резервных путей к площадке. Однако автоматизированные системы при запуске работ захватили дополнительные устройства в периметр изоляции и удалили IP-маршруты, не учтённые в первоначальной оценке.
Дополнительным фактором стали недавние работы с оптоволокном — они могли повлиять на конфигурацию сети, которую автоматика сочла штатной.
Реакция и исправление
Клиенты обнаружили проблему почти мгновенно — снижение связности в таком масштабе заметно на уровне мониторинга за первые минуты. Инженеры Microsoft идентифицировали причину в течение первого часа и начали восстанавливать удалённые маршруты. К 19:41 UTC соединение было полностью восстановлено.
Второй значительный сбой за год
Это второй крупный инцидент Azure в 2026 году. В феврале 10-часовой сбой затронул одновременно регионы West US и East US. Примечательно, что оба инцидента связаны не с аппаратными отказами, а с ошибками в процедурах обслуживания и автоматизации. Инструменты автоматизации, призванные уменьшить влияние человеческого фактора, сами становятся источником нештатных ситуаций, когда проверочные сценарии не учитывают всех зависимостей. Этот случай — наглядная иллюстрация того, что автоматизация процедур обслуживания требует столь же тщательного проектирования границ изменений, как и сами сети.
Рекомендации
Microsoft советует организациям с критически важными данными рассматривать мульти-региональную архитектуру. Единый регион как точка отказа остаётся рискованным подходом: даже если внутри региона всё работает, потеря пограничной связности парализует сервисы, которым нужен обмен данными с внешним миром. Инцидент также подчёркивает, что автоматизация сама по себе не решает проблему надёжности — сценарии обслуживания должны проверяться на корректность границ изоляции не менее тщательно, чем ручные процедуры. Для тех, кто проектирует облачную инфраструктуру, ключевой вывод прост: мульти-региональная архитектура — не роскошь, а необходимая мера предосторожности.
Источник: networkworld.com