От редакции:
В пятницу 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: не проверять решения-гипотизы на горячую
Кажется, мы переросли быстрые и скоропостижные решения текущих проблем (проблема-пример: затык в очереди амо). Быстро проверить решение-гипотезу – это, конечно, эффективно, но уже не позволительно. Как надо теперь – ответа нет, ушел думать.
Ну и минутка юмора:
Теперь мне предельно понятно как заддосить кого-нибудь просто средствами наших юзеров и нашим фронтом в их браузерах 😊
