Краткое содержание

  • 25 января 2023 года в 07:08 UTC команда без подтверждённой области действия, применённая при работах по наращиванию ёмкости в Мадриде, удалила маршрутную информацию за пределами локального устройства на платформе одного из вендоров, запустив глобальный пересчёт IGP, повторное анонсирование маршрутов BGP и первую волну влияния на клиентов.
  • Операция была повторена на втором мадридском маршрутизаторе 33 минуты спустя, поскольку инженер не был уведомлён об активных предупреждениях, что вызвало вторую волну и сделало координацию между выполнением изменений и реагированием центральной проблемой ответственности.
  • Большинство регионов и сервисов восстановились к 09:05 UTC, последнее сетевое оборудование — к 09:25, однако приостановленные системы контроля состояния WAN и управления трафиком потребовали ручного перезапуска до полного устранения последствий в 12:43; поэтому восстановление было поэтапным, а не единым событием отката.

Задача с ограниченной областью достигла глобального домена маршрутизации

25 января 2023 года в 07:08 UTC инженер в Мадриде приступил к работам по наращиванию ёмкости глобальной сети Microsoft. Задача включала изменение IP-адресов на новых маршрутизаторах и их подключение к внутреннему и внешнему доменам маршрутизации сети. Физически работы ограничивались парой маршрутизаторов. Логическая область действия команды, использованной в ходе работ, ограниченной не была.

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

Это расхождение вызвало общесетевой пересчёт внутренней топологии. Затем маршрутизаторы Border Gateway Protocol повторно анонсировали и проверяли интернет-префиксы по мере изменения путей. Клиенты столкнулись с меняющимся сочетанием задержек, тайм-аутов, периодической потери пакетов, а на некоторых путях — с полной потерей связи. Инцидент затронул трафик из интернета в Azure, межрегиональный трафик и каналы между площадками, использующие ExpressRoute, VPN или виртуальную WAN. Были затронуты и сервисы, зависящие от связности Azure, включая часть Microsoft 365, Power Platform и Azure Government.

Такая последовательность делает инцидент делом об ответственности сетевой инфраструктуры, а не рядовым облачным сбоем. Если убрать очистку IGP, повторное анонсирование BGP и изменение путей пересылки, центральное объяснение исчезнет. Системный вопрос не в том, почему человек ввёл команду. Вопрос в том, почему окружающие процедура и средства авторизации не смогли установить фактическую область действия команды до того, как она попала в действующий домен маршрутизации.

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

Процедура описывала одну задачу; маршрутизаторы выполняли другую

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

Различие между локальной командой и командой, действующей в масштабе всего IGP, — не примечание в документации. В глобальной WAN инструкция, достигающая всех маршрутизаторов, подключённых к IGP, одновременно меняет набор устройств, вычисляющих внутреннюю достижимость. Инициирующий сбой, описанный Microsoft, находился внутри WAN: широко действующая очистка IGP запустила пересчёт топологии, за которым последовали повторное анонсирование BGP и проверка маршрутов.

Команда была разрешена, потому что средства авторизации Microsoft не определили глобальное поведение третьей платформы как запрещённое. Это отделяет разрешение от квалификации. Команда может быть принята системой контроля доступа и всё же быть небезопасной для контекста, в котором она используется. Авторизация отвечает на вопрос, может ли оператор действовать. Квалификация должна ответить, что сделает сеть, когда это действие достигнет конкретной платформы, программной среды и роли устройства.

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

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

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

Публичные данные маршрутизации показали возмущение, но не первопричину

Внешние наблюдатели видели реакцию сети. ThousandEyes зафиксировала отзыв и повторное анонсирование префиксов Microsoft, уход трафика с прямых пиринговых каналов к транзитным провайдерам и значительную потерю пакетов. Kentik сообщила о двух совокупных падениях трафика и сильно различающихся эффектах между путями и регионами. Некоторые префиксы были нарушены, тогда как другие продолжали передавать трафик.

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

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

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

Таким образом, записи выполняют разные доказательственные задачи. Отчёт оператора объясняет внутреннюю последовательность и состояние его собственных систем. ThousandEyes и Kentik дают независимые наблюдения за поведением маршрутов и трафика. Согласие между этими уровнями усиливает причинно-следственный вывод, тогда как расхождение стало бы поводом для дальнейшего расследования. Рассматривать один уровень как замену другому значило бы ослабить анализ.

Та же дисциплина применима и к предварительным объяснениям. Ранний внешний анализ рассматривал, могла ли автоматизация повторить изменение. Это был разумный вопрос, пока отчёт об инциденте был неполным, но это не окончательный вывод. Итоговый обзор Microsoft утверждает, что операция была выполнена повторно на втором маршрутизаторе. Поздние, более конкретные свидетельства должны иметь приоритет над более ранней гипотезой.

