Pracovný proces padol. Synchronizácia nie.

V prednáške, ktorú 3. októbra 2026 zverejnil AI Engineer, spúšťa špecialista na vzťahy s vývojármi zo spoločnosti Crusoe tréningovú úlohu PyTorch na dvoch uzloch A100. Potom oznámi vlastnému monitorovaciemu systému ukážky, že jedna GPU vyhodila chybu XID 79. Uzol je označený ako nedostupný a úloha zrušená. Proces dostane SIGTERM a „až dve minúty na spracovanie toho SIGTERM, aby ste uložili kontrolné body alebo vyprázdnili logy“. Nastúpi náhradný uzol a „úloha slurm sa reštartuje. Načíta kontrolný bod a bude pokračovať v tréningu tam, kde skončila“. Celé to trvá necelých pätnásť minút. Nikoho nebolo treba volať na pohotovosť.

Synchronizácia je oveľa menšie zviera než tréningový beh. Otázka je však rovnaká. Čo beh potrebuje, aby ukončenie pracovného procesu stálo minúty a žiadne duplicity?

Toto je odpoveď pre vlastný synchronizačný systém Tajo, vyčítaná z kódu, nie z brožúry. Reverse ETL opisuje tvar tejto práce. Tento článok opisuje, čo sa stane, keď táto práca zomrie.

Sledujte jeden kontakt

Beh číta zdroj stránku po stránke od uloženého kurzora. Kurzor stránky nazvime c3 a náš kontakt 212. záznamom na tejto stránke. Kým sa čokoľvek zapíše, o tomto kontakte platia tri veci.

Po prvé, má doručovací kľúč. Kľúč je hash identifikátora synchronizácie, zdroja, kurzora stránky, pozície na stránke a samotného záznamu. Kurzor a záznam vstupujú do hashu a nikdy nie sú vložené do kľúča, takže kľúč nenesie žiadnu e-mailovú adresu.

Po druhé, zápis ide cez register, nie priamo do cieľa. Pred volaním cieľa sa kľúč zaberie v stave čakajúci. Keď zápis uspeje, riadok sa označí ako dokončený a uchová sa sedem dní.

Po tretie, kurzor sa neposunul. Posúva sa len na konci dávky, len ak dorazil každý záznam v tejto dávke, a len potom, ako beh preukázal, že synchronizáciu stále vlastní.

Teraz ukončite pracovný proces medzi zápisom a kontrolným bodom.

Po SIGTERM každý pracovný proces frontu dokončuje rozpracované úlohy v rámci jedného spoločného pätnásťsekundového limitu a proces skončí po dvadsiatich piatich sekundách bez ohľadu na to, čo ešte beží; systemd mu dá štyridsaťpäť, kým ho ukončí násilím. Beh, ktorý v tomto okne neskončil, je stále označený ako prebiehajúci a ďalší pracovný proces ho prevezme vďaka obnove zaseknutých úloh vo fronte. Pri tvrdom ukončení žiadne dokončovanie nie je. Tak či onak platia tie isté dva fakty. Cieľ má náš kontakt. Náš kurzor stále ukazuje c3.

Opakovanie

Ďalší beh začne na c3, načíta tú istú stránku, odvodí pre 212. záznam ten istý kľúč a opýta sa registra. Register odpovie: dokončené. Cieľ sa nevolá; uložený výsledok sa prehrá a beh pokračuje ďalej. Na hromadnej ceste, kde importný endpoint Brevo prijíma celú stránku v jednom volaní, prebehne tá istá kontrola pre každý kľúč ešte pred zostavením požiadavky. Stránka, v ktorej je každý kľúč už dokončený, neodošle nič.

V tom je celý trik a oplatí sa povedať, prečo funguje. Kľúč sa odvodzuje z kurzora stránky na začiatku dávky, nie z behu, ktorý sa práve vykonával. Pád, opakovaný pokus o šesťdesiat sekúnd neskôr aj plánovaný beh zajtra odvodia pre ten istý záznam ten istý kľúč. Registru je jedno, ktorý z nich sa pýta.

