Кратко

  • Команда обслуживания, которой измеряли доступную ёмкость глобального backbone, оборвала все соединения внутри backbone Facebook и отрезала его дата-центры от мира.
  • Инстанция, которая должна была перехватить такие команды, сама была программой — и дефект в этой программе не дал ей остановить команду.
  • DNS-серверы сняли свои BGP-анонсы, потому что перестали видеть собственные дата-центры. Это предусмотренное поведение, а не побочный эффект, и оно перенесло отказ с внутренней связности на глобальную доступность.

Команда пришла из повседневной работы, а не из аварийного сценария. Ею собирались выяснить, сколько ёмкости осталось у глобального backbone. Вместо этого она забрала всё. «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.» Так это описано в материале Engineering at Meta, опубликованном 5 октября 2021 года.

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

Интереснее самой команды — инстанция, которая должна была её остановить. Facebook описывает её как слой, построенный именно для такого класса вмешательств. Он не сработал, и причина была не в невиданном исключении, а в самом инструменте проверки. «Our systems are designed to audit commands like these to prevent mistakes like this, but a bug in that audit tool prevented it from properly stopping the command.»

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

Затем сработал второй контроль, и он сделал ровно то, для чего был построен. Авторитативные DNS-серверы Facebook настроены так, чтобы снимать собственные BGP-анонсы, как только перестают видеть свои дата-центры: это сигнал нездорового соединения. «To ensure reliable operation, our DNS servers disable those BGP advertisements if they themselves can not speak to our data centers, since this is an indication of an unhealthy network connection. In the recent outage the entire backbone was removed from operation, making these locations declare themselves unhealthy and withdraw those BGP advertisements.»

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

Сколько это длилось, из отчёта оператора не прочитать — только из внешнего измерения. Cloudflare наблюдал, что имя facebook.com на резолвере 1.1.1.1 перестало разрешаться около 15:50 UTC и вернулось около 21:20 UTC. Между 15:58 UTC и 21:00 UTC анонсов DNS-префиксов по BGP не было, а около 21:17 UTC новая BGP-активность достигла пика. «At around 21:00 UTC we saw renewed BGP activity from Facebook's network which peaked at 21:17 UTC. ... This chart shows the availability of the DNS name 'facebook.com' on Cloudflare's DNS resolver 1.1.1.1. It stopped being available at around 15:50 UTC and returned at 21:20 UTC.» Cloudflare оценивает сбой примерно в пять с половиной — шесть часов. Это трактовка Cloudflare, а не указание длительности от Meta.

Почему это заняло столько времени — самая неприятная часть истории. Обратный путь шёл не через консоль. «Our primary and out-of-band network access was down, so we sent engineers onsite to the data centers to have them debug the issue and restart the systems. But this took time, because these facilities are designed with high levels of physical and system security in mind. They're hard to get into, and once you're inside, the hardware and routers are designed to be difficult to modify even when you have physical access to them.»

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

Отсюда вопрос, который этот случай выставляет наружу: кто проверяет проверяющего? Инструмент аудита становится контролем только тогда, когда проверено его собственное поведение и становится виден его собственный отказ. Ни того, ни другого в просмотренном материале нет — ни в двух документах от 5 октября 2021 года, ни в дополнительной технической записи. Я читал описание оператора и внешнее измерение Cloudflare; плана восстановления, статуса его выполнения или подтверждения долговечности ремонта они не содержат. Это граница просмотренного материала, а не утверждение, что таких подтверждений не существует.

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