Тридцать три минуты превратили один сбой контроля в две волны

Событие не развивалось как один непрерывный автоматический каскад. Microsoft сообщает, что мониторинг обнаружил симптомы DNS и WAN в течение нескольких минут, и в 07:11 были сформированы предупреждения. Однако инженер, выполнявший работы в Мадриде, не был проинформирован об этих предупреждениях и повторил операцию на втором маршрутизаторе через 33 минуты после первой. Эта вторая операция вызвала ещё одну волну воздействия.

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

Интервал в 33 минуты важен, поскольку выявляет границу контроля между выполнением изменений и реагированием на инцидент. Мониторинг обнаружил проблему. Процессы реагирования начались. Человек, способный снова задействовать тот же механизм, не получил информацию, необходимую для остановки. Каждый компонент мог быть активен, но объединённая система не предотвратила второе выполнение, пока сеть уже восстанавливалась.

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

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

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

Воздействие различалось в зависимости от пути

Инцидент был глобальным по масштабу, но его последствия для клиентов не были однородными. Microsoft описывает динамические различия по источнику и назначению. Одни клиенты наблюдали задержки или периодическую потерю пакетов; другие сталкивались с тайм-аутами или полной потерей связи на конкретных путях. Kentik также обнаружила как затронутые, так и незатронутые префиксы, а не свидетельства исчезновения всех маршрутов Microsoft.

Такая изменчивость согласуется с сетью, в которой маршруты отзываются, повторно анонсируются, проверяются и переносятся на другие пути. Она не поддерживает простое утверждение, что отказали все регионы Azure, сервисы, клиенты или интернет-маршруты. Индия и части Северной Америки оказались среди путей с более длительным восстановлением, но источники не дают полного перечня по регионам.

Подтверждённые поверхности воздействия существенны и без преувеличений. Были затронуты трафик из интернета в Azure и межрегиональный трафик. Связность между площадками через ExpressRoute, VPN и виртуальную WAN испытывала проблемы. Зависимости Microsoft 365 и Power Platform, а также сервисы Azure Government, зависящие от публичного Azure, тоже были вовлечены. Отчёт не устанавливает точное число пострадавших пользователей, проверенную потерю выручки или полный список сервисов.

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

Восстановление шло слоями

Microsoft сообщает, что инженеры, проверявшие недавние изменения, выявили проблемную команду к 08:20, тогда как восстановление маршрутизации уже шло. Почти все сетевые устройства, регионы и сервисы восстановились к 09:05, а последнее сетевое оборудование — к 09:25. Это не было концом инцидента.

Некоторые локации, включая Индию и части Северной Америки, шли по более длинным путям восстановления. Локальная потеря пакетов сохранялась, поскольку системы контроля состояния WAN и управления трафиком были приостановлены. Этим системам потребовались ручные перезапуски, прежде чем Microsoft объявила полное устранение последствий в 12:43. Официальное окно влияния на клиентов поэтому длится с 07:08 до 12:43, хотя большинство сервисов восстановились гораздо раньше.

Современный репортаж The Register зафиксировал видимый сбой Azure и сервисов Microsoft, пока событие ещё развивалось, а также ранние упоминания Microsoft об изменениях маршрутизации и откате. Эти первоначальные заявления — полезное свидетельство того, что говорили клиентам в тот момент. Они не должны заменять более полные часы позднего разбора инцидента или его описание автоматической конвергенции и ручных перезапусков.

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

Это различие также защищает хронологию инцидента от обманчиво короткого изложения. Отметка 09:05 описывает момент, к которому восстановились почти все устройства, регионы и сервисы. Отметка 09:25 описывает последнее сетевое оборудование. Граница 12:43 учитывает вспомогательные системы и сохраняющуюся потерю пакетов. Каждые часы отвечают на свой вопрос, и ни одни не следует молча подменять другими.

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

Отчёт поддерживает системный вывод, а не юридический вердикт

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

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

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

Эти ограничения не ослабляют вывод об инфраструктуре. Они удерживают его в правильных рамках. Сбой WAN Microsoft 2023 года показал, что глобальная система маршрутизации может быть нарушена, когда процедура, авторизация и семантика платформы расходятся во мнении о области действия команды. Мера контроля — не то, как называлось изменение и кому было разрешено его вводить. Мера в том, было ли фактическое поведение действующей сети ограничено, наблюдаемо и восстанавливаемо до того, как стала возможной вторая волна.

Источники