n8n w produkcji: co się psuje, gdy proces staje się krytyczny dla firmy

Zbudowanie działającego procesu w n8n jest łatwe. O to właśnie w n8n chodzi i jest to naprawdę dobre narzędzie.

Co nie jest łatwe — i przed czym nikt nie ostrzega — to przejście od „to działa" do „firma polega na tym, że zadziała poprawnie o 3:00 w niedzielę, kiedy nikt nie patrzy". To przejście ma swoje konkretne tryby awarii i za każdym razem są takie same.

Oto te, na które trafiam najczęściej, mniej więcej w kolejności, w jakiej dają się we znaki.

1. Ponowne próby, które dublują skutki uboczne

To pierwsza i najdroższa z nich.

Węzeł pada przy chwilowym problemie z siecią. n8n ponawia próbę. Ponowienie się udaje. Tyle że pierwsza próba zdążyła już utworzyć fakturę, zanim przekroczyła limit czasu na odpowiedzi — więc są teraz dwie faktury, a nikt tego nie zauważa przez miesiąc.

Wszystko, co zapisuje coś w świecie zewnętrznym, musi być idempotentne, czyli dwukrotne uruchomienie musi dawać ten sam efekt co jednokrotne. W praktyce:

Wysyłaj deterministyczny klucz idempotentności przy każdym żądaniu tworzącym zasób, jeśli API to obsługuje. Wiele API to potrafi; prawie nikt z tego nie korzysta.
Jeśli API tego nie ma, sprawdź-potem-utwórz: najpierw odpytaj o rekord po naturalnym kluczu.
Ustaw kolejność węzłów tak, żeby zapis był ostatnią rzeczą, która się dzieje. Proces, który zapisuje, a potem wykonuje jeszcze pięć kroków, ma pięć dodatkowych szans na awarię po nieodwracalnej części.

Zasada, której używam: zanim włączysz ponawianie na węźle, zadaj sobie pytanie, co się stanie, jeśli wykona się dwa razy. Jeśli nie umiesz odpowiedzieć, nie włączaj go.

2. Brak procesu obsługi błędów, więc awarie są ciche

Domyślnym trybem awarii zepsutej automatyzacji nie jest alarm. Jest nim cisza, a cisza wygląda dokładnie jak sukces.

Ustaw error workflow (Settings → Error Workflow) w każdym procesie produkcyjnym, pierwszego dnia. Powinien robić dwie rzeczy: powiadomić człowieka tam, gdzie ten człowiek naprawdę zagląda, i zawierać dość kontekstu do diagnozy — który proces, które ID wykonania, który węzeł i jakie dane wejściowe to spowodowały.

Subtelniejsza wersja tego problemu: procesy, które zawodzą przez nicnierobienie. Trigger, który przestaje odpalać, nie generuje żadnego błędu, bo nic się nie wykonało. To jest ta awaria, której nikt nie wykrywa przez trzy tygodnie. Jedyna pewna odpowiedź to czuwak: osobne zaplanowane sprawdzenie, które alarmuje, gdy oczekiwane uruchomienie nie nastąpiło.

3. Jeden gigantyczny proces

Każda dojrzała instalacja n8n, jaką widziałem, ma jeden proces z sześćdziesięcioma węzłami, którego nikt nie chce dotykać. Zwykle zaczynał od dwunastu.

Koszt nie jest estetyczny. Chodzi o to, że nie da się powtórzyć nieudanego kroku w środku bez powtórzenia wszystkiego przed nim, a przy czymkolwiek ze skutkami ubocznymi oznacza to, że nie da się tego powtórzyć w ogóle. Awarie wymagają więc ręcznej naprawy zamiast ponowienia.

Dziel w miejscach, w których chciałbyś móc wznowić pracę. Proces nadrzędny wywołujący podprocesy przez Execute Workflow kosztuje trochę czytelności w edytorze, a daje możliwość naprawienia jednego etapu bez ruszania pozostałych.

4. Poświadczenia, które wygasają w święto

Tokeny OAuth wygasają. Klucze API są rotowane przez dział IT, który nie wie, że Twój proces istnieje. Certyfikaty tracą ważność. Wszystko to daje błędy uwierzytelniania, które wyglądają jak nagła, tajemnicza awaria.

