3. évad – 3. epizód – Menedzselt szolgáltatások: amikor a partner irányít

00:16 Üdvözlök mindenkit, ez itt a DIG-IT Podcast Személyi László vagyok, a Future-NOW vezető partnere és társam a krimiben, Szekér Zoltán, az OD&IT Solutions és a SailingHangar alapító ügyvezetője. Sziasztok, jó napot kívánok! A DIG-IT 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.

00:41 Mi itt a mélyére fogunk ásni a dolgoknak.

00:47 Üdvözlet minden kedves hallgatónknak itthon és külföldön. A mai témáink milyen az ideális felhőszolgáltató partner, aki irányít is. A felhőben percek alatt lehet tesztelni új dolgokat, de vajon mennyi munka üzembiztossá tenni azokat, sőt akár skálázhatóvá tenni. Hasonló-e egy felhő alapú alkalmazás üzemeltetése egy iroda vagy lakóépület üzemeltetéséhez. Mekkora feladat a felhőben napi szinten érkező innovációkat és módosításokat lekövetni, és ki tudja ezt a követést jól elvégezni? Hát unalom ellen DIG-IT Podcast. Vendégünk Sepsi Károly, a TC2 volt technológiai igazgatója és újdonsült üzletfejlesztési vezetője. Köszöntünk a stúdióban.

01:30 Üdvözlöm a hallgatókat, sziasztok, és köszönöm a meghívást. Köszi, hogy eljöttél. Kezdjük gyorsan ezzel a titulussal. Jól mondom, hogy üzletfejlesztési vezető?

01:39 Mert az aláírásodban CBDO szerepel.

01:42 Így van. Chif business development officerre hallgatok, de igen, azt hiszem, hogy magyarul ez üzletfejlesztési vezető. Nemrég kerültem egyébként ebbe a Rolba, ugye nagyon sok évig voltam CTO, meg előtte Head of Engineering, most ma már azt látjuk, hogy egy jól meghatározott portfóliónk van, sok partnerrel dolgozunk, de hogy ugye az Amazon Map Services publikus felhőplatform zömében egy technológiai platform, hogy ebből az üzleti értéket is tudjuk definiálni, ez egyfajta külön roll, tehát hogy absztraktáljam, amit különböző területeken összeraktunk, és hogy ez hogy lesz emészthető mondjuk üzleti nyelven is. Tehát azt mondanám, hogy én a business és az IT között vagyok egy ilyen híd végül is, és nyilván a technikai vonalat pedig a nagyon jól bevált, igen, kolléga, a Molnár Sanyi viszi helyettem, úgyhogy ez egy ilyen win-win szituáció.

02:40 Hogy érzed magad az új szerepkörödben?

02:42 Alapvetően jól. Ez egy izgalmas terület nekem. Én nagyon szeretek egyébként emberekkel együtt dolgozni, meg megtalálni, hogy egyre több partnerrel dolgozunk, és attól, hogy valaki felhőzik és a fafelhőben valamilyen részt csinál, az sokszor nem kompetitor, hanem pont, hogy össze kéne állnunk. Nagyon sok esetben a cégek az egész felhős transzformáció ellen állnak, mert hogy mi lesz, hogyha így lesz, meg mi lesz. Van egyfajta ilyen félelem, mondhatnám, hogy irracionális félelem, mert nagyon sok pozitív példát lehet látni mostanra. És hogyha összeállunk más partnerekkel, akik kicsit mást csinálnak, akkor együtt sokkal több értéket tudunk vinni az ügyfélhez. És akkor nem az van, hogy mi ezt meg tudjuk csinálni, de fogalmam sincs, hogy hogy lesz ebből N2 &1 megoldás, tehát hogy üzleti értéket teremtsünk.

03:32 Tehát mondjunk egy példát, mondjuk mi be migráljuk az adatot a Data Warhouse-ba, de hogy a riporting Layer felett hogy lesz, hát azt én nem tudom. Most hogyha én ilyet mondok, akkor azt mondja a döntéshozó, hogy tök jó, hogy van egy Datawarehouse-unk, de ez önmagában semmire nem jó, ez egy technikai valami, ami lehet, hogy nagyon jól működik és felskálázódik. Nekem kell az egész csomag, hogy ezzel nyerjünk, és akkor pont ezt kell felkutatni. A mi csapatunkon belül is, hogy alatta vannak ugye ilyen technológiai domainek, hogy azok hogy működnek együtt, hogy lesznek ebből a mi solutionjaink, és aztán hogy működünk együtt más partnerekkel, és hogy aztán ezt új piacokra hogy visszük el, úgyhogy ez nekem egy nagyon izgalmas terület.

04:11 És nagyon kevesen beszélnek arról, bármilyen adást hallgatok és nézek, hogy van egy szervezeti változás, hogy az milyen alapon jön elő a szervezeti változás, mérést mértétek, vagy nem mértétek, ez egy ilyen egyéni kutatási kérdésem, de az innovációhoz köze van. Illetve, hogy amikor téged kineveztek, akkor te hogy élted meg ezt az egész kinevezéses információt, miközben persze felhőről beszélünk, hozzáadott értéket szeretnétek képviselni, egyre több szolgáltatást nyújtotok, és hogyha jól tudom, akkor maga a cég is kapott eggyel nagyobb minősítést. Jól emlékszem erre, hogy beszélgettünk? Ez a három kérdésem van, négy.

04:54 Igen, igen. Ez egy összetett kérdés. Egyébként ez nem egyik pillanatról a másikra történt.

04:59 Igen, tavaly nyáron kaptunk egy Strategy kollaboration agreementet az AWS-sel, tehát hogy üzletet fejlesztünk Közép-Kelet Európában. Egyébként ez is egyrészt indukálta a változásokat, tehát hogy nagyon fókusz kell ezekre a területekre, mert máshogy kell közelíteni mondjuk érettebb és érettebb piacokon a terjeszkedéshez és a publikus felhő evangelizációhoz, hogy így mondjam. Nyilván egyébként én nem pénteken tudtam meg, hogy ez lesz, tehát a CEU-nk, a Révész Robi ott elkezdte nekem pedzegetni, ugye mi sokat szoktunk beszélgetni, és akkor mi lenne ha, meg hogy te lennél erre alkalmas, vagy ha nem te, akkor ki? És hát én is gondolkoztam rajta. Ez egyébként relatíve hosszú folyamat volt, erről már tavaly nyáron is beszélgettünk, nem hivatalosan, és akkor ugye kialakult a szervezeti struktúra, tehát itt azért igen sok ember volt alattam eddig, tehát akkor azt átszervezni, feleségi köröket meghatározni, KIPI-okat, tehát hogy egyébként azt kell, hogy mondjam, hogy egészen profin álltunk hozzá itt a saját szervezetünket tekintve, tehát mindenkinek megvan a dolga, és hogy miért felelős, és meddig terjed, és honnan nem foglalkozik a dolgokkal, mert az máshoz tartozik.

06:15 Aztán igen, majd meglátjuk, hogy a jövő mit hoz, de nagy várakozásaim vannak ezzel, hogy mire jutok. Van sok tervem, és remélem, hogy be is fognak válni.

06:24 Szuper!

06:25 Na, én innen folytatnám. Tehát az első, hát azt mondom, hogy atomrobbanás ezen a piacon a ti szempontotokból az volt, amikor ti tavaly Manny Services partnerek lettetek, ami így nemhogy Magyarországon, de a régióban se nagyon osztogattak.

06:41 Nem akarom mondani, milyen nagynevű cégekkel együtt kaptátok meg, akik Amerikában több ezer emberrel dolgoznak.

06:46 Így van.

06:48 Azt hiszem, hogy ez egy tényleg kategóriaugrás volt, és én büszke vagyok arra, hogy azután kb. először nálunk szólaltatok meg részleteiben erről, hogy ez mit takar az ügyfelek szemszögéből, és hogy azóta pedig kaptatok egy ilyen újabb minőségbiztosítási kategóriát az EVS-től, ezt úgy hívják, hogy Partnerlet Support. Na most erről részletesen fogunk beszélni mondjuk az adás második felében, de hogy röviden azért emlékeztess minket arra, légy szíves, meg a hallgatókat is. Mi ez a két kategória, mit kell ez alatt így egy percben értenünk.

07:19 Igen.

