TL;DR: Kredity na AI takmer spôsobili výpadok produkčnej databázy, pretože autonómny agent vstúpil do rekurzívnych slučiek, generoval neefektívne dotazy, vyčerpal kapacitu pripojení a škáloval sa bez účinných limitov. Článok argumentuje, že zľavnený výpočetný výkon môže oslabiť inžiniersku disciplínu, a preto systémy AI-databáza potrebujú izolované repliky len na čítanie, limity rýchlosti brány, deterministické kontroly dotazov, ľudskú kontrolu, záťažové testovanie, monitorovanie a záruky vrátenia zmien pred prístupom do produkcie.

  • Rekurzívna slučka agenta zvýšila počet databázových pripojení zo 150 na 4 500 a spotrebovala približne 200 € za hodinu výpočtového výkonu.
  • Päťdesiat paralelných vlákien agenta generovalo veľké, neindexované prehľadávania, ktoré vážne zaťažili databázu a jej zápisový denník.
  • Vnímaná dostupnosť bezplatných kreditov viedla tím k obídeniu bežného záťažového testovania a analýzy stresu.
  • Agenti AI by mali používať izolované, automaticky škálovateľné repliky na čítanie namiesto inštancií na zápis.
  • Odporúčané záruky zahŕňajú limity dotazov na reláciu, ľudskú kontrolu po 50 dotazoch za 60 sekúnd a deterministické kontroly pred vykonaním generovaných dotazov.

Najdrahšia časť automatizácie AI nie je vždy účet za model. Je to to, čo sa stane, keď sa rýchly systém pustí k produkčným dátam bez hraníc, kontroly a možnosti vrátenia zmien.

Všimnete si istý druh ticha v Slack kanáli, keď produkčná databáza dosiahne 99% využitie CPU a zostane tam. Nie je to ticho systému v nečinnosti; je to ticho inžinierskeho tímu, ktorý si uvedomuje, že „bezplatné peniaze“, ktoré práve prijali, práve rozoberajú ich infraštruktúru. Väčšina ľudí si neuvedomuje, že kredity na AI sú často vysokoúročný úver na váš technický dlh, ktorý si svoje pohľadávky uplatňuje o 3:00 ráno v utorok.

Práve sme získali grant 10 000 € v cloudových kreditoch na urýchlenie našich interných nástrojov LLM. Cítili sme to ako povolenie experimentovať bez trenia rozpočtových schválení. Stavali sme autonómneho agenta určeného na prehľadávanie našej internej dokumentácie a jej mapovanie oproti živým metadátam schémy, aby pomohol mladším vývojárom orientovať sa v našich starších systémoch. Mal to byť nástroj na zvýšenie produktivity. Namiesto toho sa stal distribuovaným útokom odmietnutia služby pochádzajúcim zvnútra nášho vlastného VPC.

Pravdepodobne vám bolo povedané, že najväčším rizikom AI je halucinácia alebo ochrana osobných údajov. To sú povrchové obavy vrcholového manažmentu. Pre nás, ktorí dodávame kód, je skutočným nebezpečenstvom neobmedzené vykonávacie slučky, ktoré vznikajú, keď dáte nedeterministickému modelu kľúče od deterministického prostredia. Neprišli sme o dáta kvôli hackerovi; takmer sme o ne prišli kvôli rekurzívnej slučke, ktorá spaľovala 200 € „bezplatného“ výpočtového výkonu každú hodinu a zároveň ničila našu inštanciu Postgres.

Problém začal jednoduchým prehliadnutím pri návrhu promptov. Testovali sme nový agentný pracovný postup, kde mal model za úlohu „nájsť všetky osirelé tabuľky a krížovo ich porovnať s časovými pečiatkami poslednej aktualizácie“. V tradičnom skripte napíšete konečnú slučku. V agentnom rámci model rozhoduje, kedy je hotový. Pretože naša schéma bola zložitá – výsledok rokov dlhu superaplikácie – AI sa zasekla v logickej slučke. Stále nachádzala „možné“ spojenia, spúšťala nové podúlohy na ich overenie a každá podúloha otvorila nové pripojenie k databáze.

