Почему Facebook, Instagram и WhatsApp лежали 6 часов. Разбор по хардкору

Всем привет. Самат Галимов, и это подкаст «Запуск завтра». Как технический директор я пытаюсь разобраться, как устроены сложные и интересные штуки. Я зову профессионала, с которым можно поговорить простым человеческим языком. Сегодня у нас новостной эпизод. Даже если вы никакого отношения к айти не имеете, вы наверняка заметили, что в понедельник 6 часов не работал ни фейсбук, ни инстаграм, ни даже ватсап. Это из ряда вон выходящие события ЧП прямо международного масштаба. При этом причины падения там в сетях, компьютерных сетях. И вообще в сетях разбирается очень мало людей. Даже в том, как устроен домашний интернет, вот этот Wi-Fi роутер, который у каждого дома стоит, даже в нем разбирается очень мало людей. Может объяснить, что там реально происходит. Что уж говорить о компаниях размеров Фейсбука. Специалистов, которые в этом шарят и которые могут этим управлять и как-то чинить проблемы вроде той, из-за которой Фейсбук полег, их вообще считано единицы. Этот эпизод мы собирали очень быстро, мы его записали буквально во вторник в 10 вечера. При этом гости у нас совершенно офигенные, нам очень повезло. Один— это технический директор ВКонтакте, второй— отвечает за сетевую инфраструктуру всего Mail.ru групп. В общем, это люди, с которыми можно реально разобраться в теме. Так что повод у нас— это падение Фейсбука, а разбираться мы будем сегодня в сетях. Это подкаст студии Либо-Либо, и мы его делаем вместе с сервисом онлайн-образования Яндекс Практикум. У Практикума есть курсы по разработке, по анализу данных и по английскому языку. А еще студенты в Практикуме иногда сайд-проекты (side projects). Вообще, меня в программировании больше всего восхищает эта возможность, если ты умеешь программировать, делать какие-то маленькие штучки для себя, которые упрощают твою собственную жизнь. Например, студенты-бэкендеры сделали программу, которая собирает объявления о разных тематических событиях из сотни телеграм-каналов, выделяет только те из них, которые будут интересны студентам, и раз в сутки подписывает дайджест в Слаке. Если вы хотите научиться делать такие маленькие штучки для себя, приходите на сайт Яндекс.Практикум и учитесь бэкенду.

Меня зовут Александр Тоболь, я технический директор ВКонтакте.

Лена Якупова, за всю сетевую инфраструктуру Mail.ru Group.

Круто. В понедельник вечером лёг Facebook. Вместе с ним лёг и Instagram, и WhatsApp, потому что это все сервисы одной компании, они технически связаны. не работали шесть часов подряд. Сегодня я хочу разобраться, почему это могло произойти. Вообще, главная публичная версия среди технорей, которую я слышал, это то, что прекратилось анонсирование IP-адресов из-за ошибки конфигурации BGP роутеров. Возможно, вы с этой версией поспорите, но сначала я хочу объяснить, что такое BGP, что такое анонсы и вот это все. То есть нам сейчас придется довольно много просить и рассказать, и это, мне кажется, даже интереснее, чем факт падения Фейсбука. И в самом конце только, когда мы все это объясним, мы сможем вместе понять, а почему мог упасть Фейсбук. Для начала я сейчас попробую в двух словах сказать, что такое BGP, зачем он нужен, а вы меня поправите, потому что вы в этом разбираетесь гораздо лучше, чем я. BGP— это протокол, который нужен для того, чтобы связать два компьютера, которые пользуются разными провайдерами. Насколько это правда?

относительно BGP, это протокол динамической маршрутизации, зачем он нужен? Что такое интернет? Начнем так издалека. То есть интернет— это на самом деле множество разных сетей. Сетей операторов связи, сетей таких IT-компаний, как, например, наша, сетей каких-то предприятий и до наших домашних сетей, где мы сидим дома, пьем чай и смотрим Facebook или ВКонтакте. И как им взаимодействуют? То есть помимо вот этого множества, они друг с другом соединяются в физические соединения.

То есть просто проводами.