07:20 Igen, tehát tavaly nyáron kaptuk meg a Melis Service Provider Rangot. Ugye az AWS-nél van nagyon sok program, meg kompetencia, meg service delivery, tehát mindenféle dolgok, amiket úgy intéznek, hogy kell hozzá valahány darab ügyfélkész tagé, és csinálnak egy auditot. Ez az MSP program kétnapos audit, tehát kétszer nyolc órát egy külső auditor, nem is az AWS csapatból, hanem az ő megbízottjuk, átvilágított minket, hogy milyenek a folyamataink, le van-e dokumentálva, következetesek vagyunk-e. Tehát ilyen ítélszerű működés, de egy elég rigolyás fajta Audit, tehát hogy én is ott voltam végig, én vezettem az Auditot, tehát hogy egy kemény dolog átmenni rajta, és nyilván ezért vannak ebben a bizonyos klubban kevesen, tehát globálisan azt hiszem 200-nál kevesebb partner van, de ugye itt a nagyok is ott vannak, az Accenture, stb. stb. A nagy cégek.

08:16 És mielőtt voltunk egy ilyen Next Generation MSP programban, hogy hogyan kezeljük az ügyfeleknek az AWS környezeteit és rendszereit. Vannak ilyen rajzok, most ez nem fog látszani. Amíg egy hagyományos rendszernél mondjuk ilyen nyilakat húzunk, hogy akkor tervezési szakasz, meg megvalósítás, és akkor élesbe ment, és akkor meg vagyunk nyugodva öt évre, le van írva a vas, meg ott fut a sarokban. Ugye egy felhős rendszerben, hogyha mondjuk egy Meryl Storage Provaler kezeli, akkor ez ilyen visszahat egy ilyen körrel, tehát hogy optimalizálunk, security review-t csinálunk, modernizálunk. Ez sokaknak egyébként rosszul hangozhat, hogy úristen, akkor ezzel folyamatosan foglalkozni kell. Igen, de azért, mert egyre jobb lesz és egyre olcsóbb lesz.

09:04 Ráadásul sok esetben, hogyha olyan rendszerről beszélünk, ami ki van nyitva publikus felhasználásra. A trendek is változnak nagyon gyorsan, vagy bemegy egy fejlesztés, és másféle erőforrások kellenek alá. Tehát igenis foglalkozni kell vele, hogyha azt akarjuk, hogy ez optimálisan működjön.

09:21 Na, ez engem nagyon szokott foglalkoztatni, merthogy üzleti szempontból ez a megtérülési kérdés, hogy én végrehajtok bizonyos beruházást, attól elvárok egyfajta hatékonyságjavulást, de mind a két oldalhoz tudok utána hozzányúlni, és adott esetben szoktam mondani előadásban is, hogy az üzleti döntéseinknek a szavatossági ideje jóval rövidebb, mint korábban. Tehát korábban valóban lehetett hozni akár 3-5 évre is döntéseket. Most is lehet, de csak sokkal szűkebb kategóriában a legtöbb döntésünk néha csak 3-6 hónapra szól. És hogyha itt a számszerűsítésnél maradunk, akkor mi a helyzet a költségszámításokkal? Hogyha mondjuk építek egy szervertermet vagy egy privát hálózatot, akkor relatíve egyszerű a matek, tehát összeadom a vételárakat, szerelési költségeket, üzemeltetési béreket, áramszolgáltatási díjat, nem tudom, teszek rá tartalékot, ha tudok, és esetleg műhiba meghibásodás, stb.-vel számolok.

10:21 És pont. De hogyha egy felhőberuházást próbálok tervezni, akkor ott milyen elemekből áll a költség, és egyáltalán lehet-e olyan pontossággal kalkulálni, mint egy szerverteremnél.

10:33 És még mielőtt erre válaszolnál, ami nagyon fontos kérdés. Szeretném kiegészíteni a Laci számolásából hiányzó egy mondatot. Kompliance költségek.

10:43 Ó, igen, igen.

10:44 Oké. Tehát van legalább négy különböző szabályozás, amit nekem a szervertermet építek mondatodban, meg kéne, hogy feleljek, meg kéne felelnem Dorának vagy Nis 2-nek, attól függ, hogy kritikus üzletág vagy pénzügyi szervezet. Ha nem akarok ezeknek megfelelni és el kéne gondolkodni a kockázatalapú megoldásokon, ami egyébként az ISO minősítésnek az alapja.

11:09 Igen.

11:09 Ehhez hozzátartozik az, amit mondtál, hogy ez a PDCA modell, és a totál quality managementnek az egyik eredője ez a körforgás is, hogy a hibákat kijavítani és a jókra visszacserélni, de ezekkel a költségekkel jellemzően nem számolnak. És most itt visszaadnám a Laci kérdését, hogy ezzel kiegészítve tudnál nekünk erre mondani?

11:35 Ez egy nagyon jó kérdés, a végtelenségig fejtegethető pontja a business case-nek. Mindig kell egy business case, tehát nem fognak csak azért úgy dönteni a cégek, hogy na, menjünk fel, mert úgyis kíváncsi voltam, meg szeretem a technológiát, és akkor bumm, akkor AWS. Egyébként hozzáteszem, hogy akár egy nem tudom, Ecomers-nek, vagy bármilyen cégnek, tehát hogyha az on-premise költségeket tervezik, tehát az, hogy az AWS-ben benne van mondjuk a hozzáférés menedzsment, mondjuk a naplózás, vagy a backup, tehát a mentések, ez mind kvázi ingyenesen. Ezt soha senki nem számolja ki, amikor valamit kiszámol a kompromisszumra. Jellemzően durván felülbecsülik a kapacitást, mert vannak bizonyos feltételezések, amik vagy légből kapottak, vagy nem, és akkor erre szokták sokszorosan felülbecsülni a kapacitást.

12:26 Az AWS-es költségkalkulációkban mi egyébként két lépést szoktunk megtenni, kétlépcsős esztimáció, ami igazán jól működik. Tehát van elsőnek egy business cased development. Egyébként ez szokott lenni az első lépés az ügyfelekkel a közös munkában, amikor felmérjük, hogy mi van nekik on premise-ben, vagy hogyha még nem létező rendszer, akkor mit terveznek. Mivel sok esetben nincs jobb, akkor ilyen úgynevezett liftenshift módon, tehát hogy virtuális gépeket virtuális gépekre fordítunk, és akkor csinálunk egy olyan kalkulációt, amiben már úgynevezett rightsizinggal, tehát hogy a valós igényekre, kapacitásigényekre lecsökkentve a méretezést, úgy számoljuk ki az AWS-ben. Nyilván, tehát igen, ez jellemzően, hogyha a meglévő rendszerek migrációjáról van szó, akkor lehet ezt jól becsülni.

13:27 És akkor kapunk egy olyan számot, ami nemcsak az infrastruktúrát, hanem sok esetben a licencszámot is lecsökkenti. Tehát van egy ilyen licenc optimalizációs business case. Óriási pénzeket lehet fogni egyébként rajta. Oracle és nem tudom, ennyi megannyi 100 CPU-ra van licencelve, holott közben a felén is elfutnak, csak már ötéves ciklusokban gondolkoznak a hagyományos beruházásoknál, nem tehetik meg, hogy mi van, hogyha duplázódik a work-lód. A felhőben simán ezt fel lehet skálázni.

13:53 Bocsánat, ezt egy hasonlattal szeretném megvilágítani. Tehát amikor veszünk egy cégautót, az jellemzően öt személyes.

14:00 De amikor használunk egy cégautót, azt jellemzően egy személy használja. Igaz, hogy tíz útból kétszer-háromszor többen is ülnek benne, ezért nem egyszemélyes autókat veszünk a cégbe, ugye?

14:11 Igen.

14:12 Na de mi lenne, hogyha lenne lehetőségünk naponta váltogatni, és nem is kéne foglalkozni, csak ott állni a garázsban vagy a parkolóban, az mikor, melyik autóban?

14:21 Manuális autó.

14:22 Kiegészítem ezzel a gondolattal milyen autó álljon a garázsban. Tehát, hogy azért azt nem árt tudni, hogy az öt személynek az összsúlya az 400 kilót meghalad, vagy nem. Ez az adattárolásra vonatkozik.

14:37 Mert azért úgy csinálnak beruházásokat többnyire, hogy menjünk felhőbe, mi baj lehet, csak közben nem néztük meg, hogy hány terával növekszik hetente.

