Hat szabály egy szinkronizáláshoz, amely akkor is fut, amikor senki sem figyeli

2026. október 8-án Lance Martin és CJ Avilla bemutatott egy ügynököt, amely minden reggel elolvassa a Slacket és a GitHubot, és összefoglalót tesz közzé a Slacken. Senki sem figyeli, ahogy fut. A leghasznosabb bekezdésük egy olyan hibáról szól, amely sikernek látszik. Ha egy forrás szervere leállt, vagy lejárt a tokenje, „az ügynök semmit sem lát abból a forrásból, és azt jelenti: »nincs semmi új«”.

Egy Shopifyból Brevóba tartó kontaktszinkronizálásnak ugyanez a hibája. Ahogy minden ütemezett szinkronizálásnak is két SaaS-eszköz között. Egy csendben meghiúsuló olvasás pontosan úgy néz ki, mint egy bolt, ahol ma senki sem regisztrált.

A cikkük hat szabállyal zárul egy felügyelet nélkül futó ügynökhöz. Olvasd el őket úgy, mint aki szinkronizálásokat üzemeltet, és mindegyik a reverse ETL egy szabálya lesz. A feldolgozó meghalt. A szinkronizálás nem. egy kontaktot követ végig egy összeomláson. Ez az oldal a fölötte álló ellenőrzőlista: hat szabály az automatizált adatszinkronizáláshoz, mit tesz ma a Tajo runnere mindegyikkel, és hol nem elég. A runner oldalát az Elakadt vagy sikertelen szinkronizálás helyreállítása írja le.

1. Olvass egy könyvjelzőtől, és csak akkor mozdítsd, ha a köteg megérkezett

Az első szabályuk: „Minden forrást egy könyvjelzőtől olvass, ne rögzített időablakból.” Az „utolsó 24 óra” ablaka rést hagy, ha egy futás későn indul, és megismétli a rekordokat, ha korán indul.

Egy Tajo-szinkronizálás kötegekben olvassa a forrását egy elmentett kurzortól. A kurzor egy köteg végén lép tovább, és csak akkor, ha a köteg minden rekordja megérkezett. Egy sikertelen futás megtartja az utolsó tiszta pozíciót, így a következő futás újra elolvassa a megszakadt köteget, ahelyett hogy átugraná.

A rendeléseknek saját könyvjelzőjük van. Egy ütemezett Shopify-rendelésszinkronizálás az első ütemezett futásával kezdődik, és azt küldi el, ami az előző óta megváltozott. A korábbi rendelések csak akkor mennek át, ha egy ember futtatja a szinkronizálást. Az ütemezett futásoknak és az ember által indított futásoknak külön kurzoruk van, így egy előzménybetöltés vagy egy tesztköteg nem tudja visszatekerni az ütemezettet.

Az ára az, hogy egy megszakadt köteget kétszer olvasnak. A 2. szabály teszi ezt biztonságossá.

2. Adj minden írásnak olyan kulcsot, amely túléli az összeomlást

A negyedik szabályuk csak akkor tekint elküldöttnek egy bejegyzést, „ha a Slack megerősíti”, és csak ekkor frissíti a könyvjelzőt és a naplót. Egy ajánlott levél így működik. Akkor kézbesítették, amikor visszajön az aláírt tértivevény, nem amikor elhagyja a pultot.

Mielőtt a Tajo kiír egy rekordot, a rekord kap egy kézbesítési kulcsot. A kulcs a szinkronizálás, a forrás, az oldalkurzor, az oldalon elfoglalt pozíció és maga a rekord hash-e, így nem tartalmaz személyes adatot. A cél meghívása előtt lefoglalják, és befejezettnek jelölik, amikor az írás sikerül. A befejezett kulcsokat hét napig őrzik meg. Egy újrapróbálkozás vagy egy későbbi ütemezett futás ugyanahhoz a rekordhoz ugyanazt a kulcsot vezeti le, befejezettnek találja, és nem hívja meg újra a célt.

Ennek két ára van. Hét nap után a napló felejt, és egy régebbi kurzortól induló újrajátszás újra írhat. És egy időtúllépéssel végződő írás jogos kétséget hagy: a másik rendszer talán elmentette, csak nem válaszolt. A Tajo ezt az írást egy későbbi próbálkozásnál újra megkísérli, ahelyett hogy hét napra sikertelenként rögzítené. Egy konnektor, amely saját idempotenciakulcsot ad át a célnak, megszünteti ezt a kétséget. Amelyik erre nem képes, annál megmarad egy duplikátum esélye.