В физическом соединении они соединяются не все, конечно, друг с другом, а некоторые со множеством других. Таким образом, в общем-то, все они физически соединяются в конечном результате. И что делать дальше? Как послать от компьютера А к компьютеру Б пакетик? То есть это как почта работает.

Пакетик это информация в интернете.

Да. Каким образом каждая сеть знает, куда дальше передать? Вот для этого используется протокол динамической маршрутизации, который в своей таблице содержит все адреса назначения в сети интернета, это IP-адреса, да, и маршрут до них.

Я так понимаю, что если мы с тобой в одной комнате сидим и подключены к одному роутеру, типа к Wi-Fi-точке, то между нами соединение довольно простое. Я передаю тебе, ты передаешь мне через этот роутер. А вот если у нас с тобой два разных провайдера, два разных роутера, то им нужно как-то друг до друга еще найти маршрут. Вот, например, я сейчас в Латвии, Lattelecom, а у вас, не знаю, какой провайдер, Саша, у тебя что?

Пусть будет мегафон.

А, у тебя отель «Националь». Он как бы через что-то там подключен к интернету. И вот нам нужно друг до друга построить соединение. При этом прямого провода от меня до «Национали» точно нет. Но он есть через каких-то других провайдеров. И вот BGP— это протокол, по которому провайдеры договариваются между собой, как передать информацию, да?

BGP— это протокол, по которому каждый провайдер сообщает другому провайдеру, до каких адресатов он может доставить информацию.

У каждого компьютера в интернете есть свой IP-адрес. Есть адрес, по которому до него можно достучаться. И BGP— это протокол, с помощью которого провайдеры говорят, короче, вот эти адреса обслуживаю я, посылайте всю информацию для них ко мне.

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

А, то есть они не только для своих пользователей, они еще могут таким передаточным звеном быть.

Да, то есть это транзитом.

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

Окей, мы с вами разобрались, зачем нужны IP-адреса и даже протокол BGP. Теперь, насколько я понимаю, Facebook, он сам себе провайдер. И в ВКонтакте, скорее всего, тоже вы сами являетесь провайдером для себя, да?

Мы являемся, да, провайдером для себя, контент-провайдером.

Но ваши IP-адреса— это не пользователи, а это сервера ваши. В том числе и пользователи, но в основном это ваши сервера, IP-адреса ваших серверов.

Да, это IP-адреса сервисов наших, да.

Вообще, я видел статьи, в которых прямо на графиках видно, что за пару минут до того, как Facebook у всего мира отключился, вот этот провайдер Facebook, он отозвал анонс IP-адресов. То есть он сказал, я эти свои IP-адреса больше не обслуживаю. Ну, то есть это такая уже точная информация. К чему это привело? Вообще, что происходит, когда твой IP-адрес перестает анонсироваться твоим провайдером?

Для тебя пропадает связность. Ты отключаешься от сети интернет, да, если простыми словами.

Просто как кабель выдраный.

Да. Ну, на самом деле, оперируем сети интернет мы, конечно, не IP-адресом одним, а блоками IP-адресов, да, сетями так называемыми. И, соответственно, Facebook наверняка, я уверена в этом, как и мы, имеет подключение не только к одному провайдеру, но и ко множеству провайдеров. И для того, чтобы они исчезли из интернета, они должны прекратить анонсировать свои блоки, все или какие-то, всем этим пирам (peers).

Всем, с кем они сконтакчены.

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

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

Объездные, да.

В случае с дорогой мне понятно. Написано, дорога закрыта, дороги нет, якобы не проеду. А вот в случае с Фейсбуком IP-адреса пропали из интернета. Мой телефон пытается сделать к ним запрос. Что происходит с моими запросами в этот момент?

Из того, что документально было видно, это пропали DNS именно сервера, которые стали недоступны.

Слушай, надо объяснить, что такое DNS.

Давайте просто вот, как мы заходим в строчку в браузере и вбиваем какой-то сайт. У нас есть какое-то доменное имя. Вот мы идем на доменный сервер, и это сервер имен нашего провайдера или какой мы настроили, и он нам возвращает как раз в данном случае IP-адрес. И дальше вот этот IP-адрес – это имя какого-то нашего города на карте, куда нам нужно дальше доставлять все пакеты и найти получателя как раз этого письма.

