Sześć zasad dla synchronizacji, która działa, gdy nikt nie patrzy

8 października 2026 roku Lance Martin i CJ Avilla opublikowali omówienie agenta, który co rano czyta Slacka i GitHuba i publikuje podsumowanie na Slacku. Nikt nie patrzy, jak działa. Ich najbardziej przydatny akapit dotyczy błędu, który wygląda jak sukces. Gdy serwer źródła nie działa albo jego token wygasł, „agent nie widzi niczego z tego źródła i zgłasza »nic nowego«”.

Synchronizacja kontaktów z Shopify do Brevo ma ten sam błąd. Podobnie jak każda zaplanowana synchronizacja między dwoma narzędziami SaaS. Odczyt, który po cichu się nie udaje, wygląda dokładnie jak sklep, w którym dziś nikt się nie zarejestrował.

Ich artykuł kończy się sześcioma zasadami dla agenta działającego bez nadzoru. Przeczytaj je jako ktoś, kto prowadzi synchronizacje, a każda okaże się zasadą reverse ETL. Proces roboczy padł. Synchronizacja nie. śledzi jeden kontakt przez awarię. Ta strona to lista kontrolna nad nim: sześć zasad automatycznej synchronizacji danych, co runner Tajo robi dziś w każdej z nich i gdzie mu czegoś brakuje. Strona runnera jest opisana w Przywracanie zablokowanej lub nieudanej synchronizacji.

1. Czytaj od zakładki i przesuwaj ją dopiero, gdy partia dotrze

Ich pierwsza zasada: „Czytaj każde źródło od zakładki, a nie ze stałego okna czasu”. Okno „ostatnich 24 godzin” zostawia lukę, gdy przebieg startuje z opóźnieniem, i powtarza rekordy, gdy startuje za wcześnie.

Synchronizacja Tajo czyta swoje źródło partiami od zapisanego kursora. Kursor przesuwa się na końcu partii i tylko wtedy, gdy dotarł każdy rekord z tej partii. Przebieg, który kończy się błędem, zachowuje ostatnią czystą pozycję, więc następny przebieg czyta przerwaną partię ponownie, zamiast ją pominąć.

Zamówienia mają własną zakładkę. Zaplanowana synchronizacja zamówień Shopify zaczyna od pierwszego zaplanowanego przebiegu i wysyła to, co zmieniło się od poprzedniego. Wcześniejsze zamówienia trafiają dalej tylko wtedy, gdy synchronizację uruchomi człowiek. Przebiegi zaplanowane i przebiegi uruchomione przez człowieka mają osobne kursory, więc wczytanie historii ani partia testowa nie mogą cofnąć zaplanowanego.

Ceną jest to, że przerwana partia jest czytana dwa razy. Zasada 2 sprawia, że to bezpieczne.

2. Daj każdemu zapisowi klucz, który przetrwa awarię

Ich czwarta zasada uznaje wpis za wysłany dopiero „gdy Slack go potwierdzi” i dopiero wtedy aktualizuje zakładkę i rejestr. Tak działa list polecony. Jest doręczony, gdy wraca podpisane potwierdzenie odbioru, a nie gdy opuszcza okienko.

Zanim Tajo zapisze rekord, rekord dostaje klucz dostarczenia. Klucz to hash synchronizacji, źródła, kursora strony, pozycji na stronie i samego rekordu, więc nie zawiera danych osobowych. Jest rezerwowany przed wywołaniem miejsca docelowego i oznaczany jako zakończony, gdy zapis się uda. Zakończone klucze są przechowywane przez siedem dni. Ponowienie albo późniejszy zaplanowany przebieg wylicza dla tego samego rekordu ten sam klucz, znajduje go jako zakończony i nie wywołuje miejsca docelowego ponownie.

Ma to dwie ceny. Po siedmiu dniach rejestr zapomina, a powtórzenie od starszego kursora może zapisać ponownie. A zapis, który przekroczy limit czasu, zostawia uczciwą wątpliwość: drugi system mógł go zapisać, nie odpowiadając. Tajo ponawia taki zapis w późniejszej próbie, zamiast oznaczać go jako nieudany na siedem dni. Konektor, który przekazuje miejscu docelowemu własny klucz idempotencji, rozwiewa tę wątpliwość. Ten, który tego nie potrafi, zostaje z ryzykiem jednego duplikatu.

3. Jeden przebieg jest właścicielem synchronizacji i potwierdza to przed każdym zapisem

