Грабли продакшена: от утечек до дубликатов

Таблица ниже — карта диагностики: найдите симптом слева, получите гипотезу и лечение. Три верхних грабля встречаются чаще остальных, поэтому после таблицы разбираем их с кодом: забытый воркер, payload без версии и взрыв ретраев — на них приходится большая часть реальных тикетов. Остальные — дубликаты, короткий таймаут остановки, один Redis без приоритетов и отсутствие мониторинга лага — проходятся короче, но от этого не реже случаются. Держите чек-лист в дежурной документации рядом с алертами из прошлого урока: в разгар инцидента листать исходники библиотеки некогда, а таблица снимает большую часть догадок. И просматривайте таблицу целиком: у соседних граблей симптомы похожи, а лечение разное — копящийся Retry и стоящий Processed говорят о разном.

Грабль первый — классика: клиент ставит задачи, очередь принимает, API отвечает, а работа не делается. Проверяется одним вызовом GetQueueInfo: Pending растёт, Processed стоит, Latency растёт. Причина скучна: сервер asynq не запущен, запущен без нужной очереди в конфиге или не достучался до Redis. Лечение: Servers() из пятнадцатого урока показывает, кто вообще подключён, стартовые логи подскажут конфиг, а алерт «Processed равен нулю при backlog» ловит это без пользователей. Разновидность того же грабля: сервер запущен, но смотрит в Redis соседней среды — staging вместо продакшена. Воркер жив, а задач из вашей очереди он не видит, и картина идентична до последнего процента. Грабль второй коварнее: вы добавили поле в payload и выкатили релиз — и хендлеры начали падать на сообщениях, поставленных старой версией клиента. Задачи в Redis переживают релиз: ретраи, отложенные и периодические задачи были сохранены со старым форматом и теперь декодируются новым кодом. Симптом: волна ошибок после каждого деплоя, которая потом проходит сама — очередь вычерпала старое. Лечение: версионирование payload — поле с номером формата; хендлер проверяет версию и понимает старые форматы или отказывается с осмысленной ошибкой. Полезно помнить асимметрию JSON: старый код новое поле просто игнорирует, а новый код на старом сообщении поле не находит — ломается всегда новая сторона, поэтому версия ставится при постановке и читается при исполнении. Тесты задач из двадцать второго урока обязаны включать старую версию: контракт формата живёт дольше кода, который его выпустил.

Грабль третий — самый дорогой по последствиям. По умолчанию asynq делает двадцать пять попыток, а пауза между ними растёт по формуле из sidekiq: n^4 плюс пятнадцать секунд и джиттер. Для нестабильного внешнего API это выглядит так: сервис деградировал на десять минут, у вас тысячи задач, каждая ждёт своего окна, а после восстановления на него обрушивается отложенный шторм — плюс ретраи задач, поставленных прямо в разгар деградации. Симптом: Retry копится, паузы между попытками уходят в часы, внешний сервис проседает от ваших же повторов. Лечение многослойное: разумный MaxRetry на постановке — три-пять для обычных задач; RetryDelayFunc в Config — свой профиль пауз под тип задачи; SkipRetry из тринадцатого урока — для ошибок, которые повтором не исправятся; circuit breaker перед внешним вызовом — чтобы не добивать умирающий сервис. Помните арифметику: backlog, умноженный на число попыток, — это ваша будущая нагрузка на зависимость, и считать её надо до инцидента, а не после. Классифицируйте ошибки до настройки повторов: сетевой таймаут стоит повторить, а нехватку баланса — нет, и лечатся они разными механизмами: профилем пауз или SkipRetry.

Грабль четвёртый — следствие честной семантики at-least-once: asynq гарантирует исполнение как минимум один раз, значит, потенциально — больше одного. Воркер умер посреди исполнения — задача вернётся в pending и исполнится снова; деплой оборвал попытку — то же самое. Если хендлер списывает деньги, второй запуск и есть двойное списание. Защита живёт не в очереди, а в хендлере: ключ идемпотентности — обычно идентификатор бизнес-операции из payload, а не ID задачи — проверяется до работы. Варианты: уникальный индекс в базе по ключу операции, SetNX в Redis с TTL или таблица исполненных операций. Выбор хранилища зависит от цены ошибки: для платежей ключ живёт в базе рядом с транзакцией, Redis — для операций, где потеря ключа не катастрофа. Unique-опция из двенадцатого урока и ErrTaskIDConflict защищают только постановку: две копии не попадут в очередь, но повторное исполнение одной и той же задачи они не отменяют — это разные вещи. Отсюда тест-лист идемпотентности: одна и та же задача дважды, две задачи с одним бизнес-ключом, рестарт посреди списания — все три случая дают ровно одно исполнение. Паттерн из восемнадцатого урока: захватили ключ — работаем; ключ занят — задача уже сделана или делается. Симптом грабля: жалобы на дубликаты после каждого рестарта; лечение ставится один раз и навсегда. Зато после него деплои перестают быть источником финансовых тикетов.

Грабль пятый: ShutdownTimeout по умолчанию — восемь секунд. Деплой шлёт сигнал, сервер ждёт восемь секунд и уходит; задачи, которым нужны минуты, рвутся посреди попытки. Дальше включается механика восстановления: задача без живого воркера помечается флагом IsOrphaned и возвращается в pending — исполнение начнётся заново с нуля. Задача не пропадает, но после деплоя возможна минута тишины — объясните это дежурным заранее, чтобы не искали пропажу. Для платежей это снова про идемпотентность, для писем — про дубли в почте. Лечение: ShutdownTimeout в Config под реальную длительность задач, хендлеры, слушающие отмену контекста, и поэтапный выкат. Грабль шестой: один Redis и очередь default на всё — критичные платежи стоят за тяжёлыми отчётами. Очереди с весами из седьмого урока делят трафик: critical, default, low — вес это вероятность выборки, а не строгий порядок, поэтому перегруженная тяжёлая очередь не отбирает всё время у критичной; Concurrency из двадцатого урока задаёт, сколько задач берётся одновременно; отдельные воркеры с разными конфигами дают жёсткую изоляцию, когда отчёты душат всё. Симптом: Latency растёт только у одной очереди, остальные здоровы; лечение — приоритеты и границы, а не больше CPU. И проверьте, что критичная очередь вообще перечислена у каждого воркера: очередь, забытая в конфиге, обслуживается никем.