3 мая вы могли заметить, что Имперский Стражник с ночи работал не очень стабильно: не отвечал на некоторые запросы, а на другие отвечал по несколько минут. Мы признаём — мы накосячили. И сильно. Давайте вместе посмотрим, что мы делали и где всё пошло не так.
Уже давно у нас стояла задача на создание второй, текстовой модели для ИИ-модерации. Сейчас мы умеем проверять только визуал, но если запрещённый контент находится в тексте — мы его не видим. Тут и должна помочь текстовая модель.
27 апреля — 1 мая
Мы берём в активную разработку задачу на создание и интеграцию текстовой модели. Первая итерация: для хранения угрозы используется единое поле
danger с приоритизацией по опасности. На наш взгляд, это была рабочая и вполне нормальная логика. Мы дописали код и выкатили релиз в продакшен.2 мая, 13:00 — первый звоночек
Нам присылают репорт и интересное предложение. Суть: Стражник выдал ограничение за порнографию в ответ на стикер, где был лишь шуточный текст про половой акт.
Предложение звучало так:
«А ты не думал им отдельные категории выдать? Потому что порнография текстом и порнография картинкой — вещи немного разные».
Мы задумываемся и понимаем: поинт крайне корректный. Нужно срочно исправлять ситуацию, пока массовые ограничения с такой логикой не улетели всем подряд.
2 мая, 14:15
Создаём задачу
IG-132841, в рамках которой планируем рефактор:intent_mediaintent_textРазделяем текстовую и визуальную угрозу.
3 мая, 1:26
Выкатываемся на прод (не с первого раза). Пропускная способность крайне низкая, при этом
Load Average — 23. Потеряли индексы в БД. Спустя 20 минут восстанавливаем индексы, чиним медленные запросы и продолжаем жить.3 мая, 1:52
Отваливается Prometheus.
Мы уже понимаем: вечер будет весёлый.
За 7 минут дебага находим кривой запрос сбора статистики и правим его.
3 мая, 2:27
После ещё пары хотфиксов мы наконец в проде. Всё работает. Без даунтайма внедрили фичу. Красота.
Тогда мы ещё не знали, что натворили.
За пару минут система разгоняется до 11 ops.
Что такое 11 ops? Это 11 файлов, которые скачиваются, проверяются и сохраняются каждую секунду.
3 мая, 3:01 — первый звонок армагеддона
Начинаем получать от BOT API:
TelegramError: 429: Too Many Requests: retry after 60Мы подумали, что упёрлись в лимит
getFile. Ну бывает. Сейчас ограничим скорость и пойдём спать. Ага. Конечно.Оказалось, мы упёрлись в лимит общего количества запросов к BOT API. Ошибки начали ловить вообще все методы бота.
Через 8 минут внедряем rate limiter и заканчиваем рабочий день.
3 мая, 14:17
Замечаем странное поведение. Несмотря на лимитер, Too Many Requests становится только больше.
Очень странно.
Я решаю написать миксин, который будет отдавать в Prometheus статистику запросов в разрезе бота и метода.
3 мая, 14:40
Дописываю логику, собираю дашборд… и тут становится понятно то, что мы уже начинали подозревать.
Лимитер. Не работает.
При лимите в 20 ops…
МЫ ДЕЛАЕМ 95 OPS.
3 мая, 16:36
Релизим новый лимитер, который уже нормально работает с потоками и не допускает ошибок прошлой версии.
Но за время разработки у нас случился тот самый:
«пик, после которого лимиты Telegram посадили нас на пику».
Из-за разгона до 173 ops Telegram на минуту отрезал нам вообще все запросы. Полностью.
Да, было больно.
3 мая, 17:00
Инцидент полностью разрешён. Очереди разгребены, фон ошибок снижен, всё стабилизировалось.
Что можно сказать по итогу?
Ну… мы очень жёстко накосячили 😅
Недостаток метрик и нормальных prod-like тестов привёл к тому, что в продакшен уехал код, который устроил харакири нашей пропускной способности.
Но зато:
— появились новые дашборды
— алерты на рост ops
— понимание, куда смотреть и чёткое осознание того, насколько опасно релизить в прод
Вот как-то так :3
А у вас в проектах были подобные инциденты?
Буду рад почитать истории в комментариях. Ну и да, ещё покидаю туда цитаты из рабочего чатика — там были настоящие легендарные сообщения
#downTime