14:49 Ez egy nagyon jó pont, igen, valóban. Tehát, hogy ezzel a kalkulációval, amit mondtam, tehát, hogy a vasat, tehát a szerverkapacitást, meg a diszkeket mondjuk, azt be lehet lőni a meglévő rendszerek alapján. A felhőben jellemzően, ami egy mozgó célpont, az például a data transzfert, hogy mennyi adatot küld oda-vissza, akár ki a polikus internetre, vagy mondjuk felhőrégiók között. Erre kellenek becslések. Ez egyébként ritkán tükrözi a valóságot. Mi nyilván tudunk segíteni az ügyfeleknek azzal, hogy már jó pár nagy rendszert láttunk és üzemeltetünk is, és tudjuk, hogy nagyságrendileg mire lehet számítani. Nyilván, hogyha több, akkor többet kell fizetni, ha kevesebb, akkor kevesebb. Ugye ez azért nem gond, mert ez a költségeknek jellemzően a 10 százalék alatt, de inkább ilyen 3 százalék alatti része, tehát a szerverekhez és a diszkekhez viszonyítva, tehát nagyságrendileg nem téríti el azt a számolást.

15:46 És akkor ebből lesz egy olyan bizniszkészünk, hogy ez ennyibe kerül, ennyi nagyságrendileg átmigrálni, és akkor van egy felhős, totál cost of warnership egy összköltség, meg van egy on premise, és akkor el lehet dönteni, úgyhogy nyilván vannak egyéb ilyen szoft faktorok mellette, például a compliance, tehát hogy egy felhőplatform már alapból komplient, és csak az alkalmazáson kell dolgozni, hogy megkapja az ilyen szintű plecsniket, illetve az innováció nagyon sokszor ott van, tehát hogy ott van az AI platformja az AWS-nek, és akkor az csak egy karnyújtásnyira van, lehet nagyon olcsón próbálgatni. És hogyha ez a biznisz kész, továbbmegy és zöldet kap, akkor tudunk olyat csinálni, hogy kialakítunk egy környezetet, ahol többféle rendszer is helyet tud kapni, ezt hívják Lendingsonnak, erre nekünk van egy külön termékcsaládunk, a Lazy-nek hívjuk, és ebben a környezetben egy-két proof of constant-et szoktunk csinálni.

16:48 Tehát vannak nagyon tipikus felállások, hogy hogy szoktak kinézni alkalmazások, tehát jellemzően vagy meglévő Legacy alkalmazásokat kicsit modernizálunk, tehát ilyen menedzselt adatbázis, menedzselt e-mail küldés, menedzselt autentikáció, akármi. Van, amikor konténerizálunk, és akkor ezáltal skálázhatóbb lesz, illetve van, amikor szerverleszre megy. Igazából ez a három fő típus, ennek van pár variánsa. Mindegyikből mondjuk kipróbálunk egyet, és megnézzük, hogy hogy működik, és úgy mennyibe kerülne az eredeti kalkulációhoz képest. És akkor lesz egy sokkal fontosabb rálátásunk, hogy mennyi lenne a valós költség.

17:24 Ez a második kör így van, a modernizáció után. Nyilván a modernizációnak is van egy effortja, amibe kerül, de ez is, hogyha az első alkalmazás konténerizálni mondjuk 5x idő, a másodikat 2x, a harmadikat már lehet, hogy csak x, tehát mindenki belejön, az ügyfél is érti, hogy hogy van, sokkal gyorsabban megy ez, tehát nyilván nagyobb volumenben sokkal jobban lehet ezzel haladni, és jobban megtérül. És akkor hát a biznisz kész, ezáltal így finomodik, tehát sokkal közelebb lesz a valósághoz.

17:56 Ide vonatkozó két kérdés az egyik, hogy van-e egy ilyen kockázatelemzés, vagy ez már az, amit mondasz, mielőtt elkezdődik a projekt. Ez egy fontos kérdés, tehát hogy A kockázatelemzés van-e?

18:11 A projekt kockázata, vagy magának az alkalmazásnak a cégnek az IT kockázatára van-e lehetősége, hanem projekt, az a kettes számú, tehát valamit meg akarunk valósítani. De az egyes számú, hogy tudjuk-e, hogy jelenleg milyen kockázatai vannak a cégnek kiberbiztonság téren. Mert ugye azt mondod, hogy meg fog felelni egy compliance típusú működésnek abban az esetben, amikor már bekerült, de tudjuk-e, hogy most mi az, ami nem jól működik. A másik, hogy ennek az egész átalakulásnak van-e ilyen előtét programja ez az átalakuláshoz szükséges program, ami a változáskezelés maga.

18:54 Igen, és igen, abszolút, megint csak jó kérdések.

19:00 Ez az egész, amiket, tehát ahogy business case-t készítünk, ahogy a Landingsont csináljuk, ahogy proof of concepteket futtatunk, ez a Migration Axeleration programnak a része, és hát egyébként nagyon jó túlokat ad az AWS rám, meg sorvezetőket, amiben nagyon jól a sokféle ügyfél, sokféle problémája egyébként szuperül beillik, de hogy a fő lépések mindig ugyanazok, hogy ezek a validációk, és ezáltal egyébként a kockázatokat is csökkentsük a migrációra nézve. Egyébként ennek a Migration programnak az elején mindig azzal kezdünk, hogy az egyes rendszerekre vetítve mondjuk milyen Recovery time objected, milyen recovery ponyt objected, hogy mennyi adatot lehet veszteni. Ezt most már rá szoktuk erőltetni.

19:45 Nagyon sok esetben halljuk, hogy nem tudom, meg hogy gondolj valamire, és akkor beírjuk. Tehát ki nforce tojik, még hogyha nincs is konkrét óra vagy perc vagy másodperces érték a fejükben, akkor kikonzultáljuk az ügyfélből, és akkor szerintünk ez szerinted is, és akkor szerintem is. Nyilván ez nagyon erősen a költségeket is befolyásolja. Az ritkán jó válasz, hogy mindig futnia kell, és soha nem állhatna meg.

20:14 Van az a pénz, hogy akkor füledezik az ügyfél, hogy miért ennyi. Úgyhogy ez is egyébként a kockázatelemzés része, meg ugye, hogy exit pen kell-e, jellemzően a nagyobb cégeknek mindig kell, akkor hogy lehet ezt kihozni, akkor hogy nem lesz lokin, tehát erről ezt minimum lepapírozni, esetleg kipróbálni kicsiben. Úgyhogy ilyesmiket csinálunk. Nyilván ez a platformszint, az, hogy az alkalmazásszinten ők hogy gondolkoznak tovább, abban mi partnerek vagyunk, de az ugye az ügyfélre vár ilyen esetben.

20:46 Most, hogy láttuk így a kiinduló döntéseknek a nem is egyszerű hátterét, és részben ez a célja itt a podcastunknak, hogy mit tudom én, írásunk a dolgoknak. Vegyük másra egy kicsit a menet közbeni teendőket.

20:59 Tehát az újonnan indult építőipari rovatunk első adását nemrég vettük fel, épületüzemeltetés volt a téma. Azt hallottuk, hogy alapvetően eredetileg két módszertan létezett, most már kialakulóban van egy harmadik. A hagyományos modell az üzemeltetésre épületek esetében ez a breakfix, hát nem meglepő módon, ha elromlik, meg kell javítani. Ebben azért túl sok intelligencia szerintem nincsen, de érdekes módon mégis nagyon elterjedt volt, és nagyon sokáig ennél állt meg a szakma. Az emelt színvonal az az úgynevezett prediktív karbantartás, amikor vagy szakértői becslés alapon mondom meg, hogy mikor kell majd a generátort, meg a szellőzőt, meg a nem tudom mit, vagy pedig még előrelátó módon beépítek bizonyos alkalmazásrutinokat, hogy figyelem, hogy mennyire használódik el, mérem a koszt, adatot gyűjtök, és adat alapon próbálok előre jelezni.

21:52 És hát a digitális eszközök elterjedésével egyre inkább beépülnek ezek a szenzorok és adatgyűjtő eszközök, tehát már okosak az épület, egyre több része, akár a fal is lehet okos, és ő szolgáltat adatot, nem kell nekem odamenni és méricskélni és adatot generálni róla, hanem kapok belőle adatot, és adott esetben ez a predikciót elég egyszerűvé tudja tenni. Na most az az én kérdésem, hogy eljött-e már ez a korszak, mondjuk a szerverek felhőbeli működtetése kapcsán, tehát hasonló-e a logika, hogy most már magától szól a rendszer, hogy mikor kell legközelebb átnézni, karbantartani, optimalizálni, akár biztonsági szempontból újratervezni.

22:36 Igen, egyébként nekünk nagyon könnyű dolgunk van ilyen szempontból a publikus felhővel, mert mindennek vannak adatpontjai, metrikái. Nincs olyan dolog, amit ott használunk, és úgymond bérlünk az AWS-től, és ne lennének különböző fajta ilyen metrika pontjai, hogy éppen hogy működik, mennyit fogyaszt, nem tudom, rendelkezésre áll, kezd betelni. Ezeket kell tudni jól használni, ebben nyilván tapasztalat kell. Tehát mi már a korai időktől fogva üzemeltetünk, és ott behoztuk ezeket az általunk meghatározott ilyen prediktív maintenance pontokat.

