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

HUP cikkturkáló

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

  • 728 megtekintés

( sinkog | 2025. 11. 19., sze – 09:41 )

ö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?

Bocsi tanulom az oldalt és az előnézeti képben jól nézett ki nem így.... de majd csak sikrül valahogy megoldani.

kiemelek egy két szót: értelmes, megbizonyosodik.... ez mind a bizalomról szól és arról hogy te oldaladon áll az illető NIS2 audit vagy főleg az ellenőrzés már nem erről fog szólni hanem a tényekről és amit bizonyítani tudsz a többi meg az ellenőr hozzáállása amire én nem alapoznák...

megnézted a prompot amit betetem, belegondoltál az előállításába... és igen mi a véleményed miért vagyok itt? részint hogy átadjam azt amit megcsináltam részint hogy ellenőrizzem hogy légvár-e vagy sem. Jelenleg keresem még mindig a lehetőséget, hogy azt amit összeraktam(AI-ztam) átadjam és ezáltal kiderüljön hogy tényleg légvár-e vagy csak a szokásos ellenállás az újtól. Szépen relevánsan válaszolgatok, igaz nem ismerlek igy esélyes a pontatlan válasz... ami légvárat eredményez.

miben jobb szerintem mint a jelenlegi rendszerek:
- az elvárt állapot mely egy IaC-ben van deffiniálva és a state állapot mind git-ben van tárolva de külön külön branch-en de azonos struktúrában azaz diffelhetően.
- a state branch-ben leírt állapot megegyezik az figyelt paraméterek állpotával (mintavételezés mikéntje függvényében időeltolódás lehetséges) melynek frissítése notify alapu
- a CIC minden adatforgalma layer7 szintjén cert-rel vagy titkosítva vagy aláírva van az adattartalom kb 2 oldalba leírva a működés... state branch-re is átmegy ez az aláírás
- minden modulba belépő adat verziótott schema validáción megy át igy a modulba csak valid adatok érkeznek és következményképpen gyakorlatilag maga az IaC is validálható rekurzivan a sémákkal (pre process-ként)

Ezek az alapok a többi csak következmény és kifejtés.
Nem mondom hogy nincs rá szabályok alapján megoldás, de azok szabályok amiket vagy betartanak vagy nem... itt az is benne van ha nem tartják be. a Git miatt nem log analizálás megy hanem látszik mikor mi változott. (szűrési feltételek jóval kevesebb keresgélés stb) 

ha arra az ISO-s válaszomra gondoltál én konkrétan megválszoltam milyen szabályozókban ad segítséget a CIC. Ennék konrkétabban nem tudom felsoroltam őket, aki meg több infó kell az olvassa le amit csináltam hozzá. Az hogy faszság az egész erre mit mondhatok? Vagy 1 hónappal ezelőtt félretett py elemezgett amikor ugyanabban a repoban benne van a friss verzió, miért szar az py? részint mert félkész részint mert működött és nekem megfelelt az amit csinált akkor is ott... 
Nemcsak itt validálok... személyes jobban meg, vagy csak álarcokat látok :D pl: egy prof javasolta, hogy kezdjem el terjeszteni a CIC-et itt a közösségben (őt látszólag meggyőzte az anyag és a beszélgetés)...

ui: nem érdekel a sapka, nem érdekel mekkora meló... mindenki véleményét meghallgatom, elolvasom és 100%-alékban elfogadom hogy adott pillanatban azt akarta mondani amit mondott/irt..

( YleGreg | 2025. 11. 19., sze – 10:57 )

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?

( sz332 v | 2025. 11. 19., sze – 11:34 )

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-

Minőségbiztosítónak miért kell a cég minőségét auditáló szervezettel foglakoznia.... MINŐSÉG szó nem üti meg a füledet? Minden ellenőrzésen amin részt vettem azt ellenőrizték az auditok hogy azon vállalásokat amik le vannak írva a dokumnetációkban betartják-e, ebben benne vannak a munkafolyamatok és biza ha ITSec oldalról nézzük a sérülékenységvizsgálatok is... és igen mi köze a minőségbizosítónak az infárhoz... a felsorolt szabványok szerves részét képezi az infrastuktúra leírás is melynek a minűségét illene ellenőrizni... nemcsak azért mert az 5 éve működő szerver működik-e... kb olyan mint amikor megkérdezném tőled miért kell menteni a szerver adattartalmát... úgyis redundáns minden, kell? 

