Díjmentes demó kérése

FinOps és observability: avagy hogyan csökkenthető a vállalati felhőköltség

FinOps és observability: avagy hogyan csökkenthető a vállalati felhőköltség - FinOps

A Forrester előrejelzése szerint a globális nyilvános felhőpiac 2026-ban érheti el az 1,03 billió dolláros szintet. Ez majdnem duplája annak, amit öt évvel ezelőtt erre a célra fordítottak.

A Flexera State of the Cloud Report korábbi kiadásai rendre 28–32% közé teszik a pazarlást, és a legfrissebb trendek alapján 2026-ra is hasonló arány várható: kihasználatlan, túlméretezett vagy soha nem leállított erőforrásokra megy el. Az AI terhelések költségtervezése főként a GPU kapacitás, autoscaling és spot árak változékonysága miatt válik egyre összetettebbé. 

A legtöbb vállalat valamilyen formában használ felhőszolgáltatásokat, bár sok szervezet továbbra is hibrid vagy on premise megoldásokkal működik. Az viszont elengedhetetlen, hogy a felhőköltségek átláthatóak legyenek. Ehhez az observability fontos kiegészítő eszköz lehet, különösen akkor, ha FinOps adatokkal összekapcsolva használják. 

Miből tevődik össze a felesleges 29%? 

A 29%-os veszteség nem egyetlen forrásból ered, hanem néhány visszatérő mintából, amelyek szinte minden felhőt használó szervezetnél megjelennek.

A legnagyobb tétel a kihasználatlan, üresjáratban futó erőforrás. Egy virtuális gép, adatbázis vagy tárolóegység, amit valaki elindított egy projekthez, majd a projekt lezárása után elfelejtett leállítani. A rendszerek futnak, számláznak, miközben gyakorlatilag semmilyen munkát nem végeznek. Ez a kategória adja a teljes veszteség mintegy harmadát.

Szorosan mögötte következik a túlméretezés: olyan aktívan használt erőforrás, ami jóval nagyobb kapacitással fut, mint amire szükség lenne. Ez tipikusan úgy alakul ki, hogy egy csapat indításkor „biztonságból” nagyobb kapacitást tesz lehetővé, majd soha nem tér vissza módosítani, még akkor sem, ha a tényleges terhelés hónapok óta ennek töredéke.

Végül ott van az elhagyott erőforrás: olyan tárolóegység vagy pillanatkép, ami egy már törölt rendszer után maradt vissza, és senki nem vette észre, hogy önállóan tovább számlázódik.

Fontos látni, hogy mindegyik tétel abból ered, hogy valaki egy adott pillanatban ésszerű döntést hozott, majd a helyzet megváltozott, és ezt senki nem vette észre időben.

Miért halmozódik fel ez a veszteség?

A probléma valójában nem a költségjelentéssel van. A legtöbb vállalatnál pontosan látszik, mennyi ment el felhőre az adott hónapban. Ami hiányzik, az a gyakorlat, hogy ezt a fogyasztást valaki folyamatosan felül is vizsgálja.

Olyan ez, mint az előfizetés, amit soha nem mondtunk le. Az elindítása pillanatában ésszerű döntés volt, kellett, hasznos volt, megérte. Aztán a helyzet megváltozott, a szükséglet megszűnt, de a levonás havonta továbbra is megtörténik, mert nincs olyan pillanat, amikor valaki visszatérne rá és feltenné a kérdést: ez még mindig kell?

Egy vállalati felhőkörnyezetben pontosan ez történik, csak nagyobb léptékben, és kevésbé egyértelmű módon. Egy tesztkörnyezet, egy túlméretezett szerver, egy lekötött kapacitás, mindegyik egy-egy „előfizetés”, amit valaki elindított, és senki nem mondott le.

Miért nem vizsgálnak felül minden felhőköltséget?

Mert nem fáj. Egy feleslegesen futó szerver nem okoz leállást, nem küld riasztást, nem zavar senkit a napi munkában. Csendben számláz a háttérben. Emellett a leállítás felelőse sem egyértelmű. Aki elindította, már régen a következő feladaton dolgozik. Aki a számlát nézi, nem tudja, mire fut az adott tétel. 

A FinOps és observability összekapcsolása

Erre a „csendes jelre” ad választ a FinOps és az observability összekapcsolása, és a piac két vezető szereplője éppen ebbe az irányba mozdul.