Пакеты, то есть информацию.

Поэтому, наверное, первый момент, что всегда, когда что-то случается в интернете, все вспоминают про то, что что-то случилось либо с DNS-ом, либо с BGP, потому что резолвили в некоторый IP-адрес, а BGP – это протокол, который нам позволяет в интернете найти, где же находится этот сервер и как до него добраться.

То есть IP-адрес— это набор цифр, которые никто не помнит, но это такой физический адрес, который важен для того, чтобы компьютеры между собой говорили. А мы с вами помним адреса типа vk.com или facebook.com, и вот DNS— это сервис, который переводит запоминающиеся нормальные имена в IP-адреса.

Так точно. И вот в этом месте у нас происходит история с тем, что действительно доменные сервера Facebook перестали отвечать, и мы перестали резолвить как раз именно Facebook в какой-то адрес.

Ага, то есть я пишу facebook.com, а мне некуда отправить запрос и спросить, типа, а какой IP-адрес соответствует этому?

Да, тут надо глубже вдаваться, как работает DNS, то, что есть у вас некоторый доменный резолвер на провайдере.

Вот, скорее всего, это связано, я слышал, что из-за того, что не были доступны DNS-сервера Facebook, у людей вообще интернет перестал работать, ну, типа, Яндекс перестал открываться. Как это связано?

Тут мне сложно прокомментировать, но я точно знаю ситуации, что если у вас есть какой-то, допустим, виджет Facebook, или ваше внутреннее API опирается так или иначе на Facebook, или где-то вот здесь появляется как раз ресурс, который не резолвится и не находится, то действительно могут появляться тормоза. То есть есть страница, отображение которой зависит от Facebook, и в данном случае Facebook не работает. Если все качественно не обработано с точки зрения разработки, разработчик не заложился, что фейсбук может быть недоступен, то в это время проверка по тайм-ауту может занять приличное количество времени. Обычно до 15-30 секунд тайм-аута мы можем ожидать, пока нам ответят, что фейсбук нам уже не отвечает.

Но это Саша рассказал про то, почему могли страдать сайты при недоступности Фейсбука. Также, возможно, была история, когда у людей просто сломался интернет. Почему он мог сломаться? Я лично сама не видела, у меня ничего не ломалось. Но мне рассказали о том, что в какой-то момент, очень короткий на самом деле, DNS, а гугловые ДНС у нас публичные, их используют на самом деле многие люди, или настройки дефолтовые роутеров которые покупают люди для домашнего интернета. В какой-то момент они затаймаутили.

Затаймаутили, значит, они перестали отвечать за приемлемое время.

Да, и у людей перестало резолвиться, соответственно, мог резолвиться перестать Яндекс или Mail.ru, но это не значит, что мы не работали.

Почему упали DNS сервера Google?

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

То есть, получается, миллионы устройств, на которых было приложение Facebook, и люди просто открывали Facebook.com, они пытались зарезолвить этот адрес, то есть получить IP-адрес Facebook.com, и делали эти запросы не напрямую к Facebook, а через своих провайдеров, через DNS-сервера своих провайдеров. И они не выдержали такого количества запросов.

Мы этого не знаем.

Часть из них, я вот точно знаю, что крупный провайдер очень во многих странах, Vodafone, один из крупнейших, вот у них там вообще DNS просто лег. Мы сейчас очень кратко, но, мне кажется, ёмко и понятно объяснили, что есть BGP, что если убрать анонс адресов, то эти адреса просто пропадают из интернета. Объяснили, что DNS-сервера Facebook пропали из интернета, и поэтому, во-первых, Facebook перестал работать, а во-вторых, еще и остальные сервисы тоже задело. Я понимаю, что у вас как бы нет видимости сети Фейсбука, вы не инженеры Фейсбука. Это все окей, я этого и не спрашиваю. Расскажите вообще, как в теории это устроено, почему это может сломаться? И может быть на своей практике, может быть у вас был в практике опыт, пропадали BGP-анонсы, которые вы не хотели бы, чтобы пропадали.

