Comments 82
Вот вам и микросервисы
А почему именно микросервисы, а не, например, биткойн, или почечный чай? Они имеют ровно такое-же отношение к оной проблеме у Фейсбука, что и микросервисы.
Первая версия BGP выпущена в конце прошлого века https://datatracker.ietf.org/doc/html/rfc1105. В те времена про микросервисы еще никто не думал.
Тут скорее нужно сказать "Вот вам и интернет".
а при чем тут микросервисы?
Автор комментария наблюдает в индустрии слепую веру в микро-сервисный подход к архитектуре системы. Одним из столпов этой веры автор видит негласное убеждение, что используя микро-сервисный подход вы автоматически получаете лучшую отказоустойчивость. Ведь больше нет большого монстра-монолита, и значит как бы нету single point of failure. Монолиты - плохо. Микросервисы - хорошо.
Автор надеется, что данный инцидент поможет индустрии понять, что использование микросервисной архитектуры для приложения не панацея. И не абсолютное добро, которое надо пихать направо и налево как волшебную таблетку от SPOF.
P.S. Все еще интересно услышать ответ автора комментария, хоть это уже и крайне маловероятно. :)
[Update]
P.P.S. Простите, не сразу заметил, что именно Вы и есть автор изначального комментария — предлагаю продолжить дискуссию. :)
Забавно, что автор комментария под обе статьи про падение ФБ написал про микросервисы.
Что в случае монолита, что в случае микросервисов единой точкой отказа является мисконфигурация сети. Также можно предлагать не использовать интернет или электричество, например.
Возвращаясь из абстракции и теорий непосредственно к теме разговора, это, конечно, забавно, но есть вероятность, что автор комментария не получил желаемого отклика на свой первый комментарий и оставил подобный комментарий к статье на ту же тему. Если у нас несколько почти одинаковых статей, смысл удивляться почти одинаковым комментариям?
Вторая часть Вашего комментария, думаю, не нуждается в ответе. :)
Все можно использовать неправильно) Однако в последнее время я вижу, что неправильно используется как раз подход с микро-сервисами. По причине неправильной мотивации. "А что же еще?" "Мы хотим быть как нетфликс, гугл и фейсбук!" "Все используют, мы хотим быть современными"
Сначала дорасти бы до проблем, решаемых микросервисной архитектурой, потому уже их решать.
Могу я поинтересоваться, вы когда последний раз выбирали микросервисную архитектуру, какие были критерии?
предположу, что низкоуровневые сетевые протоколы точно не входят в список критериев для для выбора в пользу или против микросервисной архитектуры, т.к. они немного про другое. монолит бы прилег при таких проблемах еще быстрее.
поэтому, IMHO, микросервисы в комментариях под данной статьей — это оффтоп.
На текущем проекте я задумываюсь о применении микросервисов, потому что это очень неплохой вариант разгрести древнее, неповоротливое легаси.
Скажите, а эти микросервисы, они сейчас тут, в этой комнате?
Только микросервисы тут совершенно ни при чём. Ошибка произошла из-за кривой конфигурации BGP. Это человеческий фактор. Если до всей сети Фейсбука пропал маршрут -- там хоть монолит, хоть микросервис -- разницы нет, не достучаться.
Не зря, наверное, есть требования пропускную систему и пожарную безопасность делать автономной и изолированной, что бы ни какой компьютерный сбой её не положил.
У них авторизация через фейсбук. /trollface
Как человек работавший в АСУ ТП, ответственно заявляю - д@#$*!ы есть везде. Я уже перестал считать количество ошибок, объяснять и бить по рукам, чтобы люди смотрели и вели IP-план (хотя бы).
Всегда, стабильно находятся чудаки которые на объекте: "ну а четакова? я попинговал IP вроде никто не отвечает, ткнулся в свободный порт, сервер не увидел, подумал что проблема в vlan и отключил их. Просидел тут сутки, у меня самолет через час, в чем может быть проблема?" А потом оказывается что на этом IP сидел шлюз который раз в час\сутки шлет отчет в систему верхнего уровня, порт был включен потому что другую железку забрали на ремонт, а vlan'ы, цЫтирую "я в этом не понимаю, нафиг оно нужно?!"
Что за шлюз, который не может на запрос ping ответить?
Любой у которого все лишние сервисы и порты отключены или заблокированы.
И как же он мониторится тогда? По SNMP?
По зеленым индикаторам на морде, сухим контактам (общая авария), profibus\net, МЭК61850, SNMP и для особо упоротых UART воткнутый в PLC. ...но уж точно не через ICMP.
Бонусом шлюз может быть в другой системе, т.е. вне зоны вашей ответственности и туды вас никто и никогда не пустит - максимум дадут протокол передачи данных. Т.е. система регистрации событий может состоять из условного 1 сервера и 100500 шлюзов смотрящих в разные, смежные системы.
Второе, вы, своим нижним\средним уровнем, мониторить верхний не должны. Это как если бы у вас сервера мониторили систему мониторинга (простите за тавтологию). Ну увидят они отвал Zabbix'a дальше то что?
ответ по ICMP-протоколу никак не гарантирует работоспособность шлюза, так что такой мониторинг — это скорее "мониторинг"
вспомнились предания про БГП в неумелых руках и редистрибьют fullview, который валит огромные сегменты интернета
«Обожаю» апдейты со сбросом конфига.) А вообще странно что на рабочие железки обновление накатывали. Помню как сотрудник рассказывал как так же софты на магистральных роутерах обновил и роутинги все слетели. Легло все, включая телефонию у части страны. Страшно было всем кто слушал эту душещипательную историю.)
Ой, а че это получается программисты не умеют в сети и оказалось что сетевые инженеры тоже нужны? Кто бы мог подумать...
Зато сетевик, который положил сетку на бочок, наверняка с успехом прошел курсы "как пройти собеседование в FAANG". И вот вам показательный пример, к чему приводит стратегия найма лучших из лучших со стороны работодателя и учение проходить собеседования, а не иметь знания, со стороны сотрудника.
Сколько подобных косяков Вы знаете в рамках одной крупной компании (не обязательно ФБ)? Это очень редкие явления в рамках крупной компании, но они случаются и это банальный человеческий фактор от которого очень трудно избавиться.
Так вот почему машины пытаются истребить человечество в фантастике: хотят просто избавиться от т.н. "человеческого фактора".
Как Вы думаете, машины не могут допустить ошибку? Тогда почему у нас есть понятие «bit flip»? Почему в космос запускается, в основном, промышленный, а то и «военный» кремний? За исключением недавнего прецедента с Ingenuity. Даже исключив человеческий фактор, нельзя исключать природный фактор.
У этого явления есть название - Swiss cheese model
Оправдания, как дырка в носу, есть у каждого. 6 часов простоя говорят об отсутствии и/или out-of-band управления, отсутствии резерва, плана отката и вообще понимания, что произошло и почему. А скорее всего, сразу лили на прод, как это сейчас модно. Канареечные, елки-палки, релизы.
Канареечный релиз работает немного не так, это совсем не синоним "сразу лить на прод".
Да, я понимаю. Но мне необходимо словосочетание не из обсценной лексики для обозначения той дикой феерии некомпетентности, что происходит сейчас в сетевой и серверной инфраструктуре. А программирование, как таковое, наверное, больше всех пострадало. Люди, претендующие на звание инженера, способны только на действие уровня "нажать вот эту кнопку и тогда произойдет вот это". А ответить на вопрос "почему?" именно на эту кнопку они не могут. Это уровень техника, а не инженера, средне-специальное образование - знаем "как", но не понимаем "почему".
к чему приводит стратегия найма лучших из лучших
К тому, что таких прилеганий было пару раз за последние 15 лет, а не каждые полгода по паре часов на "перенастройку сервера"?
Примета есть такая: Удаленно настраивать маршрутизатор - к дальней дороге
Интересно, конфиг меняли свои штатные сетевики или же аутсорс из страны слонов и дельта-штамма?
Окей. Но как тогда объяснить параллельные проблемы с сервисами гугла, тиктока, твиттера и прочих?
Пользователи фейсбука ломанулись туда, создав временную нагрузку, к которой часть сервисов оказалась не готова? Телеграм вот тоже немножко напрягся, когда к нему ломанулись вотсапники.
Проблемы были не только у отдельных социальных сервисов (тут как раз всё просто – люди миллионами кинулись обсуждать упавший Facebook и его сервисы, что серьезно увеличило нагрузку на их инфраструктуру). Сильно упрощённо: значительно и резко выросла нагрузка – приложения FB, Instagram и WhatsApp у сотен миллионов пользователей делают множество повторяющихся запросов, сами пользователи пытаются "достучаться" до неработающих сервисов... Учитывая огромное количество клиентов – это привело к резкому всплеску нагрузки на инфраструктуру и к замедлению работы даже у независимых от Facebook сервисов.
2) Огромное количество сайтов всякими виджетами, лайками и прочим продолжало ломиться в несуществующий на тот момент в сети Фейсбук, DDoSя корневые DNS сервера.
Раньше была примета: удаленная настройка файерволла - к дальней дороге.
Потом стало проще, воткнуть ноут в консоль, подключить его к инету через телефон и запустить какой-нибудь тимвьювер сейчас сможет практически любой человек, примета забылась.
И вот фейсбук снова возродил традицию конфигурирования маршрутизаторов прямо из ЦОД.
Умные люди катали скрипт, который правил файрволл, затем уходил в спячку на какое то время, после чего откатывал изменения назад. Успел прибить скрипт - значит, файрволл настроен правильно; не успел - значит, попробуй еще раз.
С культурными железками отчасти было проще, ту же асу в крайнем случае можно было просто попросить перезагрузить и получить startup-config. А вот со всякими enterprise class firewall от *-Link происходили страшные и странные вещи. Ну и всякое пожелтевшее от времени древнее зло, натужно пыхтящее в подсобке на большой кадке с землей(10 лет прошло, а кошмары до сих пор снятся) могло дать жару.
Но и с культурным происходило всякое. Отсутствующий или неактуальный startup-config, битый бинарник, бинарник другой версии на одном из коммутаторов в стеке. Поэтому для меня наличие человека с ноутбуком, переходником com-usb, инетом на телефоне и голубым проводком в шаговой доступности от железа - обязательный стандарт при проведении даже самых простых работ.
Вообще, с трудом представляю тот ужас, который испытали люди, ответственные за этот апдейт. Это вам не стеджинг порушить и даже не прод.
Наташа, мы всё уронили. Вообще всё. (С)
А еще очень любопытно, какими порядками исчисляются убытки от данного факапа.
А по итогу дай бог не уволят такого опытного сетевика, как у них сейчас есть. Не каждый имеет в своём багаже факап на n млрд. долларов, обучение такого специалиста весьма непростая и дорогая задача :D
Отчет от Cloudflare: https://blog.cloudflare.com/october-2021-facebook-outage/
И перевод на Хабре: https://habr.com/ru/company/flant/blog/581560/
Черт! А я думал ИИ виновато!
Теперь системные архитекторы Facebook узнают что оказывается DNS и внутренние сервисы надо делать отказоустойчивыми и учитывать фактор "а что будет если".
Их VR-шлемы тоже не работали?
P.S.: ага, даже это :)
проблема коснулась очков виртуальной реальности Oculus. Пользователи могут использовать уже загруженные игры, но установка новых игр и социальные функции не работают.
Ох уж эти маршрутизаторы)
На моем веку помню несколько крупных факапов у инженеров, когда к примеру, в резервном модуле бгп в циске, память забыли апгрейднуть. С апгрейдом на основном модуле. Что-то пошло не так, переключение на резерв. Память закончилась и заверт.... пока разобрались почему, было уже слишком поздно.
Интересно, каким образом система безопасности по доступу к периметру дата центра зависит от маршрутизации?!
На то она и система безопасности, чтобы в случае сбоя в любых других системах, оставаться работоспособной. Странно как-то.
То есть компания еще сама до конца не поняла причину сбоя.
Надеюсь, раскопают и обнародуют, чтобы такого никто больше не повторял.
Базовая причина по сути та же — неразделение ресурсов управления внешней и внутренней инфраструктуры и отсутствие аварийных средств восстановления.
Facebook объявила причину глобального сбоя