A pénztáros devopsos

HUP

Kutatások szerint a cloudra elköltött pénzek közel 30%-a pazarlás. A kifejezetten költségszemléletű DevOps-tudás értékes skill lehet idővel. A témát az 59. kraftie adásban igyekeztünk alaposabban körüljárni.

A pazarlás okai sokrétűek, kezdve a rosszul megválasztott vagy fölöslegesen igénybe vett szolgáltatásoktól az árazási modellek nem ismeretén át, egészen a konkrét műszaki és architekturális hibákig. Farkas Tamással (Lufthansa Systems) és Korom Gergely cloud mérnökkel beszélgettünk... a FinOps-ról. A végére csak leírtuk ezt az újabb "opszos" kifejezést.

Az adásban elhangzott hivatkozások a Discord csatornánkon érhetők el, ahol még beszélgetni is tudsz velünk, és a többi hallgatóval. Adásainkat megtaláljátok a SoundCloudon, a Spotify-on, az Apple Podcasten, a YouTube csatornánkon, és immár a YouTube Music-on is.

( asm v | 2025. 06. 20., p – 22:02 )

Szerkesztve: 2025. 06. 20., p – 22:08

Arra van becsles, hogy nem cloudos (on-prem, DC coloc) IT-ban kb. mennyi a pazarlas?

Ugy tippelem, hogy tobb, mert a bare-metal gepeket nem szokas lekapcsolgatni (mondjuk amikor nem fut buildeles), hajlamosabbak az emberek futva hagyni nem hasznalt gepet, mert "mar meg lett veve, nincs koltsege" (aramfogyasztast nem szokas szamolni). A nehezebb bovithetoseg miatt jobban felul szokas tervezni. Stb. 

Ez a FinOps nagyon a cloudra van kihegyezve, de igazandibol a nem cloudos IT koltsegekre is ugyanugy szamolando.

Sok helyen úgy vannak vele, hogy amíg saját szerverteremről van szó, addig nem számolgatnak. "Minek az? Kifizettük már!" címszóval. Amortizációval meg képtelenek számolni és pislognak, hogy a 10 éves klíma cseréje hány millió Ft-ba kerül.
Amikor meg jön a szolgáltatótól a számla - akár Dataplex / VH / Telekom, akár AWS / Azure / GCP -, akkor gyorsan jön a pénzügyről a kérdés: "Mi kerül ezen ennyibe? Nem tudnánk ezen spórolni?".

Én úgy emlékszem, hogy az egész "cloud-világ" (pl. AWS) úgy indult a Big Tech cégeken belül, hogy a saját IT infrastruktúrájukat akarták hatékonyabban kihasználni és skálázni pontos belső elszámolással a részlegek / leányvállalatok között, és ebből csináltak aztán külsősök számára is elérhető termékeket. Tehát a "FinOps" (~ költséghatékony üzemeltetés) volt az egyik mozgatórugója a "cloud" létrejöttének, és nem a cloudhoz találták ki a "FinOps"-ot (függetlenül attól, hogy mikor kezdték el így hívni).

Ugyanígy, DevOps is létezett már 20-25 éve is, csak nem így hívták, hanem sokszor "CM" (= Configuration Management) alá volt besuvasztva :). Konkrétan ~2005 környékén mi csináltunk olyan rendszert a Siemens Mobile-on belül, ami nagyon hasonló volt egy mai DevOps rendszerhez, persze még nem Git alapon (hiszen még nem létezett), hanem ClearCase, CM Synergy, és mivel trendik voltunk Subversion is, meg egyedi build megoldásokra építve.

A legfontosabb dolog amit a FinOps/Cloud cost management-nel meg kell jegyezni hogy on-prem, DC, etc. infrastrukturanal 1000x konnyebb a koltsegeket tervezni es kontroll alatt tartani, mert ott nincs a felmuvelt, magat cloud-expertnek gondolo developereknek hozzaferese a felhos konzolhoz, ahol feloranyi kattintassal dollartizezreket tud havi szinten elkolteni.

On-prem annyi vas van amennyi, es ha tobb kell akkor senki nem tud csak ugy venni maganak 2 kattintassal.
Boviteskor pedig muszaj vegigmenni a review/procurement processen amit a felhoben a developerek nagyon konnyen megkerulnek.