Если говорить совершенно простым языком, то анонсы сети могли пропасть, потому что что-то случилось с первоисточником этой сети, то, где она оригинируется. Ну и, соответственно, она пропала.

Первоисточник— это какая-то таблица, в которую сакральные карандашом пишут, или что это?

Это таблица, безусловно. Пишут туда не карандашом, пишут туда конфигурацией какой-то. То есть это некое сетевое устройство, как правило.

Это сетевое устройство такое самое главное, типа, и в котором все хранится. От первоисточника ты сказала. Главный роутер, который управляет протоколом BGP в компании.

На самом деле их вообще несколько бывает. Как это устроено у Фейсбука, опять же, мы не знаем.

А как во Вконтакте, например?

У «Контакта» несколько устройств, которые оригинируют наши сети. И в случае, если одно устройство становится недоступным, соответственно, анонсы никуда не пропадают, они продолжают анонситься во внешний мир с другого устройства.

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

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

Да, как варианты, это мне кажется такие самые стандартные, как это, поделить на две части можно всегда.

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

В самом старом варианте, как это было устроено и как это устроено сейчас, и большинство все-таки так продолжает конфигурировать сеть, это сетевой инженер удаленно заходит по, опять же, IP-адресу сетевого устройства, на это устройство, в его Command Line Interface.

Интерфейс командной строки. То есть это надо словами писать. На кнопочки не понажимаешь.

Да, заходишь, вводишь команды, пишешь в слово save или write и нажимаешь enter. И в общем ждешь, что все случится. Молишься. То, что ты захотела. Не видела малящихся сетевиков, честно. Может быть, про себя.

Мне интересно, ты когда вводишь эту конфигурацию, когда тебе что-то надо поменять, ты это меняешь ради чего? Для чего? Ну вообще для чего нужно менять конфигурацию сети? Когда у тебя какие-то договоренности с другими провайдерами меняются или когда новые компьютеры добавляются, в чем обычно причина?

Давайте очень простой пример расширения. Купили больше адресов, серверов, проект растет, надо, например, добавить оборудование с внешними IP-адресами.

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

Это частые действия.

Да, но ночью стараемся не конфигурить.

Слушай, а когда инженеры твои что-то изменяют, тебе прямо сообщение на телефон приходит?

Не на телефон, а в мессенджер.

Ничего себе. Ага, то есть это не суперредкая операция, а довольно часто. Я слышал, что в таких крупных компаниях, как ВКонтакте, например, в Фейсбуке точно такое слышал, что люди не заходят руками, вот как ты сейчас рассказала, на вот эти железки, а что ими управляет какая-то другая система, которую уже типа ты в ней что-то одно сделал, а она дальше пошла, пробежалась и везде настройки поменяла.

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

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

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

Ну, я скорее о том, что типа там можно накосячить, не о том, что…

Да, можно накосячить, конечно, в этой единой системе управления. Есть разные практики, которые применяются для того, чтобы это совсем все не положило, да. Выкатка на какую-то часть оборудования, если все окей, там продолжается. Но в каких-то вариантах такое применяется.

Каждый раз, когда падает какой-нибудь крупный сервис, я почти всегда знаю, что это проблема с сетью. Потому что писать софт мы вроде уже худо-бедно как индустрии в целом, как программисты научились. В смысле, мы как минимум умеем писать... Саш, ты так мотаешь головой там, типа, нет, не научились. Я понимаю твою боль, но у нас хотя бы есть понятие тестов. Мы можем написать тесты на код, который написали. Тесты— это маленькие программы, которые проверяют, что моя программа работает правильно. А вот в сетях такое вообще возможно?

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

Ты хочешь сказать, что у тебя вот есть продакшен-сеть, то есть та, которая обслуживает пользователей ВКонтакте, а есть еще параллельно такое же железо, которое работает просто для тестирования, для проверки того, что вы будете делать?

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

Чувствую голос сетевого инженера. Вы софт поцелуи научитесь писать?

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

Блин, ты рассказываешь, я прямо вспоминаю, как мы сидим вдвоем. Причем в моей памяти было даже такое, с Cisco. Когда ты сидишь, ты пишешь команду, и ты ее перед тем, как отправить, спрашиваешь человека, который с тобой рядом, напарника, спрашиваешь, все окей? И он такой, да, окей, кивает, и ты тогда нажимаешь Enter.