A Datadog Cloud Cost Management terméke egy platformon egyesíti a mérnöki és a FinOps-szempontokat. A költség- és teljesítményadatok összekapcsolásával a mérnöki csapat nem egy külön táblázatban találkozik a számlával, hanem ugyanabban a rendszerben, ahol egyébként is dolgozik. Így egy anomália nemcsak azt jelzi, hogy valami eltér a megszokottól, hanem azt is, hogy ez mennyibe kerül.

A Dynatrace hasonló irányba mozdult a Kubernetes-monitorozásánál: az energiafogyasztás és a karbonlábnyom mérése ugyanabból az adatból történik, amit a rendszer egyébként is gyűjt a teljesítményről. A költség itt már nem egy külön nézet, hanem a meglévő megfigyelés egyik dimenziója.

A közös elv mindkét megközelítésben ugyanaz: a felülvizsgálat nem akkor történik meg, amikor valaki külön időt szán rá, hanem folyamatosan, automatikusan, ugyanabban a rendszerben, ahol a többi üzemeltetési adat is látszik. Ez oldja meg azt, amiről az előző szakasz szólt: hogy a csendes veszteség nem azért marad észrevétlen, mert rossz szándék áll mögötte, hanem mert nincs, aki folyamatosan odanézzen. Az observability pontosan ezt a folyamatos odanézést teszi lehetővé, akár emberi beavatkozás nélkül is.

Hogyan csökken a felhő költsége az observability segítségével?

A mechanizmus lényegében három lépésben írható le, és mindegyik ugyanarra az elvre épül: láthatóvá tenni azt, ami eddig nem volt az.

Először is: az erőforrás és a hozzá tartozó felelős összekapcsolódik. Az observability platform képes feltérképezni az erőforrás használatot, ha a szervezet következetesen alkalmazza a címkézést és a metaadatok karbantartását.  Ezzel megszűnik az a helyzet, hogy egy tétel a számlán „gazdátlanul” lóg – mindig van hozzá kontextus: ki indította, mihez tartozik, mikor volt utoljára ténylegesen használva.

Másodszor: a kihasználtság folyamatosan látszik, nem csak a futás ténye. Az observability nem azt méri, hogy egy szerver fut-e, hanem azt, hogy mennyire van kihasználva. Egy alacsony kihasználtságú, de aktívan futó erőforrás így ugyanúgy látszik, mint egy hibás rendszer – automatikusan jelzésre kerül, anélkül hogy valakinek külön időt kellene szánnia a keresésére.

Harmadszor: a riasztás nem várja meg, hogy valaki ránézzen. Ahelyett hogy a felülvizsgálat egy naptárba beírt, könnyen elmaradó feladat lenne, a rendszer képes riasztást küldeni alacsony kihasználtság esetén, ha a szervezet erre vonatkozó szabályokat és küszöbértékeket beállít, vagy amikor egy kiadás eltér a megszokott mintától. Ez pontosan azt a hiányzó felelősséget pótolja, amiről korábban volt szó. Nem kell külön ember, aki erre figyel, mert a rendszer maga veszi észre.

Ez a három elem együtt azt eredményezi, hogy a felhőköltség nem utólag, egy negyedéves felülvizsgálat során derül ki, hanem folyamatosan, valós időben látható marad, ugyanabban a rendszerben, ahol a teljesítmény és a megbízhatóság adatai is élnek.

Záró gondolat

A felhőköltségek növekedését részben a fogyasztás, részben pedig bizonyos szolgáltatások áremelkedése és az új, erőforrásigényes technológiák terjedése okozza. Ez nem hanyagság kérdése. Egyszerűen nincs, ami ezt a feladatot valakihez rendelje, amíg a rendszer maga nem teszi láthatóvá.

Ez az a pont, ahol a pénzügyi vezető és az IT Ops vezető végre ugyanazt látja. Nem két külön adatforrásból, két külön nézőpontból próbálják összerakni a képet, hanem egy közös felületen: mi fut, miért fut, és megéri-e még futtatni.

A Telvice-nél abban segítünk ügyfeleinknek, hogy a meglévő observability-befektetésük ne csak a rendszerek stabilitását szolgálja, hanem a felhőköltségek folyamatos, automatikus felülvizsgálatát is. Sok esetben a szükséges adatok már rendelkezésre állnak, de a költségoptimalizáláshoz gyakran új modulok vagy FinOps funkciók bekapcsolása is szükséges. A legtöbb esetben a szükséges adat már rendelkezésre áll, csak eddig nem ebből a szempontból nézték.

Kérjen tőlünk szakértői konzultációt.

Források

Picture of Telvice Zrt.
Telvice Zrt.