23:15 Hány százaléknál kezdjen el értesítést nyújtani?

23:18 Így van, a legegyszerűbb igen, mondjuk, hogy a diszkre elkezd betelni, akkor 80 százalék, akkor lehet, hogy még akkor nem ugrasz ki az ágyból, de már jó, ha tudod, akkor oldd meg hét közben munkaidőben. Mondjuk 95 százalék, akkor ugorj ki, mert akkor az lesz a következő, hogy bedől az egész. Ezek egyszerű példák, nyilván ennél jóval összetettebbek is vannak, illetve ahogy az AI terjed, az AWS is rengeteg AI service-t hozott be, és ennek egy nagy része az üzemeltetésben csapódik le. Anomália detekció a monitoringban, átnézi nekünk a network logokat, az api hívásokat, ott is nézi az anomáliákat.

23:52 Itt most egy kiegészítést szeretnék elmondani, jó, mert ez fontos lesz, hogy az AI-nak ugye nem az a szerepe ebben, hogy majd ő előre jelzi, hanem azokat a dolgokat jelzi előre, amivel rendszeresen egy elemzőnek minden nap több órányi dolga van, amiből ki tud égni maga az elemző. Mondok egy egyszerű példát. Jelszó, policy, ez szokott a leggyakrabban megtalálható ilyen. Ugye compliance-ben jeleznem kell, hogy a jelszó sérül, tehát hogy megpróbáltak belépni azzal a jelszóval. Ugye ez fontos. De ugyanis van, hogy a felhasználó elgépeli. De ez nem olyan mélységű, mint hogyha megpróbálnak bemenni. És nekem azokat kell kiszűrnöm, hogy hány olyan próbálkozásom van, amikor nem a felhasználó gépeli el.

24:39 És ezek, hogyha egy nap történik 17 ezer, akkor mind a 17 ezret ugyanúgy kell kivizsgálnom. És ezért fontos az, hogy egy AI előszűrje nekem, ezeket az ismétlődő munkákat végig tudja nézni 16999-szer, és egyébként az elemző csak azt az egyet, tehát a kiberbiztonsági felelős azt az egyet szúrja ki, ami ténylegesen fontos. Bocsánat, visszaadtam.

25:05 Ez nagyon fontos kiegészítés. Az AI tooloknak egyébként nagyon sokszor nem az a szerepe, hogy az ember helyett, hanem hogy az emberileg lehetetlen részt tegye mellé. Az én kiegészítésem az volna, hogy ugye minket sokan hallgatnak, akik nem informatikusok, hanem informatikusokat alkalmaznak. Döntéshozók, aki támaszkodik az informatikus tudására. És az ő esetükben azért bizonyos kereteket fontos látni, láttatni, és bizonyos beszélgetéseket szeretnénk indukálni közte és az informatikusai között az adás során. Ez egy jó pont szerintem arra, hogy ismét indukáljunk egyet. Tehát ha most nincs felhő a cégben, mert minden on-premise, minden fizikai gépeken, saját helyeken, még ha nem is ott az irodában, hanem valamilyen szerverparkban, de sajátom van, akkor vajon ezek a mechtikák rendelkezésre állnak?

25:59 Vajon van bármi predikció arra, hogy mi megy tönkre, vagy az van, mint a breakfix módszertanban az épületben, hogy majd ha elromlik, akkor meg kell javítani, és akkor három órán keresztül nem tudnak dolgozni a kollégák. Mit tapasztaltok, amikor ugye nekimentek ezeknek a felméréseknek, amiről beszéltünk az előbb.

26:17 Valamilyen monitoring rendszer jellemzően mindenhol van, de hogy ennek mennyire kifinomult a legyűjtése, vagy akár használata. Tehát itt azért elég nagy a skála. Igen, ezek az olcsó és jól működő AI-s megoldások, ezek jellemzően a felhőplatformhoz kötődnek, vagy hogyha a felhőben feltöltjük az adatot. Tehát egyébként nem kizárt, hogy mondjuk kompromisszum van a fejlesztésünk, ugye egy terület, ami a General CIA-nál nagyon jól működik, az a fejlesztésnek a hatékonyságának a segítése. Megkérdezzük, kiegészíti a kurdot, meg tesztet ír nekünk, erre több technológia is van, az AWS-nak is van ilyenje, és hát ez ilyen iparági mondás kezd lenni, hogy egy 30-40 százalékot simán lehet a hatékonyságba gyorsítani a fejlesztéseken.

27:06 Ehhez mondjuk nem kell a felhőben lenni önmagában, tehát ezt nyugodtan ilyen plug-en play oda lehet csatolni. Nyilván az üzemeltetési példa, amiket mondtam, az felelős rendszerekre vonatkozik leginkább, vagy valami olyan szoftvercsomagot kell megvennünk, ami on-premise-ben is ezekkel a kitanított modelleket ott már helyben tudja alkalmazni. Szerintem egyébként az a szuper az AWS-es platform megoldásokban, hogy rettentő olcsón adják, tehát nem is tudom, ilyen 5 terabájtot végigteker nekünk, megnézi az anomáliákat, és akkor ilyen egy dollár, tehát ilyen volumen. Nyilván ott is pár százat el lehet költeni ilyen igazán nagy rendszereknél, de hol beszélünk arról, hogyha magam tanítom meg a modellt, meg fine tune-olom, és akkor eldöntöm, hogy mi a hiba, meg mi a nem hiba.

27:52 És igen, elképesztő jól működik a legtöbb. Most bevallom én is, tehát hogy nem minden működik tökéletesen, tehát valahol nagyon sok a fals pozitív, és akkor itt a srácok is a csapatban, hogy te jó Isten, akkor inkább kapcsoljuk ki, mert ez már inkább nem segít, hanem nyilván mi is úgy használjuk, hogy casebye kész, amit jól meg tud tanulni, olyan patterneket, azokra jól működik, amit nem tud megtanulni, az ott lehet, hogy olyan variancia van, nem tudom, ahogy hívják az alkalmazást, hogy nem használható még egyelőre, nyilván ez is nagyon gyorsan fejlődik, tehát érdemes megnézni.

28:25 Mind a kettőtöknek a példájára mondanék még egy ilyen kis kiegészítő, ilyen gondolatébresztőket fogok ma mondani, én azt gondolom, hogy ugye az épületgépészetnél, ha már maradunk ennél, az egy dolog, hogy a tervszerű megelőző karbantartásnak hívták, azt az 50 évesek fogják tudni, hogy miről beszélek, tehát hogy néztük, és előtte voltak ilyen időablakok, amikor leállították, megzsírozták, megolajozták, kicserélték. Ezek elmúltak, erre vannak a szenzorok, az IOT eszközök, amik adják ezeket az információkat, de hát amit a legutóbb az egyik autóval fordult elő, hogy a két szenzor közötti vákuumcsövet egy állatka átrágta. De az autó azt érzékelte az egyik oldalon, hogy a turbó fölrobban, a másik oldalon meg, hogy most aztán vége a világnak, ezért ő konkrétan letiltotta volna az autó működés közben, miközben egy darab cső volt ténylegesen megrágva.

29:18 Jó szerelő emberünk a hangján hallotta a dolgokat, hogy mi történik, és kicserélte a csövet, és egyik szenzornak sem volt igaza. És ezt a felhasználói vakságot, amikor bízok mindenben és mindenkiben, úgy tudnám visszaforgatni egy épületüzemeltetésbe, hogy képzeljük el azt a klímaberendezést, ami fönt van a tetőn, tökéletesen működik, csak már öt éve nincs hozzá sem alkatrész, sem support. Ja, hogy és ez úgy lett tervezve, hogy nem lehet kicserélni, merthogy tervezéskor, építéskor tették be. És nekünk mégis le kell cserélni, mert változott a tűzvédelmi előírás, változott a zajelőírás, változott a rezgéselőírás. Jelen pillanatban ezeket a dolgokat, ha nézem egy üzemeltetési környezetben, számítógép központokban, ugyanígy elhiszik a cégek.

