Bestemt, du har sikkert spurgt dig selv, hvad infrastrukturen for dit projekt koster. Det er bemærkelsesværdigt: omkostningsvæksten er ikke lineær i forhold til belastningerne. Mange virksomhedsejere, CTO'er og udviklere forstår på et underbevidst niveau, at de betaler for meget. Men hvad betaler de egentlig for?
Oftest handler nedskæring af omkostninger om at finde den billigste løsning, en AWS-plan eller, når vi taler om fysiske servere, at optimere hardwarekonfigurationen. Faktisk er det ofte enhver, der kan finde på det: hvis vi taler om start-ups, er det sandsynligvis en førende udvikler, der har nok at se til. I større virksomheder er det CMO/CTO, og nogle gange blander direktøren og økonomichefen sig personligt i sagen. Generelt er det de folk, der også har rigeligt med 'faglige' opgaver. Resultatet er, at regningerne til infrastrukturen vokser, men dem, der kan finde tid til at tage hånd om det, er sjældne.
Hvis der skal købes toiletpapir til kontoret, så tager det ansvarsfulde søde menneske fra rengøringsfirmaet sig af det. Når det drejer sig om udvikling — så er det leads og CTO'er. Salg — det er også helt klart. Men siden 'serverrummet' blev betragtet som et skab, hvor der stod en almindelig tower-PC med lidt mere RAM og et par harddiske i RAID, har alle (eller i det mindste mange) ignoreret det faktum, at indkøb af kapaciteter også skal håndteres af en specialuddannet person.
Desværre viser historisk hukommelse og erfaring, at denne opgave i årtier er blevet overladt til 'tilfældige' personer: den, der var tættest på, greb spørgsmålet. Og kun for nylig har professionen FinOps begyndt at tage form på markedet. Det er den specifikt uddannede person, hvis opgave det er at kontrollere indkøb og brug af kapaciteter. Og i sidste ende at reducere virksomhedens omkostninger på dette område.
Vi opfordrer ikke til at afskedige dyre og effektive løsninger: hver virksomhed må selv vælge, hvad der er nødvendigt for at opretholde en komfortabel tilstand med hensyn til hardware og cloud-tariffer. Men man kan ikke undgå at bemærke, at en tankeløs indkøb "efter liste" uden efterfølgende kontrol og analyse af brugen for mange virksomheder ender med at medføre betydelige tab på grund af ineffektiv styring af backend-"aktiverne".
Hvad er FinOps?
Lad os sige, at du har en solid virksomhed, som sælgerne bevæger sig spændt i retning af at kalde "enterprise". Sandsynligvis har du "efter liste" købt et dusin servere, AWS og lidt ekstra "småting". Det giver mening: i en stor virksomhed sker der konstant bevægelse — nogle teams vokser, andre splittes op, tredje flyttes til naboprojekter. Denne kombination af bevægelser sammen med indkøbsmetoden "efter liste" fører til ny grå hår, når man ser den næste månedlige infrastrukturregning.
Hvad skal man så gøre — tålmodigt blive gråhåret, male over eller finde årsagerne til de mange forfærdelige nuller på regningen?
Hvad skal man skjule: godkendelse, accept og selve betalingen af anmodningen inden for virksomheden til den samme AWS-tarif — er ikke altid (i virkeligheden næsten aldrig) en hurtig sag. Netop på grund af den konstante bevægelse i virksomheden kan en del af disse indkøb gå "tabt" et sted. Og simpelthen stå stille. Hvis en opgivet rack i din serverrum bliver bemærket af en opmærksom administrator, så er det meget værre med cloud-tarifferne. De kan stå "frossen" i måneder — betalt, men samtidig allerede unødvendig for det team, der købte dem. Imens fratager kollegerne fra det nærliggende kontor deres endnu ikke-grå hår, ikke kun på hovedet, men også andre steder — de har i ugevis ikke kunnet få betalt en lignende AWS-tarif, som de akut har brug for.
Hvad er den mest åbenlyse løsning? Rigtig, at overdrage ansvaret til dem, der har brug for det, og så er alle glade. Men de horisontale kommunikationer er ikke altid godt etableret. Og den anden afdeling kan simpelthen ikke være klar over, hvilken rigdom den første har, som de faktisk ikke har brug for.
Hvem er skyld i dette? — Egentlig, ingen. Sådan er det simpelthen sat op nu.
Hvem lider under dette? — Alle, hele virksomheden.
Hvem kan rette op på situationen? — Ja, ja, FinOps.
FinOps er ikke bare et mellemlag mellem udviklerne og det udstyr, de har brug for, men en person eller et team, der ved, hvor, hvad og hvor godt alt 'ligger' i forhold til de cloud-tariffer, virksomheden har købt. Faktisk skal disse personer arbejde i tæt samarbejde med DevOps på den ene side og finansafdelingen på den anden side, og fungere som en effektiv mægler og, vigtigst af alt, analyst.
Lidt om optimering
Cloud-løsninger. Relativt billige og meget praktiske. Men denne løsning stopper med at være billig, når antallet af servere bliver tosifret eller tresifret. Desuden giver cloud'en mulighed for at bruge flere og flere tjenester, som tidligere var utilgængelige: dette inkluderer database som service (Amazon AWS, Azure Database), serverless-applikationer (AWS Lambda, Azure Functions) og mange andre. De er alle rigtig gode ved, at de er nemme at bruge — købte og afsted, ingen problemer. Men jo dybere virksomheden og dens projekter dykker ned i cloud-løsninger, desto dårligere sover finansdirektøren. Og jo hurtigere bliver direktøren gråhåret.
Det, der er problemet, er, at regningerne for forskellige cloud-tjenester altid er ekstremt forvirrende: du kan modtage en tre-siders opgørelse for en enkelt post, hvor dine penge er gået hen. Det er selvfølgelig rart, men at forstå det er praktisk talt umuligt. Og vores mening om dette emne er langt fra den eneste: for at oversætte cloud-regninger til menneskelig forståelse, findes der hele tjenester, for eksempel eller . Hvis nogen har taget sig tid til at oprette en separat tjeneste til afkodning af regninger, så er problemets omfang større end omkostningen til hårfarve.
Så, hvad gør FinOps i denne situation:
- forstår klart, hvornår og i hvilke mængder cloud-løsninger er blevet købt.
- ved, hvordan disse ressourcer bliver brugt.
- omfordeler dem alt efter behovene i de forskellige afdelinger.
- køber ikke 'bare for at have dem'.
- og i sidste ende — sparer dine penge.
Et glimrende eksempel er cloudlagring af en kold kopi af databasen. Arkiverer du for eksempel den for at reducere det forbrugte plads og trafik ved opdatering af lagringssystemet? Ja, det virker som en lille situation — i et enkelt, specifikt tilfælde, men summen af sådanne små situationer kan senere føre til urimelige omkostninger for cloudtjenester.
Eller en anden situation: du har købt kapacitet på AWS eller Azure som reserve, så du ikke falder under spidsbelastning. Kan man være sikker på, at det er den optimale løsning? For hvis disse instanser står stille 80% af tiden, giver du faktisk penge til Amazon. Desuden har både AWS og Azure burstable instanser — hvorfor skulle du have servere, der kører for ingenting, når du kan bruge værktøjer til at håndtere netop spidsbelastninger? Eller i stedet for On-Premise instanser, kan det være en god idé at overveje Reserved — de er meget billigere, og der gives også rabatter.
For resten, om rabatter
Som vi nævnte i begyndelsen, så er det ofte en hvem som helst, der står for indkøb — man finder en, og så må han bare klare det. Ofte er det 'den, der står til ansvar', som allerede er meget optaget, og i sidste ende får vi en situation, hvor en person hurtigt og kvalificeret, men helt alene, beslutter, hvad og i hvilke mængder der skal købes.
Men ved at interagere med en sælger fra cloudtjenesten kan man få mere fordelagtige betingelser, når det drejer sig om engrosindkøb af kapacitet. Det er klart, at det ikke vil være muligt at få sådanne rabatter fra en maskine ved stille og ensidig bestilling — men ved at tale med en rigtig salgmanager kan det være, at det fungerer. Eller de kan endda fortælle, hvilke rabatter de har lige nu. Det kan også være nyttigt.
Og man skal huske på, at AWS eller Azure ikke er de eneste løsninger. Selvfølgelig taler vi ikke om at organisere vores egen server — men der findes alternativer til disse to klassiske løsninger fra gigantene.
For eksempel har Google leveret en platform til virksomheder, Firebase, hvorpå man kan 'færdigbygge' det samme mobile projekt, som kan kræve hurtig skalering. Der er lagringsløsninger, realtids-databaser, hosting og cloud-synkronisering af data tilgængelige ét sted med dette tilbud.
På den anden side, hvis vi ikke taler om et monolitisk projekt, men om deres samlede antal, er en centraliseret løsning ikke altid fordelagtig. Hvis et projekt har en lang levetid, har sin egen udviklingshistorie og det nødvendige antal data, der skal opbevares, så er det værd at overveje en mere fragmenteret placering.
Når man optimerer udgifterne til cloud-tjenester, kan man pludselig indse, at for kritiske forretningsapplikationer kan man købe mere kraftfulde planer, som sikrer virksomheden en stabil indtjening. Samtidig er det ikke den bedste løsning at opbevare 'arv' fra udviklingen, gamle arkiver, databaser og lignende i dyre clouds. For sådanne data vil en standard datacenter med almindelige HDD'er og gennemsnitligt hardware være tilstrækkeligt.
Her kan man igen tænke, at 'denne besværlighed ikke er værd', men hele problematikken i denne publikation bygger på, at ansvarlige personer på forskellige stadier ignorerer detaljer og gør det, der er lettere og hurtigere. Som ender med at føre til de samme skræmmende regninger om et par år.
Hvad ender vi med?
Generelt er cloud løsninger fantastiske; de løser mange problemer for virksomheder af enhver størrelse. Dog fører nyheden om dette fænomen til, at vi stadig ikke har en kultur for forbrug og styring. FinOps er et organisatorisk værktøj, der hjælper med at udnytte cloud-ressourcer mere effektivt. Det vigtigste er ikke at forvandle denne stilling til en slags eksamenskommission, der har til opgave at fange uopmærksomme udviklere i aktion og 'klage' over spild af ressourcer.
Udviklere bør udvikle og ikke fortælle virksomheden, hvordan de skal bruge deres penge. FinOps skal gøre både købsprocessen og processen med at afskrive eller overføre cloud-ressourcer til andre teams til en enkel og behagelig begivenhed for alle parter.
Kilde: habr.com
