Kihagyás és továbblépés a tartalomhoz

DevOps és infrastruktúra AI-val

Ugyanaz a modell, amelyik a Python-feladatok 86%-át megoldja, az infrastruktúra-leíró feladatoknak alig az **ötödét**. És van egy mérés, ami 14%-ról **93%-ra** vitte fel az eredményt — a 79 pontos javulásból **48,9 pont** a behúzott dokumentációból, a promptszerkezetből és a szkenner visszajelzéséből jött, **21,5 pont** a modellváltásból, **8,6 pont** pedig abból, hogy a modell **látta a szabályt**.
2026. szeptember 13. által
DevOps és infrastruktúra AI-val
Krisztian Eyssen, Krisztian Eyssen

A szám, amivel kezdeni kell

Egy lektorált, 458 valós forgatókönyvet tartalmazó mérésben egy erős modell az infrastruktúra-leíró feladatok 19,36%-át oldotta meg elsőre. Ugyanaz a modell egy bevett Python-feladatkészleten 86,6%-ot ért el.

Nem a modell lett hirtelen buta. Az infrastruktúra más feladat: itt nem az a kérdés, lefut-e, hanem hogy mit enged meg.

Két további, 2026-os mérés ugyanoda mutat:

  • 153 valós feladaton hat élvonalbeli modell 20,8–30,2%-os arányban tudott elsőre sikeresen telepíthető konfigurációt adni — és a bevett megfelelőségi szabályok szerint mindössze 8,4% volt szabálykövető.
  • Egy 17 modellt vizsgáló mérés szerint a modelleknek a HCL szintaxis nehezebb, mint a YAML vagy a JSON.

Az emberi kódhoz képest 3–4-szer sűrűbb a hiba

Van egy vizsgálat, ami pontosan azt csinálja, amit kellene: 1 196 géppel generált infrastruktúra-leírót hasonlít össze 634 ember által írt sablonnal, három független szabályellenőrző motorral.

Méretre igazítva minden vizsgált beállításnál a generált konfiguráció sérülékenységsűrűsége az emberinek 3,21–3,87-szerese.

És van benne egy ellentétes intuíciójú részlet: a különbség egyetlen erőforrásnál 4,9-szeres, húsz vagy több erőforrásnál viszont csak 1,4-szeres. Vagyis a rövid, gyorsan bekért részlet a veszélyesebb, nem a hosszú, átgondolt konfiguráció. Pont az, amit az ember a leggyorsabban bemásol.