30:20 Megvettem egy szervert, ott van a szerver, van rajta monitor, meg hőmérséklet van. Ad a szenzor jelet? Igen, de közben nem cseréltük ki. És azt gondolom, és ezért fontos és próbálom egy picit ezt a gondolatot visszaadni, hogy nem mindig azért kell elgondolkozni azon, hogy csak rögzítve legyen helyben, vagy csak felhőben, hanem ez a hibrid megoldás, mert ez a kérdésem tulajdonképpen, hogy mit gondolsz arról, hogy százalékban a felmérések alapján a hibridet hogy tudjátok jól kezelni, hogy egyébként vannak olyan megoldások, amikor a szenzorok elhelyezése a felhőben nagyon fontos, mert egy prognózisban elöregedő gépparkot kell ideiglenesen áttennünk felhőbe, hogy kicseréljük a hibridnek a földi részét.

31:11 Ez egy teljesen valid use case. Egyébként nagyon-nagyon sok hibrid rendszer van. Jellemzően a nagyvállalatoknál, tehát ahol már beruháztak On Premise Data Centerekbe, ott nem is szeretnék teljesen elengedni, meg ahol megvan a stáb, hogy ezt üzemeltessék, és akkor úgy kell összerakni, hogy ez a két világ jól együttműködjön. Ráadásul a felhőben is van, ami kifejezetten jó megtérüléssel kecsegtet, van, ami meg csak úgy összehasonlíthatóan jó. Egyébként ez egy nagyon jó példa, hogy áthelyezzük, tehát ez az ilyen birth kapacitás, hogy ideiglenesen több kapacitásra van szükségem, akár mert nyugdíjazzuk vagy lecseréljük, akár mert nem tudom, tesztelünk, akár mert Black Friday van, és akkor pluszban.

31:52 Szezonális.

31:54 De egyébként a Disaster Recovery is nagyon jó, nem is muszáj teljesen felmenni, de miért van egy másodlagos Data Center? Ott sok esetben az egy olyan plusz költség, amit egyébként ki lehetne mozogni, és akkor ki van próbálva a felhőbe, majd hogyha kell, akkor ott fut. Ugye attól függően most visszatérve az RTO, RPO, tehát hogy mennyi idő alatt kell átbillenni, hogyha mondjuk Disaster van, ez nagyon-nagyon fontos, mert hogyha aránylag megengedőek vagyunk, és mondjuk van rá egy fél napunk, akkor lehet ezt a pilot light, ilyen earlang nevű disaster recovery megoldást alkalmazni, hogy nagyon kis mértékű infrastruktúrát, vagy akár csak a mentéseket rakjuk a felhőbe. A felhőben van ez az úgynevezett infrastructure kód, hogy kódként tudjuk definiálni az egész felhős infrastruktúrát, és akkor egy paranccsal fel lehet építeni az egészet, cakk-pakk.

32:45 Az egész Datacenter, mint kód kvázi megfogható, és amíg nem kell, addig meg nem fogyaszt pénzt. Ez olyan, mintha lenne egy lekapcsolt Disaster Recovery site-unk. Ezt azért nagyon nehéz agyonvágni egy on-premise szemlélettel business case-ben, tehát hogy ráköltött forintokat nézve. És engem még egy gondolat az Infrastructure Scote, ez egy hosszú válasz lehet, de mi szoktuk. Ugye, hogy megkaptuk ezt a Manny Service Prider programot, mi előtte benne voltunk egy ilyen Next Generation MSP programban, és akkor mindig kérdezik, hogy mitől next generation ez, hogy te még Old Generation, én már Új Generation, tehát ez ilyen megfoghatatlan. De az a tény, hogy az új fejlesztések, akik igazán modern, jó módon csinálja a felhős fejlesztéseket, infrastrukturális kóddal csinálja meg a rendszereit, és akkor definiálva van, hogy hogy áll össze a hálózat, a szerverek, mi kerül rá, hogy lesz ebből CIC Repipeline.

33:44 Micsoda? Bocsánat, mert ezt nem minden hallgató fogja.

33:47 A CIC Repipeline, tehát hogy hogy hogy lesz automatizálva az újabb változásoknak a publikálása az infrastruktúrában, vagy a szoftver.

33:57 Tehát az élesítési lépcsőknek a.

33:57 Így van. Egy picit megint csak a tolmács robot hadd jöjjön ki belőlem, jó?

34:04 Jó.

34:05 Tehát ahhoz, hogy valamit élesítsünk, ugye ott a compliance policy-hoz, tehát a compliance szabályokhoz képest is végig kell néznünk, hogy meddig tart a tesztszakasz, meddig tart élesen az áttelepítési és a tesztszakasz, és onnantól mikor engedélyezzük éles futásra, és engedjük rá a teljes terhelést. Ezeknek az idejét nagyon fontos megbecsülni, kettő, mivel hogyha most megint csak maradjunk Doron is kettő izzó, mindenhol definiálva van, hogy milyen időszakonként, milyen típusú riasztásoknál kell a frissítéseket mondjuk föltelepíteni, amiben nem lehet egy terhelés alatt lévő rendszeren frissítést telepíteni, sőt, hogyha mondjuk egy kritikus alkalmazás, mondjuk vízellátás a városban, ha a vízellátó szerveren, mondjuk egy, ez biztosan emlékeztek a kékhalálos történetre a reptereken, amikor bekövetkezett, hogyha ilyen egy vízellátásban is bekövetkezik, akkor az az Álmoskönyv szerint nem jelent jót.

35:12 Erre kell különböző poliszikat kitalálni, aminek lehet az egyik lába az, hogy én letesztelem magát a frissítést a felhőben, és egyébként miután ott lefutott, az éles környezetbe átteszem. Akár a felhőből működve, ez nyilván most nem akarom az összes létező kiberszekurity biztonsági szakértőnek a miért nem mondtam, mit mondtam és mikor mondtam a haragját magamra húzni, tehát hogy képzeljük oda, hogy a teljes szabályrendszer mellett meg van határozva, hogy hogyan csinálom végig, de ennek, és akkor itt, hogyha ezt így végigmondanád, akkor.

35:51 Nagyon jó, hogy behoztad, igen, ez egy nagyon jó gondolat, mert akkor csak rácsatlakozva erre. Tehát hogyha a felhőben felépített infrastruktúránk, mint infrastructures kód, az egy szoftver, akkor ennek a változásait is ugyanígy kell kezelnünk. Tehát ez nagyon sok esetben csak úgy ott van, meg valaki kattintgat. Mi, ahogy üzemeltetünk, tehát megvan ez a kód, ami magát az infrastruktúrát definiálja, és ez ugyanúgy egy szoftverkód, ezt ugyanúgy frissítjük, ennek ugyanúgy van egy meghatározott sorrendje, hogy hogy lehet változtatni, az bemegy a szoftverkódnak a verziókezelő rendszerébe, vagy a gitbe, és hogyha van egy változás, azt jóvá kell hagyni. Na most, hogyha van egy változás, akkor biztos, hogy van egy ticket is a GIRÁ-ban, tehát a jegykezelő rendszerben, hogy valaki kért egy változást.

36:37 Ott van, hogy ki kérte, milyen pozícióban kérhette el. Tehát ez az egész az ISO szabványoknak és az italszerű működésnek az alapja. Nagyon sok helyen azt látjuk, hogy csinálnak egy ilyen infrastruktures kódot, lerakják egyszer, és akkor jól otthagyják, és akkor mindenki össze-vissza kattintgat, és akkor megnézed, és ezt úgy hívják, hogy drift. Tehát, hogy a valóság, ami ott van, meg ami a kódban van definiálva, az teljesen köszönőviszonyban sincs egymással. Úgyhogy csak hogy visszatérjek az elejére, ami nagyon hosszú körvonat volt, de hogy mitől vagyunk mi Next Generation MSP? Hát attól, hogy például így üzemeltetünk, és hogy ennek a teljes folyamatát és életciklusát eszerint kezeljük, tehát a change management is ilyen alapon megy, és ezáltal egyébként a kitettséget is óriási mértékben lecsökkentjük az ügyfelek számára, hogyha tőlünk függenek.

37:27 Ugyan én nem akarom a TC2-nek adni a rendszerem, mert akkor mi van, hogyha visszaélek bármivel, vagy hasonló, de hisz ott van a kód, és ez a kód, ezt nem mi találtuk ki, ez egy iparági sztenderd most már, ahogy az összes fejlesztő és felhős mérnök ezekkel a platformokkal interaktál és dolgozik. Tehát kvázi bárkinek átadható, ez világosan megvan, ez gépi kód, tehát ez nem a mi szubjektív véleményünk.

37:53 Úgyhogy ezáltal a függőség is az irányunkba le van csökkentve, hiszen ez egy jól dokumentált rendszerkód, és igen, hogyha úgy dönt az ügyfél, hogy nem tetszik a TC2, mert nem jól látja a feladatát, akkor lehet máshoz menni, aki jobban teszi.

