{"id":14274,"url":"\/distributions\/14274\/click?bit=1&hash=fadd1ae2f2e07e0dfe00a9cff0f1f56eecf48fb8ab0df0b0bfa4004b70b3f9e6","title":"\u0427\u0435\u043c \u043c\u0443\u0440\u0430\u0432\u044c\u0438\u043d\u044b\u0435 \u0434\u043e\u0440\u043e\u0436\u043a\u0438 \u043f\u043e\u043c\u043e\u0433\u0430\u044e\u0442 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u0430\u043c?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"6fbf3884-3bcf-55d2-978b-295966d75ee2"}

Объяснение: что случилось с Facebook, почему долго чинили и может ли это повториться Статьи редакции

Разбор от бывшего директора по распространению технологий «Яндекса» Григория Бакунова.

Пролистал большую статью от Cloudflare про сегодняшнее падение Facebook и решил написать свою — сильно более простую. 4 октября приблизительно в 19:45 мск оглушительно рухнул Facebook и почти все его внешние и внутренние сервисы. Лежал Facebook, Messenger, Instagram, WhatsApp, лежали корпоративные и бизнес-сервисы Facebook, не отвечали ни сайты, ни мобильные приложения.

Что произошло

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

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

Так вот, одна из таких подсетей анонсировала всем внутри и снаружи, что часть сети Facebook теперь находится не у неё. Так получилось, что именно в этой подсети жили NS-сервера, отвечающие за домены, принадлежащие компании. А значит, начиная с какого-то момента все, кто пытался узнать на каком IP-адресе находится facebook.com, стали получать пустой ответ. Последствия предсказуемы: не работает Facebook и все его сервисы у пользователей, внешних и внутренних.

Почему так долго не работали сервисы

Вместе с тем сотрудники Facebook оказались в незавидном положении:

  • Недоступные все внутренние ресурсы компании, включая мессенджеры и корпоративные адресные книги.
  • Нельзя зайти в офис (часть офисов пускали только по бейджикам, которые привязаны к интернет-авторизации).
  • Потеряны почти любые привычные способы коммуникации.

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

При этом крепко досталось всему интернету. Лежали почти все крупные соцсети, которым внезапно достался трафик Facebook — люди, не найдя привычных Instagram и WhatsApp, пошли искать спасения в Twitter и Telegram. Получившие новый трафик поначалу радовались, но потом начали стонать под полученной неожиданно нагрузкой.

Сильно пострадали все публичные DNS-сервера — мобильные клиенты Facebook и все сайты, где была авторизация через Facebook или кнопка like, безостановочно DDoS-или свои DNS запросами к несуществующему Facebook. Трафик некоторых мобильных приложений вырос в 30-50 раз. Впечатляет?

Будет ли такое повторяться

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

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

0
170 комментариев
Написать комментарий...
Гала Перидоловна
 Пролистал большую статью от Cloudflare про сегодняшнее падение Facebook и решил написать свою — сильно более простую.

Не надо ни читать статью CF, ни писать на ее основе свои предположения. CF просто описали то, что они видели. А что было на самом деле расскажет FB, ну либо знакомых попросите. Может быть в личной беседе расскажут. В целом забавная ситуация получилась.

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

Это все булшит и предположения людей, которые не связаны с FB. Самое смешное, что люди зачем-то шли в офис чинить проблемы и их там не пускали. Это самый смешной бред. Если вы работает/работали настолько большой компании, то знали бы, что есть дежурные. У дежурных есть VPN в том или ином виде. Как только срабатывают алерты человек не бежит в офис за компухтер, чтобы сеточку починить. У него уже сразу все есть на его рабочем ноутбуке. Проблемы могут возникнуть при доступе к управляющей сети маршрутизаторов и при откате конфигурации. Это все так не очень похоже на фильмы про кулхацкеров, где двумя командами кладут Пентагон.

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

Какая ночь? У FB дата-центры по всему миру стоят. Команды дежурят везде. Это не Сбербанк, который может уходить на обед. Люди дежурят 24/7.  Опять же, в ДЦ тоже есть дежурные, но они не очень квалифицированные, конечно BGP они сами не поднимут, они только подготавливают оборудование, чтобы дежурный удаленно все поднял.

 Сильно пострадали все публичные DNS-сервера — мобильные клиенты Facebook и все сайты, где была авторизация через Facebook или кнопка like, безостановочно DDoS-или свои DNS запросами к несуществующему Facebook. Трафик некоторых мобильных приложений вырос в 30-50 раз. Впечатляет?

Тоже булшит. UDP по которому работает DNS в обычном режиме сильно дешевле TCP. Ядро не тратит ресурсы на поддержание стейта, а просто шлет ответ, ну либо клиент ждет таймаута. Проблемы могут начать если только DNS'ы криво настроены.

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

Это вообще смешно. Диванные исправители вообще не имеют представления о том, что они хотят исправлять и сколько это будет стоить, если получится исправить то, что они решат исправлять. На самом деле BGP отличное решение. Ломается редко. Я ни разу не слышал, чтобы ломалось из-за самого BGP, а не из-за кривой настройки. 

Ответить
Развернуть ветку
Николай Замотаев
У дежурных есть VPN в том или ином виде. Как только срабатывают алерты человек не бежит в офис за компухтер, чтобы сеточку починить.

Я почти уверен, что VPN там был куда-то в духе vpn.facebook.com а DNS лёг. И начался тот цирк, который мы наблюдаем.

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

Так если читать оригинал наблюдений от Cloudflare - там как раз и возникли проблемы с BGP и маршрутизацией.

Ответить
Развернуть ветку
Гала Перидоловна
 Я почти уверен, что VPN там был куда-то в духе vpn.facebook.com а DNS лёг. И начался тот цирк, который мы наблюдаем.

VPN ортогонален DNS. Первое без второго прекрасно работает, возможны проблемы если в конфиге написано vpn.facebook.com, но это легко решается кэшами. Я просто был в такой ситуации, просто открыл логи VPN и из них достал предыдущий разрезолвленный адрес. В этой ситуации не помогло бы, т.к. там сами AS не знали что делать с трафиком.

 Так если читать оригинал наблюдений от Cloudflare - там как раз и возникли проблемы с BGP и маршрутизацией.

Не, сломалась сеть которая направляет как бы основной трафик. Но у сетевого оборудования обычно есть еще одна изолированная сеть, которая нужна как раз для конфигурирования оборудования. Вообще критические узлы часто резервируют out-of-band.

Ответить
Развернуть ветку
Николай Замотаев
VPN ортогонален DNS.

Работает, иногда - зависит от того как настроено. Если vpn на базе чего-нибудь TLS-ного - может и не работать нормально. + требует минимальной квалификации тех кто работает на поддержке.
А так - если догадались посмотреть логи (и логи вообще были). А если нет - ну тогда "ой".

В этой ситуации не помогло бы, т.к. там сами AS не знали что делать с трафиком.

Ну так зачем тогда пишете про VPN. Если уж не помогло бы - то в любом случае физически ехать в офис.

сломалась сеть которая направляет как бы основной трафик.

Cloudflare писали что сломалась как раз сеть до DNS-серверов. Остальное было живо.

А при не работающем VPN или доступе снаружи - что out-of-band, что in-band -  так что результат ровно один (потому что управляющие сети наружу не открывают):

"Удалённое изменение сетевой конфигурации - к долгой дороге"
Ответить
Развернуть ветку
Гала Перидоловна
Работает, иногда - зависит от того как настроено. Если vpn на базе чего-нибудь TLS-ного - может и не работать нормально. + требует минимальной квалификации тех кто работает на поддержке.

А так - если догадались посмотреть логи (и логи вообще были). А если нет - ну тогда "ой".

Не, TLS тут дело десятое. Главное чтобы пакеты шли в сторону правильной AS. Нужно было просто убрать резолв. Это можно обойти простым редактированием /etc/hosts. DNS это самая меньшая проблема.

 Ну так зачем тогда пишете про VPN. Если уж не помогло бы - то в любом случае физически ехать в офис.

В офисе все тоже самое будет. Что VPN, что обычная сеть. Там проблема была в том, что коммутаторы/роутеры перестали говорить куда отправлять трафик. Даже если человек приедет в офис пакеты просто не дойдут до ДЦ. И даже если дойдут до ДЦ, то они обратно не вернутся. VPN или другой способ аутентификации нужен в данном случае для того, чтобы добраться до управляющей(внутренней) сети коммутаторов. Он есть у NOC'ов в том или ином виде. Это как бы независимая сеть, чтобы чуваки пришли и все починили.

 Cloudflare писали что сломалась как раз сеть до DNS-серверов. Остальное было живо.

Не, не было. 

```AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name
32934 | 129.134.30.12 | 129.134.30.0/24 | US | arin | 2015-05-13 | FACEBOOK, US
32934 | 157.240.205.35 | 157.240.205.0/24 | US | arin | 2015-05-14 | FACEBOOK, US```

У них все в одной AS. Поэтому вместе с DNS в черную дыру и покатился остальной трафик. 

 А при не работающем VPN или доступе снаружи - что out-of-band, что in-band - так что результат ровно один (потому что управляющие сети наружу не открывают):

Конечно открывают. Просто это работает через кучу разных хостов с аутентификацией по железным ключам. 

Ответить
Развернуть ветку
Игорь Тарасов

Почти как в передаче, пересказать не изменяя.
Про проблемы доступа и правда писал сам FB (при том слово "офис" добавили позже). Также FB писал что пришлось откатывать конфиг через консоль. То есть нужные роутеры не были досягаемы для vpn ниоткуда.
Теперь сопоставим слова "консоль" и "затруднен физический доступ". Дежурные ДЦ конечно пустили в здание нужных админов, но вот чтобы к стойкам попасть возможно без болгарки не обошлось.
Насчет DDOS, вы не слышали про самый популярный усилитель DDOS - DNS? В данном случае усилитель и отработал, CF показывал графики, другие тоже показывали, нагрузка на DNS прыгнула на порядок у всех и вся эта красота долбилась в никуда.
На самом деле FB еще довольно быстро поднялись как для такой ситуации. Ведь можно было еще прилечь отправив анонсы и получив ddos :)

