Tylios automatizavimo klaidos: kai sistema rodo „viskas gerai“, bet taip nėra

Tylioji klaida – tai gedimas, po kurio automatizacija toliau veikia ir praneša apie sėkmę, nors rezultatas neteisingas. Akivaizdi klaida sustabdo darbą: pasirodo pranešimas, kažkas paskambina, problema sutvarkoma. Tylioji leidžia klaidingiems duomenims keliauti toliau – į sąskaitą, ataskaitą ar atsakymą klientui – ir išaiškėja tada, kai jau sunku atsekti, nuo kada viskas prasidėjo.

Su tuo susidūrėme ir patys: kontrolinė suma dar prieš paleidimą sugavo tylią mūsų pačių PDF nuskaitymo klaidą. Programa klaidos neparodė – ją parodė tik sumų nesutapimas. Nuo tada laikomės taisyklės: kiekvienam automatiniam skaičiavimui – savas invariantas, t. y. sąlyga, kuri turi galioti visada (pvz., sąskaitos eilučių suma lygi bendrai sumai).

Toliau – septyni tylių klaidų tipai, kuriuos pažįstame iš savo darbo: kiekvieno tipinis simptomas, priežastis ir apsauga. Priežastys techninės, o pasekmes jaučia verslas: neapdoroti laiškai, per maža suvestinė, dublikatai, sustoję pokalbiai.

HTTP būsenos kodas 200 reiškia tik tiek, kad serveris užklausą įvykdė be klaidos; jis nepatvirtina, kad gavote tai, ko prašėte. Štai du tokie atvejai.

Google Sheets eksportas grąžina ne tą lapą. Simptomas: automatizacija skaito kainas ar užsakymus iš Google Sheets lentelės, viskas veikia, bet duomenys paimti iš kito lapo. Priežastis: mūsų pastebėjimu, CSV eksportas, paprašius neegzistuojančio lapo (pvz., kai lapas pervadintas), klaidos negrąžina – jis be jokio įspėjimo grąžina pirmąjį lentelės lapą su būsenos kodu 200. Apsauga: lapo ieškome pagal pavadinimą, stulpelius atpažįstame pagal antraštes, o tokio lapo neradę darbą sustabdome ir aiškiai pranešame, ko trūksta, užuot dirbę toliau su bet kokiais duomenimis.

Serverio maršrutas, kuris visada atsako 200. Simptomas: forma ar kita sąsaja praneša apie sėkmę, nors duomenys į išorinę paslaugą taip ir nenukeliavo. Priežastis: serverio kodas perima išorinio API klaidą, bet vis tiek grąžina sėkmės atsakymą – pavyzdžiui, kad naudotojas nepamatytų techninio pranešimo. Apsauga: išorinio API nesėkmę įrašome į žurnalą su būsenos kodu ir atsakymo turiniu, o naudotojui grąžiname tikrą būseną. Be atsakymo turinio žurnale lieka tik „kažkas nepavyko“ ir priežasties tenka ieškoti spėliojant.

Tuščias rezultatas ir nepavykusi užklausa atrodo vienodai, jei kodas klaidos netikrina atskirai. Tai klasikinė tylios klaidos forma dirbant su duomenų bazėmis.

Klaida, kuri virsta nuliu. Simptomas: pavyzdžiui, rytinė ataskaita praneša „naujų užsakymų: 0“, nors užklausa iš tikrųjų nepavyko dėl pasibaigusio prieigos rakto. Priežastis: kai kurios duomenų bazių klientinės bibliotekos klaidos neiškelia kaip išimties, o grąžina ją kartu su tuščiais duomenimis. Supabase JavaScript bibliotekos dokumentacijoje nurodyta, kad kiekvienas kreipinys grąžina duomenų ir klaidos porą (data, error), užuot iškėlęs išimtį. Jei kodas tikrina tik duomenis, klaidos jis nepastebi ir ataskaitoje lieka nulis. Apsauga: pirmiausia tikriname klaidos objektą, o ataskaitoje „0 įrašų“ ir „nepavyko gauti“ rodome kaip skirtingas būsenas.

