Auditálhatóság az IT-ban? A jelenlegi formájában egyre kevésbé értelmezhető.

Ő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.

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

Gondolom azért nem került ki, mert ez nem egy cikk. Az oldalidegen formázástól eltekintve is, a cikkek a hupon valami konkrétról szólnak. Ez nem az, ez valami ötletelés, nyílt végű beszélgetés. A helye a fórumon, vagy ennek speciel talán még inkább a blogban van, azért került ide gondolom. Ezekre (nem csak a tiédre, senkiére sem) nem vagyunk kíváncsiak a hírek között.

Egyébként: őszintén szólva én nem tudom, hogy jön a QA az audithoz. Én még életemben nem hallottam róla, hogy egy QA auditált volna, azt jellemzően valami szabályozás megfelelőség hatására jellemzően valami külsős csinálja. Az előfordul, hogy a szükséges dolgokat esetleg a QA csapat kénytelen valahogy megtámasztani, de az általában nem olyasmi, amit egyébként is csinálnak. A két irány jelentősen eltér egymástól mind módszertanában, mind céljában. Így meg nehéz érdemben reagálni, mert nem tudni, valójában melyikre gondolta a költő.

Classic QAs vonalon szerintem szellemeket kergetsz. Értelmes QAs nem fog konkrét podokat keresgélni, nem hülye, tudja hogy az egy ephemeral dolog. Azt fogja nézni, amit abban a rendszerben kell. Például megbizonyosodik arról, hogy azok a policyk, amik a skálázódást és környékét vezérlik, azok úgy reagálnak-e, ahogy kell, és ahogy a design az feltételezte. Ráadásul ilyen cloud infrák esetében a klasszikus QA legalább részben bevándorol a devops szemlélet miatt abba a csapatba, és elkezd a prod dolgaival is foglalkozni, pl metrikákon és hasonlókon át (ami egy klasszikus dobozos termék QAja nyilván nem csinált, mert eleve nem is volt szolgáltatás). Még ilyen mindenféle buzzanatok is vannak, hogy pl site reliability engineering, meg ilyenek...

---

Egyéb híreinkben, értem, hogy téged most mindenki bánt, és úgy érzed sehogy nincs rajtad sapka, de így tényleg nem nagyon leszel előrébb. Nem az AI a legnagyobb baj (bár a szófosásról leszoktathatnád, ez itt direkt beszélgetés, a fene se kíváncsi a doksivá habosított hozzászólásokra, meg egyébként is, szófosni itt van Raynes prof, sokkal jobb benne :) ), de amikor azzal jössz, hogy de ennyi meg ennyi prompt, és azt hiszed, hogy attól át van gondolva... newsflash, mi is szoktunk időnként hosszan gumikacsázni az AIval, attól, hogy sokáig forogsz körülötte, és építesz benne jól átgondolt (nak tűnő) részletes izét, attól még nem biztos, hogy nem légvárat építesz meg lufit hámozol. Been there, done that, csak azért mert sok, nem biztos, hogy jó is.

És hát, te azért eddig rendre a konkrét kérdések konkrét megválaszolása helyett valami túlfújt lózung heggyel jöttél, meg (mint pl lent geleinek, de az előző topicodban is) értelmes, konkrét, a kérdésre szignifikáns válasz helyett pl így belemutatsz valami chagpt közepébe, hogy hát ha ez nem elég, akkor nem tudod mi az. Nem vagy a feleségünk, a nehézség se akar gondolatot olvasni, meg hallgatni, hogy megsértődsz, hogy nem olvastuk. Tessék szépen relevánsan megválaszolni.

Az egyébként is egy jó szűrő, hogy ha nem tudod értelmes, tömören elmondani, hogy mi az alapvető különbség, az miben jobb/más mint a korábbi, a korábbi mit csinált rosszul, továbbá ha a részletekbe belekérdezést nem tudod normálisan elmagyarázni,  akkor érdemes feltenni magadnak a kérdést, hogy biztos nem egy légvárban csücsülsz-e?

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?

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?

Ezt köpte ki neki az LLM.

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

https://en.wikipedia.org/wiki/Quality_assurance
"The company-wide quality approach places an emphasis on four aspects (enshrined in standards such as ISO 9001):[28]

  1. Elements such as controls, job management, adequate processes, performance and integrity criteria, and identification of records
  2. Competence such as knowledge, skills, experiences, qualifications
  3. Soft elements, such as personnel integrity, confidence, organizational culture, motivation, team spirit and quality relationships
  4. Infrastructure (as it enhances or limits functionality)

The quality of the outputs is at risk if any of these aspects is deficient."

