Du har definitivt lurt på hvor mye prosjektets infrastruktur koster. Samtidig er det overraskende: kostnadsveksten er ikke lineær med hensyn til belastninger. Mange bedriftseiere, bensinstasjoner og utviklere forstår i all hemmelighet at de betaler for mye. Men for hva egentlig?
Vanligvis kommer kostnadsreduksjoner ganske enkelt ned på å finne den billigste løsningen, en AWS-plan, eller, i tilfelle fysiske stativer, optimalisere maskinvarekonfigurasjonen. Ikke bare det: faktisk gjør hvem som helst dette, slik Gud vil: hvis vi snakker om en oppstart, så er dette sannsynligvis en ledende utvikler som har mye hodepine. På større kontorer håndteres dette av CMO/CTO, og noen ganger blir daglig leder personlig involvert i saken sammen med regnskapssjefen. Generelt, de menneskene som har nok "kjerne" bekymringer. Og det viser seg at infrastrukturregningene stiger, men de som ikke har tid til å håndtere det, takler det.
Dersom du har behov for å kjøpe toalettpapir til kontoret, gjøres dette av forsyningsansvarlig eller en ansvarlig fra renholdsfirmaet. Hvis vi snakker om utvikling - leads og CTO. Salg - alt er også klart. Men siden gamle dager, da et "serverrom" var et navn på et skap der det var et vanlig tårnsystem med litt mer RAM og et par harddisker i raidet, ignorerer alle (eller i det minste mange) faktum at kjøp av kapasitet bør håndteres også en spesialutdannet person.
Akk, historisk hukommelse og erfaring indikerer at denne oppgaven i flere tiår ble flyttet til "tilfeldige" mennesker: den som var nærmest tok opp spørsmålet. Og først nylig begynte FinOps-profesjonen å ta form på markedet og ta litt konkret form. Dette er den samme spesialutdannede personen som har som oppgave å kontrollere innkjøp og bruk av kapasitet. Og til syvende og sist for å redusere selskapets kostnader på dette området.
Vi tar ikke til orde for å forlate dyre og effektive løsninger: hver virksomhet må selv bestemme hva den trenger for en komfortabel tilværelse når det gjelder maskinvare og skytariffer. Men man kan ikke unngå å legge merke til det faktum at tankeløse kjøp "i henhold til listen" uten påfølgende overvåking og analyse av bruk for mange selskaper til slutt resulterer i svært, veldig betydelige tap på grunn av ineffektiv forvaltning av "aktiva" til deres backend.
Hvem er FinOps
La oss si at du har en anerkjent bedrift, som selgere snakker om "enterprise" i en pustende tone. Sannsynligvis, "i henhold til listen" kjøpte du et dusin eller to servere, AWS og noen andre "småting". Noe som er logisk: i et stort selskap skjer det stadig en slags bevegelse - noen lag vokser, andre går i oppløsning, andre overføres til naboprosjekter. Og kombinasjonen av disse bevegelsene, sammen med den "listebaserte" anskaffelsesmekanismen, fører til slutt til nye grå hår når man ser på den neste månedlige infrastrukturregningen.
Så hva skal jeg gjøre - tålmodig fortsette å gråne, male over det, eller finne ut årsakene til utseendet til disse mange forferdelige nullene i betalingen?
La oss være ærlige: godkjenning, godkjenning og direkte betaling av en søknad innen selskapet for samme AWS-tariff er ikke alltid (i realiteten, nesten aldri) raskt. Og nettopp på grunn av den konstante bedriftsbevegelsen, kan noen av de samme oppkjøpene gå tapt et sted. Og det er trivielt å stå stille. Hvis en oppmerksom administrator legger merke til et eierløst rack i serverrommet hans, er alt mye tristere når det gjelder skytariffer. De kan ligge oppe i månedsvis - betalt, men samtidig ikke lenger behøves av noen i avdelingen de ble kjøpt for. Samtidig begynner kolleger fra neste kontor å rive ut det ennå ikke grå håret ikke bare på hodet, men også andre steder - de har ikke kunnet betale for omtrent samme AWS-tariff for den n. uken, som er desperat nødvendig.
Hva er den mest åpenbare løsningen? Det stemmer, overlate tøylene til de som trenger det, og alle er fornøyde. Men horisontal kommunikasjon er ikke alltid godt etablert. Og den andre avdelingen vet kanskje rett og slett ikke om rikdommen til den første, som på en eller annen måte viste seg å ikke virkelig trenge denne rikdommen.
Hvem har skylden for dette? - Egentlig ingen. Sånn er alt lagt opp foreløpig.
Hvem lider av dette? – Det er det, hele selskapet.
Hvem kan fikse situasjonen? – Ja, ja, FinOps.
FinOps er ikke bare et lag mellom utviklere og utstyret de trenger, men en person eller et team som vil vite hvor, hva og hvor godt det "ligger" i form av de samme skytariffene kjøpt av selskapet. Faktisk må disse menneskene jobbe sammen med DevOps, på den ene siden, og finansavdelingen på den andre, og spille rollen som en effektiv mellommann og, viktigst av alt, en analytiker.
Litt om optimalisering
Skyer. Relativt billig og veldig praktisk. Men denne løsningen slutter å være billig når antall servere når to- eller trippelsifret. I tillegg gjør skyer det mulig å bruke stadig flere tjenester som tidligere var utilgjengelige: dette er databaser som en tjeneste (Amazon AWS, Azure Database), serverløse applikasjoner (AWS Lambda, Azure Functions) og mange andre. De er alle veldig kule fordi de er enkle å bruke - kjøp og gå, ingen problemer. Men jo dypere selskapet og dets prosjekter stuper ned i skyene, jo dårligere sover finansdirektøren. Og jo raskere blir generalen grå.
Faktum er at fakturaer for ulike skytjenester alltid er ekstremt forvirrende: for én vare kan du motta en tre-siders forklaring på hva, hvor og hvordan pengene dine gikk. Dette er selvfølgelig hyggelig, men det er nesten umulig å forstå det. Dessuten er vår mening om dette spørsmålet langt fra den eneste: for å overføre skykontoer til menneskelige, er det hele tjenester, for eksempel eller . Hvis noen gidder å lage en egen tjeneste for å tyde regninger, har omfanget av problemet vokst ut av kostnadene for hårfarging.
Så hva gjør FinOps i denne situasjonen:
- forstår tydelig når og i hvilke volumer skyløsninger ble kjøpt.
- vet hvordan disse kapasitetene brukes.
- omfordeler dem avhengig av behovene til en bestemt enhet.
- kjøper ikke "slik at det kan være".
- og til slutt sparer du penger.
Et godt eksempel er skylagring av en kald kopi av en database. Arkiverer du det for eksempel for å redusere mengden plass og trafikk som forbrukes når du oppdaterer lagringen? Ja, det ser ut til at situasjonen er billig - i et enkelt tilfelle, men helheten av slike billige situasjoner resulterer senere i ublu kostnader for skytjenester.
Eller en annen situasjon: du kjøpte reservekapasitet på AWS eller Azure for ikke å falle under toppbelastning. Kan du være sikker på at dette er den optimale løsningen? Tross alt, hvis disse tilfellene er inaktive 80%, gir du ganske enkelt penger til Amazon. Dessuten, for slike tilfeller, har de samme AWS og Azure burstable forekomster - hvorfor trenger du tomgangsservere, hvis du kan bruke et verktøy for å løse problemer med toppbelastninger? Eller, i stedet for On Premise-forekomster, bør du se mot Reserved - de er mye billigere og de tilbyr også rabatter.
Forresten, om rabatter
Som vi sa i begynnelsen, utføres anskaffelser ofte av hvem som helst - de fant den siste, og så gjør han det på en eller annen måte selv. Oftest blir folk som allerede er opptatt "ekstrem", og som et resultat får vi en situasjon der en person raskt og dyktig, men helt uavhengig, bestemmer hva og i hvilke mengder å kjøpe.
Men når du samhandler med en selger fra skytjenesten, kan du få gunstigere betingelser når det gjelder grossistkjøp av kapasitet. Det er klart at du ikke vil kunne få slike rabatter fra en bil med en lydløs og ensidig registrering - men etter å ha snakket med en ekte salgssjef, kan du brenne ut. Eller disse gutta kan fortelle deg hva de for øyeblikket har rabatter på. Det kan også være nyttig.
Samtidig må du huske at lyset ikke konvergerte som en kile på AWS eller Azure. Det er selvsagt ikke snakk om å organisere sitt eget serverrom – men det finnes alternativer til disse to klassiske løsningene fra gigantene.
For eksempel brakte Google Firebase-plattformen til selskaper, der de kan være vert for det samme mobilprosjektet på nøkkelferdig basis, noe som kan kreve rask skalering. Lagring, sanntidsdatabase, hosting og skydatasynkronisering med denne løsningen som eksempel er tilgjengelig på ett sted.
På den annen side, hvis vi ikke snakker om et monolittisk prosjekt, men om deres helhet, så er ikke en sentralisert løsning alltid fordelaktig. Hvis prosjektet er langvarig, har sin egen utviklingshistorie og en tilsvarende mengde data som kreves for lagring, er det verdt å tenke på mer fragmentert plassering.
Når du optimaliserer kostnader for skytjenester, kan du plutselig innse at for forretningskritiske applikasjoner kan du kjøpe kraftigere tariffer som vil gi selskapet uavbrutt inntjening. Samtidig er det en løsning å lagre «arven» fra utvikling, gamle arkiver, databaser osv. i dyre skyer. Tross alt, for slike data, er et standard datasenter med vanlige HDD-er og middels kraftig maskinvare uten bjeller og plystre ganske egnet.
Her igjen kan du kanskje tro at "dette oppstyret ikke er verdt det", men hele problemet med denne publikasjonen er basert på det faktum at de ansvarlige på forskjellige stadier forsømmer de små tingene og gjør det som er mer praktisk og raskere. Som til slutt, etter et par år, resulterer i de samme skrekkberetningene.
Resultatet?
Generelt er skyer kule, de løser mange problemer for bedrifter av alle størrelser. Det nye ved dette fenomenet betyr imidlertid at vi fortsatt ikke har en kultur for forbruk og ledelse. FinOps er en organisatorisk spak som hjelper deg å utnytte skykraft mer effektivt. Det viktigste er ikke å gjøre denne stillingen til en analog av en skytegruppe, hvis oppgave vil være å fange uoppmerksomme utviklere ved hånden og "skjelle" dem for nedetid.
Utviklere bør utvikle, ikke telle selskapets penger. Og derfor bør FinOps gjøre både kjøpsprosessen og prosessen med å avvikle eller overføre skykapasitet til andre team til en begivenhet enkel og hyggelig for alle parter.
Kilde: www.habr.com