Riba, apie kurią niekas neįspėja. Simptomas: pavyzdžiui, mėnesio suvestinė be jokios klaidos rodo per mažą sumą, nors anksčiau, kai duomenų buvo mažai, viskas sutapdavo. Priežastis: Supabase projektai pagal numatytuosius nustatymus vienai užklausai grąžina ne daugiau kaip 1 000 eilučių (riba keičiama projekto API nustatymuose); likusios eilutės į atsakymą nepatenka, o klaida negrąžinama. Pats PostgREST (API sluoksnis, kurį naudoja Supabase) tokios ribos neturi – ją nustato konkretus diegimas, todėl verta patikrinti savąjį. Apsauga: suvestinėms naudojame puslapiavimą (pvz., range()), o lygiai 1 000 grąžintų eilučių laikome įspėjamuoju ženklu, ne rezultatu.

Dalis gedimų nesukuria jokio klaidingo rezultato – sistema nebedaro to, ką turėtų, o tyla iš šalies atrodo kaip ramybė.

Baigiasi Gmail pranešimų prenumerata. Simptomas: automatizacija, reaguojanti į naujus laiškus, kelias dienas veikia, o paskui be jokios klaidos nutyla. Priežastis: Gmail API pranešimų prenumerata (users.watch) galioja ribotą laiką. Gmail API pranešimų dokumentacijoje nurodyta, kad metodą watch reikia iškviesti bent kartą per 7 dienas, kitaip pranešimai nebeateina; rekomenduojama tai daryti kasdien. Apsauga: prenumeratą atnaujiname kasdien pagal grafiką ir tikriname, ar per parą atėjo bent vienas pranešimas; jei ne – siunčiame įspėjimą. Pašto dėžutei, į kurią laiškai ateina ne kasdien, leistiną tylos trukmę parenkame pagal jos įprastą ritmą.

Pakeitus kalbos modelį, sustoja pokalbiai. Simptomas: po konfigūracijos pakeitimo DI (AI) pokalbių asistentas svetainėje nebeatsako nė vienam lankytojui, nors diegimas pavyko ir svetainė veikia. Priežastis: naujas modelis neįjungtas DI paslaugos projekto nustatymuose, todėl paslauga užklausų nepriima. Apsauga: modelį pirmiausia įjungiame projekto nustatymuose, išbandome ir tik tada keičiame konfigūraciją, o žurnale įrašome, kuris modelis atsakinėjo kiekviename pokalbyje.

Mūsų kuriami pokalbių asistentai ir balso DI agentai pokalbio pradžioje prisistato kaip DI. Pokalbio tekstas siunčiamas debesyje veikiančiam kalbos modeliui, todėl įrašas apie naudotą modelį reikalingas ne tik gedimams tirti – iš jo matyti ir tai, kurio teikėjo modelis tą tekstą gavo.

Jei šaltinis vėluoja, „neradau“ dar nereiškia „nėra“, o automatizacija, kuri tokiu atveju įrašą sukuria iš naujo, gamina dublikatus.

Google Sheets duomenys per viešą CSV eksportą atsilieka. Simptomas: ką tik įvesta eilutė kurį laiką nematoma; jei automatizacija ją „atkuria“, lentelėje atsiranda du vienodi įrašai. Priežastis: mūsų stebėjimais, per viešą CSV eksportą skaitomi duomenys atsilieka keliomis minutėmis, o jei svetainė juos dar laiko savo podėlyje, pakeitimas matomas dar vėliau. Apsauga: iš tokio šaltinio niekada nesprendžiame, kad įrašo trūksta, ir jo nekuriame iš naujo, o įrašymo rezultatą tikriname per API, tiesiai šaltinio lape.

Atsiliekančius duomenis galima rodyti svetainėje ar pokalbių asistento atsakymuose, bet pagal juos negalima automatiškai ko nors kurti, trinti ar perrašyti.

Kiekvienam automatiniam skaičiavimui numatome patikrą, kuri gali parodyti, kad rezultatas neteisingas, o reguliariai vykstantiems procesams – ir įspėjimą apie tylą. Praktiškai tai šeši dalykai:

