Безсерверные cron‑задачи: прекращаем перекрытия и ловим тихие отказы

Проблема: перекрытия и тихие отказы

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

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

Тихие отказы ещё хуже, потому что кажется, что ничего не случилось. Задание может остановиться из‑за того, что деплой удалил расписание, изменились права доступа к базе, истёк секрет, превышены квоты или платформа отключила триггер. Старые логи могут быть на месте, и всё кажется в порядке, пока клиент не сообщит о пропавших данных.

«Оно сработало один раз» — не план по надёжности. То, что задание выполнилось вчера, не гарантирует, что оно выполнится завтра, особенно когда конфиг, права, секреты и рантаймы меняются без изменения кода.

Вам нужно простое и измеримое поведение:

• Никаких одновременных запусков (один запуск владеет работой, остальные откатываются)
• Быстрое обнаружение, если запуски остановились (ясный «последний запуск» плюс оповещение, когда он устарел)

Относитесь к планированию как к части продакшн‑инфраструктуры — и потом вы перестанете гоняться за странными прерывистыми багами.

Выберите планировщик, подходящий задаче

Не все планировщики работают одинаково — это важно, когда люди зависят от ваших заданий.

Событийные планировщики (event-based) срабатывают в (примерно) определённое время и передают работу функции или endpoint'у. Они просты и дешёвы, но доставка часто «по мере возможности», если не добавить ретраи, dead‑letter и мониторинг.

Очередные планировщики кладут сообщение «выполнить эту задачу» в очередь. Этот дополнительный шаг полезен, потому что очереди обычно дают лучший контроль над повторами, нагрузкой и видимостью. Если задача тяжёлая, долгая или пиковая, очередь облегчает обнаружение и восстановление при ошибках.

Распространённые варианты: AWS EventBridge Scheduler (или CloudWatch schedules), GCP Cloud Scheduler (часто в связке с Pub/Sub или Cloud Tasks), Azure Functions Timer Trigger (или Logic Apps), а также CI‑планировщики вроде GitHub Actions для лёгких обслуживающих задач.

Практический способ выбора — ответить на несколько вопросов:

• Как часто запускается задача и важна ли точная минута?
• Сколько может занять запуск в пике (секунды против часов)?
• Что должно произойти при ошибке: повторить, оповестить или и то, и другое?
• Какие права нужны (база, секреты, сторонние API)?
• Нужно ли догонять пропущенные запуски?

Если вам нужны строгие гарантии, избегайте схем «выстрелил и забыл» без ретраев, dead‑letter и оповещений при отсутствии запусков. Так задачи тихо перестают работать на дни.

Определите модель запуска до того, как писать код

Многие проблемы надёжности начинаются до планировщика. Они начинаются с нечёткого определения, что такое «запуск».

Решите, что считается одним запуском, и зафиксируйте это. Это «всё, что с прошлого запуска», «все записи за вчера», или «batch id, созданный в 02:00»? Этот выбор влияет на то, как вы будете блокировать, повторять и восстанавливаться.

Сделайте «два раза» безопасным, где это возможно

Даже с хорошими блокировками предполагайте, что запуск может произойти дважды из‑за ретраев, тайм‑аутов или ручных повторов. Стремитесь к идемпотентности: одинаковый ввод должен приводить к одному и тому же результату.

Простой паттерн — хранить ключ запуска (например, 2026-01-20) и записывать, какие элементы обработаны под этим ключом. Если тот же ключ запустится снова, вы пропускаете завершённые элементы, а не повторяете побочные эффекты.

Разделяйте триггер и воркер

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

Это отделяет бизнес‑логику от надёжностных ограждений и упрощает смену планировщика в будущем.

До кодирования определите исходы:

• Успех: какие данные гарантированно корректны и где они записаны?
• Провал: что нужно откатить, а что можно повторить?
• Частичный успех: что можно оставить и как продолжить?
• Тайм‑аут: какое состояние может остаться после прерывания?

Спланируйте защиту от конкуренции (стратегия блокировок)

Если вы запускаете безсерверные cron‑задачи, предполагайте две плохих ситуации: задача выполняется долго, и следующее расписание всё равно срабатывает; или функция повторно запускается после тайм‑аута и получается две копии. Конкурентная защита — это мелочь, которая делает такие дни скучными.

Начните с выбора места хранения блокировки. Выберите хранилище, которое задача может быстро читать и записывать, с сильным поведением «только один выигрывает».

