Pull to refresh

Comments 82

А почему именно микросервисы, а не, например, биткойн, или почечный чай? Они имеют ровно такое-же отношение к оной проблеме у Фейсбука, что и микросервисы.

Первая версия BGP выпущена в конце прошлого века https://datatracker.ietf.org/doc/html/rfc1105. В те времена про микросервисы еще никто не думал.

Тут скорее нужно сказать "Вот вам и интернет".

Просто у некоторых в .опе свербит, забывают про главное правило программиста - работает не трогай, пока не поломается.

Т.е. вы до сих пор не понимаете, почему обновляют железо и софт?

В наше время, увы, зачастую что-то очень может очень больно и серьезно сломаться наоборот если вовремя не обновиться.

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

Нет, речь, например, про 0-day уязвимости.

а при чем тут микросервисы?

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

Автор комментария наблюдает в индустрии слепую веру в микро-сервисный подход к архитектуре системы. Одним из столпов этой веры автор видит негласное убеждение, что используя микро-сервисный подход вы автоматически получаете лучшую отказоустойчивость. Ведь больше нет большого монстра-монолита, и значит как бы нету single point of failure. Монолиты - плохо. Микросервисы - хорошо.

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

Однако ведь оба подхода можно использовать неправильно. Один человек может написать стабильный, адекватный монолит, но не осилит в микро-сервисы, при этом другой человек отлично спроектирует микро-сервисную архитектуру, но не осилит в монолит. Я даже по себе, порой, замечаю, что порой бывает трудно отстраниться от личных предпочтений и выбрать правильную архитектуру проекта именно на данный момент.
P.S. Все еще интересно услышать ответ автора комментария, хоть это уже и крайне маловероятно. :)
[Update]
P.P.S. Простите, не сразу заметил, что именно Вы и есть автор изначального комментария — предлагаю продолжить дискуссию. :)

Забавно, что автор комментария под обе статьи про падение ФБ написал про микросервисы.

Что в случае монолита, что в случае микросервисов единой точкой отказа является мисконфигурация сети. Также можно предлагать не использовать интернет или электричество, например.

Возможно, у chilicoder был какой-то супер-негативный опыт с микросервисами. Я сам не очень люблю слепую веру в то, что «проповедуют», я считаю, что надо относиться ко всему с адеватной долей критичности.

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

Вторая часть Вашего комментария, думаю, не нуждается в ответе. :)

Все можно использовать неправильно) Однако в последнее время я вижу, что неправильно используется как раз подход с микро-сервисами. По причине неправильной мотивации. "А что же еще?" "Мы хотим быть как нетфликс, гугл и фейсбук!" "Все используют, мы хотим быть современными"

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

Могу я поинтересоваться, вы когда последний раз выбирали микросервисную архитектуру, какие были критерии?

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

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

Скажите, а эти микросервисы, они сейчас тут, в этой комнате?

UFO landed and left these words here

Только микросервисы тут совершенно ни при чём. Ошибка произошла из-за кривой конфигурации BGP. Это человеческий фактор. Если до всей сети Фейсбука пропал маршрут -- там хоть монолит, хоть микросервис -- разницы нет, не достучаться.

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

У них авторизация через фейсбук. /trollface

Наши бы надзорные органы их за это давно на счетчик поставили

Как человек работавший в АСУ ТП, ответственно заявляю - д@#$*!ы есть везде. Я уже перестал считать количество ошибок, объяснять и бить по рукам, чтобы люди смотрели и вели IP-план (хотя бы).

Всегда, стабильно находятся чудаки которые на объекте: "ну а четакова? я попинговал IP вроде никто не отвечает, ткнулся в свободный порт, сервер не увидел, подумал что проблема в vlan и отключил их. Просидел тут сутки, у меня самолет через час, в чем может быть проблема?" А потом оказывается что на этом IP сидел шлюз который раз в час\сутки шлет отчет в систему верхнего уровня, порт был включен потому что другую железку забрали на ремонт, а vlan'ы, цЫтирую "я в этом не понимаю, нафиг оно нужно?!"