Да, Cisco.

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

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

просто есть, как воздух, которым ты дышишь.

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

Дело в том, что когда всё работает, то сеть не видно. Её нет, всё работает.

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

Лена, вспомни историю. Какое самое стремное падение сети было в твоей практике?

Была стремная авария, когда инженер очень сильно торопился, и ему нужно было раскатить конфиг на несколько коробок. Коробки были, в общем, довольно важные во всей сетевой инфраструктуре.

Раскатить конфиг— это значит изменить конфигурацию, то есть как-то перенастроить.

Да, то есть перенастроить и нажать вот эту волшебную команду, там, commit.

Типа поехали.

Поехали, да. И чтобы ускорить это, он решил сделать это в параллельных консолях, то есть запустить сразу на все устройства.

Параллельные консоли, это значит, что он один раз нажимает букву, а это сообщение, эта буква отправляется на все устройства сразу.

Ну не на все, а на те, которые ему нужно было, да.

Ох, чую, сейчас будет жесть какая-то.

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

Превратилось в кирпич просто.

Ну, в общем, можно сказать, в кирпич, да, в такой. Ну, работающий кирпич, просто не отвечающий ни на команды, никаким образом, в общем, так. где-то на третьем устройстве мы его остановили, заметив неисправность, криками «останавливай, что ты там делаешь». Он быстро остановил остальные консоли, которые я запускал в этот момент. В общем, ну такая неприятная история. Довольно быстро починили, понятно, потому что аварии, которые рукотворные, которые ты сделал руками, как правило, чинятся быстро. Ну то есть ты знаешь, где ты что сломал, то есть тебе не нужно тратить время на поиск проблемы, на то, что происходит. нерукотворная авария, ты сидел, сидел такой, ничего не делал, вроде у тебя раз, и что-то сломалось. А сеть большая, и, в общем-то, ну, то есть сломалось в одном месте, а отзвуки везде, да. То есть не так просто локализовать проблему,

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

Я помню эту историю.

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

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

Да, да.

Даже не электростанции, а с одной подстанции, как бы, и такой, окей, два входа. Знаете, я вот так подробно расспрашиваю, чтобы дать немножечко вайб того, что происходит, когда какая-то сетевая проблема. Типа приходят реально крутые инженеры и пытаются разобраться руками. То есть это такая филигранная ручная работа, почти как операция. Я прочитал в интернете, появился анонимный аккаунт на Reddit. Человек писал, что он участвует в восстановлении Facebook от этой ошибки. Анонимно там что-то рассказывал, рассказывал, а потом в какой-то момент просто все его сообщения удалили и аккаунт тоже удалили. Ну, типа, понятно, чувака просто потерли. Не понятно, насколько это правда, но он писал то, что устранение проблемы этой фейсбучной заняло так много времени, потому что инженеры, которые управляли этими железками, они оказались отрезаны от этой железки. То есть они как-то так изменили конфигурацию, что уже дальше не могли до нее достучаться и не могли ничего исправить. Эти железки стояли в дата-центре. Инженеры, которые были в дата-центре, не имели паролей, ключей доступа к этой железке. А инженеры, которые сидели дома и имели ключи доступа, они не были в дата-центре. То есть получилось так, что никто не мог конфигурацию изменить. Насколько это реалистично звучит?

Я бы, наверное, сказал, что это не очень реалистичная ситуация. То есть, действительно, смотрите, верхний уровень, если у нас есть какая-то удаленная система, неважно, маршрутизатор, или вы сервер конфигурируете, вы уходите удаленно на этот сервер, вы можете с собой сделать все, что угодно.

ты можешь сам себя закрыть.

Да, можешь сам себя зафейрволить, зарейтлимитить, можешь с собой, можешь доступ у себя отнять и к этой штуке как бы и в итоге не вернуться.

Потерять доступ.

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

Лена, реально себя закрыть от такой крупной серьезной железки?

Потерять доступ к сетевому оборудованию, конечно же, можно. Вся сеть слегла, понятно, что доступа нет. На этот случай, как правило, во всех компаниях, которые я видела, имеется аварийный доступ. Это доступ по консольному порту к сетевому оборудованию.

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

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