Выберите хранилище для блокировки

Обычные варианты:

• Одна строка в базе данных (подойдёт, если у вас уже есть Postgres/MySQL и вы можете сделать атомарное обновление)
• Redis (быстро и удобно для коротких блокировок, но убедитесь в высокой доступности)
• Лиз (lease) в объектном хранилище (файл/blob, созданный с «if not exists»; просто, но может быть медленнее)

Далее решите, что представляет собой ключ блокировки. Практичный ключ часто содержит имя задачи и окно по расписанию, например billing-sync:2026-01-20T02:00Z. Это блокирует дубликаты для одного слота, не мешая следующему дню.

Всегда устанавливайте TTL (время жизни). TTL защищает, когда запуск падает посередине или платформа убивает процесс. Ставьте его чуть больше, чем ваш наихудший сценарий выполнения, а не больше среднего.

Наконец, решите поведение при конфликте:

• Пропустить (безопасно для идемпотентной работы, но вы можете пропустить окно)
• Перенести (лучше для покрытия, но может создать всплески трафика)
• Оповестить громко (лучше для критичных задач, где пропуск хуже шума)

Пошагово: предотвратите одновременные запуски с помощью блокировки

Перекрытия происходят, когда планировщик срабатывает дважды или запуск длится дольше, чем ожидалось. В безсерверной среде простое решение — общая блокировка вне функции (строка в БД, ключ Redis или управляемый KV). Один запуск выигрывает; остальные завершаются.

1) Используйте понятный поток блокировки

Сделайте поток предсказуемым:

• Захватить блокировку (атомарное создание или условное обновление)
• Если блок занят, быстро выйти
• Выполнить задачу
• Освободить блокировку, но только если вы всё ещё её владеете

2) Добавьте токен владельца и всегда освобождайте

Токен владельца предотвращает ситуацию, когда Запуск B снимает блокировку Запуска A. Всегда освобождайте в блоке finally, чтобы ошибки не оставляли вечную блокировку.

import crypto from "crypto";

export async function handler() {
  const lockKey = "nightly-report";
  const owner = crypto.randomUUID();
  const ttlSeconds = 15 * 60; // lock safety window

  const acquired = await acquireLock({ lockKey, owner, ttlSeconds });
  if (!acquired) return { status: "skipped", reason: "lock_taken" };

  try {
    await doWork();
    return { status: "ok" };
  } finally {
    await releaseLock({ lockKey, owner }); // only release if owner matches
  }
}

Хорошая реализация acquireLock атомарна и ставит срок жизни (TTL), чтобы упавший запуск не блокировал всё навсегда.

3) Тестируйте с принудительным перекрытием

Запустите два запуска одновременно (ручной вызов дважды или временное уменьшение расписания). Один должен выполняться; второй должен записать «skipped: lock_taken». Если оба запускаются, значит запись блокировки не атомарна или отсутствует проверка владельца.

Пошагово: добавьте проверку «последний запуск» (heartbeat)

Heartbeat — это маленькая запись «я запустился», которую ваша задача пишет при завершении (успех или ошибка). Он превращает тихие отказы в оповещения, что важно в безсерверной среде, где нет всегда‑работающего процесса, который заметит простои.

1) Выберите место для хранения «последний запуск»

Выберите место, куда просто писать, быстро читать и которое вряд ли упадёт одновременно с планировщиком:

• Таблица в базе данных
• Запись в key-value (простая пара "job_name -> last_run")
• Система метрик / временных рядов

2) Записывайте правильные поля

Не храните только timestamp. Запишите достаточно данных, чтобы дебажить без копания в логах.

job_name, run_id, started_at, finished_at, status, duration_ms, error_snippet

Практичное правило: пишите запись в начале (status=running), затем обновляйте в конце (status=success или failed). Это позволяет также обнаруживать «зависшие в состоянии running».

3) Настройте порог и правила оповещений

Порог «пропавшего сердцебиения» ставьте примерно в 2× ожидаемый интервал. Если задача запускается каждые 15 минут, присылайте алерт, если нет успешного heartbeat за 30 минут.

Разделите типы оповещений:

• Пропал heartbeat: нет успеха внутри порога (возможно, задача вообще не запускается)
• Повторные ошибки: последние N запусков завершились с ошибкой (задача запускается, но работа сломана)