Teraz cena. Register po siedmich dňoch zabúda. Komentár v kóde hovorí, že sedem dní pokryje oneskorený opakovaný pokus a krátky výpadok, a nič viac netvrdí. Opakovanie od kurzora staršieho ako sedem dní zapisuje znova. A beh, ktorý bol prerušený natvrdo, môže čakať. Dočasný zámok mŕtveho behu platí až pätnásť minút a pri plánovanej synchronizácii sa beh, ktorého zámok je voľný, uprace a znova naplánuje, až keď sa začal pred viac ako hodinou. Ukážka Crusoe je späť za menej ako pätnásť minút. Tá naša nie vždy.

Komu patrí synchronizácia počas reštartu

Synchronizáciu vlastní v danom okamihu jeden beh. Beh si v Redis vezme dočasný zámok s vlastným tokenom, pätnásťminútovou platnosťou a obnovou každých päť minút. Pred každým kontrolným bodom overí, že zámok stále drží. Ak nie, zastaví sa. Beh sa zaznamená jednoduchou vetou, ktorú si človek prečíta: „The run lost its slot part-way through and stopped to avoid writing twice.“ (Beh v priebehu stratil svoj slot a zastavil sa, aby nezapisoval dvakrát.) Druhý beh, ktorý narazí na živého vlastníka, sa neopakuje. Skončí správou „Another run of this sync was already in progress“ (iný beh tejto synchronizácie už prebiehal) a ďalší plánovaný beh začne normálne.

Kto vlastní opravu, je tiež zapísané. Každý kód zlyhania zodpovedá jednej vete o tom, čo sa stalo, jednej o tom, čo urobiť ďalej, a vlastníkovi: Vy alebo Tajo. Cieľ, ktorý odmietol každý záznam, pretože je mapovanie chybné, je Váš. Stratený zámok je náš. Stránka behu ukazuje ďalší krok; návod na obnovu synchronizácie uvádza, o ktorý prípad ide.

Zatiaľ je to tá ľahká polovica. Pád stojí jedno opakovanie a nič sa nezapíše dvakrát. Druhú polovicu nás naučili dva incidenty.

Zlyhanie za zlyhaním

Jedna synchronizácia zlyhávala znova a znova. Nie v tesnej slučke: raz za interval plánovača, beh za behom, zakaždým s tou istou správou, že vlastný identifikátor nesmie obsahovať dvojbodku. Beh sa nikdy nedostal k cieľu. Zomrel už pri zaraďovaní do frontu, skôr než ho akýkoľvek spúšťač uvidel, takže upozornenie naviazané na spúšťač nikdy nemalo na čo reagovať.

Túto sériu nič nestrážilo. To je celé zistenie.

Opravou je istič. Po každom zaznamenanom zlyhaní načíta posledných päť dokončených behov synchronizácie od jej poslednej zmeny. Ak je všetkých päť chybových, synchronizáciu pozastaví, zapíše jeden auditný riadok s dôvodom circuit_breaker_tripped a odošle jedno kritické upozornenie. Séria sa odvodzuje z uložených behov, nie z počítadla v pracovnom procese. Počíta sa zlyhanie zaznamenané akoukoľvek cestou, vrátane zlyhania pri zaraďovaní do frontu, ktoré incident spôsobilo. Komentár v kóde hovorí, že by ten incident zastavil pri piatom behu. Jeden úspech sériu vynuluje. Zrušenie pozastavenia istič znova aktivuje, namiesto toho, aby ho znova vyhodilo na starých riadkoch. Sprievodca konektorom Shopify hovorí to isté jednou vetou: po piatich po sebe idúcich neúspešných behoch sa synchronizácia sama pozastaví a jej stránka ukáže poslednú chybu.

Istič však nič neopraví. Crusoe vymení uzol a reštartuje úlohu bez pýtania. Tajo sa zastaví a opýta: pozastavená synchronizácia zostane pozastavená, kým človek neodstráni príčinu a znova ju nepublikuje. Opatrné predvolené správanie je zámerné: automatický opakovaný pokus synchronizácie, ktorá zapisuje do zákazníckych záznamov, je sám osebe zápis.

Ticho, ktoré nikto nevidel