Ich trzecia zasada: „Sprawdź każdy element ponownie tuż przed publikacją”. W synchronizacji tym, co najpewniej zmieniło się między odczytem a zapisem, jest to, kto ma prawo zapisywać.

Każda synchronizacja Tajo ma jedną dzierżawę, z własnym tokenem i czasem życia 15 minut, odnawianym co pięć minut. Przebieg sprawdza, czy nadal ją ma, zanim wywoła miejsce docelowe, i jeszcze raz, zanim przesunie kursor. Przebieg, który ją stracił, zatrzymuje się, a jego strona pokazuje „Przebieg w trakcie stracił swój slot i zatrzymał się, żeby nie zapisać dwa razy”. Drugi przebieg, który zderzy się z trwającym, kończy się, zamiast ustawiać się za nim w kolejce.

Sprawdzane są też rekordy. Między odczytem a zapisem rekordy przechodzą przez filtr zgód. Kontakt, który miałby trafić do grupy marketingowej bez udokumentowanej zgody, jest odrzucany, a nie zgadywany. Słowami strony pomocy tryb awarii to „zbyt ostrożnie”, nigdy „wysłano za dużo”.

4. Ponawiaj to, co mija, zatrzymuj to, co trwa

Ich sześć zasad nic nie mówi o tym, jak często próbować ponownie. Synchronizacja potrzebuje tej zasady, bo jej najczęstsze błędy to limit zapytań i zła minuta u dostawcy.

Przebieg Tajo z kolejki, który kończy się błędem, dostaje pięć prób. Przerwy między nimi wynoszą 60, 120, 240 i 480 sekund, łącznie około piętnastu minut. Niektóre błędy nigdy nie są ponawiane, bo kolejna próba ich nie naprawi. Przebieg, który zderzył się z przebiegiem już trwającym, nie jest ponawiany, podobnie jak przebieg, którego opublikowana wersja lub połączenia nie są już ważne.

Seria to coś innego niż potknięcie. Jeśli ostatnie pięć zakończonych przebiegów od ostatniej zmiany synchronizacji zakończyło się błędem, Tajo wstrzymuje synchronizację i pokazuje ostatni błąd na jej stronie. Jeden sukces zeruje licznik. Nic nie wznawia wstrzymanej synchronizacji samo z siebie; człowiek usuwa przyczynę i publikuje ją ponownie. Artykuł o procesie roboczym, który padł, opowiada o incydencie, z którego wzięła się ta zasada.

5. Traktuj ciszę jako ustalenie

„Zgłaszaj nieudany odczyt jako nieczytelny, nigdy jako spokojny dzień”. To najtrudniejsza z sześciu zasad i ta, którą spełniamy tylko częściowo.

Gdzie działa: odczyt zakończony błędem powoduje błąd przebiegu. Odrzucony token albo serwer, który nie odpowiada, nie wysyła niczego do miejsca docelowego, zostawia kursor tam, gdzie był, i liczy się do pauzy po pięciu nieudanych przebiegach. A co godzinę, 13 minut po pełnej godzinie, Tajo sprawdza każdy obszar roboczy z aktywną synchronizacją. Alarmuje własny zespół, gdy w ciągu ostatnich 24 godzin nie było żadnego udanego przebiegu, także w obszarze roboczym, w którym nie zarejestrowano żadnego przebiegu. To cogodzinna kontrola.

Gdzie nie działa: cichy odczyt, który opisują autorzy, to odczyt odpowiadający „OK” bez rekordów. Nasz runner liczy go jako sukces. Dla źródeł takich jak klienci Shopify osobna kontrola ostrzega zespół Tajo po dziesięciu udanych przebiegach z rzędu z zerową liczbą rekordów, jeśli synchronizacja wcześniej zwracała rekordy. Zamówienia Shopify są czytane według czasu aktualizacji, więc pusty przebieg jest tam normalny i ta kontrola nie działa. Źródło, które zwraca trochę rekordów, ale mniej, niż powinno, nie jest wykrywane wcale.

Zarzut brzmi tak: „Dziesięć pustych przebiegów to dwie i pół godziny przy harmonogramie co 15 minut. Dlaczego nie alarmować przy pierwszym?”. Synchronizacje kontaktów domyślnie działają co 15 minut. A sklep bez nowych klientów przez kwadrans to rzecz zwyczajna. Alarm przy pierwszym pustym przebiegu włączałby się co noc, a alarmu, który włącza się zawsze, nikt nie czyta. Ten próg zamienia szybkość na wiarygodność. Wciąż jest to domysł na temat ciszy, a nie zasada autorów.