Что за шлюз, который не может на запрос ping ответить?

Любой у которого все лишние сервисы и порты отключены или заблокированы.

И как же он мониторится тогда? По SNMP?

Да по чему угодно, в том числе и по SNMP, да.

По зеленым индикаторам на морде, сухим контактам (общая авария), profibus\net, МЭК61850, SNMP и для особо упоротых UART воткнутый в PLC. ...но уж точно не через ICMP.

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

Второе, вы, своим нижним\средним уровнем, мониторить верхний не должны. Это как если бы у вас сервера мониторили систему мониторинга (простите за тавтологию). Ну увидят они отвал Zabbix'a дальше то что?

ответ по ICMP-протоколу никак не гарантирует работоспособность шлюза, так что такой мониторинг — это скорее "мониторинг"

вспомнились предания про БГП в неумелых руках и редистрибьют fullview, который валит огромные сегменты интернета

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

Спасибо, впечатлений на несколько дней))))

«Обожаю» апдейты со сбросом конфига.) А вообще странно что на рабочие железки обновление накатывали. Помню как сотрудник рассказывал как так же софты на магистральных роутерах обновил и роутинги все слетели. Легло все, включая телефонию у части страны. Страшно было всем кто слушал эту душещипательную историю.)

Компетентность сотрудника - я у мамы сисядмин

Хе. Напомнило мне про "почта не ходит дальше 500 миль". Тоже весь прикол был в обновлении postfix

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

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

UFO landed and left these words here

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

Зато сетевик, который положил сетку на бочок, наверняка с успехом прошел курсы "как пройти собеседование в FAANG". И вот вам показательный пример, к чему приводит стратегия найма лучших из лучших со стороны работодателя и учение проходить собеседования, а не иметь знания, со стороны сотрудника.

Любой человек может допустить ошибку. Иногда ошибки нескольких людей накладываются друг на друга: один человек, запарившись по тем или иным причинам, внес изменения с ошибкой, другой человек, по тем или иным причинам, проверил и не нашел косяков в обновлении с ошибкой, третий человек тоже по каким-то причинам не заметил ошибку. Это случается.
Сколько подобных косяков Вы знаете в рамках одной крупной компании (не обязательно ФБ)? Это очень редкие явления в рамках крупной компании, но они случаются и это банальный человеческий фактор от которого очень трудно избавиться.

Так вот почему машины пытаются истребить человечество в фантастике: хотят просто избавиться от т.н. "человеческого фактора".

Ну давайте обсудим «фантастику». :)
Как Вы думаете, машины не могут допустить ошибку? Тогда почему у нас есть понятие «bit flip»? Почему в космос запускается, в основном, промышленный, а то и «военный» кремний? За исключением недавнего прецедента с Ingenuity. Даже исключив человеческий фактор, нельзя исключать природный фактор.
Ни разу не слышал этого названия, спасибо Вам — я стал немного умнее. :)

Оправдания, как дырка в носу, есть у каждого. 6 часов простоя говорят об отсутствии и/или out-of-band управления, отсутствии резерва, плана отката и вообще понимания, что произошло и почему. А скорее всего, сразу лили на прод, как это сейчас модно. Канареечные, елки-палки, релизы.

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

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

UFO landed and left these words here

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

к чему приводит стратегия найма лучших из лучших

К тому, что таких прилеганий было пару раз за последние 15 лет, а не каждые полгода по паре часов на "перенастройку сервера"?

Примета есть такая: Удаленно настраивать маршрутизатор - к дальней дороге

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

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

Интересно, конфиг меняли свои штатные сетевики или же аутсорс из страны слонов и дельта-штамма?

Окей. Но как тогда объяснить параллельные проблемы с сервисами гугла, тиктока, твиттера и прочих?

