Šest pravidel pro synchronizaci, která běží, když se nikdo nedívá

Dne 8. října 2026 zveřejnili Lance Martin a CJ Avilla popis agenta, který každé ráno čte Slack a GitHub a do Slacku posílá souhrn. Nikdo se nedívá, jak běží. Jejich nejužitečnější odstavec je o selhání, které vypadá jako úspěch. Když server zdroje nefunguje nebo vypršel jeho token, „agent z toho zdroje nic nevidí a hlásí ‚nic nového‘“.

Synchronizace kontaktů ze Shopify do Brevo má stejné selhání. Stejně jako každá plánovaná synchronizace mezi dvěma nástroji SaaS. Čtení, které potichu selže, vypadá přesně jako obchod, kde se dnes nikdo nezaregistroval.

Jejich článek končí šesti pravidly pro agenta, který běží bez dozoru. Přečti si je jako někdo, kdo provozuje synchronizace, a každé z nich je pravidlem pro reverse ETL. Pracovní proces spadl. Synchronizace ne. sleduje jeden kontakt během pádu. Tahle stránka je kontrolní seznam nad ním: šest pravidel pro automatizovanou synchronizaci dat, co s každým z nich dnes dělá runner Tajo a kde nestačí. Stranu runneru popisuje Obnova zaseknuté nebo neúspěšné synchronizace.

1. Čti od záložky a posuň ji, až když dávka dorazí

Jejich první pravidlo: „Čti každý zdroj od záložky, ne z pevného časového okna.“ Okno „posledních 24 hodin“ nechá mezeru, když běh začne pozdě, a opakuje záznamy, když začne brzy.

Synchronizace Tajo čte svůj zdroj po dávkách od uloženého kurzoru. Kurzor se posune na konci dávky, a jen když dorazil každý záznam z té dávky. Běh, který selže, si ponechá poslední čistou pozici, takže další běh přečte přerušenou dávku znovu, místo aby ji přeskočil.

Objednávky mají vlastní záložku. Plánovaná synchronizace objednávek Shopify začíná svým prvním plánovaným během a posílá to, co se změnilo od předchozího. Starší objednávky odejdou jen tehdy, když synchronizaci spustí člověk. Plánované běhy a běhy spuštěné člověkem mají oddělené kurzory, takže načtení historie ani testovací dávka nemůže plánovaný kurzor vrátit zpět.

Cenou je, že přerušená dávka se čte dvakrát. Pravidlo 2 zajišťuje, že je to bezpečné.

2. Dej každému zápisu klíč, který přežije pád

Jejich čtvrté pravidlo považuje příspěvek za odeslaný, až „když ho Slack potvrdí“, a teprve potom aktualizuje záložku a záznam. Takhle funguje doporučený dopis. Je doručený, když se vrátí podepsaná doručenka, ne když opustí přepážku.

Než Tajo zapíše záznam, záznam dostane doručovací klíč. Klíč je hash synchronizace, zdroje, kurzoru stránky, pozice na stránce a samotného záznamu, takže neobsahuje žádné osobní údaje. Zarezervuje se před voláním cíle a označí se jako dokončený, když zápis uspěje. Dokončené klíče se uchovávají sedm dní. Opakovaný pokus nebo pozdější plánovaný běh odvodí pro stejný záznam stejný klíč, najde ho dokončený a cíl znovu nevolá.

Má to dvě ceny. Po sedmi dnech záznam zapomíná a přehrání od staršího kurzoru může zapsat znovu. A zápis, kterému vyprší časový limit, zanechá poctivou pochybnost: druhý systém ho mohl uložit, aniž by odpověděl. Tajo takový zápis zkusí znovu při pozdějším pokusu, místo aby ho na sedm dní zaznamenal jako neúspěšný. Konektor, který cíli předá vlastní klíč idempotence, tuto pochybnost odstraní. Ten, který to neumí, zůstane s možností jednoho duplikátu.

