Temporal для ArticleFactory: как не терять состояние публикаций

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

Temporal полезен не тем, что «автоматизирует контент», а тем, что удерживает состояние процесса. Это важно для редакции: публикация — не одно действие, а последовательность решений, в которой нужно сохранять контроль, возможность остановки и понятный аудит. Если вы хотите перенести workflow из набора разрозненных интеграций в управляемый контент-завод, Temporal подходит как оркестратор долгоживущих процессов.

Что именно переносить в Temporal

Первое решение — не пытаться перенести туда всё подряд. В Temporal стоит выносить не редакционный смысл статьи, а переходы между состояниями:

• статья готова к проверке;
• нужен факт-чек;
• согласовано;
• опубликовано в Ghost;
• подготовлены публикации в соцсетях;
• отправлено на индексацию;
• получены подтверждения;
• требуется ручное вмешательство.

Это ключевой принцип: Temporal не заменяет CMS, редактора или SMM-менеджера. Он связывает их в один процесс с сохранением контекста. Тогда Ghost остаётся источником контента, соцсети — каналами распространения, а Temporal — системой управления маршрутом.

Практически это означает, что каждую публикацию нужно рассматривать как экземпляр workflow с собственным идентификатором. У статьи есть один путь, но внутри него много контрольных точек. Именно они и становятся шагами workflow.

Что не стоит делать

• Не превращать workflow в монолитный «суперскрипт» без границ ответственности.
• Не хранить весь контент процесса только в памяти воркера.
• Не запускать публикацию без явного статуса и возможности вернуться к ручной проверке.
• Не пытаться делать Temporal единственным местом редактирования текста.

Базовая схема процесса

Надёжный контент-пайплайн обычно строится вокруг последовательности:

1. Получить событие о готовности материала.
2. Зафиксировать состояние публикации.
3. Проверить обязательные условия.
4. Выполнить публикацию в Ghost.
5. Распространить материал в внешние каналы.
6. Зафиксировать результаты и ошибки.
7. При необходимости поставить задачу на ручное действие.

Эта схема хороша тем, что в ней видны точки возврата. Например, если Ghost принял публикацию, а социальная сеть временно недоступна, процесс не должен терять уже выполненный результат. Temporal здесь полезен за счёт долговременного хранения состояния workflow и повторяемости шагов.

Ниже — компактная карта, которая помогает принять решение, что делать в Temporal, а что оставить вне его.

Важно не путать «публикационный workflow» и «доставку контента». Workflow отвечает на вопрос, что делать дальше, а доставка — на вопрос, как именно отправить данные в конкретный сервис.

Где Temporal помогает сильнее всего

На практике Temporal особенно полезен в трёх сценариях.

1. Долгие процессы с паузами

Редакция часто работает не линейно. Материал может быть готов, но ждать согласования, правки заголовка, изменения даты публикации или синхронизации с партнёрами. Обычный cron или короткоживущий скрипт для этого плохо подходит: ему нужно заново собирать состояние. Temporal умеет ждать события без потери контекста.

2. Повторяемые попытки без ручной пересборки

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

3. Нужна трассируемость решений

Для редакции важно понимать, кто и когда разрешил публикацию, почему материал ушёл позже, на каком шаге возникла проблема. Temporal сохраняет историю выполнения процесса. Это не заменяет редакционный журнал, но даёт техническую основу для разбора спорных ситуаций.

Практический смысл

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

Как сохранить редакционный контроль

Самая частая ошибка при внедрении оркестратора — попытка полностью убрать человека из контура. Для контента это обычно приводит к тому, что автоматизация начинает публиковать «по форме», но не «по редакционному смыслу». Чтобы этого не произошло, контроль нужно строить как встроенный этап процесса.

Есть три рабочих приёма.

Встроенные точки утверждения

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

Роли и границы

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

Явные статусы вместо «магии»

Каждый материал должен находиться в понятном статусе: draft, ready_for_review, approved, published, distribution_failed, needs_manual_action. Это дисциплина, а не косметика. Без неё любая автоматизация начинает жить в комментариях, чатах и догадках.

Проверка перед публикацией

Перед шагом «опубликовать» workflow должен пройти короткий набор автоматических проверок: есть ли заголовок, заполнены ли обязательные поля, не нарушена ли последовательность дат, есть ли согласование. Это простая защита от случайной публикации сырого материала.

Рабочий шаблон внедрения

Если переносить публикационный процесс в Temporal без лишнего риска, лучше идти не от большой архитектуры, а от одного стабильного сценария. Например, от публикации одного материала в Ghost с последующей рассылкой в два внешних канала.

Минимальный рабочий контур

1. Событие о готовности материала приходит в workflow.
2. Temporal фиксирует идентификатор публикации.
3. Выполняются проверки готовности.
4. Если нужно — workflow ждёт решения редактора.
5. После одобрения запускается activity публикации в Ghost.
6. Затем запускаются отдельные activities для соцсетей и индексации.
7. В случае ошибки процесс сохраняет статус и сообщает, где именно нужна реакция.

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

На что обратить внимание в реализации

• Делайте activities короткими и изолированными: один внешний вызов — одна activity.
• Не храните бизнес-логику публикации внутри интеграции с API.
• Не смешивайте повторные попытки с ручными решениями.
• Закладывайте идемпотентность: повторный запуск не должен создавать дубли.
• Разделяйте «ошибка сервиса» и «редакционный отказ».

Именно идемпотентность часто спасает workflow от дублей в соцсетях и повторной отправки в индексаторы. Если шаг можно безопасно повторить, Temporal становится гораздо более предсказуемым инструментом.

Проверка перед запуском и короткий чек-лист

Перед тем как переносить контент-процесс в Temporal, полезно пройтись по одной рабочей проверке. Это не документ для галочки, а быстрый вопросник перед запуском пилота.

Чек-лист

• У каждого материала есть уникальный идентификатор workflow.
• Определены статусы и переходы между ними.
• Есть отдельная точка ручного утверждения.
• Публикация в Ghost изолирована от шагов распространения.
• Внешние интеграции реализованы как отдельные activities.
• Для повторных попыток определены безопасные правила.
• Есть понятный сценарий аварийной остановки.
• Редакция видит, на каком шаге находится материал.

Если на два-три пункта ответа нет, перенос лучше начинать не с расширения автоматизации, а с упрощения процесса.

Когда Temporal оправдан, а когда нет

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

Но если редакция работает с несколькими платформами, требует согласования, умеет терять состояние на стыках сервисов и регулярно сталкивается с повторными отправками, Temporal даёт практическое преимущество: он удерживает процесс целиком.

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