Du har helt sikkert undret dig over, hvor meget dit projekts infrastruktur koster. Samtidig er det overraskende: Væksten i omkostningerne er ikke lineær med hensyn til belastninger. Mange virksomhedsejere, tankstationer og udviklere forstår i al hemmelighed, at de betaler for meget. Men for hvad præcist?
Typisk kommer omkostningerne ned på at finde den billigste løsning, en AWS-plan eller, i tilfælde af fysiske racks, at optimere hardwarekonfigurationen. Ikke nok med det: faktisk gør enhver dette, som Gud vil: hvis vi taler om en startup, så er dette sandsynligvis en førende udvikler, der har masser af hovedpine. På større kontorer håndteres dette af CMO/CTO, og nogle gange bliver generaldirektøren personligt involveret i sagen sammen med regnskabschefen. Generelt er de mennesker, der har nok "kerne" bekymringer. Og det viser sig, at infrastrukturregningerne stiger, men dem, der ikke har tid til at håndtere det, håndterer det.
Skal du købe toiletpapir til kontoret, sker dette af den forsyningsansvarlige eller en ansvarlig fra rengøringsfirmaet. Hvis vi taler om udvikling - leads og CTO. Salg - alt er også klart. Men siden gamle dage, hvor et "serverrum" var et navn for et kabinet, hvor der var et almindeligt tårnsystem med lidt mere RAM og et par harddiske i raidet, ignorerer alle (eller i hvert fald mange) kendsgerning, at køb af kapacitet skal varetages også en specialuddannet person.
Ak, historisk hukommelse og erfaring indikerer, at denne opgave i årtier blev flyttet til "tilfældige" mennesker: den, der var tættest på, tog spørgsmålet op. Og først for nylig begyndte FinOps-faget at tage form på markedet og tage konkret form. Dette er den samme specialuddannede person, hvis opgave er at kontrollere indkøb og udnyttelse af kapacitet. Og i sidste ende med at reducere virksomhedens omkostninger på dette område.
Vi advokerer ikke for at opgive dyre og effektive løsninger: Hver virksomhed skal selv bestemme, hvad den har brug for for en behagelig tilværelse i form af hardware og cloud-takster. Men man kan ikke undgå at være opmærksom på, at tankeløse indkøb "ifølge listen" uden efterfølgende overvågning og analyse af brugen for mange virksomheder i sidste ende resulterer i meget, meget betydelige tab på grund af ineffektiv styring af "aktiverne" i deres backend.
Hvem er FinOps
Lad os sige, at du har en velrenommeret virksomhed, som sælgere taler om "enterprise" i en betagende tone. Sandsynligvis købte du "ifølge listen" et dusin eller to servere, AWS og nogle andre "småting". Hvilket er logisk: I en stor virksomhed sker der konstant en eller anden form for bevægelse - nogle teams vokser, andre går i opløsning, andre overføres til naboprojekter. Og kombinationen af disse bevægelser, sammen med den "listebaserede" indkøbsmekanisme, fører i sidste ende til nye grå hår, når man ser på den næste månedlige infrastrukturregning.
Så hvad skal man gøre - tålmodigt fortsætte med at gråne, male over det, eller finde ud af årsagerne til udseendet af disse talrige forfærdelige nuller i betalingen?
Lad os være ærlige: Godkendelse, godkendelse og direkte betaling af en ansøgning inden for virksomheden for den samme AWS-takst er ikke altid (i virkeligheden næsten aldrig) hurtig. Og netop på grund af den konstante virksomhedsbevægelse kan nogle af de samme opkøb være "tabt" et eller andet sted. Og det er trivielt at stå stille. Hvis en opmærksom administrator bemærker et ejerløst rack i sit serverrum, er alt meget mere trist i tilfælde af skytakster. De kan ligge i månedsvis - betalt, men samtidig ikke længere behøves af nogen i den afdeling, de er købt til. Samtidig begynder kollegerne fra det næste kontor at rive deres endnu ikke grå hår ud ikke kun på hovedet, men også andre steder - de har ikke kunne betale for nogenlunde samme AWS-takst for n. uge, hvilket der er hårdt brug for.
Hvad er den mest oplagte løsning? Det er rigtigt, overlad tøjlerne til dem i nød, og alle er glade. Men horisontal kommunikation er ikke altid veletableret. Og den anden afdeling kender måske simpelthen ikke til den førstes rigdom, som på en eller anden måde viste sig ikke rigtig at have brug for denne rigdom.
Hvem er skyld i dette? - Faktisk ingen. Sådan er alt sat op lige nu.
Hvem lider af dette? - Det er det, hele virksomheden.
Hvem kan rette op på situationen? - Ja, ja, FinOps.
FinOps er ikke bare et lag mellem udviklere og det udstyr, de har brug for, men en person eller et team, der vil vide, hvor, hvad og hvor godt det "ligger" i forhold til de samme cloud-takster, som virksomheden har købt. Faktisk skal disse mennesker arbejde sammen med DevOps på den ene side og finansafdelingen på den anden og spille rollen som en effektiv mellemmand og, vigtigst af alt, en analytiker.
Lidt om optimering
Skyer. Relativt billigt og meget praktisk. Men denne løsning holder op med at være billig, når antallet af servere når to- eller trecifrede cifre. Derudover gør skyer det muligt at bruge flere og flere tjenester, der tidligere var utilgængelige: Det er databaser som en tjeneste (Amazon AWS, Azure Database), serverløse applikationer (AWS Lambda, Azure Functions) og mange andre. De er alle meget seje, fordi de er nemme at bruge - køb og gå, ingen problemer. Men jo dybere virksomheden og dens projekter dykker ned i skyerne, jo dårligere sover CFO'en. Og jo hurtigere bliver generalen grå.
Faktum er, at fakturaer for forskellige cloud-tjenester altid er ekstremt forvirrende: For én vare kan du modtage en tre-siders forklaring på, hvad, hvor og hvordan dine penge gik. Dette er selvfølgelig behageligt, men det er næsten umuligt at forstå det. Desuden er vores mening om dette spørgsmål langt fra den eneste: For at overføre skykonti til menneskelige, er der hele tjenester, f.eks. eller . Hvis nogen gad at oprette en separat service til at dechifrere regninger, så er omfanget af problemet vokset ud af omkostningerne ved hårfarve.
Så hvad gør FinOps i denne situation:
- forstår tydeligt hvornår og i hvilke mængder cloud-løsninger blev købt.
- ved, hvordan disse kapaciteter bruges.
- omfordeler dem afhængigt af en bestemt enheds behov.
- køber ikke "så det kan være".
- og i sidste ende sparer det dig penge.
Et godt eksempel er skylagring af en kold kopi af en database. Arkiverer du det for eksempel for at reducere mængden af plads og trafik, der forbruges, når du opdaterer lageret? Ja, det ser ud til, at situationen er billig - i et enkelt konkret tilfælde, men helheden af sådanne billige situationer resulterer senere i ublu omkostninger til cloud-tjenester.
Eller en anden situation: du har købt reservekapacitet på AWS eller Azure for ikke at falde under spidsbelastning. Kan du være sikker på, at dette er den optimale løsning? Når alt kommer til alt, hvis disse tilfælde er inaktive 80%, giver du simpelthen penge til Amazon. Desuden har de samme AWS og Azure burstable instanser i sådanne tilfælde - hvorfor har du brug for tomgangsservere, hvis du kan bruge et værktøj til at løse problemer med spidsbelastninger? Eller, i stedet for On Premise-forekomster, bør du kigge mod Reserved - de er meget billigere, og de tilbyder også rabatter.
I øvrigt om rabatter
Som vi sagde i begyndelsen, udføres indkøb ofte af hvem som helst - de fandt den sidste, og så gør han det på en eller anden måde selv. Oftest bliver folk, der allerede har travlt, "ekstreme", og som et resultat får vi en situation, hvor en person hurtigt og dygtigt, men helt uafhængigt, beslutter, hvad og i hvilke mængder der skal købes.
Men når du interagerer med en sælger fra cloud-tjenesten, kan du få mere fordelagtige betingelser, når det kommer til engroskøb af kapacitet. Det er klart, at du ikke vil være i stand til at få sådanne rabatter fra en bil med en lydløs og ensidig registrering - men efter at have talt med en rigtig salgschef, kan du brænde ud. Eller disse fyre kan fortælle dig, hvad de i øjeblikket har rabatter på. Det kan også være nyttigt.
Samtidig skal du huske, at lyset ikke konvergerede som en kile på AWS eller Azure. Der er selvfølgelig ikke tale om at organisere sit eget serverrum – men der findes alternativer til disse to klassiske løsninger fra giganterne.
For eksempel bragte Google Firebase-platformen til virksomheder, hvor de kan hoste det samme mobilprojekt på nøglefærdig basis, hvilket kan kræve hurtig skalering. Opbevaring, realtidsdatabase, hosting og cloud-datasynkronisering med denne løsning som eksempel er tilgængelige ét sted.
På den anden side, hvis vi ikke taler om et monolitisk projekt, men om deres helhed, så er en centraliseret løsning ikke altid gavnlig. Hvis projektet er langvarigt, har sin egen udviklingshistorie og en tilsvarende mængde data, der kræves til opbevaring, så er det værd at tænke på mere fragmenteret placering.
Når du optimerer omkostningerne til cloud-tjenester, kan du pludselig indse, at for forretningskritiske applikationer kan du købe mere kraftfulde tariffer, der vil give virksomheden uafbrudt indtjening. Samtidig er det en løsning at gemme ”arven” fra udvikling, gamle arkiver, databaser osv. i dyre skyer. Når alt kommer til alt, for sådanne data er et standard datacenter med almindelige HDD'er og medium-power hardware uden nogen klokker og fløjter ganske velegnet.
Her tænker du måske igen, at "denne ballade er ikke det værd", men hele problemet med denne publikation er baseret på det faktum, at de ansvarlige på forskellige stadier forsømmer de små ting og gør, hvad der er mere bekvemt og hurtigere. Hvilket i sidste ende efter et par år resulterer i netop de rædselsberetninger.
Resultatet?
Generelt er skyer seje, de løser en masse problemer for virksomheder af enhver størrelse. Men det nye i dette fænomen betyder, at vi stadig ikke har en kultur for forbrug og ledelse. FinOps er en organisatorisk løftestang, der hjælper dig med at udnytte cloud-kraft mere effektivt. Det vigtigste er ikke at omdanne denne position til en analog af et skydehold, hvis opgave vil være at fange uopmærksomme udviklere ved hånden og "skælde ud" dem for nedetid.
Udviklere bør udvikle sig, ikke tælle virksomhedens penge. Og derfor bør FinOps gøre både købsprocessen og processen med nedlukning eller overførsel af cloudkapacitet til andre teams til en begivenhed enkel og behagelig for alle parter.
Kilde: www.habr.com