Tohle je naše vlastní infrastruktura, ne klientský projekt. Je malá, ale dobře ukazuje, jak přemýšlíme o automatizacích, které nesmějí ztratit data.
Výchozí situace
Provozujeme několik webů a každý má kontaktní formulář. Každá zpráva je potenciální klient nebo uživatel s problémem, takže záleží na dvou věcech: musíme se o ní dozvědět rychle a nikdy ji nesmíme ztratit.
Klasické řešení v malé firmě je formulář, který pošle e-mail. Pak někdo zkontroluje schránku, přepíše údaje do CRM nebo tabulky, pošle potvrzení a snaží se nezapomenout ozvat. Je to pomalé a každý krok je místo, kde se zpráva může zapomenout.
Co jsme postavili
První verze vznikla pro jeden web. Formulář posílal data do n8n workflow, které poslalo upozornění do Telegramu, takže byl dotaz vidět během pár sekund, uložilo ho do jednoduchého CRM a odesílateli poslalo potvrzovací e-mail.
Postupně jsme na stejnou instanci n8n na vlastním serveru napojili všechny naše weby. Každý jí předává odeslané formuláře a n8n nás upozorní v Telegramu. Jedno místo, kde se mění logika, jedno místo, kam se podívat, když se něco pokazí.
Tenhle návrh měl slabinu, kterou jsme zpočátku neviděli: n8n bylo jedinou kopií. Web zprávu předal a zapomněl na ni. Když bylo n8n v tu chvíli mimo provoz nebo se restartovalo, zpráva zmizela a nikdo by se nikdy nedozvěděl, že existovala.
Do serverového kódu každého webu jsme proto přidali zálohu:
- Když někdo odešle formulář, web nejdřív zapíše zprávu do logu na vlastním serveru jako přijatou.
- Teprve pak ji předá do n8n.
- Zaznamená výsledek: doručeno, nebo selhalo i s důvodem.
Přijatý záznam bez doručeného je přesně zpráva, která k nám nedorazila. Jednoduchý příkaz na serveru je vypíše, takže po výpadku vidíme, co se propáslo.
Jak to funguje v běžném provozu
Normálně se nic nemění: zpráva dorazí do Telegramu pár sekund po odeslání. Monitoring dostupnosti hlídá instanci n8n a jeho upozornění je signál podívat se do logu na nedoručené zprávy, místo hádání.
Dvě rozhodnutí byla záměrná. Když se lokální kopie povedla a předání selhalo, návštěvník se i tak dozví, že zpráva odešla, protože se neztratila, a chybová hláška by ho jen donutila psát ji znovu. A protože log obsahuje jména, e-maily a texty zpráv, je navržený tak, aby se držel jen omezenou dobu a pak ho smazal plánovaný úklid. Záchranná síť pro osobní údaje se nesmí stát jejich archivem.
Záloha se na každém webu zapne, jakmile mu server přidělí místo pro ukládání; do té doby se web chová přesně jako dřív, takže nasazení nemohlo rozbít fungující formulář.
Co jsme se naučili
I fungující automatizace může být křehká. Tok, který dlouho prostě funguje, je přesně místo, kde jediný bod selhání zůstane bez povšimnutí. U každé automatizace se neptejte „funguje to?“, ale „co se stane s daty, když to nefunguje?“
Nejdřív zapsat, potom předat. Když se zpráva uloží dřív, než se předá dál, zůstane po jakékoli chybě v dalších krocích záznam. Obráceně by se zaznamenalo jen to, co se už povedlo.
Záloha nesmí být novým zdrojem chyb. Nic v kódu pro logování nesmí rozbít odeslání formuláře. Když se zápis kopie nepovede, chyba jde do logu serveru a formulář funguje normálně. Pole mají omezenou délku, aby záplava odeslání nemohla zaplnit disk.
Malé věci klidně zdvojte. Naše weby nesdílí jeden kód, takže malý modul pro logování je zkopírovaný do každého z nich místo samostatného balíčku. U pár desítek řádků je držet kopie v souladu levnější než udržovat knihovnu.
Které službě to odpovídá
Je to n8n automatizace v nejjednodušší podobě: propojit nástroje, které firma už používá, aby se informace hned dostala ke správnému člověku. Pozornost si nezaslouží šťastná cesta, ale záloha, a stejně přemýšlíme u každého workflow, které stavíme pro klienty.