Пример: ночная синхронизация биллинга должна стартовать в 02:00 и закончиться за 5 минут. Оповестите, если к 02:15 нет успешного выполнения. Используйте другое оповещение, если задача падала три ночи подряд.

Логи и оповещения, которые действительно полезны

Когда безсерверные cron‑задачи ведут себя плохо, проблема обычно не в планировщике. Вопрос в том, что никто не может быстро ответить на три вопроса: стартовала ли задача, завершилась ли она и почему пропущена?

Давайте каждому запуску единый run id (например: метка времени + короткий случайный суффикс). Логируйте его в начале и включайте в каждую строку лога, чтобы проследить один запуск от начала до конца.

Также логируйте случаи намеренного пропуска. Пропуск — это не то же самое, что падение, но это важный сигнал. Если задача не выполнилась из‑за занятой блокировки, напишите это чётко и укажите ключ блокировки (и владельца, если есть).

Держите логи последовательными:

• Start: run id, имя задачи, время триггера, версия/коммит, важные входные данные
• Skip: run id, имя задачи, причина пропуска (конфликт блокировки, планировщик отключён, feature flag выключен)
• Finish: run id, статус (ok/failed), длительность, счётчики (обработано, ошибок)
• Failure: run id, тип ошибки, безопасный контекст и что уже сделано

Алерты должны отслеживать паттерны, а не одиночные ошибки. Резкий рост длительности может означать медленный внешний API. Слишком много пропусков — признак застрявшей блокировки. Отсутствие запусков часто указывает на дрейф разрешений планировщика или деплой, удаливший триггер.

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

Ретраи, таймауты и безопасный догон (catch‑up)

Ретраи помогают, но они также создают перекрытия. Многие планировщики автоматически повторяют, если функция вернула ошибку или тайм‑аут. Без распределённой блокировки (или при преждевременном её освобождении) ретрай может стартовать, пока оригинальный запуск ещё работает.

Таймауты усугубляют ситуацию. В безсерверной среде платформа может прервать ваш код при превышении лимита времени. Вы можете не успеть очистить состояние, и не знать, какие шаги успели выполниться. Если планировщик повторит запуск, можно отправить письма дважды, списать деньги дважды или записать дубликаты.

Безопаснее делать каждый запуск возобновляемым и идемпотентным. Думайте о контрольных точках, а не о большом «сделать всё» в одной функции. Например, ночная задача выставления счетов может хранить маркер прогресса вроде «обработано до invoice_id 18420» и продолжать с этого места.

Ограждения, которые предотвращают ущерб от ретраев и догонов:

• Держите блокировку до конца запуска. Освобождайте её только когда действительно завершили работу.
• Записывайте run_id и маркеры прогресса, чтобы ретрай мог продолжить, а не начинать заново.
• Разбейте работу на небольшие батчи с проверкой «уже обработано» для каждого элемента.
• Добавьте контролируемый режим бэфилла, который обрабатывает пропущенные окна по одному.

Бэфиллы важны, потому что расписания сдвигаются. Если вчерашний запуск упал, сегодняшний не должен автоматически обрабатывать два дня за один раз, если система не рассчитана на это. Простое правило: «обработать самое старое пропущенное окно, затем остановиться».

Частые ошибки и простые исправления

Большинство продакшн‑проблем исходят из нескольких решений, которые кажутся нормальными в прототипе.

• TTL короче, чем задача. Ваше обещание «один запуск» ломается, когда один запуск замедляется. Исправление: ставьте TTL равным худшему случаю выполнения плюс запас и обновляйте его, пока задача жива.
• TTL слишком большой. Один упавший запуск может блокировать расписание на часы. Исправление: держите TTL разумным, освобождайте в finally и используйте токен владельца, чтобы другой экземпляр не снял блокировку по ошибке.
• Блокировки в памяти. В безсерверной среде каждый запуск может оказаться на другом инстансе, поэтому флаги в памяти бесполезны. Исправление: используйте общее хранилище (строка в БД, Redis или управляемый KV).
• Предположение «ровно один раз» без идемпотентности. Ретраи и доставка хотя бы один раз вас подведут. Исправление: записывайте с уникальными ключами, используйте upsert или проверку run_id перед побочными эффектами.
• Использование логов как heartbeat. Логи хороши для дебага, но неудобны для оповещений. Исправление: пишите запись о последнем запуске в место, где её легко запросить (БД/KV/метрики).

