Kodėl DI automatizacijos nustoja veikti po paleidimo: šešios dažniausios priežastys

Demonstracija buvo puiki. Pirmos dvi savaitės irgi. Tada pasikeitė API, atsinaujino modelis, webhook pradėjo siųsti šiek tiek kitokius duomenis arba kažkas pervadino CRM lauką, ir automatizacija pradėjo tyliai gesti, o niekas to mėnesį nepastebėjo, nes niekas jos nestebėjo. Beveik kiekvienu mūsų išnagrinėtu atveju AI automatizacija nustojo veikti ne dėl modelio: modelis buvo tvarkoje, o aplink jį trūko inžinerinio darbo.

Prižiūrime kasdien veikiančias sistemas, tarp jų balso administratorių, ir mus pakankamai dažnai kviečia taisyti kitų sukurtas sistemas, kad priežastys mūsų nebestebintų. Toliau pateikiame priežasčių sąrašą, kuriuo remiamės. Kiekviena turi mechanizmą, pėdsaką, kurį galima pastebėti vykdymų sąraše nieko neatidarant, ir puslapį, kuriame ją išsamiai nagrinėjame.

Kodėl forumo diskusija čia mažai padeda

Paieškokite bet kurio iš šių simptomų, ir dauguma rezultatų bus bendruomenių forumų diskusijos. Kurį laiką teigėme, kad į tas diskusijas niekas neatsako, ir paskelbėme tai patvirtinančią statistiką, bet vėliau patys negalėjome savo skaičiaus atkartoti. Štai ką radome iš tikrųjų, kai 2026 m. rugpjūčio 26 d. tai tinkamai išmatavome, iš kiekvieno forumo Questions kategorijos paėmę po 600 temų sukūrimo tvarka.

Forumas, Questions kategorija	Paimta temų	Su priimtu atsakymu	Visai be atsakymų
n8n community	600	37,0 %	0,0 %
Make community	600	26,5 %	7,8 %

Taigi žmonės atsako. Mūsų ankstesnis teiginys, kad n8n forume šie klausimai išsprendžiami rečiau nei Make, buvo atvirkščias, ir jį pašalinome. Klaidos priežastį verta žinoti, jei kada nors patys matuosite Discourse forumą: n8n kategorijoje Help me Build my Workflow, kurioje yra 1 549 temos, sprendimų žymėjimas visiškai išjungtas, todėl bet kuri ją apimanti imtis rodo nulius dėl nustatymų, o ne todėl, kad niekas neatsako.

Lieka paprastesnė išvada. Apie 63 % n8n Questions diskusijų neturi pažymėto sprendimo, o forume per mėnesį atsiranda maždaug 722 naujos temos, kuriose rašo apie 1 235 žmonės. Gedimų vadovą rašome ne todėl, kad forumas blogas. Diskusija aprašo vieno žmogaus konkretų atvejį su jo prisijungimo duomenimis, jo duomenimis ir jo mazgų versijomis. Paieškoje ji randama, bet aprašo kito žmogaus situaciją.

Mechanizmas paprastas. Klausimas „kaip padalinti masyvą Code mazge“ turi vieną atsakymą, kuris tinka kiekvienam skaitytojui. „Mano workflow veikia, bet nieko nevyksta“ turi keturiasdešimt galimų priežasčių, o joms atsijoti reikia matyti vykdymų istoriją, prisijungimų sąrašą, įvesties duomenis ir paskutinio sėkmingo vykdymo datą. Forume niekas to nemato, todėl diskusija prisipildo spėlionių, autorius nutyla, kai problemą išsprendžia arba pasiduoda, o tema dvejus metus lieka neišspręsta ir iškyla būtent toje paieškoje, kurią sunerimęs savininkas įveda darbo dienos rytą.

Mūsų skaičiai yra vienos popietės momentinė nuotrauka iš vieno API taško su imties riba, todėl tolesni rezultatų puslapiai į ją nepateko.

Šešios priežastys, kodėl veikiančios automatizacijos sugenda

Prisijungimo duomenys baigia galioti arba atšaukiami

