Du har definitivt undrat hur mycket ditt projekts infrastruktur kostar. Samtidigt är det överraskande: kostnadsökningen är inte linjär med avseende på laster. Många företagare, bensinstationer och utvecklare förstår i hemlighet att de betalar för mycket. Men för vad exakt?
Vanligtvis handlar det om att sänka kostnaderna helt enkelt att hitta den billigaste lösningen, en AWS-plan eller, i fallet med fysiska rack, optimera hårdvarukonfigurationen. Inte nog med det: i själva verket gör vem som helst detta, som Gud vill: om vi pratar om en startup, så är detta förmodligen en ledande utvecklare som har massor av huvudvärk. På större kontor hanteras detta av CMO/CTO och ibland engagerar sig generaldirektören personligen i frågan tillsammans med ekonomichefen. I allmänhet, de människor som har tillräckligt med "kärna" bekymmer. Och det visar sig att infrastrukturräkningarna stiger, men de som inte har tid att ta itu med det tar itu med det.
Behöver du köpa toalettpapper till kontoret görs detta av försörjningsansvarig eller en ansvarig från städföretaget. Om vi pratar om utveckling – leads och CTO. Försäljning – allt är också klart. Men sedan gamla dagar, när ett "serverrum" var ett namn för ett skåp där det fanns ett vanligt tornsystem med lite mer RAM och ett par hårddiskar i raiden, ignorerar alla (eller åtminstone många) faktum att inköp av kapacitet bör skötas även en specialutbildad person.
Tyvärr, historiskt minne och erfarenhet tyder på att denna uppgift under årtionden flyttades till "slumpmässiga" människor: den som var närmast tog upp frågan. Och först nyligen började FinOps-yrket ta form på marknaden och ta lite konkret form. Detta är samma specialutbildade person som har till uppgift att kontrollera inköp och användning av kapacitet. Och i slutändan för att minska företagets kostnader på detta område.
Vi förespråkar inte att överge dyra och effektiva lösningar: varje företag måste själv bestämma vad det behöver för en bekväm tillvaro när det gäller hårdvara och molntariffer. Men man kan inte låta bli att uppmärksamma det faktum att tanklösa inköp "enligt listan" utan efterföljande övervakning och analys av användning för många företag i slutändan resulterar i mycket, mycket betydande förluster på grund av ineffektiv hantering av "tillgångarna" i deras backend.
Vem är FinOps
Låt oss säga att du har ett välrenommerat företag, som säljare talar om "företag" i en andig ton. Förmodligen, "enligt listan" köpte du ett dussin eller två servrar, AWS och några andra "småsaker". Vilket är logiskt: i ett stort företag sker ständigt någon form av rörelse - vissa team växer, andra sönderfaller, andra överförs till närliggande projekt. Och kombinationen av dessa rörelser, tillsammans med den "listbaserade" upphandlingsmekanismen, leder i slutändan till nya grå hårstrån när man tittar på nästa månatliga infrastrukturräkning.
Så vad ska man göra - fortsätt tålmodigt att gråna, måla över det eller ta reda på orsakerna till uppkomsten av dessa många hemska nollor i betalningen?
Låt oss vara ärliga: godkännande, godkännande och direktbetalning av en ansökan inom företaget för samma AWS-tariff går inte alltid (i verkligheten nästan aldrig) snabbt. Och just på grund av den ständiga företagsrörelsen kan vissa av samma förvärv "förloras" någonstans. Och det är trivialt att stå sysslolös. Om en uppmärksam administratör märker ett ägarlöst rack i sitt serverrum, är allt mycket tråkigare när det gäller molntariffer. De kan ligga upplagda i månader - betalas men samtidigt inte längre behövas av någon på den avdelning som de köptes till. Samtidigt börjar kollegor från nästa kontor slita ut sitt ännu inte gråa hår inte bara på huvudet, utan även på andra ställen – de har inte kunnat betala för ungefär samma AWS-taxa för n:e veckan, vilket behövs desperat.
Vilken är den mest uppenbara lösningen? Det stämmer, lämna över tyglarna till de behövande, och alla är nöjda. Men horisontell kommunikation är inte alltid väl etablerad. Och den andra avdelningen kanske helt enkelt inte känner till den förstas rikedom, som på något sätt visade sig inte riktigt behöva denna rikedom.
Vem är skyldig till detta? - Egentligen ingen. Så är allt upplagt för tillfället.
Vem lider av detta? – Det är det, hela företaget.
Vem kan fixa situationen? – Ja, ja, FinOps.
FinOps är inte bara ett lager mellan utvecklare och den utrustning de behöver, utan en person eller ett team som kommer att veta var, vad och hur väl det "ligger" när det gäller samma molntariffer som företaget köpt. Faktum är att dessa människor måste arbeta tillsammans med DevOps, å ena sidan, och finansavdelningen å andra sidan, och spela rollen som en effektiv mellanhand och, viktigast av allt, en analytiker.
Lite om optimering
Moln. Relativt billigt och väldigt bekvämt. Men den här lösningen slutar vara billig när antalet servrar når två- eller tresiffriga siffror. Dessutom gör moln det möjligt att använda fler och fler tjänster som tidigare inte var tillgängliga: det är databaser som en tjänst (Amazon AWS, Azure Database), serverlösa applikationer (AWS Lambda, Azure Functions) och många andra. De är alla väldigt coola eftersom de är lätta att använda - köp och gå, inga problem. Men ju djupare företaget och dess projekt störtar ner i molnen, desto sämre sover CFO. Och ju snabbare generalen blir grå.
Faktum är att fakturor för olika molntjänster alltid är extremt förvirrande: för en vara kan du få en tresidig förklaring om vad, var och hur dina pengar tog vägen. Detta är naturligtvis trevligt, men det är nästan omöjligt att förstå det. Dessutom är vår åsikt i denna fråga långt ifrån den enda: för att överföra molnkonton till mänskliga, finns det hela tjänster, till exempel eller . Om någon brydde sig om att skapa en separat tjänst för att dechiffrera räkningar, har omfattningen av problemet växt ur kostnaden för hårfärgning.
Så vad gör FinOps i den här situationen:
- förstår tydligt när och i vilka volymer molnlösningar köptes.
- vet hur dessa kapaciteter används.
- omfördelar dem beroende på behoven hos en viss enhet.
- köper inte "så att det kan vara".
- och i slutändan sparar du pengar.
Ett bra exempel är molnlagring av en kall kopia av en databas. Till exempel, arkiverar du det för att minska mängden utrymme och trafik som förbrukas när du uppdaterar lagringen? Ja, det verkar som att situationen är billig - i ett enstaka specifikt fall, men helheten av sådana billiga situationer resulterar senare i orimliga kostnader för molntjänster.
Eller en annan situation: du köpte reservkapacitet på AWS eller Azure för att inte hamna under toppbelastning. Kan du vara säker på att detta är den optimala lösningen? När allt kommer omkring, om dessa fall är inaktiva 80%, så ger du helt enkelt pengar till Amazon. Dessutom, för sådana fall, har samma AWS och Azure burstable instanser - varför behöver du tomgångsservrar, om du kan använda ett verktyg för att lösa problem med toppbelastningar? Eller, istället för On Premise-instanser, bör du titta mot Reserved - de är mycket billigare och de erbjuder även rabatter.
Förresten, om rabatter
Som vi sa i början utförs upphandling ofta av vem som helst - de hittade den sista, och sedan gör han det själv på något sätt. Oftast blir människor som redan är upptagna "extrema", och som ett resultat får vi en situation där en person snabbt och skickligt, men helt oberoende, bestämmer vad och i vilka kvantiteter som ska köpas.
Men när man interagerar med en säljare från molntjänsten kan man få förmånligare villkor när det kommer till grossistköp av kapacitet. Det är klart att du inte kommer att kunna få sådana rabatter från en bil med en tyst och ensidig registrering - men efter att ha pratat med en riktig försäljningschef kan du bli utbränd. Eller så kan de här killarna berätta vad de för närvarande har rabatter på. Det kan också vara användbart.
Samtidigt måste du komma ihåg att ljuset inte konvergerade som en kil på AWS eller Azure. Självklart är det inte tal om att organisera ett eget serverrum – men det finns alternativ till dessa två klassiska lösningar från jättarna.
Till exempel tog Google med sig Firebase-plattformen till företag, där de kan vara värd för samma mobila projekt på nyckelfärdig basis, vilket kan kräva snabb skalning. Lagring, realtidsdatabas, hosting och molndatasynkronisering med denna lösning som exempel finns på ett ställe.
Å andra sidan, om vi inte talar om ett monolitiskt projekt, utan om deras helhet, är en centraliserad lösning inte alltid fördelaktig. Om projektet är långlivat, har en egen utvecklingshistorik och en motsvarande mängd data som krävs för lagring, så är det värt att tänka på en mer fragmenterad placering.
När du optimerar kostnader för molntjänster kan du plötsligt inse att för affärskritiska applikationer kan du köpa mer kraftfulla tariffer som ger företaget oavbruten intäkt. Samtidigt är det en lösning att lagra ”arvet” av utveckling, gamla arkiv, databaser etc. i dyra moln. När allt kommer omkring, för sådana data, är ett standarddatacenter med vanliga hårddiskar och medelkraftig hårdvara utan några klockor och visselpipor ganska lämpligt.
Även här kan du tycka att "det här tjafset inte är värt det", men hela problemet med denna publikation är baserat på det faktum att de ansvariga i olika skeden försummar de små sakerna och gör det som är bekvämare och snabbare. Vilket i slutändan efter ett par år resulterar i just de där skräckkontona.
Resultatet?
I allmänhet är moln coola, de löser många problem för företag av alla storlekar. Men det nya med detta fenomen gör att vi fortfarande inte har en kultur för konsumtion och förvaltning. FinOps är en organisatorisk hävstång som hjälper dig att utnyttja molnkraften mer effektivt. Det viktigaste är att inte förvandla den här positionen till en analog av en skjutningsgrupp, vars uppgift kommer att vara att fånga ouppmärksamma utvecklare i handen och "skälla ut" dem för driftstopp.
Utvecklare ska utvecklas, inte räkna företagets pengar. Och därför borde FinOps göra både inköpsprocessen och processen att avveckla eller överföra molnkapacitet till andra team till ett evenemang enkelt och roligt för alla parter.
Källa: will.com