Do štyridsiatich minút agent vyčerpal fond pripojení. Pretože sme nestanovili prísne limity rýchlosti na „bezplatnú“ službu AI, horizontálne sa škálovala, aby uspokojila „dopyt“ svojej vlastnej rekurzívnej logiky. Naživo sme sledovali, ako počet databázových pripojení vzrástol zo 150 na 4 500, čím sa efektívne zablokovali všetci legitímni používatelia a služby. Irónia bola hmatateľná: používali sme AI autopilotov na zlepšenie našej stratégie, ale nepodarilo sa nám implementovať základné ističe, ktoré by vyžadoval každý skúsený inžinier pre bežný cron job.

Toto sú skryté náklady zlatej horúčky AI. Keď je výpočtový výkon vnímaný ako bezplatný, inžinierska disciplína má tendenciu erodovať. Prestávame myslieť na kód ako na záväzok a začneme s ním zaobchádzať ako s jednorazovým tovarom. Ignorovali sme skutočnosť, že aj keď sú tokeny LLM pokryté grantom, následný dopad na spravované IOPS databázy a pamäť je veľmi reálny náklad, ktorý zaťaží váš primárny cloudový účet.

Klam o nekonečnom pieskovisku

Keď dostanete päťcifernú sumu v kreditoch, vaším inštinktom je zvýšiť súbežnosť. Chcete vidieť, ako rýchlo môže prísť „nová éra“. Nakonfigurovali sme nášho agenta na 50 paralelných vlákien v domnienke, že naša inštancia RDS zvládne záťaž. To, s čím sme nepočítali, bola nedeterministická povaha dotazov, ktoré AI generovala. Na rozdiel od ľudského vývojára, ktorý napíše predvídateľný JOIN, AI generovala masívne, neindexované prehľadávania tabuliek s miliónmi riadkov.

Nebol to len zásah do výkonu; bol to takmer úplný kolaps zapisovacieho denníka (WAL). Databáza strávila toľko času správou zámkov a prepínaním kontextu medzi tisíckami prichádzajúcich požiadaviek AI, že prestala spracovávať signály heartbeat z našich aplikačných serverov. Chýbali nám tri minúty k zlyhaniu databázy, ktoré by s najväčšou pravdepodobnosťou viedlo k poškodeniu údajov kvôli obrovskému objemu nepotvrdených transakcií v behu.

Prečo sa to stáva skúseným tímom? Pretože prompt engineering je nový softvérový engineering a my sme ešte nevyvinuli „čuch“ na nebezpečné prompty tak, ako ho máme na zlý SQL. S promptom zaobchádzame ako s návrhom, ale pre autonómneho agenta je to príkaz spotrebovať všetky dostupné zdroje, kým nie je cieľ splnený. Ak je cieľ zle definovaný, spotreba je nekonečná.

Tmavý redakčný vizuál DataTip pre: 10 000 € v AI kreditoch nás takmer stálo produkčnú databázu.

Podzvrat: Kredity boli rozptýlením

Tu je to, čo sme si uvedomili príliš neskoro: 10 000 € v kreditoch fungovalo ako psychologický obchvat našich štandardných protokolov Testovania záťaže a analýzy výkonnosti. Ak by sme za tieto tokeny platili z nášho prevádzkového rozpočtu od prvého dňa, začali by sme s jediným vláknom. Sledovali by sme latenciu. Vybudovali by sme proxy vrstvu na očistenie dotazov AI skôr, než by sa dostali do produkcie. „Bezplatná“ povaha zdroja nás povzbudila k tomu, aby sme preskočili inžinierstvo založené na myslení na prvom mieste, ktoré definuje filozofiu našej firmy.

