Určitě jste se divili, kolik stojí infrastruktura vašeho projektu. Zároveň je překvapivé: růst nákladů není lineární s ohledem na zatížení. Mnoho majitelů firem, čerpacích stanic a vývojářů tajně chápe, že přeplácejí. Ale k čemu přesně?
Snížení nákladů se obvykle sníží na nalezení nejlevnějšího řešení, plánu AWS nebo v případě fyzických stojanů na optimalizaci hardwarové konfigurace. A nejen to: ve skutečnosti to dělá kdokoli, jak Bůh chce: pokud mluvíme o startupu, pak je to pravděpodobně přední vývojář, kterého hodně bolí hlava. Ve větších kancelářích to řeší CMO/CTO a někdy se do problematiky osobně zapojí generální ředitel spolu s hlavní účetní. Obecně platí, že lidé, kteří mají dostatek „základních“ obav. A ukazuje se, že účty za infrastrukturu rostou, ale ti, kteří nemají čas se tím zabývat, se s tím vyrovnávají.
Pokud potřebujete nakoupit toaletní papír do kanceláře, udělá to vedoucí zásobování nebo odpovědná osoba z úklidové firmy. Pokud se bavíme o vývoji – leadech a CTO. Prodej - vše je také jasné. Ale od starých časů, kdy „server room“ byl název pro skříň, ve které byl obyčejný věžový systém s trochu více RAM a několika pevnými disky v raidu, všichni (nebo alespoň mnozí) ignorují skutečnost, že nákup kapacity by měla řešit také speciálně vyškolená osoba.
Historická paměť a zkušenost bohužel naznačují, že po desetiletí byl tento úkol přesouván na „náhodné“ lidi: kdo byl nejblíže, otázku zvedl. A teprve nedávno se profese FinOps začala na trhu formovat a nabírat konkrétní podobu. Jedná se o stejnou speciálně vyškolenou osobu, která má za úkol kontrolovat nákup a využití kapacit. A v konečném důsledku ve snižování nákladů společnosti v této oblasti.
Nenabádáme k opuštění drahých a efektivních řešení: každý podnik se musí sám rozhodnout, co potřebuje pro pohodlnou existenci z hlediska hardwaru a cloudových tarifů. Nelze si ale nevšímat faktu, že bezmyšlenkovité nakupování „podle seznamu“ bez následného sledování a analýzy využití u mnoha společností nakonec vede k velmi, velmi významným ztrátám z důvodu neefektivní správy „aktiv“ jejich backendu.
Kdo je FinOps
Řekněme, že máte renomovaný podnik, o kterém prodejci mluví o „podniku“ dechovým tónem. Pravděpodobně jste „podle seznamu“ koupili tucet nebo dva servery, AWS a některé další „maličkosti“. Což je logické: ve velké firmě neustále dochází k nějakému pohybu – některé týmy rostou, jiné se rozpadají, další se přesouvají do sousedních projektů. A kombinace těchto pohybů spolu s mechanismem zadávání veřejných zakázek „na základě seznamu“ nakonec vede k novým šedivým vlasům při pohledu na příští měsíční účet za infrastrukturu.
Co tedy dělat - trpělivě pokračovat v šedivění, malování nebo zjišťování důvodů výskytu těchto četných hrozných nul v platbě?
Buďme upřímní: schválení, schválení a přímá platba žádosti v rámci společnosti o stejný tarif AWS není vždy (ve skutečnosti téměř nikdy) rychlá. A právě kvůli neustálému firemnímu pohybu se některé z těchto akvizic mohou někde „ztratit“. A zůstat nečinný je triviální. Pokud si pozorný správce všimne racku bez vlastníka ve své serverovně, pak v případě cloudových tarifů je vše mnohem smutnější. Mohou být odloženy na měsíce – zaplacené, ale zároveň již nepotřebné nikým z oddělení, pro které byly zakoupeny. Kolegové z vedlejší kanceláře si přitom začínají rvát své ještě ne šedivé vlasy nejen na hlavě, ale i na dalších místech - už n-tý týden nemohou zaplatit přibližně stejný tarif AWS, který je zoufale potřeba.
Jaké je nejzřetelnější řešení? Je to tak, předejte otěže potřebným a všichni jsou šťastní. Horizontální komunikace však nejsou vždy dobře zavedeny. A druhé oddělení možná prostě neví o bohatství toho prvního, které se jaksi ukázalo, že toto bohatství ve skutečnosti nepotřebuje.
Kdo za to může? - Vlastně nikdo. Tak je zatím vše nastaveno.
Kdo tím trpí? - To je ono, celá společnost.
Kdo může situaci napravit? - Ano, ano, FinOps.
FinOps není jen vrstva mezi vývojáři a vybavením, které potřebují, ale člověk nebo tým, který bude vědět, kde, co a jak dobře to „leží“, pokud jde o stejné cloudové tarify zakoupené společností. Ve skutečnosti musí tito lidé pracovat v tandemu s DevOps na jedné straně a finančním oddělením na straně druhé a hrát roli efektivního prostředníka a hlavně analytika.
Něco málo o optimalizaci
Mraky. Relativně levné a velmi pohodlné. Toto řešení však přestává být levné, když počet serverů dosáhne dvou nebo trojciferných čísel. Cloudy navíc umožňují využívat stále více služeb, které byly dříve nedostupné: jedná se o databáze jako službu (Amazon AWS, Azure Database), bezserverové aplikace (AWS Lambda, Azure Functions) a mnoho dalších. Všechny jsou velmi cool, protože se snadno používají – kupte a jděte, žádné problémy. Čím hlouběji se ale společnost a její projekty noří do oblak, tím hůře spí finanční ředitel. A čím rychleji generál šedne.
Faktem je, že faktury za různé cloudové služby jsou vždy extrémně matoucí: u jedné položky můžete obdržet třístránkové vysvětlení, co, kam a jak vaše peníze šly. To je samozřejmě příjemné, ale je téměř nemožné to pochopit. Náš názor na tuto problematiku navíc není zdaleka jediný: pro převod cloudových účtů na lidské existují celé služby, např. nebo . Pokud se někdo obtěžoval vytvořit samostatnou službu pro dešifrování účtů, pak rozsah problému přerostl náklady na barvení vlasů.
Co tedy FinOps dělá v této situaci:
- jasně rozumí, kdy a v jakých objemech byla cloudová řešení zakoupena.
- ví, jak jsou tyto kapacity využívány.
- přerozděluje je v závislosti na potřebách konkrétní jednotky.
- nekupuje „aby to bylo“.
- a ve finále vám to ušetří peníze.
Skvělým příkladem je cloudové úložiště studené kopie databáze. Archivujete jej například, abyste snížili množství místa a provozu spotřebovaného při aktualizaci úložiště? Ano, zdálo by se, že situace je levná – v jediném konkrétním případě, ale souhrn takových levných situací má později za následek přemrštěné náklady na cloudové služby.
Nebo jiná situace: zakoupili jste rezervní kapacitu na AWS nebo Azure, abyste se nedostali do špičkového zatížení. Můžete si být jisti, že se jedná o optimální řešení? Koneckonců, pokud jsou tyto případy nečinné z 80 %, pak jednoduše dáváte peníze Amazonu. Navíc pro takové případy mají stejné AWS a Azure burstable instance – proč potřebujete nečinné servery, když můžete použít nástroj k řešení problémů se špičkovým zatížením? Nebo byste se místo instancí On Premise měli poohlédnout po Reserved – jsou mnohem levnější a navíc nabízejí slevy.
Mimochodem, o slevách
Jak jsme řekli na začátku, obstarávání často provádí kdokoli - našel posledního a on si to pak nějak udělá sám. Nejčastěji se lidé, kteří jsou již zaneprázdnění, stávají „extrémními“ a v důsledku toho se dostáváme do situace, kdy se člověk rychle a zručně, ale zcela samostatně rozhoduje, co a v jakém množství nakoupí.
Ale při interakci s prodejcem z cloudové služby můžete získat výhodnější podmínky, pokud jde o velkoobchodní nákup kapacity. Je jasné, že z vozu s tichou a jednostrannou registrací takové slevy nezískáte – ale po rozhovoru se skutečným obchodním manažerem můžete vyhořet. Nebo vám tito kluci řeknou, na co mají aktuálně slevy. Může to být také užitečné.
Zároveň si musíte pamatovat, že světlo se nesbíhalo jako klín na AWS nebo Azure. O organizování vlastní serverovny samozřejmě nemůže být řeč – ale k těmto dvěma klasickým řešením od gigantů existují alternativy.
Google například přinesl firmám platformu Firebase, na které mohou hostovat stejný mobilní projekt na klíč, což může vyžadovat rychlé škálování. Úložiště, databáze v reálném čase, hosting a synchronizace dat v cloudu pomocí tohoto řešení jsou k dispozici na jednom místě.
Na druhou stranu, pokud nehovoříme o monolitickém projektu, ale o jejich totalitě, pak centralizované řešení není vždy výhodné. Pokud je projekt dlouhověký, má vlastní historii vývoje a odpovídající množství dat potřebných pro uložení, pak stojí za to přemýšlet o členitějším umístění.
Při optimalizaci nákladů na cloudové služby si najednou možná uvědomíte, že pro kritické obchodní aplikace si můžete pořídit výkonnější tarify, které firmě zajistí nepřetržitý výdělek. Řešením je přitom ukládání „dědictví“ vývoje, starých archivů, databází atd. v drahých cloudech. Ostatně pro taková data se standardní datové centrum s běžnými HDD a středně výkonným hardwarem bez jakýchkoliv zvonků docela hodí.
I zde si možná říkáte, že „tahle povyk za to nestojí“, ale celý problém této publikace je založen na tom, že zodpovědní lidé v různých fázích zanedbávají maličkosti a dělají to, co je pohodlnější a rychlejší. Což nakonec po pár letech vyústí v ony velmi hororové účty.
Výsledek?
Obecně jsou mraky cool, řeší spoustu problémů pro podniky jakékoli velikosti. Novost tohoto fenoménu však znamená, že stále nemáme kulturu spotřeby a řízení. FinOps je organizační páka, která vám pomůže efektivněji využít výkon cloudu. Hlavní věcí je neudělat z této pozice obdobu popravčí čety, jejímž úkolem bude chytit nepozorné vývojáře za ruku a „nadávat“ jim za prostoje.
Vývojáři by se měli vyvíjet, ne počítat firemní peníze. A tak by FinOps měl učinit jak proces nákupu, tak proces vyřazování z provozu nebo převod cloudové kapacity na jiné týmy, akci jednoduchou a příjemnou pro všechny strany.
Zdroj: www.habr.com