Ответить
Развернуть ветку
Гала Перидоловна
 Также FB писал что пришлось откатывать конфиг через консоль. То есть нужные роутеры не были досягаемы для vpn ниоткуда.

Да, у них лег out-of-band следом за бэкбоном.

 Теперь сопоставим слова "консоль" и "затруднен физический доступ". Дежурные ДЦ конечно пустили в здание нужных админов, но вот чтобы к стойкам попасть возможно без болгарки не обошлось.

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

 Насчет DDOS, вы не слышали про самый популярный усилитель DDOS - DNS?

Нет, не слышал. Я наблюдал как сервисы внутри клали свои же DNS, что приводило к тому, что мастер переставал отвечать, ну и дальше по TTL чужие DNS(1.1.1.1, 8.8.8.8) переставали анонсить адреса. Напрямую в NS сервера Facebook обычные смертные не ходят, в этом плане нагрузка сильно на их инфраструктуру не возрастала. На публичные DNS возрастала.

 На самом деле FB еще довольно быстро поднялись как для такой ситуации. Ведь можно было еще прилечь отправив анонсы и получив ddos :)

В крупных компаниях в целом отработаны варианты восстановления в таких ситуациях. FB в postmortem об этом и пишут. Обычно компании проводят тесты отключая, например, половину сервисов в ДЦ по сети. Это хороший тест еще и человеческих ошибок. Наблюдал несколько раз как при плановых проверках человек случайно вырубал еще какой-нибудь другой сервис. 

Ответить
Развернуть ветку
167 комментариев
Раскрывать всегда