Пользователи фейсбука ломанулись туда, создав временную нагрузку, к которой часть сервисов оказалась не готова? Телеграм вот тоже немножко напрягся, когда к нему ломанулись вотсапники.

Проблемы были не только у отдельных социальных сервисов (тут как раз всё просто – люди миллионами кинулись обсуждать упавший Facebook и его сервисы, что серьезно увеличило нагрузку на их инфраструктуру). Сильно упрощённо: значительно и резко выросла нагрузка – приложения FB, Instagram и WhatsApp у сотен миллионов пользователей делают множество повторяющихся запросов, сами пользователи пытаются "достучаться" до неработающих сервисов... Учитывая огромное количество клиентов – это привело к резкому всплеску нагрузки на инфраструктуру и к замедлению работы даже у независимых от Facebook сервисов.

1) Мессенджеры и соцсети испытали неожиданный прилив траффика, к которому не были готовы
2) Огромное количество сайтов всякими виджетами, лайками и прочим продолжало ломиться в несуществующий на тот момент в сети Фейсбук, DDoSя корневые DNS сервера.

Раньше была примета: удаленная настройка файерволла - к дальней дороге.

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

И вот фейсбук снова возродил традицию конфигурирования маршрутизаторов прямо из ЦОД.

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

С культурными железками отчасти было проще, ту же асу в крайнем случае можно было просто попросить перезагрузить и получить startup-config. А вот со всякими enterprise class firewall от *-Link происходили страшные и странные вещи. Ну и всякое пожелтевшее от времени древнее зло, натужно пыхтящее в подсобке на большой кадке с землей(10 лет прошло, а кошмары до сих пор снятся) могло дать жару.

Но и с культурным происходило всякое. Отсутствующий или неактуальный startup-config, битый бинарник, бинарник другой версии на одном из коммутаторов в стеке. Поэтому для меня наличие человека с ноутбуком, переходником com-usb, инетом на телефоне и голубым проводком в шаговой доступности от железа - обязательный стандарт при проведении даже самых простых работ.

ту же асу в крайнем случае можно было просто попросить перезагрузить и получить startup-config.

Можно было еще reload in сделать. Главное при успешной конфигурации не забыть reload cancel (чертовы флешбэки).

Удаленное изменение конфигурации на маршрутизаторе — к дороге

Вообще, с трудом представляю тот ужас, который испытали люди, ответственные за этот апдейт. Это вам не стеджинг порушить и даже не прод.
Наташа, мы всё уронили. Вообще всё. (С)

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

да как всегда неземными. Кто-то чихнул и цукер «потерял» $5млрд на падении акций на пару процентов. К НГ акции поднимутся (ну например, я ни разу не брокер или кто там) и он «заработает» их обратно.
А по итогу дай бог не уволят такого опытного сетевика, как у них сейчас есть. Не каждый имеет в своём багаже факап на n млрд. долларов, обучение такого специалиста весьма непростая и дорогая задача :D

Админ:
— Мне писать заявление по собственному?

Цукерберг:
— Я только что потратил олимпиард баксов на твоё обучение, будешь тут работать, пока не отработаешь!

Теперь системные архитекторы Facebook узнают что оказывается DNS и внутренние сервисы надо делать отказоустойчивыми и учитывать фактор "а что будет если".

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

Их VR-шлемы тоже не работали?


P.S.: ага, даже это :)


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

Ох уж эти маршрутизаторы)

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

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

Так она и оставалась работоспособной, работоспособно никого не пуская.


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

Фраза из первоисточника: «we’re working to understand more about what happened today».
То есть компания еще сама до конца не поняла причину сбоя.
Надеюсь, раскопают и обнародуют, чтобы такого никто больше не повторял.
UFO landed and left these words here
Кросс-линкую с похожей ситуацией этим летом.
Базовая причина по сути та же — неразделение ресурсов управления внешней и внутренней инфраструктуры и отсутствие аварийных средств восстановления.
Only those users with full accounts are able to leave comments. Log in, please.