Pomagają dwa nawyki. Prowadź spis, które procesy używają których poświadczeń — tabela gdzieś zapisana, nie wiedza plemienna. I spraw, żeby komunikat z error workflow odróżniał błędy uwierzytelniania od reszty, bo błąd uwierzytelniania ma znaną, ustaloną przyczynę i nie powinien pochłaniać czterdziestu minut debugowania.

5. Rozmiar danych i pamięć

n8n przekazuje dane między węzłami w pamięci. Jest to w porządku, dopóki ktoś nie wgra pliku o wadze 200 MB albo zapytanie, które zwykle zwraca 50 wierszy, nie zwróci 500 000, bo filtr po cichu przestał działać.

Pilnuj wejścia. Dodaj wcześnie w procesie jawne sprawdzenie rozmiaru paczki i głośno przerwij, jeśli przekracza to, na co projektowałeś. „Za dużo elementów, przerywam" to dużo lepszy wynik niż awaria z braku pamięci w połowie przetwarzania, gdy część rekordów jest zapisana, a część nie.

Przy naprawdę dużych zadaniach przetwarzaj partiami w pętli i przekazuj referencje — identyfikatory plików, adresy URL — zamiast przerzucać zawartość pliku między każdą parą węzłów.

6. Brak historii wersji, która cokolwiek znaczy

Edytor jest żywym środowiskiem produkcyjnym. Edytujesz, zapisujesz, jest na produkcji. Nie ma pull requesta, nie ma diffa, nie ma przeglądu.

Minimum, które teraz stosuję: eksportuję produkcyjne procesy do JSON-a i commituję je do gita według harmonogramu. To nie jest porządna kontrola wersji — diffy to brzydki, prawie nieczytelny JSON — ale dzięki temu można odpowiedzieć na pytanie „co się zmieniło we wtorek" i przywrócić działającą wersję.

Lepiej, jeśli proces jest ważny: osobne instancje deweloperska i produkcyjna, a wdrożenie przez import. Wolniej — i dokładnie raz warte tej ceny.

7. Nikt nie wie, co znaczy „działa"

Automatyzacja nie jest poprawna dlatego, że nie zgłosiła błędu. Jest poprawna dlatego, że dała właściwy wynik.

To rozróżnienie ma największe znaczenie przy wszystkim, co dotyka LLM-a, gdzie proces radośnie zakończy się sukcesem, produkując bzdury. Ale dotyczy też zwykłych automatyzacji: synchronizacja danych, która przebiega czysto i synchronizuje niewłaściwe pole, to zielony ptaszek i cichy problem.

Pomaga zdefiniowanie już na etapie budowy jednego sprawdzalnego założenia o wyniku — liczba, która ma się zgadzać, suma, która ma się bilansować, pole, które nigdy nie może być puste — i sprawdzanie go przez proces oraz przerwanie, gdy nie jest spełnione. To nieefektowne i wyłapuje klasę błędów, której monitoring nigdy nie złapie.

8. Decyzje o self-hostingu podjęte raz, żałowane później

Jeśli hostujesz samodzielnie — a ja tak robię — trzy rzeczy warto rozstrzygnąć świadomie, a nie domyślnie:

Retencja danych wykonań. n8n przechowuje historię wykonań razem z danymi, które przez nie przeszły. W procesie obsługującym dane osobowe to cicha ekspozycja RODO siedząca w Twojej bazie. Ustaw politykę retencji; nie zostawiaj domyślnego „na zawsze".
Tryb kolejkowy. Zwykły tryb jest prostszy i wystarcza, dopóki nie zacznie się liczyć współbieżność. Przejście później to migracja; decyzja wcześnie to konfiguracja.
Kopie zapasowe obejmujące bazę danych. To w niej są procesy, poświadczenia i historia. Backup kontenera bez bazy to backup niczego, co się liczy.

Wersja krótka

Jeśli masz zapamiętać jedno: zanim proces trafi na produkcję, wypisz, co się dzieje, gdy każdy węzeł zawiedzie, i co się dzieje, gdy wykona się dwa razy. Dziesięć minut z kartką papieru. Prawie każdy incydent produkcyjny, jaki miałem z n8n, wyłapałoby to ćwiczenie — a te, których by nie wyłapało, to wygasłe poświadczenia, i właśnie dlatego istnieje punkt czwarty.

n8n nie jest kruche. To naprawdę dobre narzędzie, które sprawia, że budowanie jest na tyle łatwe, że ludzie pomijają moment, w którym myśli się o awarii. Problemem nie jest narzędzie; problemem jest te brakujące dziesięć minut.