Tai dažniausia priežastis, kurią randame, ir apie ją beveik niekada nepranešama. Google OAuth programa, palikta Testing publikavimo būsenoje, išduoda atnaujinimo tokenus, kurie baigia galioti po septynių dienų: sistema sėkmingai praeina pirmą bandymų savaitę ir sugenda kitą pirmadienį. Atnaujinimo tokenai taip pat nustoja galioti, kai paskyros savininkas pakeičia slaptažodį arba kas nors atšaukia sutikimą savo Google saugos nustatymuose. Microsoft pusėje Entra sąlyginės prieigos politika gali nutraukti sesiją vykdymo viduryje dėl priežasčių, kurios su Jūsų workflow visiškai nesusijusios.

Slack verta atskiro įspėjimo. Kai tokenas atšauktas, API atsako HTTP 200, o turinyje yra ok:false, todėl patikra, kuri tikrina tik būsenos kodą, užfiksuoja sėkmę ir vykdo toliau. Verslo pusėje pranešimai tiesiog nustoja ateiti, vykdymų sąrašas žalias, ir nėra jokios klaidos, kurią būtų galima kam nors parodyti. Puslapyje apie nebegaliojančius prisijungimus rasite, kiek galioja kiekvieno tiekėjo tokenai, ir patikrą, kurią naudojame.

Tušti vykdymai, neatliekantys jokio darbo

Filtras nieko neatitinka. Duomenų bazės užklausa grąžina tuščią rinkinį. Webhook atsiunčia duomenis tokios struktūros, kurios pirmas mazgas neatpažįsta. Visi mazgai po tos vietos praleidžiami, o n8n vykdymą užfiksuoja kaip sėkmingą, nes jo požiūriu niekas nesugedo. Vykdymų sąrašas visą savaitę lieka žalias, nors joks darbas neatliekamas, o pirmas tai dažniausiai pastebi klientas, kuris taip ir negavo atsakymo.

Pėdsakas yra trukmė. Vykdymas, kuris paprastai trunka dvylika sekundžių, o baigiasi per 400 milisekundžių, nieko nepadarė, ir vykdymų sąraše tai matyti iš pirmo žvilgsnio, kai žinote, į ką žiūrėti. Išsamiame aprašyme apie workflow, kuris veikia, bet nieko nedaro, apžvelgiamos visos vietos, kuriose dingsta įrašai.

Pasikeitusi duomenų struktūra kitoje API pusėje

Tiekėjai prideda laukus, juos pervadina, perkelia į naujus objektus ir kartais pakeičia tipą, dažniausiai tai paskelbdami pakeitimų sąraše, kurio Jūsų įmonėje niekas neseka. Kodas, kuris skaitė data.customer.email, tą rytą, kai duomenų struktūra pasikeičia, pradeda mesti „Cannot read properties of undefined“. Toks gedimas bent jau matomas kaip nepavykęs vykdymas. Brangesnis variantas tylus: išraiška grąžina tuščią eilutę, tris savaites į CRM keliauja tušti laukai, ir tada tenka rankomis valyti duomenis skaičiuoklėje.

Užklausų limitai ir išnaudotos kvotos

Demonstracijos kuriamos su dešimčia testinių įrašų. Realiame darbe būna 200 vykdymų per dieną, pirmadienio ryto antplūdis ir masinis importas, kurį kažkas paleidžia niekam nepasakęs. Tada prasideda 429 klaidos, pasiekiama modelio paskyros tokenų per minutę riba arba šeštadienį baigiasi iš anksto apmokėtas likutis, nes automatinis papildymas taip ir nebuvo įjungtas. Per dviejų savaičių bandomąjį laikotarpį nieko iš to nepamatysite, todėl jis prastai parodo, ko sistemai iš tikrųjų reikia. Platformos skiriasi tuo, kaip susidoroja su tokiais limitais, ir tai svarbu renkantis tarp Zapier, Make ir n8n.

Continue On Fail naudojamas vietoj klaidų valdymo

Kažkas susiduria su klaida, kurios negali atkartoti, įjungia Continue On Fail (naujesnėse versijose Continue Using Error Output), nepavykęs vykdymas tampa sėkmingas, ir užduotis laikoma išspręsta. Nuo tada mazgas perduoda klaidos objektą toliau taip, lyg tai būtų duomenys. Kiekvienas po jo esantis mazgas apdoroja klaidos pranešimą ten, kur turėtų būti kliento įrašas. Esame matę workflow, kuriuose tai buvo įjungta kelis mėnesius ir į CRM tyliai rašė šiukšles, o savininkas nuoširdžiai tikėjo, kad sistema stabiliai veikia nuo pavasario.