В интернет, то есть его можно воткнуть в интернет.

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

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

Можно и так, можно и сим-карту поставить, если там хорошо ловит сигнал, конечно, безусловно, но мы, как правило, берем проводной интернет.

Просто другого провайдера.

Другого провайдера, да.

Но всегда есть экскаваторщик, то есть мы всегда уверены, что они максимально независимы, эти системы ортогональные, и систему строим так, что всегда есть дублирование, но есть экскаваторщик.

Я так подозреваю, что эта система не только у вас так, да? Это типа любая крупная интернет-сервис делает ровно так же.

Мы предполагаем, что да.

Я очень на это надеюсь, что у всех так. Но надо сказать, что никогда мы ни с какими сетевыми инженерами из других компаний не обсуждали этот вопрос. Как-то мне кажется, что это by default. Поэтому очень странно, что сетевые инженеры Facebook писали, что дата-центры.

Это, кстати, Нью-Йорк Таймс писал, что вот там типа снарядили команду инженеров в дата-центр. Смешно было читать, но... Вообще могут назвать

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

Гномики какие-то бегают, да.

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

Действительно, возможно... Из-за ковида как раз было меньше людей в дата-центре.

Да, что там людей, может быть, был один, может быть, вообще не было никого. Именно эти люди ехали, а не сетевые инженеры, которые конфигурят. Ну, кажется, что это странно.

Дайте, пожалуйста, свои теории. Как вы думаете, что там с Фейсбуком произошло? Что они 6 часов-то делали? Просто интересно же. Я не могу даже поспекулировать, потому что у меня нет понимания, как оно в принципе устроено. У вас это понимание есть. На примере вашей собственной компании. Что может пойти не так, что вы 6 часов будете разбираться?

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

То есть это не просто железка сгорела, а это кто-то после этого что-то сделал не так, или даже изначально воткнул ее.

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

SPOF— это Single Point of Failure, то есть одна точка, при падении которой все нафиг ломается.

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

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

Стало интересно, как.

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

То есть ты стелишь соломки там, где что-то может пойти не так?

Да, можно перестелить соломки, настолько там защищаться, что-нибудь сломать другое, наступить на какой-нибудь баг, например, в софте, да.

Они не ожидали, что вы столько фильтров настроите.

Да, да, ну это я... Такого нет, бага, поэтому это всё выдуманная информация, то, что я сейчас сказала. Но можно продумать при продумывании архитектуры, но, конечно же, и когда мы рассматриваем любую аварию, которые особенно с человеческим фактором анализируем, не мы имеется в виду, а вообще в целом и IT-сообщество, то есть про некоторые аварии же есть разбор, публичный в интернете, то там видно, что что-то не предусмотрели. Могли об этом догадаться, но по каким-то причинам просто вышло из-под фокуса. Или, например, работало-работало, и так с течением времени из-за того, что там не повторяется, назовем его регламент, то есть мы делаем так, а не как иначе, утерялось с течением времени, люди менялись-менялись, сразу что-то потерялось, информация исчезла. Разные истории могут быть. И поэтому именно происходят анализы. Я думаю, что сейчас компания Facebook занимается анализом проблемы, что они не предусмотрели, что нужно исправить. Как правило, мы делаем именно так. То есть при любой аварии серьезной, например, на сети может быть авария, которую мы расследуем, которую не видят внешний мир и вообще не знают даже разработчики наши ничего о том, что была авария, но мы ее разбираем, расследуем, понимаем, в чём была ошибка, если не сразу очевидно это, потом, как мы можем либо допустить, чтобы этой ошибки не было, если это человеческий фактор, либо если это железо, и мы долго искали её, то есть добавляем там какую-то аналитику дополнительную о том, чтобы мы быстрее находили эту проблему.

То есть ты учишься на ошибках как организации в целом?

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

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

Я слушаю такую фразу, что правила безопасности написаны кровью. Типа каждый раз, когда что-то идет не так, появляются новые правила безопасности. Вот я не помню дату, но я помню, как Яндекс лег тоже из-за сетевой чего-то. По-моему, там был не BGP, а OSPF, но что-то там было с сетью именно тоже с мисконфигурацией роутера.