ISO/IEC 27001, ISO/IEC 27002,NIST CSF, NIST SP 800-53, GDPR (EU 2016/679), ITIL v4, ISO/IEC 20000, ISO 22301, COBIT (Control Objectives for Information and Related Technology), SOX (Sarbanes–Oxley Act), ISO/IEC 27034 (Application Security), OWASP SAMM OpenSSF Best Practices
ha részletesen érdekel teljes magyarázat generálással együtt 15p volt cikta 1700 sornyi szöveg keletkezett 20 hozzászólással ami kb 300 szó volt összesen....

 

Akkor most tedd már meg, hogy egyedül, önállóan is elolvasod a linkelt wikipedia oldalt, és a saját szavaiddal elmondod, hogy miért kellene a QA-nak az auditálással foglalkozni. Meg úgy általában, lassan elkezdhetnél önállóan is írni dolgokat, meg megtanulni, hogy hogyan is kell ezt.

Nekem az a benyomásom, hogy az általad felvetett témák téged valójábna nem érdekelnek részletesen, hanem interakciót akarsz farmolni, isten tudja mi okból. Ugyanis ha érdekelne az adott téma, akkor egyrészt

  • körbejárnád magadtól, megpróbálnád megérteni, mi a fenéről írsz, és nem sütne az egész írásodból a fogalom nélküliség
  • képes lennél egy 4 mondatos blogposztban megfogalmazni a saját gondolataidat AI bevonása nélkül

Fogalmam sincs, mit csinálsz a való életben, de ha az én kollegám lennél, már lenémítottalak volna Slacken. Bocsáss meg, de katasztrófa amit itt művelsz, sokadjára mondjuk el, hogy mit kellene, sokadjára talál ez süket fülekre.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Megint egy AI generált fostenger.

ha fostenger hajár bizonyítsd be reprodukáld legalább a számokat 30 hozzászólásból (amiből érdemi 13 ami a generálást végezte) készült a minimum 1000 sornyi dokumentáció vagy fostenger....
hogy hogy készült:
ha részletesen érdekel teljes magyarázat generálással együtt 15p volt 

ha nem elég van kérdésed a theaddel kapcsolatban nyugodtan elmondom hogy készült el ez a fostenger .....

 

nyugodtan elmondom hogy készült el ez a fostenger .....

Elővetted a ChatGPT-t, úgy. Ez nem a kutatás definiciója.

eprodukáld legalább a számokat 30 hozzászólásból

A kutatás mértékegysége nem az, hogy hány promptból áll össze, hanem hogy te magad, a kis humán agyaddal meg kezeddel hány órát teszel bele a kutatásba. 

Istenem, te nagyon el vagy tévedve. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Az előző posztok is értelmetlenek voltak (sehol egy referencia a CIC -re, stb., csak szófosás).
Volt már hasonló itt akkor valami banki károsultakkal kapcsolatban ment a polémia, a stílus ott is nagyon hasonló.

Egy idő után már az ingerküszöböt se fogja elérni az ilyen topic.

Nem gondoltam volna, hogy hajbi zavaró, de őszínte elköteleződése pár generációval előbbi oprendszer(ek) iránt sokkal jobban elfogadható, mint ez a fenti szösszenet.

...úgyis jönnek...

Hja. Hajbinak legalább van saját szókincse, saját gondolatai, és részigazságai is, még akkor is, ha úgy egyébként amit képvisel, működésképtelen is, és nem LLM generálja szövegeit. 
Itt van ez a CIC vagy miafene, klasszikus elérettentő példa az AI slopra:

https://github.com/CentralInfraCore

 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

kisjoco mond már meg:
- hogy a bú bánatba készült el tegnap a használhatatlan toolokkal a postgresql 14,15,16,17,18 beállításához szükséges schema leírások kb sémánként laza 2e sorral? 
- hogy a bú bánatba lehet elérni hogy csak a repoból és a repohoz tartotó publikus kulcsal meg tudd mondani ki a fasz csinálta ezeket a commitokat és releaseket... tudom te még azt mondod jó az ha valaki a nevedbe kommitol és teljesen elfogadható, de én ezt nem vállalom fel
- hogy a bú bánatba tudod megmondani hogy az adott schemalírás az eredeti vagy valaki belekontárkodott
- hogy a bú bánatba lehet több repoban azonos kommit azonosítókat látni és miért is van az úgy
- hogy a bú bánatnak van dependency.yaml a gyökér könyvtárban
- hogy a bú bánatba generálta a szerző ezt a mennyiségü küdot úgy hogy még valamennyire talán működik is 
- mi is az a yang amiről reggel dobott be egy forumtémát 

