Stručně: AI kredity málem způsobily výpadek produkční databáze, protože autonomní agent uvízl v rekurzivních smyčkách, generoval neefektivní dotazy, vyčerpal kapacitu připojení a škáloval bez účinných limitů. Článek tvrdí, že zlevněný výpočetní výkon může oslabit inženýrskou disciplínu, a proto systémy propojující AI s databází potřebují před přístupem do produkce izolované read-only repliky, rate limity na gateway, deterministické kontroly dotazů, lidskou revizi, zátěžové testy, monitoring a pojistky pro rollback.

  • Rekurzivní smyčka agenta zvýšila počet databázových připojení ze 150 na 4 500 a spotřebovávala výpočetní výkon za zhruba 200 € za hodinu.
  • Padesát paralelních vláken agenta generovalo rozsáhlé skeny bez indexů, které databázi i její write-ahead log silně přetížily.
  • Dojem, že jsou k dispozici kredity zdarma, vedl tým k tomu, že vynechal běžné zátěžové testy a analýzu odolnosti.
  • AI agenti by měli používat izolované, automaticky škálované read repliky, nikoli instance pro zápis.
  • Doporučené pojistky zahrnují limity dotazů na session, lidskou revizi po 50 dotazech za 60 sekund a deterministické kontroly před spuštěním vygenerovaných dotazů.

Nejdražší částí AI automatizace nemusí být vždy účet za model. Je to to, co se stane, když rychlý systém pustíte k produkčním datům bez hranic, revize a možnosti rollbacku.

Když produkční databáze dosáhne 99% využití CPU a zůstane tam, všimnete si ve Slack kanálu zvláštního druhu ticha. Není to ticho systému, který odpočívá; je to ticho inženýrského týmu, kterému dochází, že „peníze zdarma“, které právě přijal, mu teď rozebírají infrastrukturu. Většina lidí si neuvědomuje, že AI kredity jsou často vysoce úročenou půjčkou na váš technický dluh – a ta si o splátku řekne v úterý ve tři ráno.

Právě jsme získali grant 10 000 € v cloudových kreditech na urychlení našich interních LLM nástrojů. Připadalo nám to jako povolení experimentovat bez zdržování se schvalováním rozpočtu. Stavěli jsme autonomního agenta, který měl procházet naši interní dokumentaci a mapovat ji na metadata živého schématu, aby se junior vývojáři snáze orientovali v našich legacy systémech. Měl zvýšit produktivitu. Místo toho se z něj stal distribuovaný útok typu denial-of-service vedený zevnitř našeho vlastního VPC.

Nejspíš jste slyšeli, že největším rizikem AI jsou halucinace nebo ochrana dat. To jsou povrchní obavy vedení. Pro ty z nás, kdo dodávají kód, je skutečným nebezpečím neomezené smyčky běhu, které vznikají, když nedeterministickému modelu dáte klíče od deterministického prostředí. Data jsme neztratili kvůli hackerovi; málem jsme o ně přišli kvůli rekurzivní smyčce, která každou hodinu spálila výpočetní výkon „zdarma“ za 200 € a přitom drtila naši instanci Postgres, až se vzdala.

Problém začal jednoduchým přehlédnutím v prompt engineeringu. Testovali jsme nové agentní workflow, ve kterém měl model za úkol „najít všechny osiřelé tabulky a porovnat časová razítka jejich poslední aktualizace“. V tradičním skriptu napíšete konečnou smyčku. V agentním frameworku rozhoduje o dokončení model. Protože naše schéma bylo složité – výsledek let dluhu super aplikace –, AI uvízla v logické smyčce. Neustále nacházela „možné“ vazby, spouštěla nové dílčí úlohy k jejich ověření a každá dílčí úloha otevřela nové připojení k databázi.

Během čtyřiceti minut agent vyčerpal connection pool. Protože jsme u AI výpočetní služby „zdarma“ nenastavili přísné rate limity, škálovala horizontálně, aby uspokojila „poptávku“ vlastní rekurzivní logiky. V reálném čase jsme sledovali, jak počet databázových připojení vyskočil ze 150 na 4 500 a fakticky zablokoval všechny legitimní uživatele i služby. Ironie byla hmatatelná: používali jsme AI autopiloty ke zlepšení strategie, ale nezavedli jsme základní jističe, které by každý senior inženýr vyžadoval i u obyčejného cron jobu.

To je skrytá cena AI zlaté horečky. Když je výpočetní výkon vnímán jako zdarma, inženýrská disciplína má tendenci erodovat. Přestaneme o kódu přemýšlet jako o závazku a začneme s ním zacházet jako se spotřebním zbožím na jedno použití. Přehlédli jsme, že i když tokeny LLM pokrývá grant, dopad na IOPS a paměť spravované databáze je velmi reálný náklad, který se objeví na vašem hlavním cloudovém účtu.

Omyl nekonečného sandboxu