3. Synchronizaci vlastní jeden běh a prokazuje to před každým zápisem

Jejich třetí pravidlo: „Zkontroluj každou položku znovu těsně před odesláním.“ U synchronizace se mezi čtením a zápisem nejspíš změní to, kdo smí zapisovat.

Každá synchronizace Tajo má jeden lease s vlastním tokenem a životností 15 minut, obnovovanou každých pět minut. Běh ověří, že lease stále drží, než zavolá cíl, a znovu předtím, než posune kurzor. Běh, který ho ztratil, se zastaví a jeho stránka ukáže „Běh v průběhu ztratil svůj slot a zastavil se, aby nezapsal dvakrát.“ Druhý běh, který narazí na probíhající, skončí, místo aby se za ním zařadil do fronty.

Kontrolují se i záznamy. Mezi čtením a zápisem procházejí záznamy filtrem souhlasu. Kontakt, který by se zapsal do marketingového publika bez prokazatelného souhlasu, se odmítne, místo aby se hádalo. Slovy stránky nápovědy je režim selhání „příliš opatrně“, nikdy „odesláno navíc“.

4. Opakuj, co přejde, zastav, co trvá

Jejich šest pravidel neříká nic o tom, jak často to zkoušet znovu. Synchronizace to pravidlo potřebuje, protože její nejčastější chyby jsou rate limit a špatná minuta u dodavatele.

Běh Tajo z fronty, který selže, dostane pět pokusů. Čekání mezi nimi trvá 60, 120, 240 a 480 sekund, celkem asi patnáct minut. Některé chyby se nikdy neopakují, protože nový pokus je nemůže opravit. Běh, který narazil na již probíhající běh, se neopakuje, a stejně tak ani běh, jehož publikovaná verze nebo připojení už neplatí.

Série je něco jiného než zakopnutí. Pokud posledních pět dokončených běhů od poslední změny synchronizace selhalo, Tajo synchronizaci pozastaví a na její stránce ukáže poslední chybu. Jeden úspěch počítadlo vynuluje. Nic pozastavenou synchronizaci samo znovu nespustí; člověk opraví příčinu a znovu ji publikuje. Článek o spadlém pracovním procesu vypráví incident, ze kterého toto pravidlo vzniklo.

5. Ber ticho jako zjištění

„Hlas neúspěšné čtení jako nečitelné, nikdy jako klidný den.“ Tohle je nejtěžší ze šesti pravidel a to, které plníme jen zčásti.

Kde platí: čtení, které skončí chybou, způsobí selhání běhu. Odmítnutý token nebo server, který neodpovídá, nepošle do cíle nic, nechá kurzor tam, kde byl, a započítá se do pozastavení po pěti neúspěšných bězích. A každou hodinu, 13 minut po celé, Tajo zkontroluje každý pracovní prostor s aktivní synchronizací. Upozorní vlastní tým, když za posledních 24 hodin nebyl žádný úspěšný běh, včetně pracovního prostoru, kde nebyl zaznamenán vůbec žádný běh. To je hodinová kontrola.

Kde neplatí: tiché čtení, které autoři popisují, je čtení, které odpoví „OK“ bez záznamů. Náš runner ho počítá jako úspěch. U zdrojů jako zákazníci Shopify varuje samostatná kontrola tým Tajo po deseti úspěšných bězích za sebou s nulou záznamů, pokud synchronizace dříve záznamy vracela. Objednávky Shopify se čtou podle času aktualizace, takže prázdný běh je tam normální a tato kontrola neběží. Zdroj, který vrátí nějaké záznamy, ale méně, než by měl, se neodhalí vůbec.

