Definitivno ste se zapitali koliko košta infrastruktura vašeg projekta. Istovremeno je iznenađujuće: rast troškova nije linearan u odnosu na opterećenja. Mnogi vlasnici preduzeća, servisi i programeri potajno shvataju da preplaćuju. Ali za šta tačno?
Obično se smanjenje troškova jednostavno svodi na pronalaženje najjeftinijeg rješenja, AWS plana, ili, u slučaju fizičkih rekova, optimizaciju konfiguracije hardvera. I ne samo to: u stvari, svako to radi, kako Bog hoće: ako govorimo o startupu, onda je to vjerovatno vodeći programer koji ima dosta glavobolja. U većim uredima, ovim se bavi CMO/CTO, a ponekad se generalni direktor lično uključi u pitanje zajedno sa glavnim računovođom. Generalno, oni ljudi koji imaju dovoljno „osnovnih“ briga. I ispada da računi za infrastrukturu rastu, ali oni koji nemaju vremena da se bave time se bave.
Ukoliko treba da kupite toalet papir za kancelariju, to će uraditi menadžer nabavke ili odgovorna osoba iz firme za čišćenje. Ako govorimo o razvoju - vodi i CTO. Prodaja - takođe je sve jasno. Ali od davnina, kada je „serverska soba“ bila naziv za ormarić u kojem je bio običan toranj sistem sa malo više RAM-a i par hard diskova u napadu, svi (ili barem mnogi) ignorišu činjenica da kupovinom kapaciteta treba da se bavi i posebno obučena osoba.
Nažalost, istorijsko pamćenje i iskustvo pokazuju da je decenijama ovaj zadatak prebačen na „slučajne” ljude: ko je bio najbliži, postavljao je pitanje. A tek nedavno se profesija FinOps počela oblikovati na tržištu i poprimati neke konkretne oblike. Riječ je o istoj posebno obučenoj osobi čiji je zadatak da kontroliše kupovinu i korištenje kapaciteta. I, konačno, u smanjenju troškova kompanije u ovoj oblasti.
Ne zalažemo se za odustajanje od skupih i efikasnih rješenja: svaki posao mora sam odlučiti šta mu je potrebno za ugodan život u smislu hardverskih i cloud tarifa. Ali ne može se a da se ne obrati pažnja na činjenicu da nepromišljena kupovina „po listi“ bez naknadnog praćenja i analize upotrebe za mnoge kompanije u konačnici rezultira vrlo, vrlo značajnim gubicima zbog neefikasnog upravljanja „imovinom“ njihovog bekenda.
Ko je FinOps
Recimo da imate renomirano preduzeće, o kojem prodavci pričaju o „preduzeću“ uzdahnutim tonom. Vjerovatno ste “po spisku” kupili desetak-dva servera, AWS i još neke “sitnice”. Što je i logično: u velikoj kompaniji se stalno dešava nekakav pokret – neki timovi rastu, drugi se raspadaju, treći se prenose na susjedne projekte. A kombinacija ovih pokreta, zajedno sa mehanizmom nabavke „na listi“, na kraju dovodi do novih sijedih vlasi kada se pogleda naredni mjesečni račun za infrastrukturu.
Dakle, što učiniti - strpljivo nastaviti siviti, farbati ga ili otkriti razloge za pojavu ovih brojnih strašnih nula u plaćanju?
Budimo iskreni: odobrenje, odobrenje i direktno plaćanje aplikacije unutar kompanije za istu AWS tarifu nije uvijek (u stvarnosti, gotovo nikad) brzo. A upravo zbog stalnih korporativnih kretanja, neke od istih akvizicija mogu se negdje “izgubiti”. I trivijalno je stajati besposlen. Ako pažljiv administrator primijeti stalak bez vlasnika u svojoj server sobi, onda je u slučaju tarifa u oblaku sve mnogo tužnije. Mogu se odlagati mjesecima - plaćeni, ali u isto vrijeme više nikome u odjelu za koji su kupljeni nisu potrebni. Istovremeno, kolege iz susedne kancelarije počinju da čupaju svoju još ne sijedu kosu ne samo na glavi, već i na drugim mjestima - već n-tu sedmicu ne mogu da plate približno istu AWS tarifu, koju je očajnički potrebna.
Koje je najočiglednije rješenje? Tako je, prepustite uzde onima kojima je potrebno i svi su sretni. Ali horizontalne komunikacije nisu uvijek dobro uspostavljene. A drugi odjel možda jednostavno ne zna za bogatstvo prvog, za koji se nekako ispostavilo da to bogatstvo baš i nije potrebno.
Ko je kriv za ovo? - Zapravo, niko. Tako je za sada sve postavljeno.
Ko pati od ovoga? - To je to, cela kompanija.
Ko može popraviti situaciju? - Da, da, FinOps.
FinOps nije samo sloj između programera i opreme koja im je potrebna, već osoba ili tim koji će znati gdje, šta i koliko dobro „leži“ u smislu istih tarifa u oblaku koje kupuje kompanija. Zapravo, ovi ljudi moraju raditi u tandemu sa DevOps-om, s jedne strane, i odjelom za finansije s druge strane, igrajući ulogu efikasnog posrednika i, što je najvažnije, analitičara.
Malo o optimizaciji
Oblaci. Relativno jeftino i vrlo povoljno. Ali ovo rješenje prestaje biti jeftino kada broj servera dosegne dvocifren ili trocifren broj. Osim toga, oblaci omogućavaju korištenje sve većeg broja usluga koje su ranije bile nedostupne: to su baze podataka kao usluga (Amazon AWS, Azure Database), aplikacije bez servera (AWS Lambda, Azure Functions) i mnoge druge. Svi su vrlo cool jer su jednostavni za korištenje - kupite i idite, bez problema. Ali što dublje kompanija i njeni projekti uranjaju u oblake, finansijski direktor sve gore spava. I što brže general posijedi.
Činjenica je da su fakture za razne usluge u oblaku uvijek krajnje zbunjujuće: za jednu stavku možete dobiti objašnjenje na tri stranice šta, gdje i kako je otišao vaš novac. Ovo je, naravno, prijatno, ali je gotovo nemoguće razumeti. Štaviše, naše mišljenje o ovom pitanju daleko je od jedinog: da bi se računi u oblaku prebacili na ljudske, postoje čitave usluge, npr. ili . Ako se neko potrudio da napravi zasebnu uslugu za dešifrovanje računa, onda su razmere problema prerasle cenu farbanja za kosu.
Dakle, šta FinOps radi u ovoj situaciji:
- jasno razumije kada i u kojim količinama su rješenja u oblaku kupljena.
- zna kako se ti kapaciteti koriste.
- preraspoređuje ih u zavisnosti od potreba određene jedinice.
- ne kupuje "tako da bude".
- i na kraju vam štedi novac.
Odličan primjer je skladištenje hladne kopije baze podataka u oblaku. Na primjer, da li ga arhivirate kako biste smanjili količinu prostora i prometa koji se troši prilikom ažuriranja skladišta? Da, čini se da je situacija jeftina - u jednom konkretnom slučaju, ali ukupnost takvih jeftinih situacija kasnije rezultira previsokim troškovima za usluge u oblaku.
Ili druga situacija: kupili ste rezervni kapacitet na AWS ili Azure kako ne biste pali pod vršno opterećenje. Možete li biti sigurni da je ovo optimalno rješenje? Uostalom, ako su ove instance neaktivne 80%, onda jednostavno dajete novac Amazonu. Štaviše, za takve slučajeve isti AWS i Azure imaju burstabilne instance - zašto su vam potrebni serveri u stanju mirovanja, ako možete koristiti alat za rješavanje problema vršnog opterećenja? Ili, umjesto On Premise instanca, treba gledati prema Reserved - oni su mnogo jeftiniji, a nude i popuste.
Usput, o popustima
Kao što smo rekli na početku, nabavku često obavlja bilo ko - našli su zadnjeg, a onda to nekako sam uradi. Najčešće ljudi koji su već zauzeti postaju “ekstremni”, a kao rezultat dolazimo u situaciju da osoba brzo i vješto, ali potpuno samostalno, odlučuje šta će i u kojim količinama kupiti.
Ali u interakciji sa prodavcem iz cloud servisa možete dobiti povoljnije uslove kada je u pitanju veleprodajna kupovina kapaciteta. Jasno je da nećete moći dobiti takve popuste od automobila s tihom i jednostranom registracijom - ali nakon razgovora sa pravim menadžerom prodaje možete pregorjeti. Ili vam ovi momci mogu reći na šta trenutno imaju popuste. Također može biti korisno.
U isto vrijeme, morate imati na umu da se svjetlost nije spojila kao klin na AWS ili Azure. Naravno, nema govora o organizaciji vlastite server sobe - ali postoje alternative za ova dva klasična rješenja giganata.
Na primjer, Google je kompanijama donio platformu Firebase, na kojoj mogu ugostiti isti mobilni projekat po principu ključ u ruke, što može zahtijevati brzo skaliranje. Skladištenje, baza podataka u realnom vremenu, hosting i sinhronizacija podataka u oblaku koristeći ovo rješenje kao primjer dostupni su na jednom mjestu.
S druge strane, ako ne govorimo o monolitnom projektu, već o njihovoj ukupnosti, onda centralizirano rješenje nije uvijek od koristi. Ako je projekt dugovječan, ima svoju povijest razvoja i odgovarajuću količinu podataka potrebnih za pohranu, onda je vrijedno razmisliti o fragmentiranijem smještaju.
Prilikom optimizacije troškova za usluge u oblaku, možete iznenada shvatiti da za poslovne kritične aplikacije možete kupiti moćnije tarife koje će kompaniji omogućiti neprekidnu zaradu. Istovremeno, pohranjivanje “naslijeđa” razvoja, starih arhiva, baza podataka itd. u skupe oblake je rješenje. Uostalom, za takve podatke je sasvim prikladan standardni podatkovni centar s redovnim HDD-ovima i hardverom srednje snage bez ikakvih zvona i zviždaljki.
I ovdje biste mogli pomisliti da „ova gužva nije vrijedna toga“, ali cijeli problem ove publikacije je u tome što u različitim fazama odgovorni ljudi zanemaruju sitnice i rade ono što je zgodnije i brže. Što, na kraju, nakon par godina rezultira upravo tim horor računima.
Šta je na kraju?
Općenito, oblaci su cool, rješavaju mnogo problema za preduzeća bilo koje veličine. Međutim, novost ovog fenomena znači da još uvijek nemamo kulturu potrošnje i upravljanja. FinOps je organizacijska poluga koja vam pomaže da efikasnije iskoristite snagu oblaka. Glavna stvar je ne pretvoriti ovu poziciju u analognu streljačkom vodu, čiji će zadatak biti uhvatiti nepažljive programere za ruku i "grditi" ih za zastoje.
Programeri bi trebali razvijati, a ne računati novac kompanije. Stoga bi FinOps trebao i proces kupovine i proces razgradnje ili prijenosa kapaciteta u oblaku na druge timove učiniti jednostavnim i ugodnim za sve strane.
izvor: www.habr.com