Esettanulmányok

Telepítési idő csökkentése 80%-kal Fintech startup · GitOps · ArgoCD · Multi-környezet automatizálás A kihívás Egy gyorsan növekvő fintech startup eljutott arra a pontra, ahol a régi telepítési rutin már nem bírta a tempót. A fejlesztőcsapat egy év alatt 5 főről 25-re nőtt, a release folyamat viszont maradt a régi: SSH a szerverre, friss kód lehúzása, migrációk futtatása, aztán csendes reménykedés, hogy most épp minden rendben lesz. Ismerős helyzet. A problémák egyre súlyosabbak lettek: ...

99,99% rendelkezésre állás egy rádióplatformhoz Médiaszolgáltatás · Magas rendelkezésre állás · Monitoring · Incidenskezelés A kihívás Egy médiatechnológiai vállalat rádiós streaming platformot épített, amit több országban, milliós hallgatóság mellett kellett stabilan működtetni. A rendszer élő adásokat, on-demand tartalmakat és valós idejű hirdetésbeszúrást kezelt, miközben a leállás gyakorlatilag nem fért bele. A tét nagyon is kézzelfogható volt: Az élő adás nem akadhat meg. Ha egy műsor közben megszakad a stream, a hallgató gyorsan továbbáll, és nem biztos, hogy visszajön A szabályozói elvárások dokumentált rendelkezésre állási garanciákat kértek számon A csúcsforgalom kiszámíthatatlan volt. Egy friss hír pár perc alatt a 10-szeresére tudta húzni a terhelést A meglévő infrastruktúra egyetlen régióban futott, redundancia nélkül, a monitoring pedig nagyjából annyit jelentett, hogy „valaki majd ránéz”. Néha ránéztek, néha kevésbé Olyan architektúrára volt szükség, ami akkor is megy tovább, amikor több dolog egyszerre romlik el. ...

Legacy infrastruktúra migrálása Kubernetesre Nagyvállalati projekt · EKS · Terraform · Helm · Zéró leállás melletti migráció A kihívás Egy nagyvállalati ügyfélnél a teljes platform manuálisan felhúzott EC2 példányokon futott. Ami pár éve még „gyors és egyszerű” megoldásnak tűnt, idővel nehezen kezelhető rendszerré vált: egyedi szerverek, kézzel módosított konfigurációk, és rengeteg kimondatlan tudás, ami két senior mérnök fejében élt. Ismerős helyzet. A fájdalompontok: A skálázás teljesen manuális volt. Új példányindítás, függőségek telepítése, load balancer beállítás, DNS frissítés. Csúcsidőben ez simán elvitt több órát. Nem létezett két egyforma szerver. Az évek alatt mindenhol más apró módosítás maradt, így a hibakeresés kiszámíthatatlan lett. A költségek folyamatosan nőttek. Sok túlméretezett példány futott éjjel-nappal, mert senki nem mert hozzányúlni. Az onboarding lassú volt. Új mérnököt betanítani hetekbe telt, mert dokumentáció helyett a „kérdezd meg Dávidot” folyamat működött. A kulcstudás két embernél volt. Ez lett a legnagyobb működési kockázat, és ezzel mindenki tisztában volt. Úgy kellett modernizálni, hogy közben a fizető ügyfelek semmit ne érezzenek az átállásból. ...