Boli sme tak sústredení na „prelom“, že sme ignorovali „zlyhanie“. Toto je bežný vzor na súčasnom trhu. Spoločnosti sa ponáhľajú riešiť krízu vedomostného dlhu tým, že hádžu AI na svoje dátové silá, len aby zistili, že ich základná infraštruktúra nie je pripravená na čistú „zhovorčivosť“ aplikácií poháňaných LLM. Agent AI nečíta len dáta; vypytuje sa ich, často tým najneefektívnejším možným spôsobom.

Implementácia ističov

Aby sme zachránili databázu, museli sme zabiť celý Kubernetes namespace, ktorý hostil AI workerov. Bol to hrubý nástroj, ale fungoval. Keď sa dym rozplynul, zaviedli sme tri nevyjednávateľné pravidlá pre akúkoľvek interakciu AI s databázou, ktoré teraz používame so všetkými našimi klientmi:

  1. Mandát repliky len na čítanie: Žiadny AI agent, bez ohľadu na to, aký je „bezpečný“, sa nesmie pripojiť k inštancii na zápis. Žijú na izolovaných, automaticky škálovateľných replikách na čítanie, kde 100% špička CPU neodstaví tok pokladne.
  2. Obmedzovanie rýchlosti na základe tokenov na bráne: Vytvorili sme middleware, ktorý počíta počet databázových volaní na „Agent Session“. Ak agent prekročí 50 dotazov v 60-sekundovom okne, relácia je ukončená a označená na ľudskú kontrolu.
  3. Vzor „Vysvetli pred vykonaním“: Pred spustením akéhokoľvek dotazu generovaného AI musí byť odovzdaný deterministickému analyzátoru, ktorý kontroluje chýbajúce klauzuly WHERE alebo neindexované spojenia. Ak dotaz vyzerá ako úplné prehľadávanie tabuľky, je zamietnutý skôr, než sa vôbec dostane na drôt.

Koľko z vašej súčasnej „AI stratégie“ závisí od predpokladu, že vaša infraštruktúra zvládne nevyrovnané správanie modelu? Ak tieto ochranné prvky nebudujete, neinovujete; len čakáte, kým vaše kredity spália váš dom na popol.

Stále používame kredity, ale zaobchádzame s nimi ako s vysokonapäťovou elektrinou. Sú silné, ale vyžadujú si silnú izoláciu. Naše zameranie sme presunuli späť na inžinierstvo založené na myslení, čím zabezpečujeme, že každej AI integrácii predchádza prísna mapa alokácie zdrojov. Cieľom nie je len nasadiť AI; je to nasadiť AI, ktorá nevyžaduje obnovu zo zálohy v stredu ráno.


Nakoniec, grant 10 000 € bol lacnou lekciou. Stálo nás to pár hodín výpadku a veľa hrdosti, ale zachránilo nás to od oveľa väčšej katastrofy v budúcnosti. AI je multiplikátor, ale násobí všetko – vrátane vašich architektonických chýb a vášho nedostatku disciplíny. Ak sa chystáte dať AI kľúče od vašej databázy, uistite sa, že ste najprv postavili klietku okolo motora.

Ďalší krok

Použite to ako kontrolný zoznam bezpečnosti AI automatizácie. Porozprávajte sa s DataTip.


Kontakt

Slovenská republika+421911948347

DATATIP, s.r.o.
Alžbetina 30
Košice 040 01
IČO: 36869112
DIČ: SK2023131594
IBAN: SK80 8330 0000 0022 0024 5482

Česká republika+420773926377

DATATIP CZ, s.r.o.
Pelušková 1443
Praha 198 00
IČO: 24853577
DIČ: CZ24853577
IBAN: CZ81 2010 0000 0023 0033 8790

info@datatip.euWhatsAppOnline stretnutieLI. FB. IG. YT. TH. X. BS. PI. TT. SP.

Obchodné podmienky
Datatip© 2025

Privacy Preference Center