Кратко

  • Команда, задачей которой была оценка доступной ёмкости глобальной магистрали, вывела из строя всю магистраль Meta Platforms; по описанию компании площадки затем объявили себя неработоспособными и отозвали свои BGP-анонсы, из-за чего серверы имён стали недоступны, хотя продолжали работать.
  • Внешнее измерение относит начало сбоя примерно к 15:40 UTC, отзыв маршрутов к DNS-префиксам — к 15:58 UTC, а возобновление активности BGP — примерно к 21:00 UTC с пиком в 21:17 UTC.
  • Устойчивый вывод носит структурный характер: оператор, чей путь восстановления идёт через ту же плоскость маршрутизации и имён, которую нужно восстановить, не может ни наблюдать свой сбой, ни отменить его. Непроверенным остаётся не исходное ошибочное действие, а долговечность исправления.

Что оператор рассказал о ходе событий

Meta Platforms опубликовала своё описание на следующий день после сбоя на собственной инженерной странице (Engineering at Meta). Ключевой фрагмент короток и необычно точен в последовательности:

During one of these routine maintenance jobs, a command was issued with the intention to assess the availability of global backbone capacity, which unintentionally took down all the connections in our backbone network, effectively disconnecting Facebook data centers globally. ... In the recent outage the entire backbone was removed from operation, making these locations declare themselves unhealthy and withdraw those BGP advertisements. The end result was that our DNS servers became unreachable even though they were still operational.

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

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

Первая ступень — сама команда. Её заявленная цель состояла в измерении доступной ёмкости, то есть в измерении, а не в изменении производственной топологии. Команда, у которой намерение — измерение, а результат — полное разъединение, имеет не широкую область действия, а неограниченную.

Вторая ступень автоматическая. Оставшись без магистрали, площадки проверили собственное состояние, сочли себя изолированными и сделали то, что делают корректно настроенные маршрутизаторы: отозвали свои BGP-анонсы. Это звено превращает внутреннюю ошибку в событие, видимое в интернете. Отзыв был не решением кризисного штаба, а добросовестным исполнением правила. Различие важно для каждого, кто хочет предотвратить повторение: добросовестное правило не исправляют указанием лгать. Его исправляют, решая, что площадке разрешено делать, когда её проверка состояния не проходит.

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

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

Что измерила внешняя точка наблюдения

Отчёт оператора объясняет причину; с часами у него слабее. Для хронологии определяющим является независимое измерение, опубликованное Cloudflare в день сбоя (Cloudflare Blog), где с отметками времени зафиксировано то, что видела крупная сеть резолверов:

At around 15:40 UTC we saw a peak of routing changes from Facebook. That's when the trouble began. ... At 15:58 UTC we noticed that Facebook had stopped announcing the routes to their DNS prefixes. ... At around 21:00 UTC we saw renewed BGP activity from Facebook's network which peaked at 21:17 UTC.

По-русски: около 15:40 UTC мы увидели пик изменений маршрутизации от Facebook; тогда и начались проблемы. В 15:58 UTC мы заметили, что Facebook перестал анонсировать маршруты к своим DNS-префиксам. Около 21:00 UTC мы увидели возобновление активности BGP из сети Facebook с пиком в 21:17 UTC.

Три отметки времени и одна кривая. Что-то началось около 15:40 UTC. К 15:58 UTC маршруты к DNS-префиксам компании больше не анонсировались из её сети — окно в восемнадцать минут, в течение которого изменения маршрутизации были видны ещё до того, как плоскость имён исчезла из глобальной таблицы маршрутизации. Около 21:00 UTC началась новая активность с пиком в 21:17 UTC, и, как далее сообщает анализ Cloudflare, полное восстановление подключения к глобальному интернету было заметно примерно к 21:28 UTC.

Эти конечные точки позволяют вычитание, которого ни один источник не делает за читателя. Между отзывом анонсов DNS-префиксов в 15:58 UTC и заметным полным восстановлением около 21:28 UTC лежит примерно пять с половиной часов. Эта цифра — разность двух заявленных моментов, а не независимо измеренная длительность сбоя, и читать её нужно именно с этой оговоркой. Тем не менее это наиболее конкретное указание на то, сколько на самом деле длилось восстановление на краю интернета.

Не менее важно то, чего внешнее измерение дать не может. Точка наблюдения вне затронутой сети видит, как анонсы появляются и исчезают. Она не видит согласования изменения, не видит сигнала тревоги, который сработал или не сработал, не видит внутренней панели, погасшей в тот же момент, что и объект её наблюдения, и не видит череды решений после того, как оператор осознал, что его собственные инструменты пропали. Cloudflare измерил поверхность; оператор описал механизм. Ни один документ не доказывает причинную связь сам по себе.

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

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

Обнаружение шло по той же плоскости, что и обнаруживаемое

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

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

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

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

Нагрузку несли третьи стороны

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

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

Отраслевая пресса рассказывала о случившемся преимущественно через BGP. TechTarget, например, рассматривал BGP как раннего подозреваемого, а сам сбой — как один из крупнейших в истории компании (TechTarget). Как описание восприятия это верно и как доказательство малополезно: текст является комментарием, а не измерением, и не даёт ни данных маршрутизации, ни архитектурных деталей из первых рук.

Запись справочника о Meta Platforms собирает прежние материалы о компании и служит местом, где этот анализ продолжается (Meta Platforms в справочнике).