Námitka zní takto: „Deset prázdných běhů jsou dvě a půl hodiny při plánu po 15 minutách. Proč neupozornit hned při prvním?“ Synchronizace kontaktů ve výchozím nastavení běží každých 15 minut. A obchod bez nových zákazníků za čtvrt hodiny je běžná věc. Upozornění při prvním prázdném běhu by se spouštělo každou noc, a upozornění, které se spouští pořád, nikdo nečte. Tato hranice vyměňuje rychlost za důvěryhodnost. Pořád je to odhad o tichu, ne pravidlo autorů.

6. Jednou rozhodni, co smí synchronizace zapisovat, a nech každý běh to prokázat

Jejich páté pravidlo bere preference agenta „z úložiště, které agent nemůže upravovat“. Šesté dává agentovi přístup jen pro čtení všude, kde jen čte, a omezuje, kolik může každý běh utratit. Obě existují proto, že agent čte text, který napsali jiní, a ten text se mu může pokusit dávat příkazy.

Synchronizační verzí souboru s preferencemi je publikované pravidlo. Publikování synchronizace Tajo ji sváže s digestem přesně toho pravidla, které bylo vidět v náhledu. Úprava ji vrátí do konceptu a před dalším během projde znovu náhledem. Každý běh si před jakoukoli změnou ověří, že vykonává tuto publikovanou verzi s připojeními, se kterými byla publikována. Běh, který touto kontrolou neprojde, se neopakuje. Pevný je i směr: synchronizační pravidlo zapisuje jedním směrem a nikdy zpět do Shopify.

Limit výdajů nemá obdobu. Naše synchronizační běhy nemají žádný limit výdajů na běh. Limit opakování a pozastavení omezují, jak dlouho může selhání trvat, ne kolik běh stojí.

Co je postavené a co ne

Postavené, v době psaní:

• Kurzor, který se posune až po dávce, ve které dorazil každý záznam, a plánovaný kurzor objednávek, který běhy spuštěné člověkem nemohou vrátit zpět.
• Doručovací klíč pro každý záznam, kontrolovaný proti záznamu dokončených zápisů uchovávanému sedm dní.
• Jeden lease na synchronizaci, kontrolovaný před zápisem a před posunem kurzoru.
• Pět pokusů na běh s čekáním 60 sekund a pak 120, 240 a 480, bez opakování při kolizi nebo neplatné publikaci.
• Pozastavení po pěti neúspěšných bězích za sebou, zobrazené na stránce synchronizace.
• Hodinové upozornění, když za posledních 24 hodin neuspěl žádný běh.
• Filtr souhlasu za běhu pro kontakty zapisované do marketingového publika a při každém běhu kontrola, že jde o publikovanou verzi.

Nepostavené, a dobré to vědět, než se na to spolehneš:

• Čtení, které uspěje s nulou záznamů, se nehlásí jako nečitelné. Varování po deseti bězích z toho pokrývá část. Nepokrývá objednávky Shopify ani zdroj, který vrátí příliš málo záznamů.
• Upozornění po 24 hodinách dostává Tajo, ne ty, a totéž platí pro varování po deseti bězích. Pozastavení se ale na stránce synchronizace zobrazí.
• Hodinová kontrola hlídá pracovní prostor, ne každou synchronizaci. Jedna zdravá synchronizace zakryje tichou vedle sebe.
• Žádný limit výdajů na běh.
• Nic pozastavenou synchronizaci znovu nespustí. Udělá to člověk.
• Pozastavení po pěti selháních a 24hodinová kontrola jsou nastavené pro celé nasazení Tajo, ne pro jednotlivou synchronizaci.

Když se něco z toho objeví u tvé synchronizace, Obnova zaseknuté nebo neúspěšné synchronizace ti řekne, co vidíš a co dělat.

Autoři napsali šest pravidel pro souhrn, který člověk čte každé ráno. Synchronizace nemá ráno žádného čtenáře, a proto je potřebuje ještě víc. Pravidla jedna až čtyři a pravidlo šest jsou dnes kódem v našem runneru. Pravidlo pět je napsané napůl: synchronizace, která nedokáže přečíst svůj zdroj, by to měla říct.