38:08 Most lehet, hogy ez egy elrugaszkodott hasonlat lesz, de megmagyarázom, hogy ne legyen félreérthető. Szóval most az, ahogy hallgattalak téged, az fogalmazódott meg bennem, hogy ti vagytok a felhőinformatika Disneylandje. Miért mondom ezt? Nem tudom, tudjátok-e, vannak ezek a tanácsadó cégek által nagyon nagy munkával elkészített felmérések, hogy milyen ügyfélélményt érnek el különböző iparágakban cégek, és mondjuk ki az, aki az ügyfélélmény csúcsa. Merthogy van egy ilyen pszichológia, hogy a legjobb élményeinkből lesznek az elvárásaink, tehát aki a csúcson van, az diktálja, hogy az ügyfél mindenki mást mihez viszonyít. És igazából, amíg nem tudom, hogy olyan minőségben is ki lehet engem szolgálni, addig lehet, hogy nem hiányzik, de ha egyszer én megtapasztaltam, hogy milyen Disneylandben ügyfélnek lenni, én még nem tapasztaltam meg, de beszéltem ilyen emberrel.

39:00 Disneyland a szórakoztatóiparban a legnagyobb ügyfélélmény. Tehát ott, mikor te veszel egy jegyet, már gyakorlatilag csak online tudsz, onnantól kezdve egészen odáig, hogy jövőre is milyen lehetőségeid vannak, minden Disney and alkalmazott pontosan tudja, hogy te ki vagy, pontosan tudja, hogy miért akarsz, mit szerettél volna a Disneylandtől, mi lehet neked a legjobb következő lépés, és milyen útvonalat jártál be eddig, és mennyi időd van még hátra, és nem tudom. Olyan magas minőségben tudnak téged személyesen is, meg elektronikusan is kiszolgálni, hogy minden mást ahhoz kezdesz viszonyítani. Én azt hiszem, hogy ti egy kicsit ilyenek vagytok ebben.

39:42 Egyébként most egy kutatással most én leszek a számok embere, és a Lacinak a gondolatait egy kutatással támasztom alá, hogy gyakorlatilag az történik, hogy ügyfélélményt szeretne fejleszteni azoknak a cégeknek, a piacvezető cégeknek a 80 százaléka, aki már AI-ja a támogatott megoldásokban ügyfélélményt próbál fejleszteni AI-jal. Oké, ezt értjük. Tehát 80%-a a piacvezető cégeknek AI-t vezetett be azért, hogy az ügyfélélményt fejlessze, és AI-jal szeretné az ügyfélélményt fejlesztené. A legnagyobb probléma az az, hogy jelenleg nincsenek ügyféladatok.

40:26 Anélkül nehéz AI-jal foglalkozni.

40:28 Oké, de félidő elmúlt, szóval, hogy mit szólnál Zoli hozzá, hogyha feltennék egy személyes kérdést.

40:33 Hát szerintem most zavarjuk össze a vendégünket.

40:37 Az a jó, hogy ő már volt itt, úgyhogy tudja, hogy mi vár rá.

40:39 Igen, de nem ugyanaz a személyes kérdés, nem tudja mi merre. Múltkor az iskolákról beszélgettünk, legyen most a szabadidő. Mit csináltok akkor, amikor semmi dolgotok nincsen? Mi tölt fel titeket, és erre mikor jöttetek rá, és mennyi idő kell erre minimum, hogy elkezdjetek egyáltalán egy olyan tevékenységet. Elég-e öt perc, vagy kell egy nap?

41:03 Szeretem ezeket a kérdéseket egyébként, igen, a munka magánélet. Egyébként elég sokat sportolok, és most rögtön vissza is kötöm a céghez, de csak azért, mert például most fogjuk, nem is tudom, milyen félmaraton ez a Visita Sváb Sváb Maraton, ami most lesz április közepén, és akkor beneveztünk csapatként. Tehát van, aki váltót fut, van, aki egyénileg, de hogy nálunk a cégnél is nagyon sokan szeretik a sportot, és egy komoly hely van mindenkinek az életében, tehát egyébként a menedzsmentben is mindenki elkötelezetten egy-egy sportot űz. Én egy kicsit mindenevő vagyok, de egyébként így szoktam kikapcsolni jellemzően, tehát igen, mindenfélét csinálok, úgyhogy ez nekem az egyik ilyen szabadidős rekreációs tevékenység, nyilván a családi programok és a hasonlók mellett.

41:56 Úgyhogy most a csapatépítőnk is ilyen kalandparkban lesz, és akkor mindenféle ilyen ide-oda átmászunk, meg lecsúszunk ilyen drótkötélpályán. Szerintem szuper egyébként, nyilván valaki kevésbé szereti, van, aki jobban, de ez összetartja a csapatot, összekovácsolja. Úgyhogy nekem nagyon fontos az ilyen jellegű program is, tehát hogy ne csak adott esetben napközben is, tehát volt már, hogy felbujtottam itt a kollégákat, és akkor elmentünk falat mászni, mondjuk ebédszünetben jöttünk-mentünk gyorsan, és akkor egy gyors ebéd, és akkor ezek teljesen beleférnek. Én mindenkit bátorítok, hogy legyen ilyen kis kiszakadás, és akkor nem nyolc órát kell ott egy helyben ülni. Úgyhogy igen, ilyen szempontból elég színes a társaság nálunk.

42:39 Laci?

42:41 Nekem kettő is van, az egyikhez sok idő kell, az mondjuk minimum egy nap ahhoz, hogy elkezdjem, amikor hegyet mászok, vagy hegyen kirándulok, nem vagyok ilyen sziklamászó, ahhoz még sok minden kéne, de nagyon szeretek magas hegyek, völgyek környékén túrázni. A másik, az viszont pont elkezdhető akár 5-10 perc alatt is. Én mai napig nagyon szeretek olvasni. És az engem kifejezetten kikapcsol, sőt ilyen egészen vad, akár romantikus vagy burleszk regényeket is el tudok olvasni, aminek tényleg már semmi köze a magas irodalomhoz néha, de mégis azért valahol a szókincset, a gondolkodást, de főleg az érzelmi intelligenciát ébren tartja, nálam legalábbis, és tökre kikapcsol. Zoli?

43:31 Az egyik a makettezés. Tehát, hogy én kicsi műanyag izéket kivagdosom, összerakasztom, befestem, és lesz belőle egy kész termék. Azt hiszem, ez a gépész agyamat elégíti ki funkcionálisan, hogy nem akadályozzák meg, hogy késztermék legyen, hanem hogy elkészülhet végre valami. Nagyon sokszor van egy csomó olyan projekt, amit csak úgy megcsinálunk a fióknak, és sosem készül el, de ezt nekem valahol meg kell csinálnom fizikai módon a másik, hát ez a vezetés. Tehát el szoktam menni. Amikor tényleg arra van szükségem, hogy nagyon kikapcsolódjak, akkor el szoktam menni gokartozni. És lehetőség szerint ott úgy élem ki, hogy hát nagyon, tehát vezetek, nagyon vezetek.

44:21 Mindenkit leszorítasz.

44:22 Nem, abban például nem, de olyan volt, hogy kivettem a pályát, és én köröztem egyedül. Tehát, hogy ahhoz volt kedvem, hogy nem akartam én leszorítani senkit, de hogy hadd megyek haza saját ütememben. Ez sokat számított. Tehát, hogy két óra után nem tudtam gyakorlatilag kiszállni az autóból, mert annyira kifáradtam, de hogy ez egy elképesztően nagyon jó fókusz volt.

44:46 Volt ilyen csapatépítőnk is, ilyen gokartozós, és emlékszem a meglepetésre, hogy egyes kollégák, akik nagyon visszahúzódók voltak, és ott előbújt belőlük a kompetitív, igazi énjük, és akkor csak azért, igen, ott jót mosolyogtunk, aztán.

45:01 Nekünk is a legutóbbi Futureales csapatépítőnk gokarttal indult, úgyhogy ez azért nálunk is megvan, de nekem a túrázás jobb. Viszont eszembe jutott, hogy igazából, ha valaki veletek dolgozik, a TC2-t erre használja, hogy az infrastruktúráját modernizálja, most mondjuk felhő segítségével, de itt nem a felhő mágiája a lényeg, hanem a praktikuma, akkor több szabadideje lesz. Legalábbis jobban tervezhető szabadideje lesz, mert nincs annyi váratlanság szerintem benne. És valahol megkapó az, ahogy ti ezt termékesítettétek ezt a szolgáltatásotokat, mert úgy hívjátok, hogy Cloudsen.

45:40 Cloudsen.

