Őszintén: néha már úgy érzem, hogy a QA-tól elvárjuk, hogy varázsoljon. A klasszikus definíciónk még mindig az, hogy:
„A QA ellenőrzi a megfelelést a specifikációnak.”
Ez nagyjából akkor működött, amikor a rendszerek nem úgy viselkedtek, mint egy felhőbe kidobott, önálló életet élő szürkeállomány. A monolit, determinisztikus világban volt állapot, idő, és volt értelme annak, hogy „nézzünk rá, és majd megmondjuk, jó-e”.
Na, ez ma nincs így.
A modern rendszerekben nincs egységes állapot. Pont.
Kubernetes, autoscaling, serverless, provider-managed mesh-ek… Minden olyan, mintha folyamatosan egy olyan házban laknánk, ahol a falakat néha átrendezik, néha ki is veszik alólunk, és senki nem szól előre.
A valóság:
- elosztott,
- lokálisan konzisztens (néha),
- globálisan inkonzisztens (gyakran),
- folyamatos mozgásban lévő állapottér.
És akkor valaki megkérdezi:
„De mi most miért nem tudjuk egyértelműen lekérdezni, hogy a rendszer éppen mit csinál?”
Hát… azért, mert nincs egyértelmű „most”. Nincs globális óra, nincs total ordering, nincs olyan, hogy „központi igazság”.
Ez nem QA-hiba. Ez a modern infrastruktúrák fizikája.
A QA mindig késik — mert a rendszer gyorsabb nála
Egyszer auditon a Kubernetesben kiadunk egy kubectl get pods-ot. Mire lefutott, az egyik pod már meg is halt. A bizottság kérdezi: „De hát az előző outputban még ott volt”. Persze hogy ott volt — két másodperccel ezelőtt.
A QA a saját eszközeivel mindig múltat néz:
- terraform state → múlt
- ansible inventory → régebbi múlt
- kubectl → nagyon közeli múlt, de még mindig múlt
Ebből megfelelést kimondani olyan, mintha egy sportbírónak a meccs tegnap esti videója alapján kéne ítélkeznie arról, hogy most ki rúgja a labdát.
A megfelelőségi szabványok még mindig a 90-es években élnek
Nem rossz szándékból, egyszerűen így születtek. ISO, SOC, PCI, mind feltételezi, hogy:
- a rendszer állapota stabil,
- az események időben rendezhetők,
- és mindenhol ugyanazt kellene látnunk.
Ja. Persze. Kubernetes alatt. Vagy AWS alatt, ahol a control plane néha megváltozik annélkül, hogy bárki megemlítené.
A gyakorlat sajnos:
📌 papír szintjén megfelelünk,
💻 gépileg nem feltétlen igazolható,
🤷 a kettő közé meg majd kitalálunk valami narratívát.
A felhőszolgáltatók control plane-je egy fekete doboz
A control plane nem determinisztikus, nem transzparens, és a provider kénye-kedve szerint módosítható.
Volt már olyan, hogy egy AWS szolgáltatás egyszerűen másképp viselkedett hétfőn, mint pénteken. Ticket? Release note? Bármi? Semmi.
A QA ebbe nem lát bele. Nem is láthat — mert a platform nem engedi.
Ez nem minőségbiztosítási kérdés. Ez iparági architektúra-korlát.
A klasszikus QA egy olyan rendszert próbálna leírni, amely nem definiálja önmagát
A régi feltevés:
„Mutasd a rendszer állapotát, én pedig összevetem a specifikációval.”
A gond csak az, hogy:
- nincs egységes állapot,
- nincs közös idővonal,
- nincs olyan entitás, hogy „a rendszer”.
A modern elosztott rendszerek inkább egy folyamatos, eseményekből álló felhő — nem egy szép, statikus állapotgép.
És ettől függetlenül még mindig van, aki megkérdezi:
„Jó, jó, de akkor mikor fogjuk tudni egyben látni az egész rendszert?”
Soha. Ez a lényeg. Ez a rendszer természete.
A QA nem halt meg — csak rossz modellhez van kötve
A QA ott működik, ahol:
- van stabil állapot,
- van determinisztikus specifikáció,
- a változások követhetők.
Ez ma a felhőben nincs meg.
A QA nem hibás — a környezet változott meg alatta. Gyorsan. Úgy, hogy még nem adtunk hozzá új auditálási módszertant.
Ha valódi, gépileg verifikálható QA-t akarunk:
- kriptografikusan bizonyítható állapot,
- deklaratív, globálisan konzisztens specifikáció,
- real-time event sourcing alapú auditrail.
Ezekből jelenleg sok még kutatási téma — vagy nagyon drága, ezért nekiálltam implementálni egyet.
🧨 Zárás: nem több dokumentáció kell — hanem új paradigma
A QA egy tükröt tart. A baj az, hogy a rendszer, amit tükröznie kellene, önmagában sem ad koherens képet.
Több papír, több checklista, több screenshot nem fogja ezt megoldani.
A QA-nak nem „fejlődnie” kell — hanem eszköztárat váltani:
- rendszerelméleti,
- kriptográfiai,
- eseményalapú,
- és elosztott rendszerekre szabott auditálási modellre.
Amíg ez nincs, addig minden audit csak rész-igazságot tud elmondani.
De ez nem a QA gyengesége. Ez a modern felhő-infrastruktúrák realitása — akár tetszik, akár nem.
- 183 megtekintés
Hozzászólások
öszintén ezt ha jól emlékszem cikkenek küldtem be de ide valamikor a hét végén
- A hozzászóláshoz be kell jelentkezni
Még ha nem is felhős a rendszer, akkor is igaz, amit írsz, hogy: Nincs olyan entitás, hogy "a rendszer".
Nálunk éppen két audit is folyik, egy csomó erőforrás megy el rá, de a kérdésekből ítélve esélytelen, hogy bármi olyat mondjanak a végén, amiről eddig nem tudtunk. Az "a rendszer" fogalma egy ezer+ gépes rendszerben nem definit, mert mindenki más (al)rendszert ért alatta.
Túl nagy gombócot választva nem lehet értelmesen vizsgálódni, például: készíts auditot az Internetről.
Túl kicsi gombócra meg nincs értelme lőni. Nálunk volt olyan kérdés, ami tök értelmes lett volna ha egy két gépből álló, két rétegű (frontend, backend) LAMP rendszer üzemelne, csak hát amikor százas nagyságrendben passzolgatnak adatokat egymásnak a gépek, és nem csak ez a két réteg van, akkor a túl kis gombócra kapott kérdések irrelevánsak.
Az audit papírgyár, ez van. Vagy valaki kapott már vissza olyan audit jelentést, amiben olyan javítandó és javítható hibát jeleztek neki, amiről korábban nem tudott?
- A hozzászóláshoz be kell jelentkezni
De várj csak, a QA-nak mióta kell ellenőriznie hogy a háttérrendszerek hogyan működnek? A QA alapvetően funkciókat ellenőriz hogy azok megfelelően működnek-e (az elvártaknak, a specifikációnak, vagy a józan észnek :D), de baromira nem érdekli hogy hol és hogyan fut a rendszer, az számára egy fekete doboz.
Rendszer mindig van, csak igazából ezt úgy hivjuk hogy system of interest (incose systems engineering világban), vagy ToE (target of evaluation) az ISO/CC világában. Hogy hol húzzuk meg ennek a határát az igazából a fő kérdés, mit vizsgálunk, mit nem, mi van belül, mi van kívül.
A kriptografikusan bizonyítható állapotot nem tudom értelmezni. Mit értesz ez alatt? A kriptográfiai aláírásokat lehet használni, de ez egy eszköz és számomra nem világos hogy mi a cél amit el akarsz érni és ennek mi a hozzáadott értéke?
Az ISO, SOC, PCI részt sem értem, kérlek nevezz meg egy pontos szabványt, mert az hogy ISO az egy szervezet, annak van kismillió szabványa. Konkrétan melyikre gondolsz?
- A hozzászóláshoz be kell jelentkezni