3. Egy futás birtokolja a szinkronizálást, és ezt minden írás előtt igazolja

A harmadik szabályuk: „Közvetlenül a közzététel előtt ellenőrizz újra minden elemet.” Egy szinkronizálásnál az olvasás és az írás között leginkább az változhat meg, hogy ki írhat.

Minden Tajo-szinkronizálásnak egy bérlete van, saját tokennel és 15 perces élettartammal, amelyet ötpercenként megújítanak. Egy futás ellenőrzi, hogy még nála van-e a bérlet, mielőtt meghívja a célt, és újra, mielőtt mozdítja a kurzort. Az a futás, amely elvesztette, leáll, és az oldala ezt mutatja: „A futás menet közben elvesztette a helyét, és leállt, hogy ne írjon kétszer.” Egy második futás, amely ütközik egy folyamatban lévővel, véget ér, ahelyett hogy mögé állna sorba.

A rekordokat is ellenőrzik. Az olvasás és az írás között a rekordok átmennek a hozzájárulási szűrőn. Egy kontaktot, amelyet igazolható hozzájárulás nélkül írnának egy marketingközönségbe, elutasítanak, nem találgatnak. A súgóoldal szavaival a hibamód „túl óvatos”, soha nem „túlküldött”.

4. Próbáld újra, ami elmúlik, állítsd le, ami marad

A hat szabályuk semmit sem mond arról, milyen gyakran kell újrapróbálkozni. Egy szinkronizálásnak szüksége van erre a szabályra, mert a leggyakoribb hibái egy rate limit és egy szolgáltató rossz perce.

Egy sorba állított Tajo-futás, amely sikertelen, öt próbálkozást kap. A várakozások köztük 60, 120, 240 és 480 másodpercesek, összesen nagyjából tizenöt perc. Néhány hibát soha nem próbálnak újra, mert az újrapróbálkozás nem javíthatja ki őket. Azt a futást, amely egy már folyamatban lévő futással ütközött, nem próbálják újra, és azt sem, amelynek közzétett verziója vagy kapcsolatai már nem érvényesek.

Egy sorozat más, mint egy botlás. Ha a szinkronizálás utolsó módosítása óta az utolsó öt befejezett futás mind sikertelen volt, a Tajo szünetelteti a szinkronizálást, és megmutatja az utolsó hibát az oldalán. Egyetlen siker lenullázza a számlálót. Semmi sem indítja újra magától a szüneteltetett szinkronizálást; egy ember elhárítja az okot, és újra közzéteszi. A meghalt feldolgozóról szóló cikk meséli el azt az incidenst, amelyből ez a szabály született.

5. Kezeld a csendet leletként

„Egy sikertelen olvasást olvashatatlanként jelents, soha ne nyugodt napként.” Ez a hat közül a legnehezebb, és ezt teljesítjük csak részben.

Ahol érvényes: egy hibával végződő olvasás sikertelenné teszi a futást. Egy elutasított token vagy egy nem válaszoló szerver semmit sem küld a célba, a kurzort a helyén hagyja, és beleszámít az öt sikertelen futás utáni szüneteltetésbe. És minden órában, 13 perccel az egész után, a Tajo ellenőriz minden munkaterületet, ahol aktív szinkronizálás van. Riasztja a saját csapatát, ha az utolsó 24 órában nem volt sikeres futás, olyan munkaterületen is, ahol egyáltalán nem rögzítettek futást. Ez az óránkénti ellenőrzés.

Ahol nem érvényes: a szerzők által leírt csendes olvasás olyan olvasás, amely „OK”-val válaszol, rekordok nélkül. A runnerünk ezt sikernek számolja. Az olyan forrásoknál, mint a Shopify-vásárlók, egy külön ellenőrzés figyelmezteti a Tajo csapatát tíz egymást követő, nulla rekorddal sikeres futás után, ha a szinkronizálás korábban már adott rekordokat. A Shopify-rendeléseket frissítési idő szerint olvassák, így ott egy üres futás normális, és ez az ellenőrzés nem fut. Egy forrás, amely ad vissza néhány rekordot, de kevesebbet, mint kellene, egyáltalán nem derül ki.

Az ellenvetés így szól: „Tíz üres futás 15 perces ütemezésnél két és fél óra. Miért nem riasztunk már az elsőnél?” A kontaktszinkronizálások alapértelmezés szerint 15 percenként futnak. És egy bolt, ahol negyedóra alatt nem jön új vásárló, teljesen hétköznapi. Egy riasztás az első üres futásnál minden éjjel megszólalna, és egy riasztást, amely mindig megszólal, senki sem olvas. Ez a határ sebességet cserél hitelességre. Továbbra is csak egy feltevés a csendről, nem a szerzők szabálya.

