- Ha minden zöld, akkor igazából azt kell magadnak megkérdezni, hogy mi az, amit nem figyelsz. Biztos, hogy van olyan, amit nem figyelsz, egy biztonsági szakembernek kell, hogy legyen benne egy ilyen egészséges paranoia, hogy ez túl gyanús, mint amikor csendben vannak a gyerekei, hogy ez túl gyanús, minden zöld, valamit biztosan nem veszek észre.
- Üdvözlök mindenkit, ez itt a Digit Podcast. Személyi László vagyok, a Future-NOW vezető partnere. A Digit Podcast célja, hogy akit nem elégítenek ki a felszínes cikkek és a hangzatos jelszavak, az közelebb kerülhessen a digitalizáció és az informatika mai meghatározó trendjeihez. Mi itt a mélyére fogunk ásni a dolgoknak. Van egy céges dokumentum, amit általában pontosan egyszer olvasott el valaki, és pontosan akkor, amikor megírta, ez a katasztrófa helyreállítási terv magyarul. Ott van a mappában, megvan hozzá az aláírás, bizottság kipróbálta vagy kipipálta, de hogy vajon működik-e, azt nem biztos, hogy jól megnéztük. És ma arról fogunk beszélgetni, hogy mi van akkor, amikor a normál működés feltételeiből átlépünk a havária helyzetbe, ahogy szoktuk mondani. Ketten ülnek velem szemben a TC2-től, az egyikükkel korábban már többször beszélgettünk, a másikukkal pedig most találkozom először. Két nézőpontot szerettünk volna ütköztetni. Sepsi Károly üzletfejlesztési vezetőként látja, hogyan gondolkodik az ügyfélnek a vezetője, Kulcs Viktor felhőbiztonsági szakértő pedig technikai oldalról nézi a kérdést, üdvözöllek benneteket a Digit Podcast stúdiójában.
- Köszöntjük a hallgatókat. Szia Laci!
- Szia!
- Talán kezdjük a legkonkrétabb élethelyzettel. Hétfő reggel van. A pénzügy éppen zárná mondjuk a hónapot, ez most pont így jött ki egyébként ezen a héten, és a rendszer nem jön be. Ilyenkor derül ki, hogy az a bizonyos mappában lévő terv az mennyit is ér. Karcsi, mennyire könnyű olyan embert találni egy ügyfélnél, aki meg tudja mondani, hogy hány óra alatt akarnak mondjuk visszaállni, és nyilván nem a papír szempontjából, hanem úgy az élet vagy a munka szempontjából?
- Korábban azt gondoltam, hogy nehéz. Ma már inkább azt gondolom, hogy a megfelelő kérdésekkel egyébként el lehet jutni a megfelelő emberekhez. Ugye olyanokkal támadni, hogy mondd meg, hogy mennyi az RTO és RP, ugye Ecovery time objective, Ecovery point objective. Ezek nem mondanak semmit mondjuk egy üzleti vezetőnek, a technikai vezetőknek annál inkább. Viszont olyan szempontból, hogy a szolgáltatásom mikor kell, hogy fusson, illetve mennyire fáj, hogyha megáll valami, azzal már sokkal inkább tudnak azonosulni a vezetők, a CIO-k, CIO-k, tehát ugye vezérigazgatók, informatikai igazgatók, és aztán van egy olyan szelete is, amire majd később a későbbi kérésekbe belemegyünk, hogy technikai vezetők, tehát CTO-k, akár Financial vezetők, tehát pénzügyi vezetők, CFO-k. Tehát én úgy látom, hogy van egy kör, aki pontosan meg tudja mondani a végén, hogy mi is mennyire fáj.
- Kicsit az ördög ügyvédje módjára. Tehát szerintem van az a cégvezetői megközelítés, legalábbis én találkoztam ilyennel, szerintem ti is, hogy ilyen nincs, mindig működjön. Tehát, hogy nekem nincs olyan, hogy most hány órát nem írok nélküle, hanem ilyen maximalista hozzáállás van. Meg van olyan is, aki azt mondja, hogy de hát sose állt meg, hát nálunk a rendszer évek óta stabilan működik, most akkor miért akarsz te pénzt kérni?
- Igen.
- És igen, tehát valahol logikus ez a gondolatmenet szerintem, tehát hogy egy ilyen intuitív logika van benne, csak hát az évek óta tartó stabil működés meg arról szól, hogy normál körülmények között stabil. Tehát valószínűleg nem voltak havária körülmények.
- Igen.
- És hogy mi az, ami ezekben a rendszerekben benne van akár évekig anélkül, hogy látható tünetet okozna, és mitől jön egyszer csak mégis elő ez?
- Szerintem az dicséretes, hogy egy rendszer stabil, amit megépítünk, és minden működik, és minden szuper egy normális környezetben, de általában itt az szokott lenni a probléma, hogy attól, mert nem égett le a házam, tehát egy ilyen torz, eltorzul egy kicsit, hogy mit is nézün, valójában mit látunk. Tehát az, hogy nem égett le a házam, az nem jelenti azt, hogy jó a füstjelzőm. Tehát, hogy nincsenek a megfelelő esetleg metrikák bekötve, tehát itt olyan problémák szoktak lenni, ami szépen lassan megbújik a háttérben, hogy elindul egy szervezeti fejlődés, mondjuk új policykat vezetünk be, új naming policy kerül mondjuk egy SNS topikra, fölkerül ez a naming policy, viszont a riasztásnak a korábbi fázisaira, amik kiszolgálják ezt a topikot, ott már elfelejtjük frissíteni.
- Lehet, hogy egy picit vissza kell kérdezzek, hogy mi ez az SMS topik, mi ez az élethelyzet, amiről beszélünk?
- Ugye ez egy kvázi riasztási lánc, tehát maga a metrika jelez, ott begyűjtjük a metrikát, ez az Event Bridge-en keresztül, az AWS-nek az a szolgáltatása, ami egy ilyen event vezérelt folyamat, aminek meg tudjuk adni a végén azt, hogy mondjuk te kapjál egy sms-t, vagy egy slack üzenetet, vagy egy e-mailt, vagy csörögjön a telefonod, hogy baj van. És ugye ebben itt egy naming policy változással az nem kerül következetesen végig vezetve a környezetbe, és a lámpa az zöld marad, mert pusztán csak azért, mert nem érkezik meg a riasztás. Vagy például hatalmas adatmennyiség-növekedés történik, tehát végzünk egy replikációt, amit belőttünk egy adatmennyiségre, és ez az évek folyamán mondjuk megtízszereződik az adatmennyiség, amit felhasználni.
- Most egy kicsit ilyen otthoni hasonlattal élvez, nekem olyan, minthogyha áthelyezném a kaput az új kerítésépítésnél, de a kamera az ugyanoda néz, mint eddig, vagy nem tudom, benőtte a dzsungel, előtte nem vágtam le a sövényt, szóval, hogy valami ilyesmi zajlik az informatikai rendszerekben is, nem?
- Hadd kössek egy másik példával. Egyébként én is sokat beszélgettünk erről a témáról, partnerekkel és ügyfelekkel, és akkor múltkor jött a hasonlat, hogy az autóval is, ugye? Tehát, hogy megy az autó, de mégis elviszed kötelező szervizre, nem? Hiszed, hogy minden rendben van, hiszen nem zörög, nem csattog, megy, kanyarodik, fékez, megáll, mégis el kell vinni, mert ugye vannak olyan degradációk, amiket nem látunk. És mondjuk joggal gondolhatja valaki, hogy jó, de az informatikában nem ez van.
- Nincs súrlódás.
- Az nem fog elfáradni, az nem romlik csak úgy el, de azért hogyha ilyen általánosabb szemszögből meggondoljuk, hogy azért semmilyen informatikai rendszer nem marad ugyanúgy huzamosabb ideig. Tehát minimum kiadnak javító patch-eket, fixeket a kódból. Minimum változik alatta a környezet, mert ugye patchelik a futtatókörnyezetet, ugye biztonsági frissítéseket.
- Ilyen képek is változhatnak.
- Így van, a platformon is változhat alatta az integrációs partnerek is változtathatnak, tehát folyamatosan minden megy előre, tehát az, hogy ott se változik semmi, az egy illúzió, mert attól, hogy mi nem nyúlunk hozzá, attól a háttérben nagyon sok minden változik, és egyszer csak lehet, hogy lesz egy olyan együttállás a csillagoknak, amitől valamilyen funkcióhirtelen elkezd nem működni. És ugye ennek érdemes elébe menni, hogy ugye ezek a technikai problémák nagyon gyorsan üzleti problémákká növik ki magukat, amint megáll a rendszer, tehát mennyivel jobb, hogyha nem az ügyfelünk veszi észre, hogy gond van, hanem esetleg elébe megyünk, és akkor egy proaktív teszteléssel, kipróbálással, mi tudjuk ezt munkaidőben, úgyhogy mindenki kipihenten úgy ül a géphez, hogy most ezt ki tudjuk próbálni, és nem hajnalban, vasárnap kapkodva kapják a riasztást.
- Igen, igen, erre gondoltam, hogy az információbiztonságban is, meg IT biztonságban is van ez a rettiming gyakorlat, hogy etikusan, de megpróbáljuk megtámadni a rendszert, és akkor kicsit ez is olyan, hogy nem tudom, eljátszod a Vasorrú bábát, hogy akkor te most ott jössz és szétcsapsz a rendszerben.
- Igen.
- De hogy akkor látszik, tesztelhető, hogy bizonyos havária körülmények mit okoznak?
- Abszolút, igen. Most nyilván mi itt elsősorban felhős rendszerekről beszélünk, sőt, azon belül is Amazon Map Services. Pont a Viktorral beszélgettünk erről, hogy azért egy hagyományos környezetben, tehát egy On Premis, ahol ugye megveszik a szervereket előre, és ki van mérve, ki van grammolva, vagy ennyi kell, tehát ott azért lehet, hogy nehezítő körülmény, minthogy a felhőben percalapú számlázással fel lehet skálázni az adott tesztkörnyezetet. Nyilvánvalóan nem éles környezeten tesztelünk soha ilyen gyakorlatokat, hogy mi van, hogyha havária van, tehát hogy nem döntjük be az éles környezetünket, de egy tesztkörnyezetet a felhőben egy pillanatok alatt fel lehet skálázni production like, tehát hogy éleshez hasonló környezetre és éleshez hasonló terhelést is lehet imitálni rajta. Ebbe is majd hamarosan belemegyünk, hogy milyen részei vannak az ilyen.
- Menjünk bele most, mert engem egyébként ez érdekelne, hogy ez mennyire speciális tudás. Tehát, hogy ezt most megint az ördög ügyvédje, de hogyha van egy informatikusom, vagy ahogy Zolival szoktunk néha viccelni, volt ilyen, hogy információtechnológusom, hogy akkor neki oda tudom-e adni, hogy figyelj, akkor üsd fel a Google-t, aztán nézd meg, hogy kell ezt az AWS Liten tesztelni, vagy éppen ti is alig találtok rá olyan szakembert, aki a TC2-ben ezt tudja szolgáltatni. Tehát, hogy valahol helyezzétek már el légyszi, hogy ez mennyire speciális.
- Nekünk ugye ez a profilunk már tizedik éve, tehát hogy mi mindig is, amit megépítettünk, azt aztán üzemeltettük és optimalizáltuk is.
- És nyilván az üzemeltetésnek a fokmérője, hogy egyébként mennyi kiesés van, tehát egyébként mi is mondhatnánk, hogy amíg nem romlik el semmi, addig mi is örülünk. De mi szeretnénk tudni, hogyha elromlik valami, akkor hogy fog reagálni a rendszer. Egyébként ezt úgy lehet felépíteni, hogy van az egyik rész, hogy observability, vagy a monitoring ennek egy része. Tehát, hogy látjuk, hogy mi történik, az az egyik, utána látjuk-e, hogy jól skálázódik a rendszer, tehát a beérkező igényekre arányosan, vagy lineárisan, vagy annál jobban skálázódik. Tehát ugye plusz egy egységnyi berakott ügyfélkérésre maximum egy egysége legyen több az erőforrás igény, vagy jobb esetben kevesebb. Tehát jól skálázódik, hatékonyan, és akkor a harmadik lépés, hogy tudjuk imitálni, hogy ez most egy nagy kéréshalmazt kap, tehát nagy Customer Lordot, ezt ugye ilyen load tasting framework-okkal lehet megoldani. Le tudjuk imitálni, hogy milyen az a valós kéréshalmaz, amit kap. És a negyedik rész, hogy eközben ez a káosz tesztünk, hogy ezt úgy hívják, hogy imitálunk különböző meghibásodásokat akár szoftverszinten, akár platformszinten. Tehát mondjuk teszem azt, hogyha az Amazon Web Services is valamilyen hiba miatt valamilyen szolgáltatás nem működik, vagy csak részlegesen működik, vagy csak az egyik datacenterben működik, akkor mi történik a rendszerünkkel. És egyébként ez az alaptézise az Amazon Web Servicesnek is, hogy design for failer, tehát hogy a hibákra kell dizájnolni, és egyébként ők a legjobban ezt nyomják, ezt bátorítanak, hogy ezeket próbáljuk ki. És hogyha jól van megtervezve a rendszerünk, akkor egy hiba, az vagy ugye ilyen öngyógyító módon vissza tud állni a rendszer, úgyhogy újra készíti az erőforrásokat máshol, vagy ki tudja skálázni, vagy hogyha erre nem lehetséges, akkor recovery módban vissza tudja állítani magát.
- Ezt így egyben, ezt hívjátok ti rezilienciának?
- Igen, igen, gyakorlatilag ebből a négy pillérből összeáll, és a végén egy vezetői riport készül ebből, ami feltárja, hogy amikor megtervezték az architektúrát, és ugye papírforma szerint le lett írva, hogy ennek mennyi a visszaállítási értéke, tehát az RTO és RPO, hogy az a valóságban mennyi. És hogyha ezzel nem elégedett a vezetőség, akkor mik azok a lépések, amiket hogyha megtesznek, akkor ezt közelebb lehet húzni az elvárthoz a valóságot.
- Ha megengednétek, én egy pillanatra visszaugranék ehhez a szólító témához, és ez ugye itt összeköt a monitor és az obszervativitynak a különbségeire. Tehát, hogy amikor a dashboardunk teljesen zöld, az azt jelenti, hogy amiket figyelünk, azok rendben vannak. És szerintem ez egy, és össze lehet kötni, hogy mennyire jó a szakember, mennyire jó az obszervatbilitisztek és a felhős környezet folyamatos változásával, hogy gyakorlatilag folyamatosan fejlesztened kell magad. Tehát ha minden zöld, akkor igazából azt kell magadnak megkérdezni, hogy mi az, amit nem figyelsz. Tehát, hogy biztos, hogy van olyan, amit nem figyelsz, egy biztonsági szakembernek kell, hogy legyen benne egy ilyen egészséges paranoia, hogy ez túl gyanús, mint amikor csendben vannak a gyerekeid, hogy ez túl gyanús minden zöld, valamit biztosan nem veszek észre. És pont egy ilyen, hogy a Disaster Recoveryben meg a Security-ben nincs egy ilyen checkbox, hogy kipipáltad, hogy oké, most végeztem, ez most teljesen biztonságos ez a környezet, vagy teljesen 100%-os a fél óverem, hanem ez egy folyamat, egy utazás, és amit szerintem mi tudunk nyújtani, az az, hogy ezen az úton sokkal gyorsabban végig tudunk téged vinni a saját tapasztalataink meg megoldásaink alapján.
- Most már kétszer említettétek ezt a helyreállítási időt meg pontot. Egy ilyen sztorit szeretnék meghallgatni, hogy ma egy profi szolgáltató és ügyfél kapcsolatban hogy jutnak el ehhez a két számhoz. Merthogy az elején már szó volt róla, hogy nem feltétlenül az informatikus tudja megmondani, de cserébe az üzleti vezetéssel kapásból tudja megmondani. Tehát hogy néz ez ki, milyen iterációk mentén jutunk el oda, hogy megvan, hogy akkor ilyen idő alatt szeretnék visszaállni, ha valami baj van, meg hogy ilyen öreg vagy bidős, bocsánat, a visszaállítási pontom.
- Ugye az RTORP ezek üzleti számok, tehát az üzleti vezetésnek kell gyakorlatilag a felhőben bármilyen RTORPO megvalósítható, tehát a real time-tól két év múlva tud, vagy állítjuk csak vissza belőle az adatot. Ez bármelyik könnyedén.
- Csupasz pisztoly.
- Könnyedén elérhető.
- Két óra múlva tud csak jósolni.
- Igen, igen. És ugye ez azért egy nagyon érdekes kérdés, mert a felhőben nagyon könnyű túldimenzionálni vagy túlbiztosítani a kérdéseket, hiszen.
- Látszólag végtelen az erőforrásom.
- Látszólag végtelen az erőforrás, nagyon könnyen elérhető, gyakorlatilag, ha mondjuk egy infrastruktures kódból van kitéve, akkor egy plusz flag-et bekapcsolok, és akkor már a teljes organizációmra ér a szabály. Három zónába teszek ki mindent, tehát folyamatos fél óver van.
- Igen, ha elmegyünk az All You Kennybe, vagy az Élvhotelbe a reggelinél, akkor ott aztán kétszer annyit eszünk.
- Az utolsó pici adatomat is aktív aktívba replikálom, viszont ennek lesz egy borzasztó nagy költsége a másik oldalon. És akkor itt szerintem azt kell jól felmérni, hogy például én egy bank vagyok, van egy banki alkalmazásom, mi a három legfontosabb funkcióm, lássam a számlaegyenlegemet, tudjak pénzt kapni, meg tudjak küldeni. És akkor ezt a három funkciót bebiztosítom a legkomolyabb módon, legjobb aktív aktív adatreplikálással, és lehet, hogy ez az egész egyébként egy adatbázis és egy load balancer kérdés, és az összes többi kényelmi funkció az meg ráér fél óra múlva vagy egy óra múlva.
- Tehát szerintem ezeket a szinteket nehéz jól belőni, és itt a technikai oldalon bármi megvalósítható, az üzletnek kell támasztani ezeket az igényeket, hogy melyiket hova lőjük be.
- És ez azért nagyon jó példa, amit mondasz Viktor, mert ha nem megfelelő embert kérdezel, a megfelelő kérdéseket, akkor azt fogják mondani, hogy legyen benne minden. És egyébként ezért látjuk, hogy nagyon sok felhős projekt azért nem sikeres, merthogy rettentő drága. Mert hogyha megkérdezel valakit, akinek ugye a költésre nincs azon mérve, és akkor hát legyen benne minden, miért is ne lenne? És akkor minden hangszeren játszik, mindent tud, csak nem erre lenne szükség. Egyébként nagyon sok migrációt csináltunk az elmúlt években, kifejezetten Migration Partnerek, vagy Migration és Menis Services, és ott is megvan az AWS-nek is a Migration Famework-e, és ott egy nagyon fontos pont, hogy mi az RTO és RPO. És akkor ugye számtalanszor nekifutottunk, hogy na mi az RTO, RPO? Hát nem tudom. És akkor mennyi legyen, meg hogy ti mit gondoltok. De hogy ha viszont onnan indulunk, hogy mondjuk az ügyvezető, tehát CO-CIO szintről, hogy milyen üzleti szolgáltatások vannak, és azok melyik, tehát hogy nem is egészként a céget, hanem a Portfoliónak a különböző elemei, és melyik mennyire kritikus, melyik mennyire fájdalmas, hogyha esetleg megáll, meg kiesés van. Tehát hogy ilyen szempontból üzleti szemmel definiálva. És hát ugye ez elhangzott, ezt te is mondtad Laci, ezt is hallottuk párszor, hogy hát mindig minden menjen, de azért azt mi is érezzük, hogyha gond van, akkor valamilyen priorizálás kell, hogy életbe lépjen, hogyha több mindennel is gond van. És hogyha ezt mondjuk, hogy mindig minden menjen, akkor egy szinttel lentebb toljuk ezt a priorizálást, ahelyett, hogy megadnánk az alattunk lévő szervezetnek, hogy hogy kéne gondolkozni. Tehát mindenképp érdemes valamilyen módon ezt meghatározni. Egy CFO szerintem kapásból megmondja, hogy percenként mennyi pénzt vesztünk, hogyha megáll. Ez a szolgáltatás meg az.
- Egy kicsit olyan ez, mint a fizikában volt már az ókorban ez volt a probléma, hogy hagyjatok egy fix pontot, és akkor kifordítom sarkaiból az egész világot.
- Igen.
- Akkor mondjátok meg, hogy mennyi idő, és akkor utána mindent megoldok, de hogy pont ezért ülünk itt, mert ez nem mindig szokott időben összejönni.
- És nagyon jó, hogy mondod, hogy tényleg sokszor egy cégben, ha nincs megfelelő belső kommunikáció, meg vezetői együttműködés, akkor akár a vezérigazgatót is kell ugrasztani idézőjelben, vagy kell zargatni ezzel a kérdéssel, mert igazából az, hogy mibe kerül a leállás, az nem egy helyről jön az a válasz, mert ugye ennek van egy árbevétel oldala, amíg nem megy a webshopom, addig nem jön a rendelés, stb. De van egy reputációs oldala is, hogy egész egyszerűen csak hallanak róla az emberek, vagy az ügyfeleim, hogy itt a rendszer nem ment, hogy nem tudott utalni a K&H-nál, vagy az OTP-nél, vagy a nem tudom melyik banknál a barátom. Tehát hogy nem is az ügyfél, de hogy a nagyközönség az egy ilyen reputációs kockázatot hordoz ilyenkor. Ott van a jelentéstételi kötelezettség, amiből akár büntetés is fakadhat, ha olyan szolgáltatást nem teljesít a szolgáltató, most nem feltétlenül csak egy bank, de lehet ez más telekommunikáció, stb., hogy mondjuk nem tudta vállalni az SLA-t, stb. Tehát, hogy egy csomó-csomó helyről jön ez a költség, és igazából, ha nincs jó belső szervezeti kommunikáció, akkor nincs, aki ezeket összeadja, vagy így együtt nézzen.
- Igen.
- Hogy tudtok ebben segíteni? Van-e ennek valami olyan módszertani, hogy ne az legyen az egyetlen megoldás, hogy akkor hívjátok a vezérigazgatót.
- Mi alapvetően egy ilyen, nem szeretem ezt a szót, de hogy holisztikus átnézéseket szoktunk javasolni és általában megtenni az ügyfeleknél, tehát hogy milyen informatikai rendszerek vannak, és az ugye van egy olyan consulting famework, ez ugye a migrációs gyakorlatunknak a része, ahol meg üzleti vezetőkkel is beszélünk, és akkor mindez kiderülhet. Ez mindig attól függ, hogy van-e erre dedikált felsővezető, mennyire tudunk hozzáférni a különböző embereknek, tehát nyilván mindenki nagyon elfoglalt, és tehát hogy lássák a szervezetben, hogy ez egy fontos iniciatíva, amivel sokat lehet nyerni.
- Alapvetően szerintem a gondolkozásmódot, vagy a mindsetet tudjuk átadni, hogy kezdjenek el ebben gondolkodni, és mérjék föl a járulékos költségeket is, tehát magának, például az elemzésünknek is van egy komoly olyan része, ami vállalati folyamatokra, döntéshozási folyamatokra és ezekre irányul, tehát nem feltétlen nagyon technikai, és ezeket is ugyanúgy belegyúrjuk ebbe a végső értékelésbe, ami alapján meghatározzuk, hogy ez a környezet, ez mondjuk elég érett-e arra, hogy az adott feladatot ellássa.
- Láttok-e ebben esetleg iparági különbséget, hogy vannak iparágak, ahol ezt régebb óta jobban tudják csinálni ezeket a katasztrófa-elhárítási dolgokat, míg máshol nagyon az elején járnak.
- Elgondolkoztató, tehát azért látszik, hogy hol költenek többet IT-ra, hol költenek többet biztonságra IT biztonságra, tehát ez mind összefügg. Ugye nagyon széles ez a bizonyos csúszka, hogy mennyi, tehát ugye felhőben, tehát hogy kis rendelkezésre állás, hosszú viszálytárs, versus, ugye soha ne senki soha ne álljon meg, soha ne törjék fel, tehát hogy nem tudom, tízszeres ára, nyugodtan lehet gondolni, mire mindent mellé pakolunk. Szerintem az a nehéz benne inkább, hogy jól eltaláljuk, hogy melyikre mit kell alkalmazni, tehát megfelelő költségszinten, megfelelő kockázattal. De egyébként a banki szektorban nyilvánvalóan, hogy ott azért top notch a biztonság. Az üzembiztonság is ennek következtében, tehát ott azért elég jó megoldásokat látunk a tákó szektorban is. Talán ami kevésbé regulált iparágat, ott megengedőbbek, de hát nem is tudom. Most gondolok itt egy ecommerce webshopra, hogy ott is vannak olyan periódusok, amikor nem engedhetik meg maguknak, hogy kiesés legyen, mert óriási pénzek mennek ki ott is.
- Igen.
- Még a tízszerese is megérheti abban az időszakban.
- Igen, szerintem két ilyen nagy motiváció van. Az egyik ugye a pénz, tehát például egy kereskedő cégnél, ami tudja ezt drive-olni, a másik oldalon meg a szabályozói környezet, amikor köteles vagyok megfelelni.
- Ehhez vagyok energetikai cég vagyok, stb.
- Így van, így van, és akkor ott kell megfelelni. De szerintem ez egy állandó harc egyébként szerintem a Finops, meg a Security között, hogy tehát ez egy ilyen folyamatos balanszolás, hogy nyilván ők próbálják leszorítani a költséget, te meg próbálod növelni a biztonságot, és hogy ennek a kettőnek hol találod meg az egyensúlyát.
- Igen, azért ez szerintem üzletfejlesztési szemmel is mindig egy nagyon fontos kérdés, hogy a helyes dobozba kerüljél te, mint szakember, meg projekt, meg nem tudom. Tehát, hogy te ne egy költségdobozba kerüljél, aki csak viszi a pénzt, és csak így lehet rá tekinteni, hogy hogy lehet ezt valahogy megfogni, mert ez nagyon drága már most, hanem te egy biztonsági dobozba kerüljél, hogy te azért dolgozol, hogy igazán nagy baj ne érje a céget, meg igazán nagy árbevételi kiesése ne legyen, meg nem tudom. Tehát, hogy mint egy biztosítás, vagy ilyesmi, azért úgy egészen mások a beszélgetések szerintem.
- Én látok arra hajlamot, hogy ezt az egész iparágat, vagy a szakágat ilyen mostohagyerekként kezelik, hogy na, itt jön a biztonsági srác, és akkor most ennek meg annak megint biztos kitalált valamit, aminek meg kell feleljünk, de én nagyon szeretném, hogy eljusson odáig a gondolkodás, amit te hoztál föl, hogy tényleg azt lássuk benne, hogy ez igenis megtérül, és nem akkor térül meg, amikor épp kifizetem, hanem hosszú távon térül meg a nem elvesztett nyereség során.
- Most csak, hogy mondtad, hogy ez egy mostohagyerek, tehát ez a szolgáltatás, amit mi is most nyújtunk, ez egy termék, mondjuk így, a reziliens 360, erre a névre hallgat, tehát hogy az ellenálló képességet 360 fokban felmérjük, és pont ezen gondolkoztam, ahogy beszélgettetek, hogy én ugye fejlesztőként kezdtem a pályafutásom, és akkor már ott is mondták nekem, hogy Károly, itt van a lista, amit megtehetnénk, és akkor ennek a fele arra megy, hogy a platform stabilabb legyen, meg jobban működjön, a másik fele meg új fejlesztés, és hogy az első felét soha nem fogjuk megcsinálni, mert mindig nyomnak a biznisz felől, hogy az új fejlesztés érkezzen el a felhasználókhoz. És csak mostanában gondolkoztam, hogy ugye korábban nem volt üzleti, tehát nem lehetett üzleti szempontokat megfogalmazni, hanem csak technikai szempontokat is, ez egyszerűen nem értelmezhető üzleti szempontból, de amint ugye ezt összerakjuk, és a kockázat, az esetleges kiesések mentén keletkező ilyen-olyan veszteségek mentén tényleg üzleti nyelvre fordítható le, hogy miért kell ezeket az implugmenteket megcsinálni, onnantól kezdve viszont sokkal jobban értelmezhető, és szerintem egy egészségesebb együttállás is lesz a technikai és a biznisz csapatoknak. Tehát, hogy harmonikusabb lesz az együttműködés, hiszen mindenki azt akarja, hogy ne legyen kiesés, azt senki nem szereti, a technikai emberek sem, de hogy sok esetben nem kapnak rá erőforrást, hogy ezzel foglalkozzanak, mert nem számszerűsíthető a kockázat és a fájdalom.
- Úgyhogy reméljük, hogy ebből a mostohagyerekből akkor lesz egy elfogadott szeretet.
- Igen, hát ez a része szerintem ez egy full kommunikációs feladat.
- Igen.
- Mindjárt folytatjuk ezt a mélyfúrást itt az ellenálló képesség terén, de hát félidő van, és ideje ápolni a Digit Podcast hagyományokat. Mi ilyenkor mindig megállunk egy pillanatra, elfelejtjük a szakmát, és egy személyes témát is behozunk a beszélgetésbe. Hát te ezt már Karcsi többször megúsztad nálunk, úgyhogy most egy olyat hoztam, amivel még azért nem találkoztál. Ennyi mérés, meg értékelés után egy saját fejlesztendőre gondoltam rákérdezni, hogy van-e olyan dolog, amiben kifejezetten rosszak vagytok, esetleg már beletörődtetek, vagy még küzdötök ellene, még próbáltok benne fejlődni. Hogyan próbáltok, mi a stratégia, illetve mennyire tudtok azért nevetni ezen?
- Nekem a kertészkedés az, amiben határozottan rossz vagyok.
- A feleségemet nagyon megnyugtatja, nagyon szereti, de én egyszerűen utálom csinálni szó szerint, és igazából fél óra után azt veszem észre, hogy egyrészt, hogy a kérdésedre válaszoljak, már beletörődtem, tehát hogy szerintem ezen már nem fogok változtatni. Viszont egy ideig küszködtem vele, és akkor ugye a technikai ember előbújik belőlem, és akkor elkezdesz nézni még jobb sövényvágót, még drágábbat, még profibbat, satöbbi, és akkor egy ideig mentem ezen a vonalon, de igazából ma már eljutottam odáig, hogy úgy nagyjából félig levágom a sövényt, és akkor a szomszédok szoktak odajönni, hogy ez a vizuális katasztrófa, amit én otthagytam, akkor inkább segítenek befejezni, és akkor.
- Egy jó beszélgetés.
- Igen, igen, igen.
- Egyébként ez jó téma, hogy csak úgy mondod, a kertészkedés meg kerti barkács. Én nem vagyok jó benne, de hogy mondjuk úgymond nem ott van. Kétszer ugyanazt a javát nem szoktam elkövetni, csak ugye nagyon messziről kezdem, mert én nem foglalkozok ezzel sokat, csak éppen ami adja magát, meg ami a kíváncsiságom így belehajszol, hogy ilyet építsünk, olyat fúrjunk. De egyébként nem különösebben izgattam magam, a feleségemmel mindig mondjuk, hogy good enough, hogy már elég jó, és akkor itt megáll, de mondjuk egyik nyáron mentünk nyaralni, és akkor előtte mondom, hogy lenyírom a füvet jó alacsonyan, vagy nem nő meg két hétig egy kettessel, és akkor végig borotváltam az egészet, és a fűnek igen, a rezilienciáját azonnal meglőttem ezzel, és akkor már akkor oda volt a feleségem, és akkor visszajöttünk, és persze, hogy az egész kiégett.
- Erre jó ellenpélda vagyok, mert nekem ott a lóherék, meg a nők közben.
- A pampafüvek.
- Igen, igen. De ez jó példa szerintem arra, hogy amikor rossz metrikákat nézünk, tehát hogy lehet, hogy egyébként a metrikából azt nézed, hogy milyen fű, meg szép, nagyon szép rövid lett, stb. Nagyon szép rövid lett, de valójában a rezilienciát meg nem azt mondom.
- Azt meg nem használjuk.
- Az nem volt egy hosszú távú döntés, igen. Én egy régebbi példával készültem. Nekem kamaszként én egy introvertáltabb alaptermészetű ember vagyok. Nekem nagyon nehéz volt megszólalni több ember előtt. Tehát, hogy itt családi, baráti körben sose voltam dadogós, vagy nem tudom, de amikor ki kellett volna állni, akkor azért már igen. És emlékszem, egyszer valamiért elindítottak engem is a kedves magyar tanárom egy ilyen Kossuth-szónokversenyre, ahol fel kellett olvasni Kossuth Lajos egy beszédét. Tehát nem fejből ott volt a papír a kezedben, és akkor azt el kellett szónokolni, hát mit tudom én, 10 évesen, vagy 12 évesen nagyjából. És akkor én kiálltam ott a pódiumra, egy kultúrházat képzeljetek el 200 emberrel, elővettem a kis papírt, és akkor már remegett a testem, vagy egyre inkább az egész testem. És persze ettől a remegéstől az egyébként nem dadogós, hangom is dadogóssá vált, amitől iszonyú ideges lettem, hogy én soha életemben nem dadogtam, azt most itt izé. És ez engem annyira fölbosszantott úgy kiskamaszként, hogy hát ilyen nincsen, hogy azóta is folyamatosan figyelek arra, hogy egyre jobban tudjak megszólalni, meg egyre inkább mit mondok, mennyi idő, hány szó, hány hangsúly, nem tudom. És azt gondolom, hogy valamit sikerült ebből eltüntetni, hogyha nem mondom, akkor valószínűleg nem derül ki. És ez egy nagyon jó példa szerintem másoknak is, hogy bármennyire is alacsony szintről indulsz, ahogy te is mondtad, azért ha folyamatosan foglalkozol vele, akkor biztos, hogy tök jó szintre el lehet jutni. De feltétlen görcsölök mindenen ennyire, hogy ebből muszáj ilyen jónak lenni. Ez nekem fontos volt valahogy.
- Az ilyeneket igen, szerintem is meg kell oldani ahelyett, hogy visszavonulnánk. Nem, nem, de hát azóta meg podcast beszélgetéseket vezetsz.
- Most Mozart Andrea visszatérve, hogy hogyan is segít a módszer, mert ugye nyilván ezekben a témákban is a módszer, meg az eszköz az nagyon sokat számít. Van egy elem, ami engem egyrészt szórakoztat a módszertanotokban, másrészt azért sokkol is egy kicsit. Szóval előre megtervezett forgatókönyveket készítetek, és szándékosan elrontotok valamit, hogy kiderüljön, hogy na, akkor mi történik. És azért ez egy kicsit ilyen vakmerőnek is hangzik jó, mert tudjuk, hogy ezt nem az éles környezetben teszitek. De azért úgy érdekelne, hogy amikor ezt így elkezditek elmesélni, hogy ez fog történni, akkor egy ilyen pénzügyi igazgató, meg egy nem tudom, jogi megfelelőségi igazgat, az így hogy reagál ezekre a helyzetekre, illetve, hogy a valóságban hol húzódik a határa között, ami így kontrollált, és ami meg már mondjuk felelőtlen lehetne, vagy ki mindenkinek mesélitek el ezeket a cégnél, mert nyilván utána az, hogy kiderül valami, hogy akkor ott van egy, hát nem biztonsági rés, de egy ilyen performancia kockázat, mondjuk így nagyon csúnya szóval, azért az egy üzleti titok valahol, nem?
- Igen, ez nagyon bizalmas, tehát nyilván ez csak az ügyfélre és ránk tartozik.
- Na de az ügyfélnél is.
- Az ügyfélnél is, hogy kire, igen. Egyébként meglepő módon, tehát olyan szempontból nyitottság van, tehát hogy nem félnek tőle, nyilván elmondjuk a részleteket, hogy megyünk végig, pontosan mit takar ez. Szerintem, tehát én úgy látom, hogy vezetés szinten még örülnek is neki, hogy ezek úgymond tesztkörnyezetek, és hogy tényleg ki vannak használva olyan dolgokra, ami előrelendíti a szolgáltatásnak a minőségének a javítását. Technikai oldalon egyébként szerintem szintén ez egy izgalmas téma, inkább attól szoktak tartani az emberek, hogy nem lesz rá elég kapacitás, tehát hogy erre azért kell allokálni időt. Nyilván, hogy megértsük, ahhoz kell nekünk a túloldalról is segítség, meg interjúzunk, aztán ugye oda szeretünk eljutni, hogy az ügyfélcsapattal közösen csináljunk ilyen game day-t, tehát ilyen egy-két napos vagy egy hétbe át, abba belefér, és akkor elkezdjük piszkálni a tesztkörnyezetet. Nyilván egy kicsit lehet is dedikálni rá egy környezetet, tehát nem kell, hogy bárkinek a munkáját hátráltassa. Meg ugye, amit korábban mondtam, hogy ez egy lehetőség arra, hogy esetleg olyan dolgokat meg tudjanak javítani a technikai csapatban a megoldás a platformba, vagy a szoftverbe, amire eddig nem volt budget, meg figyelem, mert nem lehetett üzleti kockázattá fordítani. És ugye, hogyha egészében nézzük a rendszert. Tehát ez egy win-win, én azt gondolom, ettől függetlenül nyilván mindig van, aki kevésbé lelkes, meg hátrahúzódik, tehát meg kell találni a hagyományos bevezetésnél is itt is a Champion-öket, aki szeretné, hogy ez jól menjen, mondjuk, akit felhívnak éjszaka, hétvégén, hogy elrablott, az ilyen zeneérdekelt ember, tehát nekik szokott ez tetszeni.
- Igen, ha valaha volt már ilyen helyzetben, akkor szerintem utána a karrierje hátralevő részében erre különösen nyitott.
- Igen, én is sokáig, évekig adtam onkorszak portot, úgyhogy.
- Szerintem ez nem egy ilyen vadnyugati berohanunk és lövöldözünk, meg kell elképzelni, tehát ez egy nagyon komoly felmérésnek, meg egy aktuális környezetértékelésnek a végeredménye az, tehát ugye akkor, ha van egy jó baseline adatod, akkor tudod hozzá hasonlítani, hogy majd a fejlesztések során, ahova eljutunk, ott milyen különbség lesz, és az a különbség az, amit szerettél volna. Tehát itt maga például egy ilyen Game Day-en van egy Go No Go lista, tehát hogy az értékelésünkből még kiesnek metrikák, amik nem szerepelnek a környezetben, lecsekkoljuk, hogy tényleg fölébreszt-e téged a telefonod, hogyha olyan esemény történik, RTORP-hoz hozzá van kötve a megfelelő mérőszám, és ez jelez is, nem megy egy fekete lyukba a jelzés, tehát nagyon sok ilyen dolog van, ami hogyha nincs meg, akkor ez egy no-go állapot, és ha ezek megvannak, akkor kezdjük el a tesztet, általában egy nagyon szűk, hogy ezt Blastradiusnak mondják, a szakma körülhatárolt.
- Igen, ez nagyon jól körülhatárolt.
- Érinthet a történet.
- Lehet ezt megvalósítani, és ha ezek megvannak, akkor kezdjük el. És nyilván minden érintett tud róla előre, tehát nincsenek meglepetés torok.
- Ezt ugye előkészítitek ilyen elemzéssel, erről beszélgettünk az elején, és hogy most egy ilyen kanyart tennék. Tehát, hogy ehhez nektek van egy ilyen elemző platformotok, amiben én azt hallottam, hogy már mesterséges intelligenciát is használ a TC2, gondolom a nemzetközi felhőnyomásra. Na most ez logikus, hiszen rengeteg adat is, meg elemzendő terület van, de hogy két kérdést is föltennék. Az egyik, hogy vajon mennyire van meg az a veszély, hogy egy ilyen nagyon szép, nagyon tüchtigre megírt riport készül, mert a mesterséges intelligencia gyönyörűen összerakja, de ez egy kicsit elfedi az igazi bukkanókat, meg egy kicsit akár ilyen nagyzolósra sikerül. A másik meg, hogy nálatok hol kezdődik, vagy bocs, inkább úgy kérdezem, hol ér véget a gép az automatizmus, meg a mesterséges intelligencia munkája, és mi az, amit már az emberre bíztok?
- Hol találjátok, vagy hogyan találjátok meg ezt az egyensúlyt.
- Korábban az egyik korábbi főnököm mondta, hogyha a gépet személyteleníted meg, akkor szemét fog kijönni belőle. Tehát ez ma is nagyon igaz egyébként, hogy az élet úgy lehet jól használni, és azt tudja jól használni, akinek van egy domain expert ize, és ezt a domain expert ice köré használja az AI-t, hogy felgyorsítsa az információ átnézését, strukturálását. És egyébként szerintem ma az is egy általánosságban gondolkozva az is egy nehézség, vagy egy gond az AI-jal, hogy sokszor nagyon könnyű hosszú anyagokat csinálni, igaz? És akkor odaadom neked, tessék, itt van 100 oldal, és olvasd el. Tehát szerintem ez nem is tudom, tiszteletlenség-e, vagy mi a jó szó erre, de hogy nem szép, hanem most az éjjel korábban az a fontos, hogy jól átlátható információkat közvetítsünk, mert hiszen bárhány száz oldalra fel lehet dagasztani. Tehát, hogy válaszoljak is a kérdésedre. Nekünk is egyébként ezt kellett jól megtalálni, és azt gondolom, megtaláltuk ezt az egyensúlyt, hogy meddig megyünk el AI-al, hol van a humán kontroll pont, és hol van az az az expert review, ami egyáltalán, hogy mit néz át az AI, az a domain tudásunkból fakadóan pontosan tudjuk, hogy hova kell nézni, mert sok mindent lehetne nézni, de bizonyos dolgokra kell fókuszálni, kiszűrni a zajt belőle, és aztán Expert review-val ezt validáljuk, hogy ez helytálló.
- De most akkor gyakorlatilag van egy ilyen bulletpont listátok, hogy mi az, amit romboltok egy ilyen folyamatban?
- Mondtad, hogy ezt kellett jól megtalálni, csak hogy ez miben kristályosodik ki, vagy mi ennek a formája nálatok?
- Igen, tehát végül is ez egy prompt stratégia, mert ugye attól függően, hogy mi van az ügyfélnél, attól függően azért sosem csináljuk mindig ugyanazt kétszer, tehát mindig van eltérés, de ráadásul most a felülvizsgálatnál nemcsak a platformot, tehát az AWS beállításokat nézzük meg, hanem az alkalmazáskódba is belemegyünk, és ugye nyilván csak olvasási joggal, a forráskódot elemezzük, és ott is rávilágítunk esetleg olyan hiányosságokra, ami által vagy nem lehet jól monitorozni, vagy nem skálázódik jól, vagy nem fog jól viselkedni, vagy akár biztonsági sérülékenység. Egyébként ennek egy szájdefektusa nagyon vicces, de sokkal olcsóbban lehet futtatni aztán. Ha minden optimálisan skálázódik, jellemzően az abban merül ki, hogy sokkal jobb lesz az alap költségszintje a rendszernek. És ugye ez nem arra gondolok, hogy lekötünk erőforrást AWS-ben, hanem ugye a legtöbb pénz egyébként ott szokott elszivárogni, hogy az alkalmazáskód az úgy van beállítva, hogy nem optimális erőforrásokat foglal. Mert a fejlesztők jellemzően nincsenek mérve ezen, tehát ott mindegy, hogy mennyibe kerül, ők azon vannak mérve, hogy milyen gyorsan fejleszti a kódot. És akkor elég lesz neki 16 giga RAM, meg nem tudom, négy CPU, úgyhogy egy Microservice-t futtatunk, amit mondjuk nem tudom, de azért a telefonon el kell, hogy fusson mondjuk 50 belőle. És akkor ugye ezekből fakadóan, tehát itt nagyon sokat lehet fogni. És hát hogyha nagy a kódbázis, egy nem tudom, 10-20 éve fejlesztett szoftver, akkor azért itt is az AI-t kell használnunk, tehát nem tudjuk sorról sorra végignézni, itt is összefüggéseket keresünk. Vannak egyébként ilyen framework-ök erre, akár a kódolásra, akár az architektúrára, amikből kiindulunk, és hát aztán nagyon szép hosszú, nem tudom, több oldalas promptok lesznek belőle, én is megnéztem a srácokat, csinálták a legutóbbi projektet, hogy.
- Illetve, hogy ez skillek, tehát gyakorlatilag.
- Igen.
- Mitől lesz jó szakember egy jó szakember, ugyanattól lesz jó asszisztens egy AI is nekünk ebben az esetben.
- Tehát, hogy minél többet látsz, minél több dologgal találkozol, és utána mondjuk ezt csapaton belül egy tudásmegosztással átadod a többi mérnök vagy architekt kollégának. Ugye ugyanez történik itt is, hogy minél több adat kerül be a rendszerbe, annál minden egyes iterációval finomítjuk a skilleknek a képességeit. Gyakorlatilag, de hát szerintem elmondhatom, minél többel találkozik, annál jobban tudjuk finomhangolni, és annál kevesebb hiba lesz. De ez nem azt jelenti, hogy egyébként a végén emberi ellenőrzés nem lesz mögötte, de itt is törekszünk arra, hogy például hogy szűröd ki a hallucinálást, mert azért hajlamos valószínűsíteni dolgokat. Tehát itt is például a prom stratégiának egy nagyon erős része volt az, hogy minden egyes kijelentés mögött egy API visszacsatolásnak kell lenni, tehát ott kell lennie mögötte a findingnak a felhőben, amivel összeköti azt az értékelést.
- Igen, tehát azáltal, hogy AI-t is használunk, ez így nincs kész 5 perc alatt. Ugyanúgy interjúzunk, és akkor ezekkel az információkkal feldúsítjuk az interjúkat, és aztán ezt összeállítjuk riporterként. Nyilván a riporthoz is használunk AI-t, de a végén, tehát ahogy korábban is mondtam, nem mehet ki olyan, hogy azért végül az ügyfél és AI-jal fogja értelmezni, hogy mit küldtünk, tehát hogy nem szeretnénk. Tehát mi ember-ember kapcsolatot szeretnénk.
- Igen, ne vigyük el irányba nagyon, de hogy ez egy jó mankó nekünk, vagy nem is tudom, vagy egy segítség gyorsító eszköz.
- Hát igen, tehát sokkal gyorsabb, például az adatgyűjtés sokkal gyorsabb, mivel itt a célt tudod megadni neki, tehát egy determinisztikus kódod megvan, hogy mit tudom én, lekéred a computokat, kijön belőle egy lista, vagy Security A-ból lekéred a findingokat, lesz egy 200 oldalas listád, hogy szerintem hibás a rendszerben, de lehet, hogy a következő rendszerben teljesen más összetevőkből, tehát más erőforrásokból áll össze. Itt viszont meg tudod értetni vele, hogy mi a célja ennek az értékelésnek, és aszerint ugye kibővíti a keresést, nem maradnak ki az adatgyűjtésnél elemek.
- Még egy kellemetlen kérdést itt az elemzés kapcsán fel akartam tenni nektek, hogy ezeknél az elemzéseknél eddig csupa olyan helyzettel foglalkoztunk itt a beszélgetésben, amikor kiderül, hogy hűha, hát itt teendők vannak, meg nem igaz az, hogy minden zöld még akkor sem, ha annak látszik. De hogy mennyire találkoztok mondjuk azzal, hogy tulajdonképpen minden rendben van, apró-cseprő dolgok nem olyan fontos dolgok kiderülnek, de egyébként igazából nem találtatok semmi komolyat, és meg tudjátok-e ezt tartani, hogy akkor elmondjátok, hogy most így hirtelen nincs teendő. Illetve, hogy a szakma természete az mennyire ilyen, vagy egyszerűen készüljünk fel arra, hogyha jön hozzánk monitoringolni a TC2, akkor ott biztos, hogy találnak jó pár dolgot.
- Jellemzően azért mindig van valami, de egyébként olyanra is emlékszem, hogy nem. Nyilván akkor elmondom azt a példát elsőnek, ahol nem biztos, hogy érdemes. Például of the shelf termék, tehát ilyen dobozos szoftvert futtattak, ráadásul abból is az ilyen régi vágású, egy szerveren fut. Egy valami. Ott nagyon sok javaslatunk lehet arra, hogy üzemeltetés terén hogy lesz biztonságosabb, de mondjuk reziliencia szempontjából jellemzően az van, amit gondolnak, hogy ott van, tehát a szoftver az tudja, amit tud, azt nem tudjuk átvilágítani, hogyha dobozos, tehát ott nincs meg a forráskód, fut egy-egy lábon, tehát az kiszámolható, vagy tudják, hogy mennyi, ha tudják, tehát arra rávilágíthatunk, de mi ugye inkább az ilyen egyedi szoftverfejlesztésnél tudunk jókat mondani, és hát ott azért jellemzően nemcsak, hogy találunk valamit, hanem ugye ott is lesz egy hosszú lista, és megmutatjuk, hogy mi mivel függ össze, és hogy minek mi a hatása különböző üzleti kockázatok csökkentésére, vagy akár költségcsökkentésre, és aztán inkább az a kérdés, hogy melyikre fókuszáljanak, és még úgyis bepriorizáljuk, hogy melyiknek mi a prioritása olyan szempontból, hogy mekkora EFOTT, tehát hogy mekkora ráfordítást megcsinálni nekünk vagy az ügyfélnek, és mekkora az impaktja annak üzletileg, annak a változásnak. Tehát, hogy ebből egy ilyen mátrixot elkészítünk a feladatokból, és akkor nyilván a low affort high impact, tehát mindenki azzal szeretné kezdeni, de hogy ezek is összefüggenek egymással, tehát hogy nem kötöd le a nem tudom az AWS kapacitást, azelőtt, hogy ne right size-olnál, tehát hogy ne lenne jól méretezve, mert ugye ha előbb lekötöd, és utána jól méretezel, akkor lehet, hogy teljesen másképp legyen a lekötés. De most ez nagyon triviális, de hogy ennél nyilván jóval mélyebben bele tudunk menni. Úgyhogy most is azt látjuk az ügyfeleknél, hogy van egy nagy menü, és akkor attól függően, hogy mit fog mondani a CEO, hogy nekem most ez a fontos, vagy az a fontos, attól függően lesz így átstrukturálva az alakzata a feladatoknak, de mindegyiknek megvan az értelme, tehát hogy mindegyiket meghatároztuk, hogy mit nyernek vele üzletileg.
- Meg azt gondolom, hogy mérnökként, tehát ha mondjuk én ülnék a másik oldalon, akkor nekem az, ha én egyébként olyan információt kapok, amit magamtól elérek, az nem érték.
- Viszont az, hogy én kapok egy olyan elemzést, ami azt mondja, hogy figyi, hétfő reggel, ha fölkelsz, ezt a három dolgot, ez kritikus, ezzel kezd és mindenképp ezt csináld meg. Tehát ez érték, mert akkor megvan a kiindulópontom, tudom, hogy kapok egy akciótervet, hogy oké, akkor ezen végigmegyek, látom, hogy annak mi lesz a hatása, és ha azt megléped, akkor egyébként milyen egyéb problémákat tudsz orvosolni, mondjuk egy sokkal kisebb efforttal, mintha más sorrendben indulnál neki.
- Vagy ha eltörik a rendszer.
- Vagy ha eltörik a rendszer, akkor gyakorlatilag buktad el az egészet, igen.
- Igen, hát akkor ezeket a piros zárt listákat egy picit félre kell tenni, és majd egy-két hónap múlva lehet talán újra elővenni. Most tanácsadóként egy ilyen helyzetben azért nyilván külső tanácsadóként egy fontos szerepet is betöltetek, azt, hogy a főnök nem azt látja, hogy a kolléga ott az IT-n, aki okos, meg nagy mérnök, mert megint jön, hogy akkor ezt meg azt akarja csinálni, és hogy hát biztos csak fontosnak akar látszani, hanem van egy ilyen külső kontroll efölött, de hogy mégis az, ami tényleg fontos, mint téma, az azért oda be tud kerülni valahova a prioritási listákra. És az érdekelne még, hogy hát persze, ha szabad ilyen választ várni. De hogy mennyire jellemző az, hogy megpróbálnak ezekbe a listákba ezek a megrendelő oldali mérnök kollégák beszuszakolni olyan dolgokat, amiben ők hisznek, hogy hát szerintük az nagyon kéne, és hogy ha már itt vagytok, akkor azt intézzük már el, hogy legalább azt elkészíthessük, mert a főnök már nem tudom, hogy éve nem hagyja jóvá. Ugyanez, amit te is mondtál, hogy hát amikor fejlesztőként kezdted, akkor azért volt egy ilyen tiltólista a jó feladatokra, hogy hiába jó a feladat, de nem kell.
- Mi örülünk, hogyha.
- Aktív a partner?
- Aktív a gengszter, igen, a túloldal, és egyébként nincs is akadály, hogy ez bekerüljön, hogyha van értelme üzletileg.
- Tehát hogy ugye az soha nem lesz megcsinálva, vagy hát nem jó, ez erős kifejezés. De jellemzően csak azért, hogy technológiát próbálgassunk, azért nem szoktuk mi sem javasolni, hogy olyat nem írunk bele, amint van ennek valami kézzelfogható haszna, de egyébként jellemzően szokott lenni. Csak mondjuk aztán mindig az a kérdés, hogy az üzleti vezető melyiket látja fontosnak neki, mi van a fejében. Úgyhogy ebben partnerek szoktunk lenni. Elmondják nekünk, hogy mi a vágyuk a technikai csapatba is, és hogy ezt hogy lehetne kivitelezni, és akkor ezt hogy kell felöltöztetni, mi az értelme, hogy hogy van ennek a résznek az egészben az egységes nagy képben szerepel, és akkor nyilván elkezdenek így egymásra épülni, és hogyha ez is megvan, akkor ez jobb lesz, vagy olcsóbb lesz, vagy hibatűrőbb, tehát igen, általában.
- A gyakorlatban ilyennel még nem találkoztam.
- Tehát, hogy igazából egy ilyen gondolatmegosztás, vagy beszélgetünk egymással, és akkor ők fölvetik, hogy ők egyébként gondoltak erre, vagy arra, vagy mi a véleményünk róla, tehát általában ezzel szoktunk találkozni, vagy hogy ők ezt olvasták valahol, vagy találkoztak vele, látták valahol. Szerintük ez jó lenne itt, mit gondolunk róla, és akkor igazából egy szakmai párbeszéd van, tehát a te kibeszéled a te kivel.
- Tehát ez nem ennyire fennkölt általában, hanem egy három-négy mondatban ezeket le lehet rendezni, vagy megbeszélni, de olyannal még nem találkoztam sose, hogy na ezt mindenképp tegyük bele.
- Egyébként korábban nagyon sok olyan példa volt, nem tudom, 5-7 éve, hogy akkor kontinentalizáljunk, és akkor, de hogy ezt mi nagyon akarjuk, de hogy miért konténerezünk, és akkor ezt hogy derül el a vezetőnek? Hú, hát ebbe ennyi idő belemegy, akkor ezt is meg kell csinálni, azt is meg kell, amazt is. És akkor, tehát hogy most, hogy jobban skálázódik, tehát hogy ez egy vérszegény alátámasztás, tehát hogy igen, hogyha jobban köré megyünk, hogy akkor ha ez történik, ha kiesés van, vagy nem tudom, könnyebb a biztonsági szint, tehát könnyebben mozgatható platformok között, tehát egy csomó minden mást is hozzá lehet rakni. Nekem mondjuk ilyen példák azért vannak eszemben, amik aztán egyébként zömében meg is valósultak, tehát ami nyilván ilyen mainstream irány is volt a technológiában, hogy arrafele ment mindenki, és hát egyébként azóta is arrafele megy. De helyzete válogatja.
- De egy értékelésen belül el tudjuk ágaztatni is, hogy egyébként ez a megoldás ez ezzel járna, ezeket vonzaná a másik megoldás, az pedig milyen előnyökkel, hátrányokkal járna, és annak a megvalósítási költsége emberidőben, pénzbe, hosszú távú megtérülés, tehát meg lehet ezt nagyon könnyen csinálni, hogy.
- Akkor mégiscsak több lesz ez a két-három fekvő mondat.
- Nincs ilyen, hogy na, ez a tuti megoldás.
- Több tuti megoldás. Tehát egy dolgot azért nagyon sokféleképpen meg tudod csinálni.
- Szerintem egyébként ez a fontos, és ez az, amit mi nekünk a TC2-nek egy fontos része a profilnak, hogy ezt az IT consultingot, tehát hogy nemcsak megcsináljuk, meg nemcsak megmondják nekünk, hogy akkor csináld meg ezt, meg menj oda, meg szereld át a csövet.
- A zsoldoshadsereg vagy.
- Igen, hanem hogy na, akkor hova kerüljön? Most csak hogyha lefordítjuk ilyen nem tudom, házépítésre, hogy akkor szereld be oda a vízcsövet, és akkor ott lesz a fürdőszoba. Tehát, hogy szépen végigmegyünk, hogy így lesz berendezve, itt lesz ez a helyiség, az a helyiség, ott lesz a konyha, és akkor úgy alakítjuk ki, nem mintha most a csőszerelő lehet, hogy egy gyenge hasonlat, de akkor most már nem olyan nehéz.
- Igen.
- Egy záró kérdést hadd tegyek még fel két különböző céges élethelyzetet akartam idehozni. Az egyik az lenne, hogy a cég éppen egy modernizáció előtt áll az alkalmazás környezete vagy egy nagy alkalmazás kapcsán, és hát most küszöbön áll, hogy rengeteg pénzt el kell költsön. A másik, hogy ez körülbelül az ellentéte ennek, hogy hát úgy morfondírozva hallgat titeket egy konferencián, vagy esetleg egy podcast adást hallgat, de hogy úgy éppen nincsen semmilyen projektje a tervben, ők most csak úgy elketyegnek. Mit szoktatok, vagy mit mondanátok ennek a két cégnek úgy külön-külön, hogy mit kezdjen ő a rezilienciával?
- Kezdjem?
- Jó, jó, jó, jó, jó. Tehát aki modernizál, annak rendkívül egyszerű, ugyanaz, amit korábban is mondtam, hogy az ilyen reményteli számok helyett kell egy pontos mérést csinálni, hogy oké, most innen indulunk, ez a baseline, és hova szeretnénk eljutni. Tehát én mindenképp ha modernizálni szeretnék, ha tudni akarnám, hogy mi az az alap, ahonnan indulok. Tehát neki azt mondanám, hogy győződjön meg róla, hogy mi az az alap, ahonnan ő most indul. Aki meg így gondolkozik rajta, hogy kéne, nem kéne, vagy úgy nagyjából kész vagyunk, az meg azt tudom mondani, hogy maga az AWS, meg a felhőtechnológia egy nagyon gyorsan fejlődő környezet. Tehát lehet, hogy nagyon jó az a megoldás, amit használ, de most már arra van modernebb, olcsóbb, kevésbé komplex, tehát nagyon sok olyan megoldás, ami az alapkoncepción nem változtat, de sokkal hatékonyabb akár költségben, akár komplexitásban megoldást tudsz találni, de ez csak mondjuk egy éven belül is annyira fejlődik.
- Igen, tehát ahogy Viktor is mondja, nagyon sok minden kijön ezekből a felmérésekből, tehát még az ellenállóképességen túl egy olyan jövőbeli fejlesztési roadmap, tehát a modernizációnál mindenképp. Van egy beállt rendszer, amivel minden jó, meg jártunk már ilyen helyeken, tehát mindent tud. Nem szokott leállni, optimálisan működik, olcsóbb se kell, hogy legyen. Nyilván egyébként az is jellemzően kiesik ebből a felmérésből, hogy hogy lehet költséget vágni, úgyhogy még jobban is performáljon a rendszer. Szerintem itt az a kérdés, hogy van-e vezetői akarat, illetve mi a stratégiai cél azzal az adott szoftverrel meg üzleti szolgáltatással. Tehát ez meg a Big Ficture, és egyébként ezt szoktuk tárgyalni az ilyen migrációs felméréseknél. Tehát, hogy van ennek jövője, vagy ki lesz vezetve a jövő utánra, lesz-e ráépítve, egyáltalán az egy kór eleme, tehát egy központi eleme a bizniszünknek, vagy csak az, ami mindenki másnak is van, és akkor csak ott elketyeg. Tehát szerintem ilyen kérdések mentén, ha van vele cél, akkor mindenképp érdemes megnézni, mert nagyon sok jobbító ötlet lehet, és lehet, hogy a reziliens felmérés után akár új üzleti ötletek indulhatnak el, hiszen rengeteg szolgáltatás van az AWS-ben, amit nem tudom, adat, AI, vagy bármi egyéb ilyen innovatív vonalon blockchain, nem tudom, mindenféle példát lehetne mondani, rá lehet ott csatlakoztatni kis erőfeszítéssel, tehát hogy mi a stratégia, meg az üzleti vezetői akarat az adott termékkel. Szerintem ennek mentén érdemes megnézni. Tehát, hogy sokkal többet lehet vele nyerni, vagy hogyha más nem, akkor egy kis nyugalmat nyer az ember, meg magabiztosságot, igen, kipróbáltuk. Ugye minden EP meg RPO érték az csak egy dokumentáció, egy papír formájú feltételezés. Amint ezt validáljuk és kimérjük, onnantól lesz egy vezetői információ, hogy tényleg annyi, amennyi. Tehát hogyha fontos szerepe van a vállalatnak a működésében ennek a rendszernek, akkor szerintem mindenképp érdemes a beállt rendszert is megnézni.
- Ebben én is hiszek, hogy amit nem fejlesztünk, az romlik.
- Igen.
- Tehát azért ott nem érdemes csak úgy hátradőlni, hanem nézegetni kell a lehetőségeket, hogy jó, de akkor mi lesz a következő projekt és miért. Hát ennyi fért bele ma a többinek egy következő adásba, majd biztos a mi írásunk. És hát valóban nem a terv hiányzik, hanem annak a pudingnak a próbája az evésen. Viktor és Karcsi, nagyon szépen köszönöm, hogy eljöttetek a Digi Podcastba.
- Köszönjük szépen.