Nem nem vagyok képes blogportban megfogalmazni a saját gondolatimat AI nélkül, vagy nem biztos hogy akarom.... de ha úgy gondolod hogy az AI blog post volt :D tévedsz 5x újraírt régi jó word-del ellenőrzött post lett egy jóóóó hosszú AI beszélgetés elemzés végén melyben a yang hálózatleképezési rendszer megismerése és integrálási lehetőségeiről folytattam... volt végeredmény, engem meggyőzőtt, de kiváncsi voltam a véleményetekre is, de ezek szerint a téma számotokra nem érdekes... vagy ismerethiány vagy prekoncepciók miatt ha jól értem....

Az itt a gond hogy képtelen vagy értelmesen, saját szavakkal összefoglalni a problémát amit meg akarsz oldani. Lehet hogy teljesen valid a probléma feltevésed, de egyszerűen olyan szintű katyvasz amit írsz hogy abból nem értjük meg hogy mi a gond, mi az ami fáj, mi a probléma, és hogy ez tényleg valódi/valós probléma-e, nem beszélve arról hogy amit megoldásként tálalsz, az tényleg, valóban megoldja a problémát, és ha igen, akkor hogyan.

Végigolvastam az LLM beszélgetést és sejtem hogy mi az a probléma amit meg akarsz oldani, de a te feladatod az, hogy világosan, mindenki számára érthetően el tudd magyarázni. Ha ezt nem tudod, akkor nem csak hogy nem érted a problémád, de valójában nem is fogod tudni átadni/eladni. 

Az ember fia próbálkozik és tudom nagyon jól hogy ez a rész nekem nem adatott meg olyan jóra mint egyeseknek. Két fő dolog indított el ennek a fejlesztésen:
1.  kerestük azt hogy mikor változott meg egy paraméter a renszerben és mi/ki változtatta meg (airgrabbad volt és érzékeny adatokkal tömve)
2. nem szerettem volna tudni mint a rendszer atyaúristene (rootja) hogy milyen adatok vannak alattam még a lehetőségét is ki akartam küszöbölni hogy a tényleges adathoz hozzá tudjak férni viszont a belső debug információk kellettek

( gabrielakos v | 2025. 11. 19., sze – 12:55 )

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-

Nem fogom megmondani mennyi időt áldoztam erre de nem egy hétvégét. Kaptatok promptot melyben benne van az anyag amit létrehoztam tegyétek fel ott a kérdést mennyi idő alatt lehet ezt összehozni 1 embernek vagy milyen csapat hozhatta létre és hogy lopott-e a tartalom, vagy AI által generált-e és nem egy file hanem az egész tartalom egybe... megtetted, vagy lementetted az anyagot és elemezted a kis kacsóddal? 
Hány helyen láttál olyan adatszerkezetet ami fel van töltve a prompt-ba? Hogy is tud ebből dolgozni az a szájbatekert AI... el tudod magyarázni? Tudod mit jelent az hogy osztott kontext? Tudod mekkora szopás ha verziót vált az AI és mindent 0 ról kell feltanítani ... meg tudod csinálni? El tudod-e érni, hogy feltöltesz neki anyagot és abból válaszoljon úgy hogy nem fantáziál? Tudod milyen alapértelmezett RAG képzése van az AI-nak amit használsz? El tudod-e érni hogy az AI-ba meg tudjál bízni.... és hogy validáliálod hogy nem tévedsz... én személy szernit rohadtul nem bizok meg benne, de jobb a találati aránya konkrét kérdésre mint a google-nak és gyorsabb...

Igen el vagyok tévedve, egy személyeskedő csapatba tévedtem abba a hiszembe, hogy szakmailag nyitotak a beszélgetésre/vitára

