Trigger.dev в продакшене: как запускать фоновые задачи без боли

Фоновые задачи — это место, где AI-конвейер ломается первым

Вы написали промпт. Модель ответила. Парсер вытащил JSON. Контент красивый. Работает? Работает. На вашей машине. Один раз. С первого запуска.

А теперь запустите это 50 раз в сутки. С расписанием. С внешними API, которые возвращают 429 каждый третий запрос. С моделью, которая иногда отвечает за 2 секунды, а иногда за 45. С Replicate, у которого cold start может занять минуту. С GitHub API, который имеет rate limit 5,000 запросов в час. С Vercel deploy hook, который иногда просто не отвечает.

Это не edge-case. Это нормальный режим работы любого AI-пайплайна в продакшене. И если у вас нет инфраструктуры, которая умеет с этим жить — вы будете чинить руками. Каждый день. В выходные. В три часа ночи.

Content Factory на atlasceo.ru генерирует и публикует 5-10 статей в сутки. Полный цикл: планирование тем, генерация текста, создание иллюстраций через FAL.ai, сборка MDX, коммит в GitHub, деплой на Vercel. Всё — через Trigger.dev. И вот подробный разбор: почему, как, что сломалось и что работает.

Прежде чем говорить о Trigger.dev — контекст. Фоновые задачи — это не новая проблема. Индустрия решает её 20 лет, и каждое поколение инструментов фиксило баги предыдущего, добавляя свои.

Видите эволюцию? От «запусти скрипт и молись» до «опиши задачу как функцию, а инфраструктура сама разберётся». Trigger.dev — не революция. Это логичный итог 20 лет проб и ошибок.

Content Factory — это не один скрипт. Это цепочка задач, где каждое звено зависит от предыдущего, но может быть перезапущено независимо. Вот архитектура:

Schedule (cron 05:00 UTC)
  → cf4-atlas-website-daily-plan     // планирование тем на день
    → cf4-generate-article           // генерация текста (Claude/GPT-4o)
      → cf4-generate-images          // иллюстрации (FAL.ai FLUX Schnell)
        → cf4-assemble-mdx           // сборка MDX с компонентами
          → cf4-publish-github       // коммит в репозиторий
            → cf4-deploy-vercel      // триггер Vercel build

Каждая стрелка — это отдельная Trigger.dev задача. Каждая задача имеет свой retry policy, свой timeout, свой concurrency limit. Падение на любом этапе не убивает весь конвейер — задача ретраится, а downstream-задачи ждут.

// Пример: задача генерации статьи с retry и timeout
export const generateArticle = task({
  id: "cf4-generate-article",
  retry: {
    maxAttempts: 3,
    factor: 2,
    minTimeoutInMs: 5_000,
    maxTimeoutInMs: 60_000,
  },
  run: async (payload: { topic: string; persona: string }) => {
    const article = await generateWithClaude(payload);

    // Идемпотентность: проверяем, не опубликована ли уже
    const existing = await supabase
      .from("articles")
      .select("id")
      .eq("slug", article.slug)
      .single();

    if (existing.data) {
      logger.info("Article already exists, skipping", { slug: article.slug });
      return { status: "skipped", slug: article.slug };
    }

    await supabase.from("articles").insert(article);
    return { status: "created", slug: article.slug };
  },
});

Можно написать задачу за 10 минут. Можно даже задеплоить. Но без трёх паттернов она сломается в первую же неделю. Не «может сломаться». Сломается. Гарантированно.

// Structured logging в Trigger.dev
import { logger } from "@trigger.dev/sdk/v3";

logger.info("Article generation started", {
  slug: payload.slug,
  persona: payload.persona,
  model: "claude-sonnet-4-20250514",
});

// После завершения
logger.info("Article generation completed", {
  slug: payload.slug,
  tokensUsed: result.usage.total_tokens,
  durationMs: Date.now() - startTime,
  wordCount: result.content.split(" ").length,
});

Я знаю, о чём вы думаете. «У меня cron + node-скрипт на VPS, и всё работает». Работает — пока работает. Вот что происходит, когда масштаб растёт с 5 задач в день до 50.

Хватит теории. Вот конкретные шаги, которые мы прошли при миграции Content Factory на Trigger.dev. Каждый шаг — с кодом, граблями и решениями.

За полгода эксплуатации Content Factory мы наступили на каждую возможную грабли. Вот коллекция — чтобы вам не пришлось.

Деплой Trigger.dev задач — это одна команда. Серьёзно. Без Docker, без Kubernetes, без CI/CD-пайплайна из 200 строк YAML.

cd ai-core && npx trigger.dev@latest deploy

Эта команда: собирает TypeScript, загружает код на Trigger.dev cloud, версионирует деплой, переключает production на новую версию. Zero-downtime. Задачи, которые выполняются в момент деплоя — дорабатывают на старой версии. Новые задачи подхватывают новую.

Что мониторим в проде:

• Dashboard Trigger.dev — real-time: текущие runs, очередь, ошибки. Открываешь — видишь всё за 5 секунд.
• Telegram-алерты — failed runs приходят в чат мгновенно. Со slug, этапом и ссылкой на run.
• Supabase таблица executions — history: все запуски, статусы, длительность. Для аналитики и дебага.
• Vercel deploy hooks — подтверждение: статья дошла до прода. Новый билд стартовал.

// Алерт в Telegram при ошибке
export const alertOnFailure = task({
  id: "alert-on-failure",
  run: async (payload: { taskId: string; error: string; slug: string }) => {
    await bot.telegram.sendMessage(
      ALERT_CHAT_ID,
      `Task ${payload.taskId} failed\n` +
      `Slug: ${payload.slug}\n` +
      `Error: ${payload.error}\n` +
      `Dashboard: https://cloud.trigger.dev/runs/...`
    );
  },
});

Итог: фоновые задачи — это не код. Это дисциплина.

Trigger.dev не напишет за вас идемпотентную логику. Не придумает retry policy. Не настроит алерты. Это инструмент — как молоток. Молоток не построит дом. Но без молотка дом не построить.

Что Trigger.dev даёт: инфраструктуру, которая не мешает. Retry, timeout, concurrency, observability — из коробки. Dashboard, который показывает реальность, а не абстракцию. Deploy, который работает с первого раза.

Что вы должны дать: дисциплину. Идемпотентность в каждой задаче. Structured logging без исключений. Graceful degradation для каждого внешнего API. Алерты, которые приходят вовремя. И — самое важное — понимание, что production-пайплайн это не «написал и забыл». Это живая система, которая требует внимания. Но с правильным инструментом — минимального внимания.

Content Factory работает 6 месяцев. 5-10 статей в сутки. 99.4% успешность. Ноль потерянных публикаций. И я сплю спокойно.

Это не магия. Это инженерная дисциплина + правильный инструмент.