45:42 Na most milyen ez, amikor a támogatást valójában a támogató partner irányítja? Ez egy kicsit elsőre, hogyha valaki nem hallgatta volna az adás első felét, és csak ennyit hall meg, hogy partner lett support, akkor hát de nehogy már én fizetek, akkor én irányítok. Most akkor ez hogy is van?

45:59 Igen, tehát alapvetően a clouds and back két típust különítünk el, van a partnered support. A partnered supportnál az AWS hivatalos support elé állunk, tehát mi vagyunk a level1, hozzánk jönnek be elsődlegesen a problémák, a ticketek, és mi vagyunk az AWS-nek az ügyfele a support szempontjából, ami azért jó, mert nekünk vannak bejáratott kapcsolataink, tudjuk, hogy kihez kell fordulni. Sajnos, hogyha az ügyfél direktben a AWS-sel, akkor sokszor azért megfordul India fele, és akkor nekik az AWS level 1, meg leveleket, ki tudja, hogy hány szint van, tehát mire eljut oda, hogy tényleg problémamegoldás legyen, azért az hiába 15 perc az SLA, ugye többnyire ez körbeér, és valódi válaszokat kapnak. Cserébe mi ugye itt vagyunk helyben, és jellemzően az ügyfeleinket is ismerjük, és sokkal-sokkal hamarabb kapnak megoldást.

46:55 De egyébként a partnered Supportnál alapvetően ez egy ilyen reaktív együttélés. Ezt akkor szoktuk ajánlani, ha az ügyfélnek van AWS technikai stábja, tehát értenek hozzá, tudják üzemeltetni, de kéne gyártói support, és ennek a színvonalát szeretnék emelni. Ráadásul egy olyan csomagunk van, ami szerintem kihagyhatatlan ajánlat, csak mondom, tehát hogy ár-érték arányban. És hogyha esetleg az ügyfélnek nincsen sok embere, vagy nincs embere, vagy nem ezzel akarják, hogy foglalkozzanak, akkor van a Menit Services, tehát az MSP csomagunk, amikor azt mondjuk, hogy nem csak reagálunk, hogyha valami bajotok van, az is benne van, tehát ez is tud partneret, supportot is, plusz még a rendszereiket monitorozzuk, és folyamatosan fine-tune-oljuk.

47:41 Egyébként ez egy olyan dolog, ami nekem szívfájdalmam, mert finomhangolhatok gyakorlatilag.

47:45 Finomhangolunk, igen. Az ügyfeleknek ez szerintem láthatatlan, szoktuk nekik mondani, hogy csinálunk ilyet, de mi minden hétfőn leülünk, és mindent átnézünk, és ugye vannak meghatározott trasholdok, nem is tudom.

47:58 Küszöbérték.

47:59 Küszöbérték, köszönöm.

48:02 És azokat finomhangoljuk, hogy hol kell, hogy jelezzen. Tehát hogyha túl sokat kiabál, akkor lentebb vesszük, hogyha nem kiabál eleget, akkor fentebb vesszük. Ezt szoktuk az anomália detekcióval, tehát ilyen AI alapon is kiegészíteni, tehát az egy plusz döntési faktor, és előre látjuk, hogyha valami gond lesz, hogyha valahol ott kilóg a lóláb, és akkor nagyon sok olyan dolog van, amit mi is meg tudunk oldani önállóan. Nyilván nagyon sok dolog van, amit az ügyfelet meg kell kérdezni és jóváhagyást kell kérni, de itt szintén átnézzük, hogy lehet-e optimalizálni valamit, és akkor itt is van. Tehát hogyha ez nem, nincsen olyan business inpactja, tehát ami bármi fennakadást okozna, akkor megcsináljuk magunktól, hogyha jóváhagyást kell kérni, vagy esetleg el kell köteleződnie az ügyfélnek az AWS fele mondjuk egy évre, vagy három évre, nyilvánvalóan ezt azért nem saját szokásra tesszük meg.

48:50 Tehát az MSP csomag az meg egy olyan, hogy igazából minden gondot leveszünk az ügyfél válláról, és hát elég nagy ügyfelek is használják ezt, tehát mondjuk egyharmad eséllyel, aki telefonál, annál az ügyfelünknél van, de ott is tehát a legnagyobb dicséret, hogy nem tudom, tehát már hat éve dolgozunk velük, hogy soha semmi gond nincsen, mintha nem lenne, mert mi mindent megoldunk. Nyilván ennek az is a hátránya, hogyha nem kap elég fókuszt az üzleti oldalon, akkor mi nehezen tudunk egyezkedni az ügyféllel, hogy mi történjen. Tehát mindig kell, hogy legyen egy felelős a túloldalon, akivel tudunk érdemben egyeztetni.

49:29 Szabályozott környezetben van.

49:30 Így van.

49:30 Tehát, hogy azért az nem árt, hogyha vagy az IT főnök, vagy pedig az IT biztonsági felelős, azért a túloldalon ott van.

49:36 Mindig kell, hogy legyen valaki, tehát hogy azért nem jó, hogyha nagyon magunkra vagyunk hagyva, mert akkor a mi hatékonyságunk is ezáltal lassan tudunk döntéseket hozni az ügyféllel, és nyilván annak is örülünk, hogyha technikai stábból is van, aki követi és visszacsatol, és elmondják az ő terveiket, tehát hogy nekünk jó tudni arról, hogy mi történik mondjuk az alkalmazással, tehát hogyha kampányt indítanak a marketing tooljukba, és akkor miért látjuk azt, amit. De egyébként összességében egy teljesen önműködő szolgáltatást adunk az ügyfélnek, és akkor nyugodtan alhatnak, tehát zenben alszanak.

50:13 Most nem lennénk igazán Digit Podcast, hogyha nem kérdezném meg, hogy ennek a vezetői oldala az milyen vezető kell ide, hogy egy clouds and szolgáltatás előálljon, meg hogy mondjuk ez, hogy négy óra alatt helyreállítást vállaltok, tehát nem az, hogy fölvesztek a telefont vagy nyomoztok, hanem hogy megjavul, ahhoz mekkora penetráció, meg milyen ügyfélkör kellett, hogy eljussatok idáig, illetve hogyan tudjátok a kollégákat motiválni abban, hogy ezt a színvonalat tartsák hétről hétre.

50:43 Igen. Mi nagyon régóta egyébként szolgáltatunk, nyilván aztán az évek alatt változott a fogászatás tartalma, de egyébként ilyen szinten mi előre menekültünk, amikor még kevés ügyfelünk volt, és akkor ennek a nagyobb költségét, hogy pár ügyfélnek adtuk ezt a szolgáltatást, az egyéb ilyen migrációs projektekből ellensúlyoztuk, tehát ez egy tudatos invesztíció volt az elején tőlünk. Egyébként nagyon fontos eleme az egésznek, hogy mi azért átnézzük, hogy mit veszünk át, és vannak olyan pontok, amiből nem engedünk, tehát amíg ez nincs meg, amíg ezt nem javítottuk meg, addig nem fogjuk átvenni. Nyilván, ami nagyon fél lábon tántorog, meg már hulla is, igen, azt akkor nem vesszük át, ha látjuk, hogy szét fog hullani.

51:30 Az ABS-ben rengeteg olyan eszköz van, amivel a magas rendelkezésre állás, vagy legalább az öngyógyulást el lehet érni, és nyilván erre is törekszünk. Ennek ellenére is sokszor vannak hibák, amiket javítani kell. És hát a kollégákat meg egyébként azzal szoktuk motiválni, hogy nem csak ezt csinálják, hanem vannak érdekes szájprojektek. Megint frusztrációs rescue-dal kell ezt végrehajtani, meg vannak ilyen kis AI hajtásai ezeknek a feladatoknak, tehát nagyon is benne vannak a sűrűjében az innovatív technológiai projektekben, úgyhogy szerintem valahol mindenkit ez mozgat nálunk, hogy itt a sűrűjében az igazán érdekes dolgokat tudjon dolgozni. És hát nyilván ez meg a velejárója, hogy igen, akkor rá kell ugrani, hogyha van valami ügyfélprobléma.

52:21 Egyébként nyilván kevés szokott lenni, tehát sokkal több tábla és rutin van abból, hogy változtassunk valamit, meg utolsó pillanatban gyorsan át kell nyomni, és akkor, de rögtön kellene, meg ugye ami nagyon nehéz tud lenni, hogy ha egy olyan nagy rendszeren dolgozunk, ahol sok beszállító van, és akkor ha valami probléma van.

52:43 Akkor ki mutat kire?

52:44 Hát igen.