Szoval igazad van, IT koltseg a fizikai infranal is szamolando, de nagysagrendekkel egyszerubb szamolni is es kontroll alatt tartani is mint egy felhoben.

Kerlek ne gyertek azzal hogy de akkor az egy szar ceg ha olyan szarok a processek hogy devnek van hozzaferese, stb. stb. :)
Mindannyian tudjuk akik eleg ideje vagyunk a szakmaban hogy kivetelek mindig vannak, hibas/hianyzo processzek mindig vannak, plane ha nem tobbezerfos, regota letezo nagy cegekrol beszelunk, hanem kisebb, fiatalabb, agilisebb helyekrol.

Kerlek ne gyertek azzal hogy de akkor az egy szar ceg ha olyan szarok a processek hogy devnek van hozzaferese, stb. stb. :)

Onpremben adtok a deveknek root jogot minden géphez? Adtok nekik jóváhagyás nélküli felhatalmazást hardvervásárlásra? Ha ott nem, akkor cloudban miért igen?

Utólagos kontroll sincs? Ha megjön a számla, csak kifizetitek, aztán hadd menjen tovább minden? Azure Advisort (és ennek megfelelőit) senki nem néz? Stb.

Csak az számít, hogy ki a hangosabb.

Múltkor is a fél vezetőséget odarángatták a devesek hozzám, hogy miért nincs root joguk. Én elmagyaráztam. Nem tetszett a deveseknek, hogy még a CEO + CFO + CTO + CIO közösen se tudott rám úgy hatni, hogy a deveseknek legyen igazuk.

Utólagos kontroll sincs?

Van, csak eső után köpönyeg. Amíg nem csinál valaki túl nagy számlát, addig benyeli a cég.
Amikor a cég elmegy költséghely meghatározásának irányába, akkor szokott jönni a pofon a deveseknek.

Btw felőlem legyen nyugodtan a deveknek root joga, én nem ez ellen kampányolok, csak a kettős mércére próbálok rámutatni:

  • onprem: ha kell egy új LAN-kábel, akkor Aribába adj fel egy ticketet, hagyja jóvá a managered, hagyja jóvá az ő managere, hagyja jóvá a CC owner, hagyja jóvá az IO kódot adó üzletág budget ownere, hagyja jóvá a CFO, és ha ez megvan, akkor kimegy a PO a hivatalos beszállítónak
  • cloud: ecsém, ha lassú a SQL Server, akkor ide kattintva tudsz nagyobb SKU-ra váltani

Érzi azért remélem mindenki, hogy ez így nem jó, ugye? :D

Alkalmazottként az MT szabályai az irányadók. Az nem tenne tönkre, de megérezném.
Vállalkozóként más a helyzet. Az EV felelősségi köre egy picit tovább terjed....

Másrészt ott van a szakmai renomé. Kicsi az ország-világ, kicsi a szakmai közösség. Vannak olyan exkollégáim, vállalkozások (al / fő), akikkel soha többet nem dolgoznék együtt. Szerencsére nem hosszú a lista.

VHP = védd a hátsód papírral. Ezt teszem már több évtizede. Ezért nem tudták rám húzni sose a vizes lepedőt.

Ha eddig bármilyen komoly problémával találtam szembe magam, akkor a devesek 99,9%-ban sunnyogtak, pingvineztek. Szóval csak személyes tapasztalatom mondatja ezeket velem.

Onpremben adtok a deveknek root jogot minden géphez? Adtok nekik jóváhagyás nélküli felhatalmazást hardvervásárlásra? Ha ott nem, akkor cloudban miért igen?

Onprem esetén a nincs root kb az alap beállítás, míg cloud esetén azért ez problémásabb tud lenni a gyakorlatban. Meg lehet oldani, de gyakran láttam hogy az X.-ik fejlesztői "nem férek hozzá valamihez és emiatt borul a sprint/negyedév/projekt" ticket után ki lesz adva felülről hogy - legalább a dev környezetekben - legyen mindenkinek admin jog. Ha van egyáltalán külön dev és nem egy prod accountban fut minden.

Ez persze nem jó, az üzemeltetők is tudják, de "történelmileg alakult így", "már tervbe volt véve hogy legyen dev account, csak még nem volt rá kapacitásunk", "a fejlesztők sem tudják előre hogy milyen jogosultságokra van szükségük", "van resource tagging policynk csak sok a régi/obsolete erőforrás amin még nincs (90+%), ha majd azok kifutnak (soha) akkor majd kánaán lesz". Ezeket mind hallottam már élőben.