ui: szememre veteték hogy nem konkrétumokat válaszolok, de baszus egy elmélet egészen addig csak filozófia mig nincs bizonyítható termék PoC és ezt a tézis is csak falrahányt borsó

Kiváncsi vagyok a feltett kérdéseimből hányra fogsz válaszolni?

( fairlane | 2025. 11. 19., sze – 13:25 )

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-

ezek szerint feleslegesen linkeltem be a wikipedia oldalt... QA azért felel hogy az a termék amit a cég értékesít akár szolgáltatás akár termék előállítása a vállalásnak megfelelő minőségben kerüljön ki a cégtől. Ebben minden rész benne  van nemcsak a programozás de még majdnem a könyvelés is... amiről te beszélsz általában vezető programozók dötik el

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.

( gelei v | 2025. 11. 19., sze – 14:22 )

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?

Ebből minden kiderül, ami ránk tartozik - semmi. Főleg azért, mert külsősöknek a canvas (és nem kanvasz - az valami betegség?) nem látható.

Menj a fenébe az AI-s slopjaiddal komolyan.

Blog | @hron84

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

via @snq-

hát izé észrevettem és az utolsó cirka 1000 sor ami a kanvasokban van tudod "kiirnád a c1 tartamát" de a végén márcsak "igen " volt a válaszom -> ha hallgattál volna nem derült volna ki hogy biza első pillanatban feladod... hidd el első körben ellenőriztem hogy hát ja fizetés nélküli chatGPT nem tudja olvasni a kanvast -> kiirattatam őket szépen sorba... na jó a tartalomjegyzék azt hiszem kimaradt
canvas legyen :P
ui: kösz legalább valalki ránézett

Engem továbbra sem az AI szófosás zavar, az legfeljebb egy szükséges rossz, hanem hogy nem értem, mi a valódi probléma, amire eddig nem volt megoldás, de a CIC már megoldja.

Ez én szakmai élményeim nyilván nem reprezentatívak, de soha nem kellett érdemben olyannal foglalkozni, hogy release notes nélkül átalakult az AWS, meg mittudomén. Ezek az eddigi karrieremben nem létező dolgok voltak. Lehet, hogy koncepció szintjén előfordulhat ilyen, oké, feladom, hiszek neked, de a gyakorlatban eddig nem volt ezekkel gondunk.

Egy ilyen toolset nulláról bevezetése nálunk a cégnél dollármilliók, esetleg dollártízmilliókban lenne mérhető a cloud footprintünk mérete miatt, és hiába rágom végig a rengeteg kommentet, AI slopot, github repót, anyámkínját, még mindig nem tudnék odaállni a főnököm elé, és elmondani neki, hogy X problémánk van, arra pedig Y lenne a megoldás.

Ennyi. Ez nem értékítélet, hanem egyszerű pragamatizmus. Lehet, hogy tényleg a te ötleted lesz a világmegváltás az IaC területen, de amíg nekünk nem old meg semmilyen konkrét problémát, addig erről csak filozofálni tudunk.

Mit tudok ehhez hozzátenni... szimplán elméletben... ha megvan a megfelelő modulok halmaza akkor a bevezetés folyamata a következő: megadod az elvárt állapotban a kiindulási objektumot (AWS account) és innentől az elvárt állapotod mellé kapásból megkapod a objektum összes paraméterét és felügyelt objektumjait a state branchen amit megnézel és azt mondod jó és átpakolsz az elvárt állapot branch-ére és ha bátor vagy az egész rendszert igy rekurzivan fel tudod térképezni... közben ha olyan obj van melynek nincs az adotthelyről elérhetősége beteszel az elvárt állapotba egy relay-t ami mint a gráf végén csücsülő végrehajtó folytatja mondjuk a szolgáltatások feltéképezését. Ez mivel a lisencfeltételek olyanok amilyenek totál ingyenes max a relay-ek erőforrásáért fogsz fizetni ami minimális még egy nagyobb rendszer esetében a rendszerhez képest... ha meg nem egy repoba akarod tenni az egész struktúrát hanem többe akkor meg $ref-el átirányítod a másik repora az  adott ág fokuszát -> gyakorlatilag a bevezetési költség innentől nem tétel és még tesztként is rentábilis és mivel jelen esetben az objk nagy részét ro--ként kezeli nincs kockázata sem....