6. Egyszer döntsd el, mit írhat a szinkronizálás, és minden futás igazolja

Az ötödik szabályuk az ügynök preferenciáit „egy olyan tárolóban tartja, amelyet az ügynök nem szerkeszthet”. A hatodik csak olvasási hozzáférést ad az ügynöknek mindenhol, ahol csak olvas, és korlátozza, mennyit költhet egy futás. Mindkettő azért létezik, mert az ügynök mások által írt szöveget olvas, és az a szöveg megpróbálhat parancsokat adni neki.

A preferenciafájl szinkronizálási megfelelője a közzétett szabály. Egy Tajo-szinkronizálás közzététele egy digesthez köti, amely pontosan az előnézetben látott szabályé. A szerkesztés visszaviszi piszkozatba, és újra átmegy az előnézeten, mielőtt ismét futna. Minden futás, mielőtt bármit megváltoztatna, ellenőrzi, hogy azt a közzétett verziót futtatja-e azokkal a kapcsolatokkal, amelyekkel közzétették. Azt a futást, amely ezen az ellenőrzésen elbukik, nem próbálják újra. Az irány is rögzített: egy szinkronizálási szabály egy irányba ír, és soha nem vissza a Shopifyba.

A költési korlátnak nincs megfelelője. A szinkronizálási futásainknak nincs futásonkénti költési korlátjuk. Az újrapróbálkozási korlát és a szüneteltetés azt határolja be, meddig tarthat egy hiba, nem azt, mennyibe kerül egy futás.

Mi készült el, és mi nem

Elkészült, az írás idején:

• Egy kurzor, amely csak olyan köteg után lép tovább, amelynek minden rekordja megérkezett, és egy ütemezett rendeléskurzor, amelyet az ember által indított futások nem tudnak visszatekerni.
• Rekordonként egy kézbesítési kulcs, amelyet a hét napig megőrzött, befejezett írások naplójában ellenőriznek.
• Szinkronizálásonként egy bérlet, amelyet az írás előtt és a kurzor továbblépése előtt ellenőriznek.
• Futásonként öt próbálkozás 60 másodperces, majd 120, 240 és 480 másodperces várakozással, ütközés vagy érvénytelen közzététel esetén újrapróbálkozás nélkül.
• Szüneteltetés öt egymást követő sikertelen futás után, a szinkronizálás oldalán megjelenítve.
• Óránkénti riasztás, ha az utolsó 24 órában egyetlen futás sem sikerült.
• Futásidejű hozzájárulási szűrő a marketingközönségbe írt kontaktokhoz, és minden futásnál ellenőrzés, hogy a közzétett verzióról van-e szó.

Nem készült el, és jó tudni, mielőtt számítasz rá:

• A nulla rekorddal sikeres olvasást nem jelentik olvashatatlannak. A tíz futás utáni figyelmeztetés ennek egy részét lefedi. Nem fedi le a Shopify-rendeléseket, sem azt a forrást, amely túl kevés rekordot ad vissza.
• A 24 órás riasztás a Tajóhoz érkezik, nem hozzád, és ugyanígy a tíz futás utáni figyelmeztetés is. A szüneteltetés viszont megjelenik a szinkronizálás oldalán.
• Az óránkénti ellenőrzés a munkaterületet figyeli, nem az egyes szinkronizálásokat. Egy egészséges szinkronizálás elrejt egy mellette lévő csendeset.
• Nincs futásonkénti költési korlát.
• Semmi sem indítja újra a szüneteltetett szinkronizálást. Egy ember teszi meg.
• Az öt hiba utáni szüneteltetés és a 24 órás ellenőrzés a teljes Tajo-telepítésre van beállítva, nem szinkronizálásonként.

Ha ezek közül valamelyik megjelenik a saját szinkronizálásodnál, az Elakadt vagy sikertelen szinkronizálás helyreállítása megmondja, mit látsz, és mit kell tenned.

A szerzők hat szabályt írtak egy összefoglalóhoz, amelyet egy ember minden reggel elolvas. Egy szinkronizálásnak reggel egyáltalán nincs olvasója, és ezért még nagyobb szüksége van rájuk. Az egytől négyig terjedő szabályok és a hatodik szabály ma kód a runnerünkben. Az ötödik szabály félig van megírva: egy szinkronizálás, amely nem tudja olvasni a forrását, mondja ezt ki.