Nėra atsakingo žmogaus ir nėra stebėsenos

Pusė mūsų vertintų taisymo darbų prasidėjo vienodai: kūrėjo nebebuvo, o visos paskyros buvo jo vardu. Jokios dokumentacijos, jokios administratoriaus prieigos ir nė vieno žmogaus, kurio darbas būtų stebėti sistemą. Stebėsena yra ta pati problema. Viename potencialių klientų paskirstymo taisymo darbe n8n workflow, atliekantis apie 200 vykdymų per dieną, sugesdavo maždaug kartą per dieną, o vienintelis jo įspėjimas keliavo į Slack kanalą, suarchyvuotą prieš kelis mėnesius, todėl niekas nebuvo matęs nė vieno gedimo. Formaliai įspėjimai buvo. Kai laisvai samdomas specialistas dingo, pirmiausia reikia susigrąžinti paskyras, o taisyti tik po to, o perdavimo kontrolinis sąrašas padeda tai susitvarkyti, kol dar niekas nedingo.

Dar vienas gedimas yra visai naujas: AI agentas, kuris nustoja naudoti savo įrankius. Workflow veikia, modelis atsako rišliu tekstu, o registracija taip ir neįvyksta, nes pasikeitė įrankio aprašymas arba sistemos instrukcija (system prompt) išaugo tiek, kad nurodymai pradėjo prieštarauti vieni kitiems. Iš pažiūros tai panašu į tuščią vykdymą, bet priežasties ieškoma kitaip, todėl tam skirtas atskiras puslapis. Pokalbių robotai turi panašų gedimą, kai modelis išgalvoja atsakymą, užuot jį suradęs.

Vykdymų duomenys saugomi tik keturiolika dienų

n8n pagal grafiką valo vykdymų duomenis, o numatytoji EXECUTIONS_DATA_MAX_AGE reikšmė yra 336 valandos, tai yra keturiolika dienų. Kai gedimas vystosi lėtai, pirmas blogas vykdymas dažnai jau būna ištrintas, kai kas nors paklausia, kada viskas prasidėjo. Esame tikrinę sistemą, dėl kurios klientai skundėsi mėnesį, ir radę tik dviejų savaičių istoriją, kuri visa prasidėjo jau po gedimo priežasties.

Iš to išplaukia dvi išvados. Padidinkite saugojimo laiką kiekvienoje savo serveryje veikiančioje instancijoje, kurioje vykdymai susiję su pinigais ar klientais: disko vieta pigesnė už spėliojimą. Ir nelaikykite valdymo skydelio stebėsena: skydelis parodo tik tai, į ką kas nors pažiūri, o įspėjimas atkeliauja, net jei niekas nežiūri. Puslapyje apie sustojusią automatizaciją rasite klaidų workflow, kurį galite importuoti: jis siunčia klaidą, mazgą ir duomenis ten, kur žmogus juos perskaitys.

Sąrašas, pagal kurį perduodame sistemas

Kiekviena mūsų sistema perduodama su šešiais dalykais: pakartojimais ir nepavykusių užklausų eile kiekvienam išoriniam kreipiniui, įspėjimais į kanalą, kurį skaito konkretus žmogus (ir dabar tikriname, ar kanalas nesuarchyvuotas), testų rinkiniu kiekvienai svarbiai užklausai, konfigūracija, atskirta nuo logikos, dokumentacija, pagal kurią sistemą galėtų valdyti ir kitas žmogus, ir paskyromis kliento vardu. Kiekvienas punktas atitinka vieną iš aukščiau aprašytų gedimų. Tai nėra įspūdingi dalykai, bet būtent dėl jų sistema veikia ilgai. Išsamesnė versija su patikromis, kurias atliekame prieš sutardami dėl paleidimo datos, yra paruoštumo kontrolinis sąrašas.

Mūsų taisyklė: workflow be įspėjimų neturėtų liesti klientų duomenų. Pridėti įspėjimą pigiau, nei aiškinti savininkui, kodėl mėnesį niekas nepastebėjo gedimo.

Jei sistema jau genda