Один лёгкий для пропуска источник тихого отказа — дрейф прав. Планировщик всё ещё срабатывает, но воркер больше не может читать секреты, писать в хранилище или вызывать API после изменения.

Быстрая чек‑листа перед релизом

Прежде чем доверять безсерверным cron‑задачам в продакшне, пройдитесь ещё раз по скучным отказам: планировщик отключён, блокировка истекает рано или heartbeat никто не проверяет.

• Подтвердите, что расписание включено в нужной среде, и что идентичность рантайма может читать секреты, писать в БД/очередь и отправлять логи.
• Запишите стратегию конкурентной защиты: формат ключа блокировки, где хранится, TTL и что происходит при конфликте (пропустить, перенести или упасть).
• Валидация TTL на реальных временных метриках. Если задача иногда занимает 12 минут, 10‑минутная блокировка создаст перекрытия.
• Храните «последний успешный запуск» в месте, где его можно быстро проверить во время инцидента, и включайте статус (а не только timestamp).
• Проведите два теста: (1) принудительный провал, чтобы подтвердить, что оповещения доходят до человека, и (2) принудительное перекрытие, чтобы убедиться, что второй запуск блокируется и логирует причину.

Простой тест перекрытия: стартуйте один запуск с намеренной паузой посередине, затем запустите второй. Если вы не видите аккуратного сообщения «lock held, exiting», ваша защита ещё ненадёжна.

Пример: ночная задача, которая никогда не должна запускаться дважды

Типичная боль: ночной «export report» запускается в 02:00, генерирует PDF и рассылает их клиентам. После деплоя планировщик срабатывает дважды (или ретрай), и некоторые клиенты получают дубликаты писем. Ничего не «упало», но доверие теряется быстро.

Исправление — два небольших шага: блокировка, чтобы предотвратить перекрытие, и heartbeat, чтобы ловить тихие остановки.

Сначала задача захватывает распределённую блокировку (строка в БД или ключ в управляемом хранилище) с TTL, большим, чем ожидаемое время выполнения. Если блок уже занят, второй вызов выходит прежде чем что‑то отправит.

Практичный поток:

• Попытаться захватить lock nightly-export с TTL 45 минут
• Если блок занят, записать «skipped: already running» и остановиться
• Если блок захвачен, сгенерировать экспорт и отправить письма
• Освободить блок (TTL — запасная защита, а не основной план)

Второй шаг — записать heartbeat last_success_at после отправки писем. Затем отдельная проверка каждые 15 минут оповещает, если now - last_success_at больше 24 часов плюс один интервал. Это ловит проблему «задача перестала работать после деплоя» быстро.

Для нетехнического владельца лучшие логи и оповещения — простым языком:

02:00:01 lock_acquired job=nightly-export run_id=abc123
02:07:44 completed job=nightly-export emails_sent=418 last_success_at=2026-01-20T02:07:44Z
02:00:02 skipped job=nightly-export reason=lock_held current_owner=abc123
ALERT: Nightly export has not succeeded in 25h. Last success: 2026-01-19 02:06 UTC. Check scheduler + secrets.

Следующие шаги, если запланированные задания всё ещё ненадёжны

Если после добавления блокировки и heartbeat задачи всё ещё перекрываются или «просто перестают работать», возможно, планировщик в порядке, но логика задания хрупкая.

Признак — когда cron‑логика пришла из ИИ‑прототипа. Часто там встречается блокировка, которая не по‑настоящему общая, секреты утекли в логи, и поведение повторов выглядит полезным, но даёт дублирующие побочные эффекты.

Сигналы, что пора перестать патчить и сделать ремедиэйшн:

• Исправления работают до следующего деплоя, затем ошибки меняют форму
• Никто не может объяснить, когда запуск считается «завершённым»
• Ретраи дают дубликаты писем, списаний или записей
• Аутентификация ломается непредсказуемо (истёкшие токены, некорректный refresh, плохие роли)
• Логи не позволяют восстановить один запуск от начала до конца

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

Если вы имеете дело с сломанной кодовой базой, сгенерированной ИИ (особенно из инструментов вроде Lovable, Bolt, v0, Cursor или Replit), FixMyMess на fixmymess.ai фокусируется на диагностике и ремонте проблем вроде перекрывающихся запусков, раскрытых секретов и хрупкой логики повторов, чтобы задача вела себя надёжно в продакшне.