Když dostanete kredity v pěticiferné výši, instinktivně zvýšíte souběžnost. Chcete vidět, jak rychle může „nová éra“ přijít. Nakonfigurovali jsme agenta na 50 paralelních vláken v domnění, že naše instance RDS zátěž zvládne. Nepočítali jsme ale s nedeterministickou povahou dotazů, které AI generovala. Na rozdíl od lidského vývojáře, který napíše předvídatelný JOIN, AI generovala masivní skeny bez indexů přes tabulky s miliony řádků.

Nešlo jen o pokles výkonu; byl to téměř úplný kolaps write-ahead logu (WAL). Databáze trávila tolik času správou zámků a přepínáním kontextu mezi tisíci příchozích AI požadavků, že přestala zpracovávat heartbeat signály z našich aplikačních serverů. Byli jsme tři minuty od failoveru databáze, který by kvůli obrovskému objemu rozpracovaných nepotvrzených transakcí pravděpodobně vedl k poškození dat.

Proč se to stává zkušeným týmům? Protože prompt engineering je nové softwarové inženýrství a pro nebezpečné prompty jsme si ještě nevyvinuli takový „čich“ jako pro špatné SQL. Prompt bereme jako návrh, ale pro autonomního agenta je to příkaz spotřebovat všechny dostupné zdroje, dokud nesplní cíl. Pokud je cíl špatně definovaný, spotřeba je nekonečná.

Tmavý redakční vizuál DataTip k článku: AI kredity za 10 000 € nás málem stály produkční databázi.

Další zvrat: kredity nás jen rozptýlily

Tady je to, co jsme si uvědomili příliš pozdě: kredity za 10 000 € fungovaly jako psychologická zkratka, díky které jsme obešli naše standardní protokoly zátěžového testování a analýzy odolnosti. Kdybychom za tokeny od prvního dne platili z provozního rozpočtu, začali bychom s jediným vláknem. Sledovali bychom latenci. Postavili bychom proxy vrstvu, která by dotazy AI před zásahem do produkce vyčistila. To, že byl zdroj „zdarma“, nás svádělo vynechat inženýrství, které začíná přemýšlením a které definuje filozofii naší firmy.

Byli jsme tak soustředění na „průlom“, že jsme přehlédli „rozpad“. To je v dnešním trhu častý vzorec. Firmy spěchají vyřešit krizi znalostního dluhu tím, že na svá datová sila nasadí AI, a pak zjistí, že jejich infrastruktura není připravená na obrovskou „upovídanost“ aplikací poháněných LLM. AI agent data jen nečte; vyslýchá je, a to často tím nejméně efektivním možným způsobem.

Zavedení jističů

Abychom databázi zachránili, museli jsme zrušit celý Kubernetes namespace, ve kterém běžely AI workery. Byl to hrubý nástroj, ale fungoval. Když se kouř rozplynul, zavedli jsme pro jakoukoli interakci AI s databází tři nepřekročitelná pravidla, která dnes používáme u všech našich klientů:

  1. Povinnost read-only repliky: Žádný AI agent, jakkoli „bezpečný“, se nesmí připojit k instanci pro zápis. Agenti běží na izolovaných, automaticky škálovaných read replikách, kde 100% špička CPU neshodí checkout.
  2. Rate limiting na gateway podle tokenů: Postavili jsme middleware, který počítá databázová volání na každou „session agenta“. Pokud agent překročí 50 dotazů v okně 60 sekund, session se ukončí a označí k lidské revizi.
  3. Vzorec „Explain Before Execute“: Každý dotaz vygenerovaný AI musí před spuštěním projít deterministickým parserem, který kontroluje chybějící klauzule WHERE nebo JOINy bez indexů. Pokud dotaz vypadá jako úplný sken tabulky, je zamítnut dřív, než vůbec odejde po síti.

Jak velká část vaší současné „AI strategie“ stojí na předpokladu, že vaše infrastruktura zvládne nevyzpytatelné chování modelu? Pokud tyto pojistky nestavíte, neinovujete; jen čekáte, až vám kredity podpálí dům.

Kredity dál používáme, ale zacházíme s nimi jako s vysokým napětím. Jsou silné, ale vyžadují důkladnou izolaci. Vrátili jsme se k inženýrství, které začíná přemýšlením, a každé AI integraci předchází přísná mapa alokace zdrojů. Cílem není jen dodat AI; cílem je dodat AI, kvůli které nebudete ve středu ráno obnovovat data ze zálohy.


Nakonec byl grant 10 000 € levnou lekcí. Stál nás pár hodin výpadku a hodně hrdosti, ale ušetřil nás mnohem větší katastrofy v budoucnu. AI je multiplikátor, ale násobí všechno – včetně vašich architektonických chyb a nedostatku disciplíny. Pokud chcete AI dát klíče od své databáze, postavte nejdřív kolem motoru klec.

Další krok

Použijte tento článek jako checklist bezpečnosti AI automatizace. Ozvěte se DataTip.

Privacy Preference Center