Határozottan felmerült Önben a kérdés, mennyibe kerül a projektje infrastruktúrája. Meglepő módon a költségek növekedése nem lineáris a terhelésekhez képest. Sok vállalkozó, CTO és fejlesztő sejtése szerint alulról fizetnek túl. De mire is igazából?
Általában a költségek csökkentése csupán annyiból áll, hogy a legolcsóbb megoldást keresik, AWS tarifát választanak, vagy, ha fizikai rack-ekről van szó, az eszközök konfigurációját optimalizálják. Ezen felül: ezt gyakorlatilag bárki elintézi, ahogy az csak jön: ha startupról van szó, akkor valószínűleg a vezető fejlesztő, akinek bőven van elég problémája. Nagyobb cégeknél ezt a CMO/CTO csinálja, néha maga az ügyvezető és a főkönyvelő is belefolyik. Szóval azok foglalkoznak vele, akiknek amúgy is rengeteg 'szakmai' dolga akad. És azt látjuk, hogy az infrastruktúra számlák nőnek, de azok kezelése… akiknek nincs idejük vele foglalkozni.
Ha az irodába toalettpapírt kell vásárolni, azt a gazdasági vezető vagy a takarító cég felelős munkatársa intézi. Fejlesztés terén — az vezetők és a CTO. Az értékesítés is világos. De már régóta, amikor a „szerver” kifejezés alatt azt értették, hogy egy szokványos tower-rendszer volt több memóriával és néhány merevlemezzel RAID-ban, mindenki (vagy legalábbis sokan) figyelmen kívül hagyják azt a tényt, hogy a kapacitások beszerzésével egy külön képzett embernek kellene foglalkoznia.
Sajnálatos módon a történelmi memória és tapasztalat azt mutatja, hogy ezt a feladatot évtizedek óta a „véletlenszerű” emberekre bízták: akinek közel volt, az átvette a kérdést. Csak nemrégiben kezdett formálódni és megszületni a piacon a FinOps nevű szakma. Ő az a külön képzett személy, akinek feladata a kapacitásvásárlás és -használat ellenőrzése. Végső soron pedig a vállalat ezen a területen történő kiadásainak csökkentése.
Nem buzdítunk azoktól a drága és hatékony megoldásoktól való lemondásra: minden vállalkozásnak magának kell eldöntenie, mi szükséges a kényelmes működéshez a hardver és a felhőszolgáltatások terén. De nem szabad figyelmen kívül hagyni, hogy a listás beszerzés, alapos ellenőrzés és a felhasználás elemzése nélkül, sok vállalat számára végül jelentős veszteségeket okozhat az "aktívák" hatékony kezelésének hiánya miatt a háttér rendszerükben.
Ki az a FinOps
Tegyük fel, hogy van egy jelentős vállalata, amelyről az értékesítők sóhajtozva beszélnek "vállalati" szinten. Valószínűleg a listás beszerzés keretein belül vásárolt egy tucat vagy két szervert, AWS-t, és néhány egyéb apróságot. Ami logikus is: egy nagy cégnél folyamatos mozgás zajlik — egyes csapatok nőnek, mások szétesnek, harmadik csoportok pedig szomszédos projektekre váltanak. Ez a mozgáskombináció a listás beszerzési mechanizmussal együtt újabb ősz hajszálakat okoz, amikor az ember megnézi a havi infrastruktúra számláját.
Tehát mi a teendő — tovább türelmesen őszülni, vagy megoldani miért is vannak ezek a borzalmas nullák a számlán?
Mit is rejtegethetünk: a jóváhagyás, az engedélyezés és a kifizetés az AWS tarifáira vonatkozó kérelem esetében nem mindig (a valóságban szinte soha) gyors folyamat. És éppen a folyamatos vállalati mozgás miatt ezek a beszerzések eltűnhetnek valahol, és üresen maradhatnak. Míg egy figyelmes admin észlelheti az elhanyagolt kiszolgáló szekrényt, a felhő tarifáknál ez sokkal szomorúbb. Ezek hónapokig állhatnak "tartalékban" — kifizetve, de ugyanakkor már senkinek sincs szüksége rá a részlegen, amelyhez beszerzésre kerültek. Közben a szomszédos irodából a kollégák a még megmaradt hajaikat tépik — már hetek óta nem tudják kifizetni körülbelül ugyanazt az AWS tarifát, amire sürgősen szükségük lenne.
Mi a legnyilvánvalóbb megoldás? Helyesen gondoltad, átadni a szükségeseknek, és mindenki elégedett. Csakhogy a horizontális kommunikációk nem mindig jól kiépítettek. A második részleg egyszerűen nem tudhat az első részleg gazdagságáról, amelynek ez a gazdagság valahogy nem is annyira szükséges.
Ki a hibás ebben? — Valójában senki. Így alakultak a dolgok.
Ki szenved emiatt? — Mindenki, az egész cég.
Ki tudja megoldani a helyzetet? — Igen, a FinOps.
A FinOps nem csupán egy híd a fejlesztők és a számukra szükséges hardver között, hanem egy személy vagy csapat, akik jól tudják, hol, mi és mennyire jól 'fekszik' a cég által vásárolt felhőtarifák szempontjából. Valójában ezek az emberek a DevOps-szal egyazon szekérben dolgoznak, és a pénzügyi osztállyal a másik oldalon, hatékony közvetítők és, ami a legfontosabb — elemzők.
Néhány szó az optimalizálásról
Felhők. Viszonylag olcsó és nagyon kényelmes. De ez a megoldás nem lesz olcsó, amikor a szerverek száma kéttagú vagy háromtagú lesz. Ráadásul a felhők lehetőséget adnak egyre több szolgáltatás használatára, amelyek korábban nem álltak rendelkezésre: ezek közé tartozik az adatbázis mint szolgáltatás (Amazon AWS, Azure Database), serverless alkalmazások (AWS Lambda, Azure Functions), és sok egyéb. Ezek mind nagyszerűek, mert könnyen használhatók — vásárolja meg és indulhat, nincsenek problémák. De minél mélyebben merül el a cég és a projektjei a felhőkben, annál rosszabbul alszik a pénzügyi igazgató. És annál gyorsabban őszül meg a vezérigazgató.
A dolog az, hogy a különböző felhőszolgáltatások számlái mindig rendkívül zavarosak: egyetlen tétel miatt háromoldalas részletet kaphat arról, hogy mire, hova és hogyan mentek el a pénzei. Ez természetesen kellemes, de szinte lehetetlen kitalálni belőle. És a mi véleményünk nem egyedülálló ebben a kérdésben: a felhőszámlák emberi nyelvre való fordításához egész szolgáltatások léteznek, például vagy . Ha valaki külön szolgáltatást hozott létre a számlák értelmezésére, akkor a probléma mérete meghaladja a hajfesték költségét.
Tehát mit csinál a FinOps ebben a helyzetben:
- világosan érti, mikor és milyen mennyiségben lettek felhőmegoldások beszerelve.
- tudja, hogyan használják ezeket a teljesítményeket.
- újraosztja őket az egyes részlegek igényei szerint.
- nem vásárol 'csak azért, hogy legyen'.
- és végül — spórol a pénzével.
Kiváló példa – felhőalapú tárolás hideg másolatra az adatbázisból. Például archiválja azt, hogy csökkentse a tárolási helyet és a forgalmat a tároló frissítésekor? Igen, úgy tűnhet, hogy ez egy apró helyzet – egy konkrét esetben, de az ilyen apró helyzetek összessége végül hatalmas költségeket eredményezhet a felhőszolgáltatásoknál.
Vagy egy másik helyzet: Ön tartalék teljesítményt vásárolt az AWS-en vagy az Azure-on, hogy ne essen össze a csúcs terhelés alatt. Lehet-e biztos benne, hogy ez az optimális megoldás? Hiszen ha ezek az instanciák 80%-ban inaktívak, akkor csak úgy ajándékoz pénzt az Amazonnak. Ráadásul ilyen esetekben az AWS-nak és az Azure-nak is vannak burstable instanciái – miért fenntartani működésben a szervereket, ha van eszköz a csúcs terhelések problémáinak megoldására? Vagy a helyi telepítésű instanciák helyett érdemes lenne a Reserved-ot megfontolni – ezek sokkal olcsóbbak, és még kedvezményeket is adnak rájuk.
Egyébként a kedvezményekről
Ahogy a kezdetekkor említettük, a beszerzéseket gyakran bárki intézi – megtalálták a legutolsót, és utána ő majd csak elintézi. Leggyakrabban az „utolsó” emberek olyan elfoglaltak, és végül azt kapjuk, hogy valaki gyorsan és szakszerűen, de teljesen önállóan dönt arról, mit és milyen mennyiségben vásárol.
Pedig a felhőszolgáltatás értékesítőjével való kapcsolatfelvétel révén kedvezőbb feltételeket is kaphat, ha nagykereskedelmi teljesítményvásárlásról van szó. Nyilvánvaló, hogy ilyen kedvezményeket nem fog kapni egy automatikus és egyoldalú ügyintézés során – de ha a valódi értékesítési menedzserrel beszél, lehet, hogy jól jár. Ez a csapat akár meg is mondhatja, hogy jelenleg mire van kedvezmény. Ez is hasznos lehet.
Eközben érdemes megjegyezni, hogy az AWS vagy az Azure nem az egyetlen lehetőség. Természetesen nem arról van szó, hogy saját szervert kellene szervezni – de ezek a két klasszikus megoldás mellett vannak alternatívák is.
Például a Google bemutatta a Firebase platformot cégek számára, amely lehetővé teszi, hogy „kulcsrakész” módon helyezze el ugyanazt a mobilprojektet, amely gyors skálázást igényelhet. A tárolók, a valós idejű adatbázisok, a webtárhely és az adatok felhőalapú szinkronizálása ennek a megoldásnak a segítségével egy helyen érhető el.
Másrészt, ha nem egy monolitikus projektről beszélünk, hanem azok összességéről, akkor a központosított megoldás nem mindig előnyös. Ha a projekt hosszú életű, van saját fejlesztési története és megfelelő mennyiségű szükséges adattal rendelkezik, érdemes elgondolkodni a fragmentált elhelyezésen.
Felhőszolgáltatások költségeinek optimalizálásakor hirtelen rájöhet, hogy a kritikus üzleti alkalmazásokhoz erősebb tarifákat is vásárolhat, amelyek biztosítják a cég zavartalan működését. Azonban a „örökség” fejlesztése, régi archívumok, adatbázisok stb. tárolása drága felhőkben — ez nem a legjobb megoldás. Az ilyen adatokhoz teljesen megfelelő egy normál adatközpont, átlagos HDD-kkel és közepes teljesítményű hardverrel bármiféle „extrák” nélkül.
Itt ismét felmerülhet, hogy „ez a mizéria nem ér ennyit”, de a kiadvány problémáit az jelenti, hogy különböző szakaszokban a felelős személyek figyelmen kívül hagyják a részleteket és azt teszik, ami kényelmesebb és gyorsabb. Ami végül néhány év múlva a híres horrorszámlákhoz vezet.
Mi az összefoglaló?
Valójában a felhők nagyszerűek, rengeteg problémát megoldanak bármilyen méretű vállalkozás számára. Azonban ennek az új jelenségnek a megjelenése miatt még mindig nincs meg az a fogyasztási és kezelési kultúra, amely szükséges. A FinOps egy szervezeti eszköz, amely segít hatékonyabban kihasználni a felhőkapacitásokat. A legfontosabb, hogy ez a pozíció ne váljon egyfajta „ni-tent” brigáddá, melynek feladata, hogy tetten érje a figyelmetlen fejlesztőket és „megrója” őket a kapacitás kihasználatlanságáért.
A fejlesztőknek fejleszteniük kell, nem a cég pénzét kell számolniuk. A FinOps-nak egyszerű és kellemes folyamatot kell kidolgoznia mind a felhőkapacitások beszerzése, mind azok leírása vagy más csapatoknak való átadás terén.
Forrás: habr.com