Míg elméletben minden szép és jó addig ha valaki nem generál egy tényleg hihetetlen összegű számlát addig a management lesz...ja az egészet. Én egyszer egy optimalizálással spóroltam nagyjából évi 70.000USD-t a cégnek (kimérve, nem csak hasraütésre), egy köszönöm sem telt a managementtől, fel sem tűnt nekik.

Onprem esetén a nincs root kb az alap beállítás, míg cloud esetén azért ez problémásabb tud lenni a gyakorlatban. Meg lehet oldani, de gyakran láttam hogy az X.-ik fejlesztői "nem férek hozzá valamihez és emiatt borul a sprint/negyedév/projekt" ticket után ki lesz adva felülről hogy - legalább a dev környezetekben - legyen mindenkinek admin jog. Ha van egyáltalán külön dev és nem egy prod accountban fut minden.

Itt most arról van szó hogy képes legyen saját magának deploy-olni cloud erőforrásokat (kihagyva minden deployment folyamatot),
illetve a meglévő erőforrások méretét megváltoztatni - ez generál cloud költséget.

Szerintem ez egyáltalán nem magától értedődő egy fejlesztő esetén - általában nem része a feladatainak, nincs szüksége rá.

Ebben egyetértünk, egy fejlesztőnek, elvileg, nem kellene közvetlenül elérnie a cloud-ot. Elvileg. Én sem állítottam az ellenkezőjét.

Az eddigi tapasztalataim azonban ennek ellent mondanak, ezért írtam hogy ez a gyakorlatban problémásabb tud lenni. Az üzemeltetés és a határidőkért aggódó product management összecsapásából általában az utóbbi került ki győztesen ott ahol megfordultam. Mondjuk ahol egy elcrashelt deployment agent által ott felejtett Terraform lock eltávolítása egy külön ticket és 3-4 munkanap ott még meg is értem a fejlesztők frusztrációját.

Emellett gyakran kaptam olyan kérést hogy új technológiákat, szolgáltatásokat akarnak kipróbálni és azokhoz kell hozzáférés közvetlenül, még nem is tudják hogy pontosan mire, legyen mindenre. Erre lenne jó egy sandbox account amin van mindenkinek admin accountja és hetente, havonta kap egy reset-et. Azonban én nem tudok olyan gombról az AWS-ben hogy törölj le minden resource-ot, mondj fel minden subscriptiont és állítsd vissza az account kezdeti állapotát. Ez mondjuk onpremben egyszerűbb, csak újrahúzod a sandbox szervert.

Nem triviális az egész CI/CD pipelinet jól belőni, úgy hogy mindenkinek kényelmes is legyen használni és ne akarja megkerülni. Szintén saját tapasztalat hogy ilyet én még sehol nem láttam a gyakorlatban.

Szóval igen, az elméletben egyet értünk, csak a gyakorlati tapasztalataim alapján az elméletet eddig még sehol sem sikerült teljesen megvalósítani.

Igen is, meg nem is. A három nagy közül valóban az AWS a legkörülményesebb*, ha eldobható sandboxokról van szó, de resource groupok és tagek ott is vannak, csak használni kell őket. Vagy eleve egy PoC = egy AWS account. Aztán a végén mehet az egész a kukába.

* Imho: Azure resource groupok > GCP projektek > AWS resource groupok >= AWS accountok

de resource groupok és tagek ott is vannak, csak használni kell őket.

Egy fejlesztő számára igazából édesmindegy, hogy az adott cloud providernél hogyan hívják ezeket a dolgokat, neki az a fontos, hogy legyen egy sandbox környezete, ha szüksége van rá.

A cégnél a pénzügynek meg az a fontos, hogy a sandbox környezet már ne okozzon költséget, ha nincs már rá szükség.

A kettő közötti dolgot valakinek át kell hidalnia. Vagy úgy, hogy a fejlesztő kap megfelelő hozzáférést a cloud providernél, vagy úgy, hogy a pénzügyesek intézik a cloud erőforrások menedzselését. Vagy úgy, hogy felvesznek erre pár embert.

 

Meg persze lehetne egy olyan megoldás is, hogy adott resource korlátozott élettartammal jön már eleve létre, de azt hiszem, ezt nem tudja egyik felhőszolgáltató sem.