ha ezekre az a válaszod hogy AI akkor érd el egy üres promptba hogy ezt igy ahogy van vagy jobban megkapd vagy hajrá ügyes 1 napod van az 5 postgres séma megvarászásához úgy hogy tudod mit miért és hogyan készült.... teszteld magad és ahogy szokták mondani p... alap
 

valamennyire talán működik is 

Tudod, anyám lakásában a konyhában van egy óra a falon. Sajnos egy ideje már elfelejtek benne elemet cserélni. Mégis, napi kétszer nagyon pontos időt mutat, azaz valamennyire működik. Hogy mennyire, az persze már képezheti vita tárgyát, elismerem.

- hogy a bú bánatba lehet elérni hogy csak a repoból és a repohoz tartotó publikus kulcsal meg tudd mondani ki a fasz csinálta ezeket a commitokat és releaseket... tudom te még azt mondod jó az ha valaki a nevedbe kommitol és teljesen elfogadható, de én ezt nem vállalom fel
[...]
- hogy a bú bánatba lehet több repoban azonos kommit azonosítókat látni és miért is van az úgy

Fogalmad sincs a Git működéséről, ugyebár? Miért is lenne, hát abba is időt és energiát kellett volna belefeccölni. Az a baj, hogy ha elkezdenénk ezeket mondani, a felét meg se értenéd, mert az AI nélkül képtelen vagy értelmezni a dolgokat. Arról meg főleg nincs, hogy mondjuk egy repository szerver hogyan működik, milyen authentikációval, a publikus kulcsok működése pláne rejtély... és még sorolhatnám.

Bocs, de úgy támadsz dolgokat, hogy a felét maximum képen láttad, a másikról valami olyasmi világosított fel, aminek a szakmai hozzáértése a nullához konvergál - alulról -, és valószínűleg mivel ötleted sincs a rendszer működéséről, ezért még rossz kérdéseket is tettél fel neki.

A jó és eredményes AI promptolásnak ugyanis elengedhetetlen feltétele az adott szakterület mélyreható ismerete. Persze, az AI minden promptra ad valamilyen eredményt - ahogy a konyhai óránk is mutat valamilyen időt. És egyébként minden egyes alkalommal, amikor ránézek, valahol a Földön tényleg ennyi az idő.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

A QA arról tud szólni hogy "mi ezt-és-ezt leteszteltük rajta és jónak gondoljuk a diffet".
Azt majd az "élet megmutatja" hogy tényleg jó volt-e? Ha mindenről mindig előre tudnánk hogy jó vagy rossz akkor sose semmilyen bug nem tudna kimenni élesbe, márpedig kimegy ...
Ha nem volt jó akkor majd csinálunk olyan tesztet amitől majd legközelebb ugyanezt a hibát nem követjük el.

Az audit pedig arról szól hogy "minden változásról tudunk". 

Ezt review-nek hívják, és mindenhol van/kell hogy legyen. A DevOps alapvetően eszközket ad, de az eszközök emberi review folyamat nélkül képtelenek eldönteni, hogy az adott diff jó-e, tényleg az kell-e oda. Mi csak arra tudunk eszközkészletet adni a fejlesztőknek, hogy a tesztek lefussanak jól, a buildek lefussanak jól, a release-k lefussanak jól, és a jól definiált workflow folyamatok a megfelelő kondíciók mellett a megfelelő reakciókat adják. Ééés ennyi.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Abban igazad van hogy egy jó DevOps-os valahol QA is de azért eléggé specifikussá vált ahhoz, hogy egy általános DevOps-os ne tudjon minden QA feladatot ellátni... még az infrával kapcsolatban sem. Mivel gyakorlatilag annyi feladat van már egy kis cégnél is QA szinten az adminisztrációval hogy 1 ember munkáját felemészti (ha komolyan veszi a szabványokat és nyugodtan akar aludni hogy ne birságolják meg)...
Az ISO auditokat mindenki laza válránditással vette mivel ha elvesztette őket akkor max egy új audit várt rá, de mivel fizettek az auditor cégnek megbukni egy ilyen auditon eléggé nehéz volt... viszont bejöttek a kötelező elemek NIS2 és a többiek ezen ha megbux a gatyádat ki fogod fizetni... és megbukni már az apróságoktól meg tudsz... hatósági ellenőrzésről meg nem is beszéljünk.

subscribe, bár már az előzőben is megbántam, hogy belefolytam

őszintén szólva a felsorolt problémák nagy részével gyakorlatilag nem találkoztam, pedig gigantikus méretű cloud környezetünk van, mindhárom nagy providernél

van valami konkrét példa, hogy az aws mikor csavarja át a live rendszert, anélkül, hogy szólna róla? vagy ez ilyen hipotetikus eset?