Comments 160
Ну встала у СММ-щиков работа ненадолго, ну какие-то бизнес-механизмы легли. А вот что будет если лягут подключенные облачно jQuery или bootstrap например. Кажется мне, больше половины сайтов перестанут работать корректно.
Уверен, сервисы FB посещают гораздо больше людей, чем все сайты, которые получают ключевые библиотеки с одного какого-то публичного CDN. Будет повод перенести библиотеки к себе, ведь межсайтовое кэширование уже сломано и толку от единых CDN стало гораздо меньше.
"межсайтовое кэширование уже сломано" поясните пожалуйста
Если сайты abc.com и cba.com запрашивают одинаковые файлы cdn.com/script.js и cdn.com/style.css. То браузер будет качать эти файлы лишь однажды.
подозреваю, что теперь эта фича кеширования изменена.
Каким образом?
Сайт Б может своими скриптами подключить тот самый уникальный скрипт с сайта А и замерить время, сколько он будет грузиться. Если этот скрипт загрузится практически мгновенно — значит он уже был в кэше.
Так и думал, спасибо.
А почему нельзя сохранить время загрузки этого скрипта с сайта А и отдавать сайту Б с такой же задержкой?
Сайт Б может попробовать сначала много раз реально запросить скрипт с сайта А (добавляя незначащие GET-параметры), построить текущее распределение времени загрузки данного скрипта, а потом запросить тот же скрипт ровно таким образом, как это делает сайт А, и проверить статистическую вероятность того, что время загрузки этого скрипта подходит под построенное распределение. Учитывая, что интернет сущность весьма динамичная, вполне может оказаться, что записанная заранее задержка не сойдётся с текущей реальностью, и опять же вскроется, что пользователь уже был на сайте А.
Толк от хранения библиотек в CDN пропал с массовым переходом на http/2.
Но ведь CDN снижает нагрузку на собственный сайт и уменьшает время, за которое грузится ресурс, из-за того, что этот самый ресурс грузится с более близкого к конечному пользователю узла CDN. Разве нет?
Разве нет?
Так утверждают. Но мой опыт ясно говорит – все сайты, которые используют CDN, медленные. И наоборот, все быстрые сайты, CDN не используют.
Да, может причина и следствие перепутаны, но я бы сказал – делайте сайты, которые в CDN не нуждаются.
В целом утверждение не совсем корректное. Взрослые быстрые сайты конечно же используют CDN, только они используют CDN как часть своей "собственной" облачной инфраструктуры, со своими собственными доменами, а не как какую-то левую публичную зависимость.
Cloudflare там, Google Cloud CDN, Cloudfront и иже с ними.
Например, я писал сервис на Angular. В нем есть возможность деплоя на другой УРЛ. Был выбрал AWS.
Никто другой не будет использовать эти скрипты на своих сайтах. А вот для пользователей скорость загрузки сайта уменьшается, так как запрос идет к ближайшему для них серверу.
Знали бы вы, как спасает CDN, когда твои сервера раздают hls-видео на тысячи людей
Это тоже влияет, но основной эффект снижения нагрузки предполагался за счет уменьшения количества запросов в веб-серверу, которые не могли выполнятся параллельно в рамках одного TCP соединения, что стало не актуальным с появлением http/2, который поддерживает мультиплексирование.
Повод перенести библиотеки к себе был всегда. Именно из за ненулевой вероятности такого случая.
И даже частичная потеря связности для клиента (например РКН) запросто обрушит сайт при недоступности того же jquery.
Никогда не понимал почему оставляют внешнюю ссылку. И никогда не принимал работу с внешними ссылками на ресурсы.
Помнится когда под горячую руку РКН при попытках блокировки телеграмма попали гугловские айпишники, огромное количество сайтов встало колом от того, что использовало блокирующую загрузку шрифтов с гуглового fonts.google.com. (браузер ждал таймаута и только после него загружал сайт).
Во многих случаях, как уже заметили выше, HTTP/2 нивелирует выигрыш, при условии нормальной ширины канала между сервером и пользователем.
Даже если и так, никто не мешает использовать, например, домен static.yourdomain.com, который вы контролируете, для хранения зависимостей.
Не оправдывая завязку на внешние ресурсы, замечу, что по стандарту browser не должен создавать много одновременных соединений с одним доменом.
Можно чуть подробнее об этом?
Ссылку на стандарт? И «много» — это сколько?
A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.
На практике в последние годы без прокси-сервера лимит у некоторых browser-ов можно было повысить или даже был повышен по умолчанию, с прокси-серверами было максимум 2, когда я проверял в последний раз.
SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
Если очень хочется, то можно.
Уже ложилось, помню. Про быстренько перенесли к себе те, кто умел, остальные дождались поднятия, ничего особенного.
Ага, плюс встала работа везде, где есть "Login with Facebook"
У меня в последние несколько месяцев bootstrap отрыгивается на некоторых сайтах
Принцип Парето в отношении сайтов еще более перекошенный. Как правило это легаси недобложики в своей массе с околонулевым траффиком, сейчас любой уважающий себя июнь даже калькулятор запихивает в вебпак, а веб проекты, в которые не стыдно кидать свое резюме, используют route 53.
Как вариант, система пропусков тоже использовала инфраструктуру мордокниги и не могла достучаться для проверки допуска.
Грубо говоря, чтобы поднять упавшую систему надо чтобы упавшая система была не упавшей.
Интересно, а как разблокируется в случае стихийного бедствия? Должна же быть у охраны "тревожная" кнопка.
Возле дверей, изнутри комнат есть что то вроде пожарной кнопки, которая разблокирует дверь. Но и охрана получает сигнал, что дверь разблокирована аварийно.
По правилам пожарной безопасности изнутри двери должны открываться безо всяких кнопок. Сигнализацию, конечно, это не отменяет.
Там два блока на стене, первый "красный пожарный" - про спуск лифтов на первый этаж, разблокировку всей дверей в здании и сирену. Второй - зеленый, который аварийно разблокирует конкретную дверь.
UPD. "Там" это не FB, это в нашем кампусе другой конторы
Это касается пожарных выходов, а не входов и это российские правила. В других странах все по своему
В порядке стёба - получает через лежащую систему?
СКД по тревоге, обычно, разблокирует проходы на выход, а не на вход)
Больше интересно, почему анонсы по BGP пропали.
Согласен, что интересно… Для этого нужно ждать информацию от самой Facebook. Им явно придётся выдать на публику какой-то отчёт. Пока есть только такое.
Информация от ФБ исходит из пиар-департамента, так что это или лукавство для отвода глаз, или просто прямая ложь, чаще последнее. Уверен, в этот раз будет точно так же, признаки уже есть типа заявлений ФБ в Тви, что падение затронуло «некоторых» пользователей.
Так что как раз не от ФБ.
От самого ФБ не лучше: https://engineering.fb.com/2021/10/04/networking-traffic/outage/
Вероятно, подпись под постом -- "Santosh Janardhan, VP Infrastructure" -- объясняет больше, чем сам пост.
Да, по три that в одном предложении – это, конечно, не пиар-департамент готовил текст. Тем не менее, любой сотрудник ФБ обязан согласовывать такие штуки, это прямо сказано вот тут https://developers.facebook.com/devpolicy/, ищите «PR Guidelines» на странице.
Я скорее о том, что там никаких подробностей. Пост построен по такому принципу:
Извините, что у нас получилась ошибочка, ведь нашими сервисами пользуются сотни миллионов.
Мы всё поняли, научились, такого больше не будет.
Нашими сервисами пользуются сотни миллионов (опять), и вам лучше не думать о плохом, ведь сотни миллионов мух не могут ошибаться.
там деталей завезли https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/
или лукавство для отвода глаз, или просто прямая ложь
Тошно от лжи уже. Особенно когда она такая прямая и очевидная. Они просто всех дураками выставляют
У нас много ребят в FB работают. На перерыве коллега встречался с одним и вот что написал:
So a friend told me that someone did a change on TF or other automation system that changed some config on all of the routers and withdraw the routes, also like everyone knows its the same infra as all of their internal tools bu they have an emergency infra just for these cases that they can fail over all of their internal system to this infra.. apperantly 90% of the company was not familliar with this infra :sweat_smile:
So no one knew how to fail over to it and most of them did not even know it exists.
Второй закон Вейнберга: если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию.
в последнее время похожее все чаще можно сказать и про администраторов, которые настраивают роутеры.
Как человек, первую половину нулевых проработавший в Тир-1 провайдере, могу сказать, что так было всегда.
Этот второй закон очень слабая аналогия. Здания не обладают такой внутренней сложностью, как программы.
Так может это не причина, а следствие. Чем проще структура, тем сложнее её поломать.
Ну и на любой замок поглядите — средневековый или наших дней. Там такие кубернетесы внутри порой бывают. А обычные человейники — это как сайты на CMS, их делают для массового потребления.
Уважаемый строитель, перенесите-ка здание на 5 метров влево. А можно ещё такое же здание, только на 50 метров дальше? Как нужны ещё ресурсы?
В 16:58 UTC мы заметили, что Facebook перестал анонсировать маршруты для своих DNS-префиксов.
Это происходит по той причине, что в DNS, как и во многих других системах в интернете, используется свой механизм маршрутизации.
Автор оригинальной статьи зачем то(может для упрощения) смешал в одну кучу 7 и 4 урони модели OSI. Маршрутизация это 4, DNS 7. И связаны они в этой истории тем, что DNS сервер, как и любой другой сервер тоже находится в сети и взаимодействует в тч на 4 уронве. И в DNS нет ни маршуртизации(в строгом смысле этого слова) ни анонсирования маршрутов.
И никакие микросервисы не спасли.
В статье нет ответа что именно сломалось у Facebook, то что DNS серверы Facebook не отвечали, разве что.
так вроде официального отчета от самой фб и не было, вот, вся инфа, что есть представлена
Вот тут теперь что-то появилось.
Так все подсети (ASN) Фейсбука просто пропали из Интернета. А для юзеров это было заметно по неработающему DNS, так как первое, что мы делаем при открытии ссылок это резолвим домен.
Там похоже не только DNS для внешних клиентов отваливался, т.к. если прописать в hosts ip facebook.com он все равно не открывался.
Отвалились не все подсети, как минимум анонсы ipv6 были доступны (судя по ripestat). Но при этом эти сервера не отвечали на пинги и на днс запросы.
Ну так автономная система отвалилась, а IP у них в собственности. Вот и привет
Что вы подразумеваете под "автономная система отвалилась"? Изначально подразумевалось что связанность роутеров с миром осталась, просто пропала часть анонсов.
В подтверждение: их static.xx.fbcdn.net (сервера, обслуживающие этот ип) оставался доступен и вполне отдавал статику для клиентов у кого не протух кеш днс (или есть запись в hosts).
AS у серверов статики (31.13.84.0/24 is announced by AS32934) и у ДНС (129.134.30.0/24 is announced by AS32934) одинаковые, т.е. получается что роутеры связанность имели. Как минимум в части ДЦ. И соответственно возник вопрос - почему анонс по ipv6 для серверов обслуживающих ДНС был, но при этом сами сервера не отвечали.
Кто-то хорошо заработал на этом;)
Даже если не было атаки, а всего лишь рученки влезли куда не надо...
"В 16:58 UTC мы заметили, что Facebook перестал анонсировать маршруты для своих DNS-префиксов" -- вот тут мой мозг сломался. =)) DNS и BGP в одну кучу.
Для тех кто не в курсе, в протоколе BGP есть только апдейты маршрутов соседней автономной зоны. DNS это этажом выше, и никак не пересекаются.
Это такой перевод, или там действительно такие чапаевские птицы?
Перевод в порядке. Вероятно, это место следует читать как "В 16:58 UTC мы заметили, что Facebook перестал анонсировать маршруты для префиксов серверов своих DNS-зон."
Ну автономная система анонсирует айпишники в глобальную сеть. Днс сервера у них свои и на своих айпишниках (странно что нет резерва в другой AS). Ну а дальше просто каскад. Нет ИП, нет ДНС, нет КЭША, нет данных
Похоже, Цукерберг предал идеалы демократии и завязал все сервисы на себя лично, без резервирования...
Сегодняшние события служат мягким напоминанием о том, что интернет — это очень сложная и взаимозависимая система из миллионов систем и протоколов, взаимодействующих друг с другом. Доверие, стандартизация и кооперация между задействованными в нём организациями — ключ к его работоспособности для почти пяти миллиардов активных пользователей со всего мира.
...
В 1968 году Министерство обороны США посчитало, что на случай войны Америке нужна надёжная система передачи информации, и предложило разработать для этого компьютерную сеть.
А потом, что-то пошло не так.
Сравните это, например, с историей Evergreen весной, когда затор в одной точке поставил раком мировую логистику на пару недель.
Тем не менее что-то в архитектуре явно сделано нехорошо.
Это же огромная контора с серверами по всему миру. Так почему он упал весь, а не для какой-то части пользователей?
Построили недостаточно отказоустойчивым.
Есть одна древняя рекомендация - не держать все авторитативные NS в одной IP-сети класса C.
По хорошему, со времён внедрения CIDR она должна звучать как "не держать все авторитативные NS в одной AS".
>А потом, что-то пошло не так.
А потом все стали переходить от децентрализованной модели изначальной сети к централизованной, где есть выделенные точки управления всей сетью. Руками ходить на каждое отдельное устройство всем надоело, решили разливать изменения всякими модными зумерскими ansible'ами, использовать REST API, NET CONF и прочие централизованные вещи. И вот одно неосторожное движение и вместо единичного отказа лежит уже вся инфраструктура.
netconf и rest api не имеют никакой связи с централизацией. rest api может вызываться/выставляться наружу микросервисами, конфиги по netconf тоже заливаются/принимаются микросервисами.
Руками никто никуда не ходит, потому что рук не хватит в энтерпрайзе и хайлоаде. Для этого используется ETSI NFV MANO. Другое дело, что внешний/внутренний периметр доступа есть в любой системе, хоть централизованной, хоть нет и если положить его весь, то может оказаться сложным удаленно его поднять обратно. Это я вам как ответственный бумер сообщаю.
Другое дело, что "положить его весь" не должно быть доступно одной группе людей, это факт. Проблема, похоже, действительно в централизации, но не архитектуры инфраструктуры, а ролей доступа к настройкам BGP. Возможно также частично проблема, а точнее задержки в её решении, заключаются и в децентрализованности BGP.
Можно было просто разные подсети анонсить из разных ASN, да ещё и с разных точек и ДЦ. Плюс, иметь DNS-серверы в разных ДЦ, в разных подсетях.
У них все так и было. Но судя по последнему отчету, они потеряли всю backbone network между дата центрами из за ошибки внесения изменений в конфигурацию роутеров (то самое централизованное управление скорее всего, про которое я писал выше). А их днс настроены так, что если теряют связь с основными сервисами, то убирают анонсы по BGP для своих адресов (считается, что данный ДЦ сломался и не надо роутить на него пользователей). И вот так получилось, что все их ДНСы во всех ДЦ потеряли связь по внутренней Backbone сети с каким то центральными сервисами и отозвали BGP анонсы.
В целом моя мысль подтверждается - виной всему излишняя централизация, которая смывает границы "домена проблемы". Сетевые протоколы всегда строились так, чтобы "домен проблемы" (объем затрагиваемых сервисов и устройств в случае точечного сбоя) был как можно меньше. Но централизованное управление ломает этот принцип и раздувает "домен проблемы" до максимальных значений, вопреки изначальному принципу.
Интересно, как скоро государства захотят себе право авторизации запросов на инфраструктурные работы для критически важных сервисов? Сейчас почти в любой крупной конторе есть какой-либо комитет с большими шишками, которые пускают или не пускают крупные работы и тормозят тем самым процесс. Представил себе в этой роли условный Роскомнадзор - и стало страшно.
админы, похоже, настолько не верили в столь масштабное падение
Чуваки из Cloudflare тоже первым делом полезли проверять со своей стороны. Правда их сервисы не так просто ребутнуть "на всякий случай".
Кстати, вспомнил, у меня тоже кабельный исчез на пару минут примерно в тоже время, что и лёг фейсбук
С 18:30 (по московскому) пропал проводной интернет с диагнозом "DNS lookup error". Перезагрузки роутера не помогали. Закончилась вся эта свистопляска где-то в 22-23 по московскому. Провайдер правда тоже так себе.
Место: ГДР, Дрезден.
На сотовых от хуавея новых тоже погас инет,так как телефоны проверяли его наличие пингуя что-то FB. Многие телефоны проверяют наличие инета пингуя 1.1.1.1. Вот если он погаснет...
А он погаснет, так как Роскомнадзор уже мечтает его заблокировать.
У меня провайдер локальный (довольно крупный) вообще умер на сутки! Ровненько одновременно с падением Фейсбука. По телефону - автоответчик "у нас авария, исправляем". Через час пришла смс "авария на магистральном кабеле". И только сегодня в обед кое-как заработало.
Киев.
У меня MTS отрубился на несколько минут тоже.
В стародавние времена, когда миллениалы ещё не пребывали в эйфории от удалёнки, а зумеры только начали появляться на свет, у бородатых сисадминов уже в ходу была такая примета: "Удалённая настройка сети - это к дальней дороге..." :)
6 часов даунтайма как раз очень похожи на типичный экстренный перелёт :)
Может быть, я не понимаю, но BGP, это протокол прикладного уровня, поверх TCP. Он служит для динамического обновления маршрутов. Отсутствие BGP пакетов не должно сразу валить всю сеть.
Может быть через некоторое время, когда последние маршрутные таблицы не обновятся и перестанут соответствовать реальной конфигурации сети. Да и тогда, должны упасть только те части сети, которые поменялись.
Или я не понимаю как работает Интернет?
Написано: "маршруты были отозваны" (=удалены) - были сообщения обновления.
Нет, интернет работает не так.
Нет keepalive = сессия падает по hold time = всё принятое из нее удаляется. Hold time обычно секунд 180.
Как сессии упадут - всем с кем есть BGP разошлются апдейты, те своим пирам разошлют и тд.
Минут 10 - и префиксов фейсбука как бы и не было никогда :-)
А это всегда так работало? Потому что мне кажется, что коммуникации на нижних уровнях, как-то не должны зависеть от протокол прикладного уровня.
Я так понимаю, вы сейчай про модель OSI говорите. Она концептуально-условная, служит только для для разделения "слоёв". Никаких реальных зависимостей там нет.
В реальности оказалось удобно обмениваться маршрутами через прокотокол построенный на TCP. Перенос BGP ниже - если, например, накостылять какой-нить MAC-BGP где будут только MAC-адреса в заголовках - смысла не имеет. Что так апдейты пропадут и l3 уйдёт, что так.
Они и не зависят в том смысле, что если согласованно остановить демон, который отвечает за BGP, на всех роутерах сети — маршруты сохранятся и сеть продолжит работу.
Но пока этот самый демон активен — он управляет маршрутами, и может эти самые маршруты вовсе удалить. Что и делает при исчезновении партнёра, который эти маршруты передал.
Ну, так гораздо понятнее. Выходит, что они себе сепуку сделали. Ведь, после падения сети, TCP тоже работать не будет. И восстановить маршруты не получится, так как BGP работает поверх TCP.
BGP -- не единственный способ управлять маршрутами. Достаточно задать маршрут вручную, и TCP поднимется. (Что, по-видимому, и было сделано.)
Все нормальные приложения тоже обязаны иметь ip fallback.
В нормальной конфигурации BGP не управляет теми маршрутами, через которые сам работает: внешние соединения BGP работают между соседними роутерами, а внутренние работают через сеть, управляемую другими протоколами или тоже статикой.
А вот что и правда у них наверняка отвалилось, это SSH и SNMP.
Вот вы пошли в IANA и купили айпишники. Вам надо сообщить миру о том, что они у вас есть. Тут включается AS + BGP. Вот кто то что то сделал и по таймауту эти связи ушли + спецы не могли достучаться до серверов (через интернет ходят?).
Тут либо надо было находиться внутри сети L2/L3 с наличием IP, либо топать в офис пешком
Падение BGP для внешних операторов - следствие какой-либо внутренней проблемы внутри ЦОД ФБ.
Такое часто бывает при редистрибьюции full view в IGP. Ложится вся сеть и определение первопричины занимает очень много времени (т.к. тасктрекеры тоже лежат).
При редистрибьюции в igp не пропадут анонсы. С чего бы….
Автономная сеть перестала анонсировать себя в глобальной сети, пул айпишников выпал по таймауту.
У меня подгрузка ленты на фб перестала работать ещё за день до полного падения.
У меня дежавю. Такое ощущение, что буквально недавно - не больше года-двух - была статья про сбой в интернете и тоже связанный с BGP. И что-то с настройкой и обновлением роутеров. Не помню, что это было, и найти не могу.
Да такое регулярно случается. То по глупости, то по умыслу и глупости (как кто-то там пытался через BGP у себя на территории блочить ютуб, в итоге заблочил его для половины мира). Все следствие того, что все эти протоколы разрабатывались давно, когда веб был уделом профессионалов и работал на доверии, в итоге корневые протоколы не содержат никаких адекватных защит от дураков и хакеров.
Год назад сам Cloudflare частично лежал из-за неправильного обновления BGP:
https://blog.cloudflare.com/cloudflare-outage-on-july-17-2020/
Не хочется уподобляться сторонникам теории заговора, но какое интересное совпадение с определенными событиями.
я счастливый человек. Абсл не заметил проблем с Интернетом и сервисами FB.
Машина стояла на качке торрентов. DNS в роутерах прописан Google, Яндекс, и че то еще бесплатное, провайдерское стер от греха. FB - зареган, но не пользуюсь. WA - раз в неделю. Insta ? меня там 3 раза банили. на 4-ый раз голых котиков постить, было как не с руки, на время сбоя.
А так. Когда кто-то мне начинает грить, что Интернет невозможно откл, я тихонько посмеиваюсь, и напоминаю, что погранзона 30 км, а где то и целые районы с областями.
Из-за чего Facebook стал глобально недоступен. Технический ликбез