• Invariantai. Kiekvienam skaičiavimui – sąlyga, kuri turi galioti visada. Pavyzdžiui, užsakovo sąskaita suvedama su kontroline suma: bendra sąskaitos suma turi sutapti su visų mokesčių stulpelių suma iki cento.
• Žurnalai su priežastimi. Išorinės sistemos nesėkmę įrašome su būsenos kodu ir atsakymo turiniu, pokalbį – su naudotu modeliu. Jei žurnale nėra priežasties, neaišku, ką taisyti.
• Įspėjimas apie tylą. Kas turi vykti reguliariai (pavyzdžiui, laiškų pranešimai), tą ir tikriname: jei neįvyko, pranešame žmogui, o ne laukiame, kol kas nors pastebės.
• Jokia eilutė nedingsta tyliai. Jei eilutės negalima patikimai suskaičiuoti, programa jos nepildo ir paaiškina kodėl; neatpažinta sąskaitos eilutė lieka matoma atskirame sąraše. Tai tikrina specialus automatinis testas.
• Testai po kiekvieno pakeitimo. Kodą pataisius ar papildžius, automatiniai testai patikrina, ar rezultatai nepasikeitė; pokalbių asistentus, atnaujinus jų instrukcijas, tikriname regresiniais testais, kuriuose testuotojas vaidina klientą.
• Žmogus patvirtina. Darbuotojas pamato, ką programa įrašys, ir tik tada patvirtina; programa rašo tik į tuščius langelius ir ranka įvestų reikšmių neperrašo.

Kontrolinė suma ir neatpažintų eilučių sąrašas veikia automatizacijoje, kuri logistikos įmonei suveda sąskaitas į jos Excel lentelę, o be žmogaus patvirtinimo programa į tą lentelę nieko neįrašo. Bandyme programos rezultatai sutapo su ranka įvestais duomenimis, o sąskaitos suma – iki cento.

Tylią klaidą galima pastebėti ir be programuotojo: užtenka automatizacijos rezultatą palyginti su jau žinomais skaičiais – sąskaitos suma, užsakymų skaičiumi ar įprastu savaitės kiekiu. Žurnalų skaityti nereikia – pakanka atsakyti į keturis klausimus:

• Ar sutampa sumos? Automatiškai suvestos sąskaitos suma turi sutapti su PDF dokumento eilute „Iš viso“. Jei sumos skiriasi, programa turi tai parodyti, o ne vis tiek įrašyti duomenis.
• Ar nulis tikrai reiškia nulį? Jei ataskaita staiga rodo „0“ arba gerokai mažiau nei įprastai, pirmiausia patikrinkite, ar duomenys apskritai buvo gauti.
• Ar vyksta tai, kas turi vykti kasdien? Jei kelias dienas neatsiranda nė vienos automatiškai surinktos sąskaitos ar apdoroto laiško, tai signalas, o ne ramybė.
• Ar matote, ko programa nesuprato? Neatpažintos eilutės turi likti matomos atskirame sąraše, o ne dingti be pėdsakų.

Jei į kurį nors klausimą atsakyti negalite, paklauskite automatizacijos kūrėjo, iš kur sužinotumėte, kad ji suklydo. Per nemokamą automatizavimo auditą aiškinamės, kur jūsų įmonėje dažniausiai klystama ir kada klaida pastebima – nuo to priklauso, kokių patikrų reikia.

Kai klaidos kaina maža ir rezultatą iškart peržiūri žmogus, pakanka paprastesnės patikros. Vienkartiniam duomenų perkėlimui, kurio rezultatą darbuotojas patikrina tą pačią dieną, kasdienių įspėjimų nereikia. Apsaugų reikia ten, kur automatizuotas verslo procesas kartojasi, veikia be priežiūros ir jo rezultatas keliauja toliau – į sąskaitas, apmokėjimus ar atsakymus klientams.

Reikia žinoti ir ribas. Invariantas aptinka tik tai, ką tikrina: kontrolinė suma neparodys, kad eilutė priskirta ne tam užsakymui, jei bendra suma vis tiek sutampa. O per daug įspėjimų virsta triukšmu, kurio niekas neskaito, todėl po kiekvieno įspėjimo turi būti aišku, ką daryti.