Да, про эту аварию, это 2011 год, насколько я помню. Редистрибьюция полной таблицы из BGP в OSPF.

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

Примерно так, да, это выглядит.

Можешь, пожалуйста, вспомнить еще какие-то такие истории?

Это на самом деле очень-очень типичная проблема про редистрибуцию из BGP в OSPF. Прекрасные есть кейсы, тоже про них в интернете наверняка написано. Это когда, ну, представим, маленький оператор связи, в нем приходит молодой сетевой инженер совсем. Он еще ничего не настраивал, первый раз настраивает BGP протоколы. Он подключает соединение к двум операторам связи крупным достаточно. Ну, допустим, предположим, к «Вымпелкому» и к МТС или к Ростелекому.

Я уже себя представляю этим инженером. Первый день на работе.

Получает таблицу маршрутизации от Билайна, допустим, от «Вымпелкома».

Передает ее в МТС.

И передает ее МТСу, допустим. Ну, МТС, наверное, никак на работу, вот в данном случае я привела таких крупных просто, чтобы вспомнились они, да. На самом деле, я думаю, что МТС ситуацию обработает правильным образом. Но ситуации, когда трафик какой-то крупной сети.

Огромной.

Какой-то большой сети начинает течь через какую-нибудь маленькую, там, не знаю, с 10-гигабитным каналом, да, все просто.

Домашние как бы сети, то, что районная сеть раньше называлась.

Да, и, в общем-то, все забивается, естественно. Тут, значит, наступает хаос, и такие истории было парочку, по-моему, точно, уже довольно давно, поэтому в деталях не помню, кто, зачем, и почему. Но это тоже такая интересная авария.

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

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

Серьезно? Просто для жизни?

Ну, чтобы что-то не забывать, да. Окей.

Лена? Ты сказала, что есть подкасты, простите, я таких не знаю.

Да, есть, наверное, подкасты. Есть такой проект Link Me Up, его ведет Марат Сибгатулин, он пишет в очень доступной форме про сети. У него там есть такое «Сети для самых маленьких, не нужно путать с сетями для чайников». В целом это то же самое, но очень понятно, подробно, простым языком рассказывает про сети. Потому что на самом деле одной единой книжки, которую ты взял и прочитал, и узнал, как строить сети, нету. Но там он даёт некий скелет, от которого можно отталкиваться, дальше углубляться, углубляться, углубляться до бесконечности, потому что конца у этого нет.

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

Спасибо.

Спасибо большое. Да, надеемся, что все будет классно и круто.

Уже после записи нашего разговора, Facebook опубликовал статью, что же произошло на самом деле. Оказалось, что мы в своих рассуждениях были не очень далеки от истины. На самом деле, по человеческой ошибке, кто-то из инженеров запустил команду, которая просто отключила интернет во всех дата-центрах Facebook. Все бы ничего, но DNS-сервера Facebook определили, что у них нет контакта до дата-центра и отключили сами себя от интернета по протоколу BGP. Вот в этот момент уже все вообще пошло не так, потому что инженеры Facebook, которые должны были решать эту проблему, потеряли доступ ко всем внутренним инструментам. Да что там к инструментам? Они даже в офис к себе не могли попасть, потому что для того, чтобы двери умные работали, тоже нужен DNS. Дальше мы в ходе разговора отмели гипотезу о том, что инженерам пришлось ехать в дата-центр, потому что гости сказали, что у любого сетевого оборудования, конечно, есть запасной канал связи. Так вот, на самом деле инженеры ехали в дата-центр, потому что запасной канал связи тоже сломался. В общем, это такой идеальный шторм, где всё пошло не так, и то, что инженеры уложили 6 часов— это, на самом деле, большое везение. Это подкаст студии Либо-Либо, и мы его сделали вместе с сервисом онлайн-образования Яндекс.Практикум. Над подкастом работали. Редактор— Юлия Яковлева. Младший редактор— Ирина Ханта. Продюсер— Павел Боровков. Звукорежиссер— Нина Мамодина. За джингл спасибо Алексею Зеленскому.