Шесть правил для синхронизации, которая работает, пока никто не смотрит

8 октября 2026 года Лэнс Мартин и Си Джей Авилла опубликовали разбор агента, который каждое утро читает Slack и GitHub и публикует сводку в Slack. Никто не следит за его работой. Самый полезный их абзац посвящён сбою, который выглядит как успех. Когда сервер источника лежит или его токен истёк, «агент ничего не видит из этого источника и сообщает: „ничего нового“».

У синхронизации контактов из Shopify в Brevo тот же сбой. Как и у любой синхронизации по расписанию между двумя SaaS-инструментами. Чтение, которое тихо не удалось, выглядит точно так же, как магазин, где сегодня никто не зарегистрировался.

Их статья заканчивается шестью правилами для агента, который работает без присмотра. Прочитайте их глазами человека, который отвечает за синхронизации, и каждое окажется правилом reverse ETL. Рабочий процесс упал. Синхронизация нет. прослеживает один контакт через сбой. Эта страница служит чек-листом над ней: шесть правил автоматической синхронизации данных, что исполнитель Tajo сегодня делает по каждому из них и где он не дотягивает. Сторона исполнителя описана в статье Восстановление зависшей или неудачной синхронизации.

1. Читайте от закладки и сдвигайте её, только когда пакет дошёл

Их первое правило: «Читайте каждый источник от закладки, а не по фиксированному временному окну». Окно «за последние 24 часа» оставляет пропуск, когда запуск стартует поздно, и повторяет записи, когда он стартует рано.

Синхронизация Tajo читает свой источник пакетами от сохранённого курсора. Курсор сдвигается в конце пакета и только тогда, когда дошла каждая запись этого пакета. Неудачный запуск сохраняет последнюю чистую позицию, поэтому следующий запуск снова читает прерванный пакет, а не пропускает его.

У заказов своя закладка. Синхронизация заказов Shopify по расписанию начинается с первого запуска по расписанию и отправляет то, что изменилось с предыдущего. Прошлые заказы уходят только тогда, когда синхронизацию запускает человек. Запуски по расписанию и запуски, начатые человеком, хранят отдельные курсоры, поэтому загрузка истории или тестовый пакет не могут отмотать курсор расписания назад.

Цена в том, что прерванный пакет читается дважды. Безопасным это делает правило 2.

2. Дайте каждой записи ключ, который переживёт сбой

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

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

У этого две цены. Через семь дней реестр забывает, и повтор от более старого курсора может записать снова. А запись, которая упала по тайм-ауту, оставляет честное сомнение: другая система могла её сохранить, не ответив. Tajo пробует такую запись снова при следующей попытке, а не помечает её неудачной на семь дней. Коннектор, который передаёт системе назначения собственный ключ идемпотентности, снимает это сомнение. Коннектор, который так не умеет, оставляет шанс на один дубликат.

3. Синхронизацией владеет один запуск, и он подтверждает это перед каждой записью

Их третье правило: «Перепроверяйте каждый элемент прямо перед публикацией». У синхронизации между чтением и записью скорее всего изменится одно: кто имеет право писать.

У каждой синхронизации Tajo одна аренда с собственным токеном и сроком жизни 15 минут, который продлевается каждые пять минут. Запуск проверяет, что всё ещё держит аренду, перед вызовом системы назначения и ещё раз перед сдвигом курсора. Запуск, который её потерял, останавливается, и его страница показывает «Запуск потерял свой слот на полпути и остановился, чтобы не записать дважды.» Второй запуск, который сталкивается с живым, завершается, а не встаёт за ним в очередь.

Записи тоже проверяются. Между чтением и записью они проходят через фильтр согласия. Контакт, который записывается в маркетинговую аудиторию без подтверждённого согласия, отклоняется, а не угадывается. Как сказано на справочной странице, ошибка всегда в сторону «слишком осторожно», никогда «отправили лишнее».

4. Повторяйте то, что пройдёт, и останавливайте то, что не пройдёт

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

Запуск Tajo из очереди, который упал, получает пять попыток. Паузы между ними составляют 60, 120, 240 и 480 секунд, всего около пятнадцати минут. Некоторые сбои никогда не повторяются, потому что новая попытка их не исправит. Запуск, который столкнулся с уже идущим запуском, не повторяется, как и запуск, чья опубликованная версия или подключения больше недействительны.

