Что делать, если воркер падает?
Что проверяют
Отвечаете ли вы только про перезапуск процесса или понимаете, что главный вопрос в судьбе задачи, которую воркер не доделал. Это проверка на опыт эксплуатации: писали ли вы фоновую обработку, которая переживает падения.
Как отвечать
Разделить два вопроса: почему упал и что стало с задачей.
Диагностика начинается с трейсбека и кода выхода. Если в логах пусто, а процесс исчез, это обычно не исключение, а убийство извне: нехватка памяти и SIGKILL от ядра, лимит контейнера, таймаут оркестратора. Такое не ловится try/except, смотреть надо на метрики памяти и на сообщения ядра. Дальше по списку: утечка памяти при долгой работе, зависшее соединение с брокером, блокировка в пуле.
Живучесть процесса обеспечивает супервизор: systemd с перезапуском по ненулевому коду, supervisord, перезапуск пода в оркестраторе. Обязательно с нарастающей паузой, иначе получится цикл рестартов, который забьёт логи и брокер.
Судьба задачи важнее. Подтверждать сообщение надо после обработки, а не до: в Celery за это отвечает acks_late, в брокере с очередями неподтверждённое сообщение вернётся в очередь при разрыве соединения. Плата за это повтор, значит обработчик обязан быть идемпотентным: ключ идемпотентности, уникальный индекс, проверка «уже сделано».
Отравленное сообщение лечится потолком попыток и очередью недоставленных. Полезны также лимит задач на процесс до его перезапуска, таймаут на задачу, корректное завершение по SIGTERM и метрики: длина очереди, возраст самого старого сообщения, частота рестартов.
Где спотыкаются
Отвечают одной фразой про автоперезапуск. Он возвращает процесс, но не возвращает потерянную задачу, и собеседующий ждёт именно вторую половину ответа.
Делают бесконечные повторы без потолка и без очереди недоставленных. Одно ядовитое сообщение роняет воркер по кругу и останавливает обработку всего остального.
Включают повторы, не сделав обработку идемпотентной. В итоге письмо уходит дважды, а платёж проводится повторно, и это хуже, чем потерянная задача.