Автопилот соцсетей для сетки сообществ
Клиент управлял более чем 30 сообществами на крупной соцплатформе в рамках линкбилдинговой стратегии. Каждому сообществу нужны были регулярные публикации — две-три в день, с картинками, по расписанию, попадающему в часы пиковой вовлечённости. Всем этим занимался один человек: искал контент, ресайзил картинки, писал подписи, постил вручную, на следующий день заходил в каждый аккаунт и проверял, не словили ли блок. Это была работа на полный день с потолком около 60 публикаций в день и без пространства для масштабирования.
пайплайн публикаций
Собрали полноценный пайплайн публикаций внутри платформы. Начинается он с поиска контента — Python-скраперы работают по расписанию и собирают записи из публичных источников по настраиваемым фильтрам: тематика, порог вовлечённости, тип медиа. Спарсенный контент попадает в очередь в базе, где дедуплицируется, размечается тегами и связывается с загруженными изображениями. Дальше управление берёт планировщик. У каждого сообщества свой календарь публикаций со слотами, и система автоматически распределяет контент из очереди по этим слотам, балансируя свежесть и разнообразие. Команда может что угодно переопределить — поменять картинку, переписать подпись, передвинуть пост на другое время, — но режим по умолчанию: руки прочь.
ротация аккаунтов
Настоящая сложность — в управлении аккаунтами. Платформа агрессивно ловит автоматизацию, а ограничение аккаунта означает потерю доступа ко всем сообществам, которыми он управляет. Мы построили слой ротации, который распределяет активность по нескольким аккаунтам, соблюдает per-account лимиты и рандомизирует время внутри каждого слота, чтобы избежать машинных паттернов. Сессии хранятся в базе и переиспользуются между рестартами — никакой повторной авторизации, пока сессия реально не истечёт. Чекер блокировок периодически проверяет способность каждого аккаунта выполнять базовые действия. Если аккаунт ограничивают, система мгновенно перераспределяет его сообщества на «здоровые» аккаунты и шлёт оповещение.
Python-скраперы
Python-скраперы добавили архитектурный челлендж. Они работают как отдельные процессы рядом с Node.js-приложением, поэтому координация идёт через базу данных, а не прямыми вызовами функций. Скрапер пишет собранный контент в staging-таблицу со статусом, Node.js-планировщик подхватывает строки, помеченные как готовые. Это работает, но мониторинг должен покрывать два рантайма. Добавили health-чеки с обеих сторон: скраперы пишут время последнего успешного запуска и количество элементов в общую status-таблицу, а основное приложение оповещает, если хоть одна из метрик протухает.
предобработка изображений
Работа с изображениями потребовала больше внимания, чем закладывали изначально. У платформы строгие требования к размерам, объёму и формату. Загруженные картинки, которые им не соответствуют, тихо ресайзятся или кропаются непредсказуемым образом. Добавили шаг предобработки: каждое изображение нормализуется ещё до попадания в очередь — приводится к оптимальным размерам, сжимается до целевого объёма, конвертируется в нужный формат. Это убрало целый класс проблем, когда посты выходили с покорёженными превью.
результаты
200+ публикаций в день по всем сообществам, один человек тратит на надзор около 30 минут. Выживаемость аккаунтов заметно улучшилась после настройки ротации и рандомизации таймингов — с двух-трёх потерянных аккаунтов в неделю до примерно одного в месяц.