52:45 Szerintem lassabb a rendszer. Hogy ezt hogy tudnánk objektíven megfogalmazni, hát sehogy. És akkor szerintem nálad van a probléma, és akkor végignézünk mindent, megadjuk, hogy ez is működik, az is működik, zöld minden, up and running, és hát szerintem nálatok van. A végén kiderült, hogy nem nálunk volt egyébként, hanem egy alkalmazás szintű beállítás. Nyilván ezután ezt senki nem fogja.

53:09 Az alkalmazásfejlesztőknek nagyon tudunk ajánlani egy rendszert, ez majd összekötlek benneteket azzal a fejlesztővel, aki ezt a tesztmegoldást hajtja.

53:19 Erről nekem az a szakállas vicc jut eszembe, mármint arról, hogy meséled, hogy mit vesznek át üzemeltetésre, és ilyen fél lábon álló látszik, hogy szét fog dőlni dolgokat, nem? Amikor együtt söröznek az állatorvos, meg a gyermekorvos, és akkor így két sör után megkérdezi az állatorvos a gyermekorvost, hogy te figyelj, hogy kezdett-e a vizsgálatot, beszéljünk már erről egy kicsit. Hát nagyon egyszerű. Megkérdezem a gyereket, hogy mi a baja, mi a panasza? Ja, hát így könnyű. Nyilván ezt józanul nem, de hogy a lényege itt is valahol ez van, hogy hát úgy könnyű, hogyha mi minden mondjuk adott így a rendszer stabilitásához, mert csak akkor kezdték tekerni az üzemeltetést. Ezt a hozzáállást szeretném aláhúzni, hogy ezt mindenkinek ajánljuk szerintem, aki IT üzemeltetéssel foglalkozik, hogy ne engedje el ezeket a dolgokat, ne vegye félvállról, mert később jóval nagyobb szívás.

54:16 Az a nehéz, hogy mostanában ez most kicsit ide tartozik, de mostanában azt látom, hogy ez a checkbox compliance megy. Tehát majd megoldjuk, meg megoldjuk okosban. Képzeljétek el, hogy valamelyik nap, csak hogy mire mondasz nemet. Ugye? Tehát, hogy nem veszel át egy ilyen épülő céget. Fel kell készíteni valamit kockázatelemezni, és amikor így az auditor mondja, hogy inkább hozom a saját gárdámat, mert majd arra, akkor biztos, hogy határidőre be lesz fejezve, meg határidőre át lesz véve. Szerintetek?

54:48 Ha kritikus infrastruktúrát auditál az a cég, aki ezt csinálja, akkor mi lesz abból kritikus infrastruktúrával? Tehát én őszintén nagyon támogatom azt, hogy nem kell mindent átvenni. Tehát, hogy legyen annak egy szakmai gazdája, mert a szakmai gazdaság az egy ilyen nagyon fontos dolgot tud csinálni, működik.

55:08 Meg ez a szakmai gazdaság kontra piacgazdaság. Tehát a piac nem old meg mindent, könyörgöm. De megy az idő, még egy utolsó kérdést hadd tegyek fel, hogy már a múltkor szemet szúrtam a múltkori beszélgetésünkben, hogy általában három havonta átnézitek a teljes szolgáltatási portfóliót. Kielemzitek és ilyen megtakarítási, optimalizálási lehetőségeket kerestek benne. Mondanál egy-két példát, hogy mire szoktatok ilyenkor bukkanni? Csak mert aki szintén visszatérek ehhez, hogy üzleti vezetők is hallgatnak minket, és bízunk benne, hogy elbeszélgetnek az informatikus kollégáikkal és beszállítóikkal, hogy nem biztos, hogy tudják, hogy ez nem felesleges kiadás, hogy ez nem egy ilyen, hogy mondjam, luxus dolog, hogy ti három hónaponta megcsináljátok, csenget a kassza, és akkor ti vagytok a boldogok.

55:56 Mondjunk már egy-két példát, hogy miért szokta ez, és milyen hamar szokott ez megtérülni.

56:01 Igen, igen. Egyébként ez a csomag része, tehát nekik nem kerül az ügyfélnek semmibe, meg hozzáteszem, tehát hogyha nagyon ez ellenállás, tehát ha sehova nem mozdul, és nem egy innovatív valami, hanem hozzá se érnek, akkor nyilvánvalóan ugyanazt nem mondjuk el háromhavonta, de jellemzően az egyszerűbb dolgok, hogy rightsizolva vannak, bocsánat, ezt nem tudom szebben magyarul mondani.

56:24 Méretgazdaságosság.

56:25 Méretgazdaságosság, igen, tehát az egyes rendszerekre, illetve nagyon sokféle erőforrás elérhető az AWS-ben, és van, hogy más formájú alakzatú erőforrás sokkal optimálisabban működik az adott rendszerrel. Ha egy alakzatot elképzelünk, úgyhogy CPU, memória, sávszélesség, és ugye a Disquare IO.

56:41 Tárhely.

56:47 Igen, igen.

56:48 Nem tudom elhinni, hogy a ki-be menő adat.

56:51 Hát a nyomóssága annak a cuccnak, hogy mennyi idő alatt megy ki.

56:54 Lehet, hogy CPU intenzív, és akkor látszik, közben memóriaintenzív lett, mert valamit még belefejlesztettek, vagy máshogy használják, vagy másfajta az ügyfél a felhasználói interakció. Ez az egyszerűbb, meg le lehet kötni egy vagy három évre az erőforrásokat, nyilván akkor jóval olcsóbb lesz, tehát ez a másik. Akkor vannak ugye az egzotikusabbak. Tehát például CPU architektúra platformot lehet váltani. Az Intel az nagyon régi versenyző. Az AWS-nek van saját fejlesztésű, ezt Gravitonnak hívják. Ez átlagosan 20 százalékkal olcsóbb, mint az Intel, és egyébként ugyanolyan jól működik. Ez egy kis alkalmazás refaktoringgal jár. Ezt már kicsit nehezebben szokták engedni, mert ugye alkalmazással kell hozzányúlni, meg lehet, hogy le is kell tesztelni, lehet, hogy nincs is teszt hozzá.

57:39 Minél nehezebben tesztelhető és validálható a változás után, annál inkább fáznak tőle. Egyébként ezekre is kínálunk megoldást, tehát hogy van csapatunk erre, akik ezt meg tudják tenni. Ez mondjuk egy éven belül megtérülhet. Egyébként ezek nagyon jó projektek adott költés felett. Hát akkor nyilván lehet konténerizálni, szerver lesz irányba vinni, tehát ugye ezek még, ami viszont tényleg nagyobb falat, tehát ezt azért nem szoktunk háromhavonta belevágni egy ilyenbe nyilván, de szerintem ahogy telik az idő, és ahogy látják a vezetők, hogy jól működik az AWS platform, és esetleg ilyen kis apró kis mellékprojekteket állítanak, hogy akkor nézzük meg ezt az AI funkciót, nézzük meg az automatizálását az akárminek.

58:23 Nő a bizalom, és akkor egyre inkább azt gondolják, hogy megéri ebbe invesztálni, és esetleg több erőforrást áttolni a felhőoldalra, hogyha ez egy hibrid működés, és így van értelme ennek a három hónaposnak, tehát itt azért nem minden három hónapban találunk valamit, de szeretnénk, hogy legyen egy rendszeresség benne, hogy ezt lássák.

58:45 Ez az a tervszerű megelőző karbantartás, amit visszahoztatok.

58:49 Igen, igen.

58:49 Tehát ez egy elképesztően fontos hozzáadott érték. Nagyon-nagyon kevesen csinálják a piacon.

58:54 Informatikában?

58:55 Informatikában pláne nagyon kevesen. Azért próbáltam meg ilyen nagyon óvatosan fogalmazni, hogy a nullától nagyobb eltérő számára ti vagytok.

59:06 Igen, szeretném is ezt gondolni, igen.

59:08 Meg szoktál fordulni színpadon is.

59:11 Legközelebb hol láthat téged a nagyérdemű?

59:16 Legközelebb szerintem ez egy júniusi időpont, most sikeresen delegáltam a kollégáknak a legtöbb előadást. Londonban fogunk fellépni, lesz az AWS-sel egy közös rendezvényünk.

59:27 Tehát London.

59:28 London.

59:30 Digit Podcast után London. Ennyi fért bele a mai adásba. Károly, nagyon szépen köszönöm, hogy vállaltad ismét a megmérettetést.

59:38 Én köszönöm, hogy itt lehettem.

59:39 Köszönöm szépen a beszélgetést.

59:41 Köszi, hogy itt voltál. 180.