HWSW podcast!

Ennyit az atomtámadást túlélő internetről (weekly #74)

· PT48M6S

Összefoglaló

A HWSW podcast 74. adásában Kohi Tamás és Számi vendége Korom Gergely DevOps Cloud Engineer. Az adásban a felelősségmegosztásról és az automatizált tesztelési folyamatok fontosságáról esik szó, különös tekintettel azokra a helyzetekre, amikor egy harmadik féltől származó…

Röviden

Műsor
HWSW podcast!
Megjelenés
2025. 11. 28.
Hossz
48 perc
Témák
devops, cloud engineering, automatizált tesztelés
Átirat
Az epizód beszélt szövege alapján indexelve

Ebben az epizódban

Az az alkalmazás, amit futtatunk, lehet, hogy fut azbe, az AVS-nél van valami baj, de egyébként az AVS-ben lévő valamilyen apit vagy szolgáltatást használja a mi alkalmazásunk, tehát hiába fut az eszure, az AVS-ben lévő probléma, akkor is hatással lesz rá.

Tehát és és szerintem ezt nagyon nehéz megállapítani, és sokan nem tudják, hogy valójában az alkalmazásuk az milyen kitettségeknek van, tehát milyen buktatói vannak, vagy hogy mondjam.

Tehát ezt még lehet, hogy ők se tudják, nem ismerik pontosan.

Ez itt a HVSV podcast sorozatának 74. adása.

Engem Kohi Tamásnak hívnak, és itt van ezúttal is velem Számi a stúdióban. >> Sziasztok! >> Valamint visszajött ide a stúdióba hozzánk Korom Gergely DevOps Cloud Engineer, aki most egyé új projektbe kezdett belető.

Ugye téged a hallgatók már a a pénztáros DevOpsopsos című crafti adásból ismerhetnek.

Azt mondtad, hogy most belevágtál egy új kezdeményesből új projektbe tudod er kis kicsit mesélni nekünk, hogy mivel foglalkozolom most egész pontosan. >> Hát először is szeretettel üdvözlöm a hallgatókat és köszönöm a meghívást.

Ugye alapvetően igen, tehát ugye a Devofs és a Cloud vonalon mozgok továbbra is.

Immáron azért úgy nagyjából 10 éve és tényleg az utóbbi olyan fél év, egy évben kezdtem el.

Nyilván az automatizáció, mint olyan, az jelen van a szakmánkban.

Tehát nyilván DevOpsnak ugye egy erős alapja. és ugye a mai adásban tárgyalt témákhoz is mondhatni igen szorosan kötődik.

És pont most ilyen automatizált főleg teszt környezetekkel kezdtem el foglalkozni. egy ilyen saját kis szoftveren is dolgozom, és pont azokat az eseteket vizsgálom, hogy vagy azokat próbálnám így így elkerülni, hogy minél tehát maga az automatizmus minél tökéletesebb legyen, és hogy minél több hibalehetőséget lefedjen, mert ugye ezeknél az eseteknél fogjuk majd látni, hogy ha a megfelelő ellenőrzés ugye benne lett volna ezekbe a folyamatokban, akkor akkor valószínűleg nem lett volna ekkora probléma, de nyilván ez már történt.

Na meg hogy miről is lesz szó a mai adásban.

Egész konkrétan ez még nem hangzott el, de még mielőtt erre rákanyarodnánk gyorsan egy körkérdést, had intéznek hozzátok.

Stranger Things nézitek a Netflixen. >> Mindenképpen nézni fogom. >> Nézni fogod.

Gergő te? >> Szerintem decemberben lesz időm ezzel foglalkozni, úgyhogy ótolni fogom. téli szünetbe.

Igen, csak azért, mert ugye ez annyi aktualitása van a sztorinak, hogy tegnap jelent meg a Netflixen a ennek a sorozatnak az ötödik éva, illetve az ötödik évadnak az első fele, assassiszem az első négy részt tette ki a Netflix és azonnal le is térdelt az egész szolgáltatás úgy, ahogy van, amikor ráugrottak a nézők erre a sorozatra, és egy kisebb világbotrány lett ebből egyébként, hogy hát nem tudták nézni a a kedvenc sorozatuk részeit, a a nézőkeinket.

Egy öt perces lejállásról volt szó összesen, tehát azért nem mondanám, hogy egy ilyen végítéletszerű várakozás volt a a sztoriban. >> Jó, ennyi év után, ennyi év várakozás után az öt év öt perc már >> Mini Brown Juniort így így ennyire késől látni csak ez tényleg egy igazán fusztáló élmény lehet.

Hát még az mennyire frusztráló élmén lehet, hogyha valami komolyabb leállás van egy komolyabb szolgáltatónál.

És ugye ilyen jó igazából fixések komoly szolgáltató, de kicsit más jellegű szolgáltató, mint aminekre most ki fogunk térni.

És ilyenből azért volt az elmúlt időszakban példa ugye hova tovább?

Október 20a környékén, ha jól emlékszem, akkor kezdődött az első ilyen üzemszünet, vagy egy ilyen ismertebb üzemtünet, amikor a az Amazon Web Services, annak az egyik régiója ugye összeomlott, fogalmazunk így, de aztán majd Gergő elmondja, hogy pontosan mi történt, ami aztán így végigsöpört az egész világon.

Egy héttel később jött egy Asure leállás, egy Asure üzemszünet, és aztán a az szinte napra pontosan a az AVSnek a a az összeomlása után egy hónappal a a Clarzler is megadta magát, amiben az volt az igazán vicces, hogy az a szolgáltatás, ami elvileg azt mutatja, hogy milyen szolgáltatások estek el az interneten.

Ugye ez a downdetector.com, az éppen a Clarkfet használata, tehát ők is elestek.

Ugye van erre egyébként már átidó a megoldás, hogy ez a East Downector Down, mert már így külön weboldal meg lehet ezt nézni, hogy él-e még a Down Detector szolgáltatás.

Na de hogy ö tehát így így térjünk rá erre egy kicsit, hogy hogy így ö ö ezek ezek ezek a hibák ezek miből erednek, miért ilyen gyakoriak mostanában?

És milyen milyen hullámokat vethetnek ezek akár vagy vetettek már most, vagy milyeneket vethetnek a jövőben? >> Azt szerintem egy nagyon jó kérdés, hogy miért lettek ezek gyakoriak.

Lehet, hogy csak úgy most a, hogy besűrössödött ebbe a ebbe a néhány hónapba tűnik ez így, de hog de hogyha úgy nézzük meg, hogy majd visszatekintünk az elmúlt öt évre, nyolc évre vagy 10 évre, akkor ez nem lesz majd annyira gyakori, hiszen azért azt figyelembe kell venni, hogy amikor szolgáltatás kiesésről beszélünk, ugye itt vannak általánosan elfogadott fogalmak ugye és amikor arról beszélünk, hogy van egy 99%-os elérésű szolgáltatás egy évre.

Az azt jelenti, most sajnos fejből nem fogom megmondani, de azt hiszem, hogy az 1% az ugye több mint egy napot jelent, és hogyha ezeket a kilenceseket utánajuk a 99%-nak, akkor gyakorlatilag exponenciálisan növekszik annak az ára, hogy azt ezt a szolgáltatás elérhetőséget ugye tudjuk biztosítani.

Na most nyilván versenyezni nagyon nehéz egy egy Amazonnal, akinek gyakorlatilag lehet így fogalmazni szinte végtelen erőforrásá rendelkezésére, míg mondjuk egy hazai hosting szolgáltató azért hát jóval messzebbről indul.

Tehát az, hogy ő el tudja érni azt a azt a rendelkezésre állást, az egy nagyon-nagyon nehéz út és hosszú út.

Ö, illetve hát ne menjünk el szó mellett, és ez kapcsolódik egyébként majd ahhoz ehhez a dologhoz, hogy ugye nyilván az Amazonnál egy dolog, hogy mondjuk a mi szolgáltatásunkat tudjuk futtatni, a mi környezetünk onnan fut, de ugye számos olyan extra szolgáltatása van az Amazonnak, hát amit azért házon belül nagyon nehéz összerakni, és ugye ott meg gyakorlatilag egy kattintással, kis túlzással vagy nagy túlzással, de ezt az ügyfelek el tudják érni.

És hát pont ez az, hogy ennyire sok minden van ott egy helyben.

Ez a régió, ahol ez a hiba előfordult, ez gyakorlatilag amennyire utána olvastam, ez az Amazonnak az egyik legrégebbi, ha nem a legrégebbi régiója. >> Ez a keleti amerikai parton.

És ez egy ilyen visszatértő dolog, hogy miért ott van mindig a probléma, miért nem a nem tudom én a svéd vagy a nem tudom melyik adatközpontba.

És hát ez tehát oda eredezhető vissza, hogy ez gyakorlatilag az ősi régió, ez a ez az első régiója, ha jól tudom, az Amazonnak.

És nagyon sok olyan szolgáltatása van, ami onnan indul ki.

Tehát amikor mi elindítunk egy szolgáltatást, akkor annak egy bizonyos része az onnan indul el.

Magyarán, hogyha ott van valami probléma, az sajnos ez egy, hát ha lehet így fogalmazni, akkor ez az AVS single point of Failure egysége tulajdonképpen.

És itt ugye az történt, hogy egy Dinamo DB nevezetű szolgáltatása nem volt elérhető, ami így ebben a formában nem igaz, mert valójában elérhető volt, viszont a rámutató DNS bejegyzés nem volt elérhető, ezért a többi alkalmazás, ami ugye a DNS alapján >> tudtam volna, így van ezt megtalálni, ezt a szolgáltatást, azt nem találta meg.

Tehát az a ezeknek az alkalmazásoknak a szempontjából úgy nézett ki a dolog, hogy nem elérhető ez a szolgáltatás.

Ott egyébként teljesen elérhető volt.

Semmi baj nem volt a én úgy tudom, hogy a Dinamo DB-vel hanem egy DNSB edzés került törlésre.

Ami ami úgy jöhetett létre, hogy az egy ugye rengeteg automatizált folyamata van a az Amazonnak.

Meg hát nyilván egy ilyen mértékű szolgáltatónál ez elképzelhetetlen, hogy manuálisan telepítsenek ekkora számosságba vagy vagy töröljenek ugye szolgáltatásokat.

Ugye ez dinamikus dolog, tehát ugye nyilván terhelés függvénye is.

És az egyik ilyen automatizmus az gyakorlatilag úgy érzékelte, hogy hogy hogy neki azt ott törölnie kell azt a bejegyzést.

És ugye ez ki lett törölve, nem indultak el a vagyis pontosabban nem érték el ezek a szolgáltatások ugye a a Dinamo DB-t.

És ugye ezt a ezt a hibát egyébként detektálta az AVS viszonylag gyorsan és ezt a ezt a DNS bejegyzést ők visszaállították, úgy tudom, manuálisan.

Tehát, hogy erre volt lehetőség, csak addigra már ugye egy ilyen kaskád effektus indult el, vagy domino effektus, >> hogy annyi, tehát például az EC2-es gépeknél, a virtuális gépeknél egy csomó állapot ebbe a Dinamo DD DB-ben volt tárolva, és ezek felsorakoztak, és akkor gyakorlatilag egy akkora egy ilyen egy ilyen feladat csomag jött létre, amit ugye az AVS nyilván valamennyire tudott kezelni, De kicsit ilyen slendrául fogalmazó, utól kellett érnie magát, és azok a azok a a hogy is mondjam, hatások, amiket ugye az ügyfelek érzékeltek, az ebből fakadt igazából, és ezzel nem is tudtak mit csinálni, tehát ennek végig kellett mennie és ez ugye hát ez jó pár órán keresztül tartott és igazából ez az, ami ez az, ami azt a azt a negatív érzéstatot okozta, amit ugye az ügyfelek végül is tapasztaltak.

Kicsit az olyan, mint amikor az ember nagyon mély alvásból vagy árulásból magához tér, ugye, hogy nem az van, hogy egyből felpattannak a szemeid, és huh, már rohanok és tovább, hanem azért kell egy kis idő, aminek teljesen magadhoz térsz, vagy vagy magához tér az egész >> így van.

És és nyilván nyilván erre az AVS úgy egyébként fel van készülve csak ugye pont amiatt amit beszéltünk hogy ez a régió ez annyira központ és annyi minden fűződik oda.

Tehát hogyha itt lett volna egy egy kicsit régió függetlenebb lett volna az egész eset akkor valószínűleg nem lett volna ekkora hatása mint amilyen mint amilyen hatása lett ebben az esetben.

Tehát engem nem az, hogy megnyugtat, de ugye mint Devopsosként, Cloud engineerként ugye szerintem nagyon sokan futottunk abba bele, hogy akár véletlen, akár nem véletlen, de sikerült némi szolgáltatáskiesést okoznunk annál a azon a rendszen, amin éppen dolgoztunk.

Lehet ugye akár egy frissítés, vagy bármi egyéb.

És mondom, nem azt akarom mondani, hogy megnyugtatott a dolog, de azért az látszódik, hogy a tényleg, mert azért egy AVS-nél nagyon komoly erőforrás van, nagyon komoly pénz van, meg hát szakembergárda, mert nyilván a legjobbakat válogatják ki.

És hát ugye melyik hiba a rossz hiba, vagy melyik hiba, amitől rettegünk? ugye a rejtett hibák, tehát amiken nem vagyunk fölkészülve, mert hogyha van egy szolgáltatásunk, aminél tudjuk azt, hogy van egy pontja, ami valami legacy dolog jött valahonnan, biztos, hogy a a kollégák is tudnak ilyet mondani.

Mikor mondjuk kezdtek egy új cégnél, és akkor az idősebb kollégák elkezdték el bemutatni, hogy van ilyen rendszerünk, van ilyen rendszerünk, itt ezt szoktuk csinálni, azt szoktunk csinálni.

Tehát, hogy az az ami az ami az ami >> ha ott valami baj van, akkor az mindenre hatással van, de mi ezzel tisztában vagyunk.

És hogyha egy olyan hibajelenség üti fel a fejét, hogy úgymond megállt minden, akkor nagy eséllyel ott van az a gond, és akkor hát nem örülünk, de tudjuk, hogy ott kell a hibát keresni.

Viszont ez a hiba, ami itt most az Amazonnál előjött, ugye ez nem egy ilyen hiba, tehát ez úgymond egy rejtett hiba volt.

És igen, hát ez ez az eset, amikor ugye a és nem akarom azonos súllyal mondani a két dolgot, de amikor történik egy légikatasztrófa, ugye az a légirányításnak a rendszerét ugye általában megváltoztatja, tehát hogy abból a azokból a hibákból ugye tanulni kell, és és azokat a azokat a megoldásokat ugye minél hamarabb implementálni, és minél szélesebb körben elterjeszteni. egyébként ebből nagyon ilyen szempontból nagyon fontos, hogy a a posztmortem kezelése ugye az ügynek vagy az incidensnek az ugye átlátható legyen, mert abból az ipar ág is tud ugye tanulni.

Na és akkor ugye pont itt jön a kérdés, hogy mit lehet akkor ilyenkor csinálni, amikor megtörtént az eset, akkor egy csomó szakértő vagy ilyen ászakértő lenyilatkoztál, hogy hát akkor redundánsabb rendszereket kell építeni, meg hogy a hibatűrésre több figyelmet kell fordítani, meg ugye mondtad a szakember gárdát is, hogy volt olyan vélemény is, hogy talán nem kellett volna kirúgni annyi mérnökszakembert meg programozót, és akkor lennének ott kompetens emberek, akik ezeket a rendszereket tudnák üzemeltetni, és hogy egyáltalán tehát hol van itt az igazság ebben így így mi mit lehet csinálni, hogy Aztán mondjuk két hónap múlva, vagy két év múlva, vagy nem tudom hány év múlva egy ilyen ne forduljon elő mi a pont.

Ezt a US East 1-es régióban volt azzem, amikor írtuk a cikket erről a témáról az elhúlt öt évben ez aztem ez a harmadik leállás volt, tehát hogy mit lehet tenni, hogy ne legyen a következő egy évben még három.

Azt azért tudni kell, hogy az különösen itt az AVS esetében ez egy elképesztően nagy régió, rengeteg erőforrás, tehát ez ez tényleg egy oké, mi is dolgozunk adatközpontokban, telepítünk szervereket, virtuális gépeket tömegével, lehet, hogy 100-assával, akármi.

Látunk nagy rendszereket, látunk olyan rendszereket, aminek van, nem tudom én, mondjuk 1 millió felhasználója, de itt azért jóval többről van szó.

Tehát ugye ha csak az amerikai piacot nézzük 300 millió fő vagy nem tudom, tehát de hogyha azt is még egy kicsit kiveszünk belőle, tehát 100 millió fő mondjuk, tehát biztos, hogy rengetegen használják ugye ezt a ezt a ezt a régiót és nyilván pontosan nem látunk be mögé, hogy hogy ott milyen automatizmusok, milyen olyan deploymentek vannak, amivel ezt ők kezelik.

Én azt gondolom, hogy valószínűleg az van itt a háttérben, hogy hogy elképzelhető, hogy maga az Amazon sem gondolt még akkor arra, biztos voltak nagyra törekvő tervei, de hogy ennyi erőforrás fölött fognak ők uralkodni.

És szerintem ez a régió, ez egy kicsit, ha lehet így fogalmazni, lehet, hogy lemaradt, és ezt most értse jól a hallgató.

Tehát, hogy a azokat az új régiókat, amiket fölépítettek, ott már lehet, hogy néhány dolgot másképp csinálnak, mint ebben a régióban.

Említett entitások

Témák

  • devops
  • cloud engineering
  • automatizált tesztelés

Személyek

  • Korom Gergely

Hallgasd meg

Gyakori kérdések erről az epizódról: „Ennyit az atomtámadást túlélő internetről (weekly #74)”

Miről szól ez az epizód: „Ennyit az atomtámadást túlélő internetről (weekly #74)”?

A HWSW podcast 74. adásában Kohi Tamás és Számi vendége Korom Gergely DevOps Cloud Engineer. Az adásban a felelősségmegosztásról és az automatizált tesztelési folyamatok fontosságáról esik szó, különös tekintettel azokra a helyzetekre, amikor egy harmadik féltől származó… Az epizód a HWSW podcast! című magyar podcast egyik adása, megjelenés: 2025. 11. 28..

Milyen témákat érint ez az epizód: „Ennyit az atomtámadást túlélő internetről (weekly #74)”?

Fő témái: devops, cloud engineering, automatizált tesztelés.

Mikor jelent meg és milyen hosszú ez az epizód: „Ennyit az atomtámadást túlélő internetről (weekly #74)”?

Megjelenés: 2025. 11. 28.. Hossz: 48 perc. Az epizód a Podiverzumon hallgatható meg: https://podiverzum.hu/podcast/hwsw-podcast/ennyit-az-atomtamadast-tulelo-internetrol-weekly-74

Több epizód a HWSW podcast!-ből

Hasonló epizódok más magyar podcastokból