6. Raz ustal, co synchronizacja może zapisywać, i niech każdy przebieg to potwierdza

Ich piąta zasada trzyma preferencje agenta „w magazynie, którego agent nie może edytować”. Szósta daje agentowi dostęp tylko do odczytu wszędzie tam, gdzie tylko czyta, i ogranicza, ile może wydać każdy przebieg. Obie istnieją, bo agent czyta tekst napisany przez innych, a ten tekst może próbować wydawać mu polecenia.

Odpowiednikiem pliku preferencji w synchronizacji jest opublikowana reguła. Opublikowanie synchronizacji Tajo wiąże ją ze skrótem dokładnie tej reguły, którą obejrzano w podglądzie. Edycja przywraca ją do wersji roboczej i reguła znowu przechodzi przez podgląd, zanim ponownie się uruchomi. Każdy przebieg, zanim cokolwiek zmieni, sprawdza, czy wykonuje tę opublikowaną wersję z połączeniami, z którymi ją opublikowano. Przebieg, który nie przejdzie tej kontroli, nie jest ponawiany. Kierunek też jest ustalony: reguła synchronizacji zapisuje w jedną stronę i nigdy z powrotem do Shopify.

Limit wydatków nie ma odpowiednika. Nasze przebiegi synchronizacji nie mają limitu wydatków na przebieg. Limit ponowień i pauza ograniczają, jak długo może trwać błąd, a nie ile kosztuje przebieg.

Co jest zbudowane, a co nie

Zbudowane, w chwili pisania:

• Kursor, który przesuwa się dopiero po partii, w której dotarł każdy rekord, oraz zaplanowany kursor zamówień, którego przebiegi uruchomione przez człowieka nie mogą cofnąć.
• Klucz dostarczenia dla każdego rekordu, sprawdzany w rejestrze zakończonych zapisów przechowywanym przez siedem dni.
• Jedna dzierżawa na synchronizację, sprawdzana przed zapisem i przed przesunięciem kursora.
• Pięć prób na przebieg, z przerwą 60 sekund, a potem 120, 240 i 480, bez ponowienia przy kolizji lub nieważnej publikacji.
• Pauza po pięciu nieudanych przebiegach z rzędu, widoczna na stronie synchronizacji.
• Cogodzinny alert, gdy w ciągu ostatnich 24 godzin żaden przebieg się nie udał.
• Filtr zgód w czasie przebiegu dla kontaktów zapisywanych do grupy marketingowej oraz kontrola przy każdym przebiegu, że jest to opublikowana wersja.

Niezbudowane, i warto o tym wiedzieć, zanim na tym polegniesz:

• Odczyt, który się udaje i zwraca zero rekordów, nie jest zgłaszany jako nieczytelny. Ostrzeżenie po dziesięciu przebiegach obejmuje część tego przypadku. Nie obejmuje zamówień Shopify ani źródła, które zwraca za mało rekordów.
• Alert 24-godzinny trafia do Tajo, nie do ciebie, podobnie jak ostrzeżenie po dziesięciu przebiegach. Pauza jest natomiast widoczna na stronie synchronizacji.
• Cogodzinna kontrola obserwuje obszar roboczy, a nie każdą synchronizację. Jedna zdrowa synchronizacja ukrywa cichą obok niej.
• Brak limitu wydatków na przebieg.
• Nic nie wznawia wstrzymanej synchronizacji. Robi to człowiek.
• Pauza po pięciu błędach i kontrola 24-godzinna są ustawione dla całej instalacji Tajo, a nie dla każdej synchronizacji osobno.

Gdy któryś z tych przypadków pojawi się w twojej synchronizacji, Przywracanie zablokowanej lub nieudanej synchronizacji mówi, co widzisz i co zrobić.

Autorzy napisali sześć zasad dla podsumowania, które człowiek czyta każdego ranka. Synchronizacja nie ma rano żadnego czytelnika, i dlatego potrzebuje ich jeszcze bardziej. Zasady od pierwszej do czwartej i zasada szósta to dziś kod w naszym runnerze. Zasada piąta jest napisana w połowie: synchronizacja, która nie może odczytać swojego źródła, powinna to powiedzieć.