Pradėkite nuo paprasčiausio klausimo: kada ji paskutinį kartą sėkmingai veikė? Dauguma platformų tai parodo vienu paspaudimu, o atsakymas dažnai būna senesnis, nei kas nors tikėjosi. Toliau priežasties ieškokite maždaug tokia tvarka.

1. Suraskite paskutinį sėkmingą ir pirmą nesėkmingą vykdymą ir užsirašykite abi datas prieš ką nors keisdami.
2. Skaitykite tikrąjį klaidos tekstą, o ne mazgo pavadinimą. „Request failed with status code 401“ ir „status code 429“ reikalauja visiškai skirtingų sprendimų, o mazgo pavadinimas abiem atvejais tas pats.
3. Palyginkite vykdymų trukmes visame sąraše. Vykdymai, kurie baigėsi gerokai per greitai, nieko nepadarė, nors ten pažymėti kaip sėkmingi.
4. Patikrinkite, kur siunčiamos klaidos, ir patys atidarykite tą vietą. Suarchyvuotas kanalas, bendra pašto dėžutė su filtravimo taisykle ar išėjusio žmogaus adresas reiškia, kad įspėjimų niekas negauna.
5. Prieš keisdami bet kokią logiką, rankomis, už workflow ribų, patikrinkite bent vieną prisijungimą.

Konkrečiai n8n atveju gedimo paieška, kai workflow nuolat lūžta, dėl tos pačios priežasties prasideda nuo klaidos teksto ir datos, kada gedimai prasidėjo.

Toliau pakartojimai. Kiekvieną išorinį kreipinį apgaubkite pakartojimu su ilgėjančia pauze ir žingsniu, kuris nepavykusius duomenis išsaugo ten, iš kur žmogus gali juos paleisti iš naujo. n8n tai klaidų workflow ir skaičiuoklės eilutė. Make tai klaidų valdymo maršrutas. Zapier tai daugiausia pačios platformos pakartotinis paleidimas, ir tai viena iš priežasčių, kodėl ji brangesnė.

Konfigūraciją žmonės dažnai praleidžia, nes ji atrodo kosmetinė. Laukų pavadinimus, modelių pavadinimus ir API versijas iškelkite į vieną nustatymų bloką workflow pradžioje arba į aplinkos failą, jei tai individualus kodas. Tada, kai CRM pervadins lauką, reikės pakeisti vieną eilutę, o ne ieškoti per keturiasdešimt mazgų. Tai ir pigiausia apsauga nuo pasikeitusios duomenų struktūros, nes būtent tokia paieška tokius pakeitimus ir padaro brangius.

Testai užima daugiau laiko, o testų rinkinio kūrimas iš Jūsų pačių pokalbių įrašų yra atskiras darbas. Trumpai: kiekvienas aukščiau aprašytas incidentas tampa testo atveju, todėl tas pats gedimas negali tyliai sugrįžti.

Atsakomybė yra paskutinis ir sunkiausiai išsprendžiamas dalykas. Turi būti konkretus atsakingas žmogus, savas darbuotojas ar tiekėjas, o paskyros bet kuriuo atveju turi būti įmonės vardu: dažniausia problema, kurią matome kūrėjui išėjus, yra ta, kad niekas net negali prisijungti pažiūrėti, kas sugedo.

Ne kiekvienai automatizacijai viso to reikia. Savaitinė ataskaita, el. paštu siunčianti CSV failą, gali neveikti savaitę, ir kas nors tai pastebės pirmadienį. Patikimumui skirkite dėmesį ten, kur tylus gedimas per dieną kitą jau kainuoja pinigų: potencialių klientų užklausoms, registracijoms, sąskaitoms ir visam, kas bendrauja su klientu. Mūsų vertintuose taisymo darbuose sistemą dažniausiai sugadindavo HTTP 500 be pakartojimo, savaitgalį pasibaigę prisijungimo duomenys, pasikeitusi duomenų struktūra arba jau minėtas suarchyvuotas kanalas.

Ar sistemą taisyti, ar kurti iš naujo, yra atskiras sprendimas, ir aprašėme, kaip jį priimame. Jei sistema, nuo kurios priklausote, jau tyliai genda, 450 € raštiška diagnostika per dvi darbo dienas suranda priežastį, o jos kaina visa įskaitoma į taisymą.