Все компоненты зелёные, а продакшн лежит: разбор аварии, которую нашли в git

[tuxi]

Так по идее "новые правила сетевого фильтра в новом облаке " должны скорей приводить к connection refused, а не к таймауту соединения, или нет?

[forthgate]

Клиенту будет выдаваться Connection refused олько в том случае, если правило в файрволле настроено на reject, но у провайдера видимо стоит правило drop, тогда соединение просто будет висеть до таймаута

[tuxi]

А правило drop более выгодно или это какие-то секурные стандарты? Просто если ставить по дефолту reject, то и диагностика проблемы была бы моментальной.

[forthgate]

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

[olegbukatchuk]

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

[forthgate]

По идее этот инцидент можно было отловить сразу, если у сервисов были бы хелсчеки и их мониторинг/алертинг

[olegbukatchuk]

Мониторинг у сервиса был и хеслчеки тоже (но они на покрывали этот кейс). После данного инцидента команда сервиса, пересмотрела механику проверки в хелсчеках.

[trublast]

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

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

[olegbukatchuk]

Алерта с такой логикой, как вы описали:  "количество запросов к базе на xx% отличается от среднего количества запросов в это время в этот день недели за последний месяц" у нас на тот момент не было. Что касается алерта с количеством запросов к базе, то он был настроен только на максимальное количество коннектов в базе.