(A „bővített gondolkodású" beállítások nagyjából 12%-kal jobbak a standard generálásnál — segít, de nem old meg.)

Attól, hogy lefut, még nyitva lehet

Ez a legfontosabb gyakorlati megkülönböztetés az egész cikkben.

Egy 2026-os mérés hét modellt vizsgált tizenhét forgatókönyvön, két szabályellenőrzőt bekötve a folyamatba. Az eredményekből két szélsőérték:

  • Az egyik nyílt súlyú modell 77,8%-os érvényességi arányt ért el — vagyis a konfiguráció szintaktikailag rendben volt, a parancs lefutott. Megfelelőségi arány: nulla.
  • Egy erős zárt modellnél az egyik ellenőrző szerint 23,1%, a másik szerint 92,5% volt az átmenő arány — vagyis maga az ellenőrző választása is döntő.

A tanulmány következtetése szó szerint: „a promptolás önmagában nem elég: az automatizált, többeszközös szkennelés továbbra is szükséges kiegészítő."

Magyarul: az érvényességi ellenőrzés lefutása nem biztonsági bizonyíték. Egy teljesen nyitott tároló ugyanúgy érvényes konfiguráció, mint egy zárt.

A négy hibaminta, ami visszatér

Generált infrastruktúra-leírókban ugyanaz a négy dolog jön elő újra és újra:

  1. Megengedő alapértelmezések — helyettesítő karakteres jogosultságok, publikus hozzáférés.
  2. Hiányzó biztonsági blokkok — titkosítás, naplózás egyszerűen nincs benne.
  3. Beégetett hitelesítő adatok.
  4. Elavult mintázatok — kivezetett szintaxis, verzió nélküli lemezképek.

Egyik sem „hiba" abban az értelemben, hogy elszállna tőle valami. Mind a négy csendben működik — pont addig, amíg valaki meg nem találja.

A mérés, ami 14%-ról 93%-ra vitte

Ez a cikk gyakorlati magja, és az eredménye annyira erős, hogy érdemes végignézni.

Egy 2026-os vizsgálat 186 feladaton háromlépcsős ellenőrzést épített be: érvényesség → tervezett változás → szabályzat-kiértékelés. Aztán lépésenként hozzáadott egy-egy elemet:

Mit adtak hozzá Sikerarány elsőre
Alapállapot, kis nyílt modellel 14,0%
+ a releváns dokumentáció behúzása 45,7%
+ optimalizált prompt szerkezet 53,2%
+ iteratív finomítás a visszajelzésből 62,9%
ugyanez erős modellel 84,4%
+ a szabályzat szövege a promptban 93,0%

És a kulcsmondat: „a finomítás utáni megfelelőségi hibák 79%-a információhiányból fakad, és feloldható, ha a szabályzat szövege látható."

Vagyis a megfelelőségi hibák négyötöde nem képességhiány, hanem az, hogy a modell nem ismerte a szabályt.

A gyakorlati recept ebből egyenesen következik: ne a promptot csiszold — tedd be a szabályzat szövegét, és kösd be a szkennert a körbe. A 14-ről 93 százalékra ugrásból 21,5 pont valóban a modellváltásé — a maradék 57,5 pontot a behúzott dokumentáció, a promptszerkezet, az iteratív kör és a szabályzat szövege adta, és az utóbbi a legerősebb modell alatt is hozott még 8,6 pontot.

AIOps: jól olvasható, közepesen pontos

Az incidenskezelés a másik terület, ahol nagy az ígéret. Erről a legjobb mérés egy nagy felhőszolgáltatótól származik, és szokatlanul őszinte.

Az adat: nagyjából 180 ezer magas súlyosságú történeti incidens, a tesztelés 2 900 valós incidensen. A gépi kiértékelés szerint az optimalizált promptú modell 21%-kal jobb, mint a kézi alapvonal.

De a lényeg az emberi kiértékelésben van, 47 ügyeletes mérnök véleményében:

Mit értékeltek Pontszám (1–5)
Pontosság 2,91
Olvashatóság 4,21

Ez a legveszélyesebb kombináció, ami létezik. Az ügyeletes mérnök hajnali háromkor egy meggyőzően megfogalmazott, jól tagolt, félig-meddig helyes összefoglalót kap. Nem azt látja, hogy bizonytalan — azt látja, hogy magabiztos.

Riasztászaj-csökkentésre és javítási idő rövidülésére nem találtunk független, módszertannal közölt mérést. Ami van, az gyártói ígéret.

Amit viszont mérnek: az AI maga is incidensforrás

Egy megbízhatósági elemzés 177 960 státuszoldali bejegyzést dolgozott fel 2018 és 2026 júniusa között:

Mutató 2023 2026
AI-szolgáltatóhoz köthető incidens 1,7% 10,7%
AI-jellegű hibamód a besorolt incidensekben 0,5% 5,1%
„AI-kimenet minőségromlása" mint hibaok 1,3% 6,3%

Ugyanitt: a harmadik feles, beszállítói incidens az összes több mint negyede, és a medián elhárítási ideje 247 perc — szemben a saját hibák 96 percével. Amit nem te üzemeltetsz, azt nem te javítod.

Konkrét, dokumentált esetek: egy agent lefuttatott egy infrastruktúra-megsemmisítő parancsot, és 1,94 millió adatbázissor veszett el; egy törlés-újralétrehozás stratégia 13 órás kiesést okozott; egy másik esetben „az éles adatbázis és az összes mentés törölve egy 9 másodperces API-hívásban".

És a másik oldal: ugyanez az eszköz oldott meg egy kiesést

Az egyensúly kedvéért érdemes egy nyilvános utóelemzést is megnézni 2026 márciusából.

Az ok-lánc klasszikus: egy folyamatos integrációs versenyhelyzet kihagyott egy build lépést, emiatt hibás artefakt-hozzárendeléssel futott le a telepítés, és a szolgáltatás nyolc órán át nem fogadta be az adatokat.

És itt az AI nem az ok volt, hanem az eszköz a felderítéshez. A cég saját monitorozó agentjei jelezték a hibát, majd — a saját leírásuk szerint — egy kódoló agentre irányítva a hibariportot, felhő- és verziókezelő-hozzáféréssel megtalálták az elromlott telepítést, újraépítették a lemezképet, és újrafuttatták a telepítőszkripteket.

A következtetésük pedig az volt, hogy több jogot adnak az agentnek, nem kevesebbet.

Ugyanaz a technológia okoz kiesést máshol és old meg kiesést itt. A különbség a jogosultságok határában és a visszafordíthatóságban van.

A munkamenet

1. A SZABÁLYZAT SZÖVEGE A PROMPTBA.
   A megfelelőségi hibák 79%-a információhiány.
   Nem a modell nem tudja - nem ismeri a szabályodat.

2. SZKENNER A KÖRBE, NEM UTÁNA.
   Generál -> szkennel -> visszakapja a hibát -> javít.
   A kör nélkül a szkenner csak jelent, nem javít.

3. TÖBB SZKENNER, NE EGY.
   Ugyanarra a konfigurációra az egyik 23%-ot, a másik
   92%-ot mért. Egy eszköz nem elég.

4. AZ ÉRVÉNYESSÉG NEM BIZTONSÁG.
   Volt olyan modell, ami 77,8%-ban érvényes konfigot adott
   NULLA megfelelés mellett.

5. A RÖVID RÉSZLET A VESZÉLYESEBB.
   Egy erőforrásnál 4,9x, húsznál 1,4x a sérülékenységsűrűség
   az emberihez képest. A gyorsan bemásolt snippet a rossz.

6. VISSZAFORDÍTHATATLAN MŰVELETRE NINCS AUTOMATIKUS
   JÓVÁHAGYÁS. Törlés, megsemmisítés, éles adatbázis:
   ember, minden alkalommal.

7. A GÉPI INCIDENSÖSSZEFOGLALÓ HIPOTÉZIS, NEM DIAGNÓZIS.
   Olvashatóság 4,21/5, pontosság 2,91/5.

Tipikus félreértések

  • „Lefutott az érvényességi ellenőrzés, tehát rendben van." Volt modell 77,8%-os érvényességgel és nulla megfelelőségi aránnyal.
  • „Egy szkenner elég." Ugyanarra a kódra két eszköz 23%-ot és 92%-ot mért.
  • „A hosszú, bonyolult konfiguráció a kockázatos." Fordítva: a különbség egyetlen erőforrásnál a legnagyobb.
  • „Jobb modellel megoldódik." Az erősebb modell sokat hoz — a mérésben 21,5 pontot —, de nem old meg mindent: a megfelelőségi hibák négyötöde információhiány, és a legjobb modell alatt is a szabály szövege adta az utolsó 8,6 pontot.
  • „Az AI-incidensösszefoglaló megmondja, mi a baj." Jól olvasható, közepesen pontos — és pont ettől meggyőző hajnali háromkor.

Amit érdemes elvinni

Az infrastruktúránál nem az a kérdés, lefut-e a konfiguráció, hanem hogy mit enged meg — és ebben a generált kód mérhetően rosszabb az emberinél. A javulás viszont nem egyetlen lépésből jön: abban a mérésben, ami 14%-ról 93%-ra vitte az eredményt, a 79 pontból 21,5 pont jött a modellváltásból, a többi a behúzott dokumentációból és a körbe kötött szabályzatból és szkennerből. A visszafordíthatatlan műveletekre pedig maradjon ember a körben — a dokumentált kieséseknek pontosan ez az egy közös vonása.

Az agent jogosultságainak beállításáról a kódolás három módja poszt szól; a tágabb biztonsági képről pedig az AI-kód biztonsági számlája poszt.

DevOps és infrastruktúra AI-val
Krisztian Eyssen, Krisztian Eyssen 2026. szeptember 13.
Poszt megosztása
Archiválás