Сбой сервиса 20.02

 

От редакции:

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

Часть пользователей видит работу над сбоем так:

Образовалась проблема → мы подождали, перезагрузили роутер → проблема отступила.

На деле при любом массовом сбое отдел разработки кидает все свои ресурсы на решение проблемы. 

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

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

Отдаем вам Ctrl+С – Ctrl+V того самого отчета, потому что не боимся быть честными.

Alexander, [20 февр. 2021 г., 03:04:25 (20 февр. 2021 г., 03:16:45)]:

Постмортем сегодняшнего сбоя: хронология

16:00 — образовался затор в очереди обновления счетчика неотвеченных в амо

У нас организовался затор в очереди обновления счетчика неотвеченных в амо (п.1 разбора) – с этого момента трафик в нашу сторону уже был выше нормы, но это стало понятно уже потом.

16:30 — увеличили количество обработчиков очереди в 10 раз

Мы увеличили количество обработчиков этой очереди в 10 раз (с различными обработчиками очередей мы так регулярно делаем, это нормальная практика, но см. п.2), очередь стала обрабатываться быстрей, все пока норм.

16:50трафик в нашу сторону резко возрос

17:00 — подозреваем ддос атаку

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

17:15 — показалось, что сервис приходит в норму

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

17:20 — трафик снова вырос и я заблокировал весь входящий трафик

Трафик снова вырос (п.3) , кабинет не открывается. Блокирую все входящие запросы, кроме самих серверов кластера и серверов касперского, фермы отправляются на 5й сервер кластера, чтобы смогли до него достучаться (т.к. они для сервиса внешний источник), тут была допущена ошибка, я кривыми руками просто заблокировал весь трафик, в т.ч. и касперского, долго разбирался, выяснил, поправил.

17:50 — снова показалось, что всё норм

Касперский фильтрует трафик, кластер обрабатывает нормальный трафик, внешне все похоже на то что норм. Смогли зайти в управление кластером, откатываем 10 обработчиков очередей (то что увеличивали в 16:30)

18:00 — теперь недоступен сервер, нашли причину

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

Причина: мои кривые руки, версия 2 – когда я исправил блокировку трафика касперского, 5й сервер оказался не в белом списке. Спасибо юзер-ненавидящий интерфейс дата-центра – тут уебаться надо, чтобы что-то сделать и не ошибиться (Катя-дизайн, после этого вашему отделу большой респект, в такие моменты еще больше ценишь когда думают о том как юзер этим будет пользоваться).

18:25 — все работает, выжидаем несколько минут, объявляем

Теперь разбор причин

(пункты из отсылок выше)

1. От Егора я узнал, что ровно во время нашего сбоя сбоило и амо у части пользователей, но как это могло на нас повлиять было не очень понятно. Поэтому я открыл у себя несколько тестовых аккаунтов амо, правда сразу после сбоя ничего необычного не заметил и просто оставил их открытыми. В 00:30 я увидел аномалию по графикам касперского, нажал ф5 во всех аккаунтах амо: один не загрузился, но у нас было все норм, сервис работал, касперский правда порезал часть трафика. А вот позже увидел интересное в этом сбойнувшем аккаунте амо – амо нормально не прогружалось, а вот наш виджет в нем перезапускался постоянно, с каждым разом открывая новое соединение с нашим сервисом – это и породило затык в очереди.

Alexander, [20 февр. 2021 г., 03:04:26 (20 февр. 2021 г., 03:32:46)]:

2. В экземпляре обработчика очереди оповещений амо, внутри находится сама точка входа (то место, куда коннектится виджет), и эта точка входа должна быть одна. Отделить точку входа от обработчика – это старая задача, так называемый техдолг, который никогда не был критичен и поэтому очень давно прикоплен в мормышечной. Но вот увеличение количества экземпляров точки входа с 1 до 10 (т.к. он находится вместе с обработчиками очереди, а увеличивали именно их) вызвало постоянный реконнект виджета к нашему сервису. И все бы ничего, но постоянный реконнект от этой ошибки, помноженный на постоянный реконнект из-за сбоев в амо вызвал шквал.

Почему сразу не заметили?

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

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

А пока не делали – вообще забыли что вот она, там где обработчик очереди.

Урок ценный, повторять не будем.

3. Как выяснилось позже – касперский первый раз блокирует подозрительные ip-адреса на 10 минут, а потом их возвращает и дальше анализирует их поведение – это нормальная страховка от ошибочной блокировки. Но это стало причиной временного возврата большого трафика, а это я трактовал неверно, в целом надо было еще подождать минут 5-10 вместо того, чтобы в спешке ошибаться.

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

Выводы

Вывод №1: “обжегшись на молоке…”:

После декабрьского ддоса теперь при каждом массовом сбое – все кажется что нас дальше ддосят. Нет, сегодня был не ддос (ну не в классическом понимании точно), технически ддос мы сделали себе сами. К слову, с новым пониманием, я еще раз пересмотрел случай в декабре, посмотрел отчеты дата-центра и да, тогда был действительно ддос: много незнакомых ip-адресов, запросы рандомные, китайские подсети. В общем, поставив бы я под сомнение возможность ддоса сразу – вероятность не наломать дров была бы выше.

Вывод №2: нужны учения для подобных ситуаций

Пойду думать как организовывать учения. т.к. во времени 2/3 было потрачено впустую из-за ошибок и ложных гипотез.

Вывод №3: пересмотреть техдолг

В техдолге есть что-то, что откладывается потому что попадает в категорию “просто привести в порядок, но сейчас критичности нет, т.к. таким образом точно не наебемся” – оказывается, наебемся. Просто потому, что забудем о том, что есть такой артефакт. Иду пересматривать техдолг.

Вывод №4: не проверять решения-гипотизы на горячую

Кажется, мы переросли быстрые и скоропостижные решения текущих проблем (проблема-пример: затык в очереди амо). Быстро проверить решение-гипотезу – это, конечно, эффективно, но уже не позволительно. Как надо теперь – ответа нет, ушел думать.

Ну и минутка юмора:

Теперь мне предельно понятно как заддосить кого-нибудь просто средствами наших юзеров и нашим фронтом в их браузерах 😊