Серия отличается от разового сбоя. Если пять последних завершённых запусков с момента последнего изменения синхронизации все упали, Tajo ставит синхронизацию на паузу и показывает последнюю ошибку на её странице. Один успех обнуляет счётчик. Ничто не снимает синхронизацию с паузы само; человек устраняет причину и публикует её снова. Статья про упавший рабочий процесс рассказывает об инциденте, из которого появилось это правило.

5. Считайте тишину находкой

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

Где оно выполняется: чтение с ошибкой проваливает запуск. Отклонённый токен или сервер, который не отвечает, ничего не отправляет в систему назначения, оставляет курсор на месте и засчитывается в паузу после пяти неудачных запусков. И каждый час, в 13 минут, Tajo проверяет каждое рабочее пространство с активной синхронизацией. Он оповещает собственную команду, когда за последние 24 часа не было ни одного успешного запуска, в том числе в рабочем пространстве, где не записано ни одного запуска. Это и есть ежечасная проверка.

Где нет: тихое чтение, которое описывают авторы, отвечает «OK» без записей. Наш исполнитель считает такое чтение успехом. Для таких источников, как покупатели Shopify, отдельная проверка предупреждает команду Tajo после десяти успешных запусков подряд с нулём записей, если синхронизация раньше давала записи. Заказы Shopify читаются по времени обновления, поэтому пустой запуск там нормален, и эта проверка не выполняется. Источник, который возвращает какие-то записи, но меньше, чем должен, не ловится вовсе.

Возражение звучит так: «Десять пустых запусков означают два с половиной часа при расписании раз в 15 минут. Почему не оповещать с первого?» Синхронизации контактов действительно по умолчанию запускаются каждые 15 минут. А магазин без новых покупателей за четверть часа встречается сплошь и рядом. Оповещение с первого пустого запуска срабатывало бы каждую ночь, а оповещение, которое срабатывает всегда, никто не читает. Эта граница жертвует скоростью ради доверия. И всё равно это догадка о тишине, а не правило авторов.

6. Решите один раз, что синхронизации можно писать, и пусть каждый запуск это подтверждает

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

У синхронизации аналогом файла предпочтений служит опубликованное правило. Публикация синхронизации Tajo привязывает её к дайджесту именно того правила, которое прошло предпросмотр. Редактирование возвращает её в черновик, и перед следующим запуском она снова проходит предпросмотр. Каждый запуск, прежде чем что-то менять, проверяет, что выполняет эту опубликованную версию с теми подключениями, с которыми она была опубликована. Запуск, не прошедший эту проверку, не повторяется. Направление тоже зафиксировано: правило синхронизации пишет в одну сторону и никогда обратно в Shopify.

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

Что построено, а что нет

Построено на момент написания:

• Курсор, который сдвигается только после пакета, в котором дошла каждая запись, и курсор заказов по расписанию, который не могут отмотать запуски, начатые человеком.
• Ключ доставки для каждой записи, который сверяется с реестром завершённых записей, хранящимся семь дней.
• Одна аренда на синхронизацию, которая проверяется перед записью и перед сдвигом курсора.
• Пять попыток на запуск с ожиданием 60 секунд, затем 120, 240 и 480, без повтора при столкновении или недействительной публикации.
• Пауза после пяти неудачных запусков подряд, видимая на странице синхронизации.
• Ежечасное оповещение, когда за последние 24 часа не удался ни один запуск.
• Фильтр согласия во время запуска для контактов, которые записываются в маркетинговую аудиторию, и проверка при каждом запуске, что это опубликованная версия.

Не построено, и об этом стоит знать, прежде чем на это полагаться:

• Чтение, которое успешно вернуло ноль записей, не считается нечитаемым. Предупреждение после десяти запусков покрывает часть этого случая. Оно не покрывает заказы Shopify и источник, который возвращает слишком мало записей.
• Оповещение о 24 часах получает Tajo, а не вы, и то же относится к предупреждению после десяти запусков. Пауза при этом видна на странице синхронизации.
• Ежечасная проверка следит за рабочим пространством, а не за каждой синхронизацией. Одна здоровая синхронизация скрывает молчащую рядом.
• Нет лимита расходов на запуск.
• Ничто не снимает синхронизацию с паузы само. Это делает человек.
• Пауза после пяти сбоев и 24-часовая проверка настроены для всего развёртывания Tajo, а не для каждой синхронизации отдельно.

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

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