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

На 8 октомври 2026 г. Lance Martin и CJ Avilla публикуваха разбор на агент, който всяка сутрин чете Slack и GitHub и публикува обобщение в Slack. Никой не го гледа, докато работи. Най-полезният им абзац е за провал, който изглежда като успех. Когато сървърът на даден източник не работи или токенът му е изтекъл, „агентът не вижда нищо от този източник и съобщава „нищо ново““.

Синхронизация на контакти от Shopify към Brevo има същия провал. Както и всяка планирана синхронизация между два SaaS инструмента. Четене, което се проваля безшумно, изглежда точно като магазин, в който днес никой не се е регистрирал.

Статията им завършва с шест правила за агент, който работи без надзор. Прочетете ги като човек, който управлява синхронизации, и всяко от тях е правило за reverse ETL. Работният процес умря. Синхронизацията не. проследява един контакт през срив. Тази страница е контролният списък над нея: шест правила за автоматизирана синхронизация на данни, какво прави днес runner-ът на Tajo по всяко от тях и къде не стига. Страната на runner-а е описана във Възстановяване на блокирала или неуспешна синхронизация.

1. Четете от отметка и я местете едва когато партидата е пристигнала

Първото им правило: „Четете всеки източник от отметка, а не от фиксиран времеви прозорец.“ Прозорец от „последните 24 часа“ оставя празнина, когато изпълнението тръгне късно, и повтаря записи, когато тръгне рано.

Синхронизация в Tajo чете източника си на партиди от запазен курсор. Курсорът се премества в края на партидата и само когато всеки запис в нея е пристигнал. Неуспешно изпълнение запазва последната чиста позиция, така че следващото изпълнение чете прекъснатата партида отново, вместо да я пропусне.

Поръчките имат собствена отметка. Планирана синхронизация на поръчки от Shopify започва от първото си планирано изпълнение и изпраща промененото от предишното. По-старите поръчки се изпращат само когато човек пусне синхронизацията. Планираните изпълнения и изпълненията, пуснати от човек, имат отделни курсори, така че зареждане на историята или тестова партида не могат да върнат назад планирания.

Цената е, че прекъсната партида се чете два пъти. Правило 2 прави това безопасно.

2. Дайте на всяко записване ключ, който оцелява след срива

Четвъртото им правило брои публикацията за изпратена едва „когато Slack я потвърди“ и чак тогава обновява отметката и регистъра. Препоръчаното писмо работи така. То е доставено, когато се върне подписаната обратна разписка, а не когато напусне гишето.

Преди Tajo да запише запис, записът получава ключ за доставка. Ключът е хеш на синхронизацията, източника, курсора на страницата, позицията на страницата и самия запис, така че не съдържа лични данни. Той се заявява преди извикването на дестинацията и се отбелязва като завършен, когато записването успее. Завършените ключове се пазят седем дни. Повторен опит или по-късно планирано изпълнение изчислява същия ключ за същия запис, намира го завършен и не извиква дестинацията отново.

Това има две цени. След седем дни регистърът забравя и повторно изпълнение от по-стар курсор може да запише отново. А записване, което изтече по време, оставя честно съмнение: другата система може да го е запазила, без да отговори. Tajo опитва това записване отново при по-късен опит, вместо да го отбележи като неуспешно за седем дни. Конектор, който дава на дестинацията собствен ключ за идемпотентност, премахва това съмнение. Конектор, който не може, остава с шанса за един дубликат.

3. Едно изпълнение притежава синхронизацията и го доказва преди всяко записване

Третото им правило: „Проверявайте всеки елемент отново точно преди публикуване.“ При синхронизация най-вероятното нещо, което се е променило между четенето и записването, е кой има право да записва.

Всяка синхронизация в Tajo има един lease със собствен токен и живот от 15 минути, подновяван на всеки пет минути. Изпълнението проверява, че все още държи lease-а, преди да извика дестинацията, и отново преди да премести курсора. Изпълнение, което го е загубило, спира и страницата му показва „Изпълнението загуби своя слот по средата и спря, за да не запише два пъти.“ Второ изпълнение, което се сблъска с текущо, приключва, вместо да чака на опашка зад него.

Проверяват се и записите. Между четенето и записването записите минават през филтъра за съгласие. Контакт, който би бил записан в маркетингова аудитория без доказуемо съгласие, се отказва, вместо да се гадае. С думите на помощната страница режимът на провал е „прекалено предпазливо“, никога „изпратено в повече“.

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

Шестте им правила не казват нищо за това колко често да се опитва отново. Синхронизацията има нужда от това правило, защото най-честите ѝ грешки са rate limit и лоша минута при доставчика.

