Zagotovo ste se spraševali, koliko stane infrastruktura vašega projekta. Obenem preseneča: rast stroškov ni linearna glede na obremenitve. Mnogi lastniki podjetij, bencinski servisi in razvijalci na skrivaj razumejo, da preplačujejo. Toda za kaj točno?
Običajno se znižanje stroškov preprosto zmanjša na iskanje najcenejše rešitve, načrta AWS ali, v primeru fizičnih omaric, optimizacije konfiguracije strojne opreme. Pa ne samo to: v bistvu to počne vsak, kakor božji volji: če govorimo o startupu, potem je to verjetno vodilni razvijalec, ki ima obilo preglavic. V večjih pisarnah se s tem ukvarja CMO/CTO, včasih pa se v zadevo skupaj z glavnim računovodjo osebno vključi generalni direktor. Na splošno tisti ljudje, ki imajo dovolj "osnovnih" skrbi. In izkazalo se je, da računi za infrastrukturo rastejo, a se s tem ukvarjajo tisti, ki se nimajo časa ukvarjati s tem.
Če boste morali kupiti toaletni papir za pisarno, bo to naredil vodja dobave ali odgovorna oseba čistilnega podjetja. Če govorimo o razvoju - vodi in CTO. Prodaja - tudi vse je jasno. Toda od starih časov, ko je bila “strežniška soba” ime za omaro, v kateri je bil navaden stolpni sistem z malo več RAM-a in nekaj trdimi diski v raidu, vsi (ali vsaj mnogi) ignorirajo Dejstvo je, da mora nakup zmogljivosti opraviti tudi posebej usposobljena oseba.
Žal, zgodovinski spomin in izkušnje kažejo, da je bila ta naloga desetletja preložena »naključnim« ljudem: kdor je bil najbližje, je izbral vprašanje. In šele pred kratkim se je stroka FinOps začela oblikovati na trgu in dobiti neko konkretno obliko. To je ista posebej usposobljena oseba, katere naloga je nadzor nad nakupom in uporabo zmogljivosti. In navsezadnje v zmanjševanju stroškov podjetja na tem področju.
Ne zagovarjamo opuščanja dragih in učinkovitih rešitev: vsako podjetje se mora samo odločiti, kaj potrebuje za udoben obstoj v smislu strojne opreme in tarif v oblaku. Ne moremo pa si pomagati, da ne bi bili pozorni na dejstvo, da nepremišljeni nakupi »po seznamu« brez naknadnega spremljanja in analize uporabe pri številnih podjetjih na koncu povzročijo zelo, zelo velike izgube zaradi neučinkovitega upravljanja »sredstev« njihovega zaledja.
Kdo je FinOps
Recimo, da imate ugledno podjetje, o katerem prodajalci govorijo o "podjetju" v zadihanem tonu. Verjetno ste "po seznamu" kupili ducat ali dva strežnikov, AWS in nekatere druge "malenkosti". Kar je logično: v velikem podjetju se nenehno dogaja nekakšno gibanje - nekatere ekipe rastejo, druge razpadajo, tretje se prenašajo na sosednje projekte. In kombinacija teh gibanj, skupaj z mehanizmom javnega naročanja »na seznamu«, na koncu privede do novih sivih las ob pogledu na naslednji mesečni račun za infrastrukturo.
Torej, kaj storiti - potrpežljivo nadaljevati s sivino, jo prebarvati ali ugotoviti razloge za pojav teh številnih strašnih ničel v plačilu?
Bodimo iskreni: odobritev, odobritev in neposredno plačilo vloge znotraj podjetja za isto tarifo AWS ni vedno (v resnici skoraj nikoli) hitro. In prav zaradi nenehnega korporativnega gibanja se lahko nekateri od teh istih prevzemov nekje »izgubijo«. In nepomembno je stati brez dela. Če pozoren skrbnik v svoji strežniški sobi opazi stojalo brez lastnika, potem je v primeru tarif v oblaku vse veliko bolj žalostno. Lahko so v mirovanju več mesecev - plačani, a hkrati ne potrebujejo več nihče v oddelku, za katerega so bili kupljeni. Istočasno si sodelavci iz sosednje pisarne začnejo puliti še ne sive lase ne samo na glavi, ampak tudi drugod - že n-ti teden ne morejo plačati približno enake tarife AWS, ki je nujno potreben.
Kaj je najbolj očitna rešitev? Tako je, predajte vajeti tistim v stiski, pa so vsi srečni. Toda horizontalne komunikacije niso vedno dobro vzpostavljene. In drugi oddelek morda preprosto ne ve za bogastvo prvega, za katerega se je nekako izkazalo, da tega bogastva res ne potrebuje.
Kdo je za to kriv? - Pravzaprav nihče. Tako je zaenkrat vse nastavljeno.
Kdo trpi zaradi tega? - To je to, cela družba.
Kdo lahko popravi situacijo? - Da, da, FinOps.
FinOps ni le plast med razvijalci in opremo, ki jo potrebujejo, ampak oseba ali ekipa, ki bo vedela, kje, kaj in kako dobro »leži« glede na iste tarife v oblaku, ki jih kupi podjetje. Pravzaprav morajo ti ljudje delati v tandemu z DevOps na eni strani in finančnim oddelkom na drugi ter igrati vlogo učinkovitega posrednika in, kar je najpomembneje, analitika.
Malo o optimizaciji
Oblaki. Relativno poceni in zelo priročno. Toda ta rešitev preneha biti poceni, ko število strežnikov doseže dvo- ali trimestno število. Poleg tega oblaki omogočajo uporabo vedno več storitev, ki prej niso bile na voljo: to so baze podatkov kot storitev (Amazon AWS, Azure Database), brezstrežniške aplikacije (AWS Lambda, Azure Functions) in številne druge. Vsi so zelo kul, ker so enostavni za uporabo - kupite in pojdite, brez težav. A globlje kot podjetje in njegovi projekti tonejo v oblake, slabše spi finančni direktor. In čim hitreje generalka sivi.
Dejstvo je, da so računi za različne oblačne storitve vedno zelo zmedeni: za eno postavko lahko prejmete na treh straneh razlago, kaj, kam in kako je šel vaš denar. To je seveda prijetno, vendar ga je skoraj nemogoče razumeti. Poleg tega naše mnenje o tem vprašanju še zdaleč ni edino: za prenos računov v oblaku na človeške obstajajo celotne storitve, npr. ali . Če se je nekdo trudil ustvariti ločeno storitev za dešifriranje računov, potem je obseg problema prerasel stroške barvanja las.
Torej, kaj naredi FinOps v tej situaciji:
- jasno razume, kdaj in v kakšnih količinah so bile kupljene rešitve v oblaku.
- ve, kako se te zmogljivosti uporabljajo.
- jih prerazporeja glede na potrebe posamezne enote.
- ne kupuje "da bi lahko bilo".
- in na koncu vam prihrani denar.
Odličen primer je shranjevanje hladne kopije baze podatkov v oblaku. Ali ga na primer arhivirate, da zmanjšate količino porabljenega prostora in prometa pri posodabljanju pomnilnika? Da, zdi se, da je situacija poceni – v enem samem konkretnem primeru, a skupek takih poceni situacij kasneje povzroči pretirane stroške za storitve v oblaku.
Ali druga situacija: kupili ste rezervno zmogljivost na AWS ali Azure, da ne bi padli pod največjo obremenitev. Ali ste prepričani, da je to optimalna rešitev? Konec koncev, če so ti primerki nedejavni 80%, potem preprosto dajete denar Amazonu. Poleg tega imata isti AWS in Azure za takšne primere razpočne primerke - zakaj potrebujete strežnike v prostem teku, če lahko uporabite orodje za reševanje težav z največjimi obremenitvami? Ali pa namesto na primerke On Premise raje poiščite Reserved - so veliko cenejši in ponujajo tudi popuste.
Mimogrede, o popustih
Kot smo rekli na začetku, nabavo velikokrat izvaja kdorkoli – zadnjega so našli, potem pa to nekako naredi sam. Najpogosteje ljudje, ki so že zaposleni, postanejo »ekstremni« in posledično dobimo situacijo, ko se človek hitro in spretno, a popolnoma samostojno odloči, kaj in v kakšnih količinah bo kupil.
Toda pri interakciji s prodajalcem iz storitve v oblaku lahko dobite ugodnejše pogoje pri veleprodajnem nakupu zmogljivosti. Jasno je, da od avtomobila s tiho in enostransko registracijo ne boste mogli dobiti takšnih popustov - toda po pogovoru s pravim vodjo prodaje lahko izgorite. Lahko pa ti povedo, na kaj imajo trenutno popuste. Lahko je tudi koristno.
Hkrati se morate spomniti, da svetloba ni konvergirala kot klin na AWS ali Azure. Seveda ni govora o organizaciji lastne strežniške sobe - vendar obstajajo alternative tema dvema klasičnima rešitvama velikanov.
Google je na primer podjetjem prinesel platformo Firebase, na kateri lahko gostijo isti mobilni projekt na ključ, kar lahko zahteva hitro skaliranje. Shramba, podatkovna baza v realnem času, gostovanje in sinhronizacija podatkov v oblaku na podlagi te rešitve kot primera so na voljo na enem mestu.
Po drugi strani pa, če ne govorimo o monolitnem projektu, ampak o njihovi celoti, potem centralizirana rešitev ni vedno koristna. Če je projekt dolgotrajen, ima svojo zgodovino razvoja in ustrezno količino podatkov, potrebnih za shranjevanje, potem je vredno razmišljati o bolj razdrobljeni umestitvi.
Pri optimizaciji stroškov za storitve v oblaku lahko nenadoma ugotovite, da lahko za poslovno kritične aplikacije kupite zmogljivejše tarife, ki bodo podjetju zagotavljale nemoten zaslužek. Hkrati je rešitev shranjevanje »zapuščine« razvoja, starih arhivov, baz ipd. v drage oblake. Navsezadnje je za takšne podatke povsem primeren standardni podatkovni center z običajnimi trdimi diski in strojno opremo srednje moči brez kakršnih koli zvončkov.
Tudi tukaj se lahko pomislite, da se »ta razburjenje ne splača«, a celoten problem te publikacije temelji na dejstvu, da odgovorni ljudje na različnih stopnjah zanemarijo malenkosti in naredijo tisto, kar je bolj priročno in hitreje. Kar na koncu po nekaj letih privede do prav tistih grozljivih računov.
Kakšen je rezultat?
Na splošno so oblaki kul, rešujejo veliko težav za podjetja vseh velikosti. Novost tega pojava pa pomeni, da še vedno nimamo kulture potrošnje in upravljanja. FinOps je organizacijski vzvod, ki vam pomaga učinkoviteje izkoristiti moč oblaka. Glavna stvar je, da tega položaja ne spremenite v analogijo strelskega voda, katerega naloga bo ujeti nepazljive razvijalce za roko in jih "prešteti" za izpade.
Razvijalci bi morali razvijati, ne pa šteti denar podjetja. In tako bi moral FinOps tako postopek nakupa kot postopek razgradnje ali prenosa zmogljivosti v oblaku na druge ekipe narediti preprost in prijeten za vse strani.
Vir: www.habr.com