Мультиплатформенная публикация звучит просто ровно до того момента, пока не выясняется, что площадки живут собственной жизнью. YouTube может на несколько минут вернуть ошибку сервера, Telegram — временно ограничить бота, VK — попросить повторную авторизацию токена администратора сообщества именно в тот момент, когда должно было выйти видео сразу на три канала. Вопрос не в том, случится ли такой сбой, а в том, что система будет делать, когда он всё-таки случится.
Самый наивный подход к автопубликации — считать её атомарной операцией: либо материал выходит сразу везде, либо не выходит вовсе, и в случае частичного сбоя всё нужно переделывать руками. На практике это самый неприятный сценарий: видео уже опубликовано на YouTube с правильным заголовком и обложкой, а публикация в Telegram и VK повисла из-за временной недоступности площадки — и теперь нужно вручную разбираться, где что вышло, а что нет, чтобы не задвоить публикацию.
Мы сознательно закладывали в Telematic логику, которая рассматривает частичный сбой публикации не как исключение, а как рабочий, ожидаемый сценарий — и обрабатывает его автоматически.
//Что такое частичная публикация
Когда материал публикуется одновременно на несколько площадок, система трактует каждую площадку как отдельную попытку в рамках одной публикации, а не как единый атомарный шаг. Если, скажем, YouTube и Telegram приняли материал, а VK в этот момент вернул ошибку — публикация не считается ни полностью успешной, ни полностью провальной. Она получает статус частично опубликовано: часть каналов уже вышла, часть — ждёт своей очереди.
Это принципиальное отличие от подхода "всё или ничего". Оно избавляет от необходимости откатывать уже успешные публикации только потому, что одна площадка подвела, и одновременно не позволяет системе молча считать материал "опубликованным", если на самом деле вышла только часть каналов.
//Автоматический докат на оставшиеся каналы
После того как публикация помечена частичной, система не оставляет проблему на усмотрение человека. Она автоматически предпринимает повторные попытки на тех площадках, которые не сработали с первого раза, — без того, чтобы кто-то вручную заходил в карточку контента, смотрел, что не вышло, и нажимал "опубликовать" ещё раз только для нужных каналов.
Это особенно важно для сбоев, которые носят временный характер: ограничение по частоте запросов у площадки, кратковременная недоступность API, истёкший токен, который вот-вот обновится. В большинстве таких случаев повторная попытка через некоторое время проходит успешно без какого-либо вмешательства — система сама долавливает оставшиеся каналы, и материал постепенно доходит до статуса полностью опубликованного.
//Регулярный репаблиш по расписанию для всего проекта
Отдельный уровень защиты — не точечный докат одной публикации, а регулярная проверка на уровне всего проекта: система по расписанию просматривает публикации, которые остались частичными дольше ожидаемого, и пытается закрыть оставшиеся каналы. Это подстраховка на случай более длительных сбоев — например, если площадка была недоступна не пять минут, а несколько часов, и обычный автоматический докат ещё не успел сработать в первом же цикле.
Для этого репаблиша важно, чтобы у проекта было настроено активное расписание публикаций — именно оно задаёт ритм, с которым система возвращается к незавершённым публикациям и проверяет их состояние. Без расписания частичные публикации всё равно будут видны в интерфейсе, но регулярный автоматический докат будет ограничен.
//Наш опыт: день, когда у нас самих отключился канал
Один день у нас самих отключился один из каналов на несколько часов — площадка проводила плановые технические работы на своей стороне, о которых мы узнали только по возвращающимся ошибкам. За это время через автопилот прошло несколько публикаций, которые должны были выйти сразу на несколько площадок одновременно.
Если бы система работала по принципу "всё или ничего", каждую из этих публикаций пришлось бы вручную пересобирать и повторно отправлять на все каналы — рискуя задвоить материал там, где он уже вышел нормально. Вместо этого мы просто увидели в интерфейсе несколько публикаций со статусом "частично опубликовано": на рабочих площадках материал вышел вовремя, а на недоступном канале запись честно ждала своей очереди.
Когда площадка восстановилась несколько часов спустя, регулярный репаблиш по расписанию сам подхватил оставшиеся публикации без какого-либо ручного вмешательства с нашей стороны — мы просто зашли в календарь на следующий день и увидели, что всё закрылось само. Это тот самый случай, когда операционная надёжность работает незаметно: проблема была, но она не создала для нас работы.
//Что это значит на практике
Если вы видите в проекте публикацию со статусом "частично опубликовано", это не повод бросаться вручную разбираться и дублировать публикацию на недостающих каналах — велика вероятность, что система уже поставила повторную попытку в очередь и разберётся с этим сама в ближайшем цикле. Ручное вмешательство имеет смысл только тогда, когда частичный статус держится необычно долго — это сигнал, что проблема на стороне площадки серьёзнее, чем обычный кратковременный сбой, и требует отдельного внимания (например, действительно истёкшая авторизация, которую нужно обновить руками).
Стоит также убедиться, что в проекте настроено активное расписание публикаций — оно не только определяет, когда выходит новый контент, но и задаёт ритм, с которым система возвращается к незавершённым публикациям. Проект без активного расписания теряет часть автоматической подстраховки на случай длительных сбоев площадок.
В конечном счёте идея частичной публикации и автоматического доката проста: сбой одной площадки не должен становиться проблемой всей публикации целиком, и уж тем более не должен превращаться в ручную работу для человека, который просто хотел, чтобы видео вышло везде, где должно.