Námietka je férová a znie takto: „Istič, ktorý pozastaví po piatich zlyhaniach, by zachytil aj druhý incident. Prečo stavať druhého strážcu?“ Pretože druhý incident nevyzeral ako zlyhanie. Dlhý čas mal jeden pracovný priestor aktívnu synchronizáciu, rastúcu kopu chybových riadkov a ani jeden úspech, nikdy, a nič neupozornilo. Každý existujúci signál bol naviazaný na aktivitu: beh zlyhal, prišiel webhook, prekročil sa rozpočet. Nula úspechov nie je udalosť. Je to absencia udalosti a istič sa spustí len vtedy, keď sa zaznamená zlyhanie. Mŕtvy plánovač, zaseknutý front, pracovný proces, ktorý nikdy nenaštartuje: nič z toho nič nezaznamená a istič sa nikdy nezobudí.

Zariadenie bdelosti v lokomotíve funguje opačne. Rušňovodič ho musí priebežne potvrdzovať a ticho vlak zastaví. Verzia pre synchronizáciu beží raz za hodinu, trinásť minút po celej. Každému pracovnému priestoru s aktívnou synchronizáciou položí jednu otázku: uspel za posledných dvadsaťštyri hodín nejaký beh? Pracovný priestor, ktorého najstaršia aktívna synchronizácia bola zapnutá pred menej ako dňom, sa nechá tak; ešte nemal deň na to, aby uspel. Starší priestor, ktorý mlčí, dostane jedno kritické upozornenie. Upozornenie hovorí, o aké ticho ide: behy sa zaznamenávajú, ale žiadny neuspeje, alebo nebol zaznamenaný vôbec žiadny beh. Spustí sa raz na incident. Značka v Redis ho drží zatvorené až do prvého úspešného behu, potom sa vymaže, takže ďalší incident znova upozorní.

Obaja strážcovia pribudli v jednom commite, až dodatočne. Komentár ističa hovorí, že by prvý incident zastavil pri piatom behu. Komentár kontroly bdelosti hovorí, že synchronizácia zapnutá dávno a s nulou behov musí upozorniť. Ani jeden neexistoval, keď bol potrebný. Napísali sme ich až potom a oba incidenty sme zapísali do hlavičky súboru, aby nikto nezabudol prečo.

Čo je hotové a čo nie

Hotové v čase písania:

• Kurzor sa ukladá na konci každej čistej dávky a znova pri páde.
• Doručovací kľúč každého záznamu sa odvodzuje z kurzora stránky a jeho pozície a pred každým volaním cieľa sa overuje v sedemdňovom registri.
• Jeden dočasný zámok na synchronizáciu s pätnásťminútovou platnosťou.
• Päť pokusov na beh s odstupom, ktorý začína na šesťdesiatich sekundách a postupne rastie.
• Istič, ktorý po piatich po sebe idúcich zlyhaniach synchronizáciu pozastaví a zaznamená prečo.
• Hodinová kontrola, ktorá upozorní po dvadsiatich štyroch hodinách bez úspechu.

Čo hotové nie je a čo sa oplatí vedieť, kým sa na to spoľahnete:

• Kontrola bdelosti stráži pracovný priestor, nie synchronizáciu. Jedna zdravá synchronizácia skryje tichú susednú synchronizáciu v tom istom pracovnom priestore.
• Jej upozornenie dorazí k operátorom Tajo: vždy ako riadok logu a tam, kde je to nastavené, aj do Sentry, na webhook alebo e-mailom. Na stránke synchronizácie sa neobjaví. Pozastavenie ističom áno.
• Nič pozastavenú synchronizáciu nereštartuje. Urobí to človek.
• Obnova po tvrdom ukončení nie je rýchla. Dočasný zámok môže platiť pätnásť minút a upratovacia kontrola čaká hodinu.
• Obe prahové hodnoty, päť zlyhaní a dvadsaťštyri hodín, sú nastavenia nasadenia. Pre jednotlivú synchronizáciu ich nastaviť nemôžete.

Aj dlhá reťaz takmer dokonalých krokov zlyháva; cestou von je definovať konečný stav a kontrolovať ho. Tento článok je prevádzkovou polovicou toho istého. Definujte, čo po sebe nechá mŕtvy beh, a kontrolujte to nič, ktoré po sebe nechá ticho.

Záverečná veta Crusoe znela, že „zlyhania sú nevyhnutné“. Naša ide o krok ďalej. Pád bol tou ľahkou polovicou, pretože po sebe nechal riadky. Ticho bolo tou polovicou, ktorú sme museli ísť hľadať.