mit nyersz ezzel gyakorlatilag az átláthatóságon kivül szinte semmit, csak a garantál környezetben tesztelt és fordított binálisokat, melyek az open világhoz képest nagyságrenddel pontosabban dokumentáltak és saját környezetben reprodukálható a buildjük, ráadásul jóval kisebb átláthatóbb kódbázissal (mivel a modulok csak és kizárólag schema leírók alapján validált adatot kapnak), a schemak/modulok/workflow-k gyakorlatilag minimum évenkénti frissitését... de mivel a fordítási környezet totál automatikus ezért döntés kérdése a build kiadása, renovate-vel támogatott frissítési lánc melyben pontosan tudod mit kell változtatni az IaC-n hogy a működés megfelelő legyen... 

ezek mind következmények abból amit eddig leírtam és nem hidd el nem fejeztem be és ha jól megnézed AI mentes a tudás amit most átadtam
 

( n.balazs v | 2025. 11. 19., sze – 21:18 )

Ez egy digitális szemét, amit itt művelsz.

( sinkog | 2025. 11. 19., sze – 21:58 )

Számotokra nem egyértelmű hogy mit ad az adott specifikáció milyen előnyökkel jár:

  • schema leírók kikényszerítése:
    • mindig csakis valid adatokat kap a modul -> a kód tisztább a hibakezelések nagy része kikerül a kódbázisból kevesebb pontosabb teszt
    • schema leírásból generálható az api dokumentációja -> gyakorlatila automatikusan előállitható az api leírása
    • verziózás miatt a változások nyomonkövethetőek igy az esetleges és szükséges javítások jobban átláthatóbbak és ráadásul nemcsak egy verzió váltás esetén -> dokumentáció olvasgatás helyett csak egy diff nézés lesz
    • api tesztek ellenőrizhetősége nagyságrenddel megnő a modul irányti bizalom gyakorlatilag mérhetővé válik
    • minden hibás belső adatáramlás kapásból látszik
    • template-ek
    • konfigurációból eredő hibák gyakorlatilag azonnal a telepítés elő validálásakor kiderülnek
  • OpenIntentSign mit add nekünk:
    • minden csomagról tudjuk ki adta fel és ha az a beállítás azt is hogy milyen helyen van a feladó a kapcsolati gráfban (egydimenziós merker tree)
    • mivel minden mondul minden host rendelkezik egyedi cert-tel a feladó összepárosítható az adott host szolgáltatásaival
    • alap értelmezetten sign a beállítás de nem okoz gondot az adattartalom titkosítása sem
    • minden kéréd minden adatsomag magában hordozza a jogosultságkezeléshez szükséges információkat
    • minden build minden commit az ököszisztémában jelenlévő fejlesztőhöz köthető
    • leállás nélküli rootCA évenkénti csere az ökoszisztémában
    • időben nem korlátos validáció
  • workflow-k miatt
    • ha igény van rá merker tree szintű folyamatvalidáció
    • könnyen egyedivé lehet tenni egy-egy folyamatot új workflowk építése...
  • relay miatt
    • minden adatfelhasználás előtt alidáció történik (autenticitását, integritás ellenőrzés, schema validálás....)
    • wasm modulok workflow-k miatt gyakorlatilag mindenre is lehet használni
  • Központi ellenjegyző alaáírás miatt
    • minden komponensről tudható hogy a specifikációjában szereplő schema leírások alapján tesztelt és a megfelelő szintet elérte a tesztek alapján
    • minden szereplő az ökoszisztémában lekövethető

hirtelen ennyi számomra evidens következmény jutott eszembe AI nélkül... na jó két szót kérdeztem tőle "autenticitását, integritás" pontosabban rákérdeztem :P és ezek CSAK a direkte következmények az hogy ezek miket fognak indikálni inkább kihagyom mert megint azt mondjátok hogy fosom a szót