Изпълнение на Tajo от опашката, което се провали, получава пет опита. Чакането между тях е 60, 120, 240 и 480 секунди, общо около петнайсет минути. Някои грешки никога не се повтарят, защото нов опит не може да ги поправи. Изпълнение, което се е сблъскало с вече текущо изпълнение, не се повтаря, нито изпълнение, чиято публикувана версия или връзки вече не са валидни.

Поредицата е нещо различно от случайност. Ако последните пет завършени изпълнения от последната промяна на синхронизацията са се провалили, Tajo поставя синхронизацията на пауза и показва последната грешка на страницата ѝ. Един успех нулира броенето. Нищо не рестартира сама синхронизация на пауза; човек отстранява причината и я публикува отново. Статията за умрелия работен процес разказва инцидента, от който се роди това правило.

5. Третирайте тишината като находка

„Съобщавайте за неуспешно четене като за нечетимо, никога като за спокоен ден.“ Това е най-трудното от шестте и това, което спазваме само отчасти.

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

Къде не важи: тихото четене, което авторите описват, е четене, което отговаря „OK“ без записи. Нашият runner го брои за успех. За източници като клиентите в Shopify отделна проверка предупреждава екипа на Tajo след десет поредни успешни изпълнения с нула записа, ако синхронизацията е давала записи преди това. Поръчките в Shopify се четат по време на обновяване, така че там празното изпълнение е нормално и тази проверка не се изпълнява. Източник, който връща някакви записи, но по-малко, отколкото би трябвало, изобщо не се открива.

Възражението звучи така: „Десет празни изпълнения са два часа и половина при график от 15 минути. Защо да не се подаде сигнал още при първото?“ Синхронизациите на контакти по подразбиране се изпълняват на всеки 15 минути. А магазин без нови клиенти за четвърт час е нещо обичайно. Сигнал при първото празно изпълнение би се задействал всяка нощ, а сигнал, който винаги се задейства, никой не чете. Този праг разменя скорост срещу достоверност. Той остава предположение за тишината, а не правилото на авторите.

6. Решете веднъж какво може да записва синхронизацията и нека всяко изпълнение го доказва

Петото им правило държи предпочитанията на агента „в хранилище, което агентът не може да редактира“. Шестото дава на агента достъп само за четене навсякъде, където той само чете, и ограничава колко може да похарчи всяко изпълнение. И двете съществуват, защото агентът чете текст, написан от други, а този текст може да се опита да му дава заповеди.

Версията на файла с предпочитания при синхронизацията е публикуваното правило. Публикуването на синхронизация в Tajo я обвързва с дайджест на точното правило, което е било прегледано. Редакцията я връща в чернова и тя отново минава през прегледа, преди да се изпълни пак. Всяко изпълнение проверява, преди да промени каквото и да било, че изпълнява именно тази публикувана версия с връзките, с които е публикувана. Изпълнение, което не мине тази проверка, не се повтаря. Посоката също е фиксирана: правилото за синхронизация записва в една посока и никога обратно в Shopify.

Таванът за разходи няма аналог. Нашите изпълнения на синхронизация нямат ограничение на разходите за изпълнение. Ограничението на повторните опити и паузата ограничават колко може да продължи една грешка, а не колко струва едно изпълнение.

Какво е изградено и какво не е

Изградено, към момента на писане:

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

Не е изградено, и е добре да го знаете, преди да разчитате на това:

• Четене, което успява с нула записа, не се отчита като нечетимо. Предупреждението след десет изпълнения покрива част от това. То не покрива поръчките в Shopify, нито източник, който връща твърде малко записи.
• Сигналът за 24 часа стига до Tajo, а не до вас, както и предупреждението след десет изпълнения. Паузата обаче се вижда на страницата на синхронизацията.
• Ежечасната проверка следи работното пространство, а не всяка синхронизация. Една здрава синхронизация скрива тиха синхронизация до себе си.
• Няма таван за разходите на изпълнение.
• Нищо не рестартира синхронизация на пауза. Прави го човек.
• Паузата след пет грешки и 24-часовата проверка са зададени за цялата инсталация на Tajo, а не за всяка синхронизация.

Когато нещо от това се появи във вашата синхронизация, Възстановяване на блокирала или неуспешна синхронизация казва какво виждате и какво да направите.

Авторите написаха шест правила за обобщение, което човек чете всяка сутрин. Синхронизацията изобщо няма читател сутрин и затова има още по-голяма нужда от тях. Правилата от едно до четири и правило шест са код в нашия runner днес. Правило пет е написано наполовина: синхронизация, която не може да прочете източника си, трябва да го каже.