Kostnadsoptimalisering i skyen med DevOps: en playbook i 6 steg

FinOps-syklusen anvendt på DevOps

Rammeverket til FinOps Foundation beskriver tre faser: Inform, Optimize og Operate. Hver av dem tilsvarer arbeid et DevOps-team allerede gjør.

For multi-sky-miljøer gir FinOps Foundations FOCUS-spesifikasjon et felles format for kostnads- og forbruksdata, slik at fakturaer fra AWS, Azure og Google Cloud kan sammenlignes i én rapport.

Steg 1: Gjør kostnader synlige for utviklerne

Du kan ikke optimalisere det du ikke ser, og utviklere åpner ikke et økonomiportal.

• Merk ved opprettelse: legg tagger som team, service, environment og cost-centre inn i Terraform-, CloudFormation- eller Bicep-modulene dine, og la pipelinen feile når de mangler.
• Vis kostnad per tjeneste: bygg dashbord etter tjeneste og miljø, ikke etter konto. Rapporter enhetskostnader som kostnad per kunde, per ordre eller per tusen API-kall.
• Estimer i pull requests: verktøy for kostnadsestimering for infrastruktur som kode kan kommentere endringen i månedlig kostnad på en pull request, slik at den som gjennomgår, ser «+USD 1 200/måned» før godkjenning.
• Varsle ved avvik: slå på leverandørens deteksjon av kostnadsavvik og send varslene til eierteamets kanal, ikke til en felles postboks.

Steg 2: Kutt sløsing i CI/CD og testmiljøer

Dette er kostnadsdriverne som hører hjemme hos DevOps-teamene.

• Levetid: hvert forhåndsvisnings- eller testmiljø får en utløpstagg og en planlagt jobb som sletter det. Opprett det på nytt fra kode ved behov.
• Planlegg miljøer utenfor produksjon: stopp utviklings- og teststacker om natten og i helgene. Kjører du dem 50 timer i uken (10 timer på 5 arbeidsdager) i stedet for hele 168, kutter du regnetimene med omtrent 70 %.
• Dimensjoner runnere riktig: bruk autoskalering og kortlivede byggerunnere på Spot-kapasitet, og tilpass runnerens størrelse til jobben.
• Bruk cache og test smart: bufre avhengigheter og containerlag, og kjør hele suiten ved merge i stedet for ved hver push.
• Rydd artefakter: sett oppbevaringstid på containerregistre, byggartefakter og logger.

Steg 3: Dimensjoner riktig og autoskaler produksjon

Dimensjoner ut fra målt bruk, ikke gjetning. Gå gjennom CPU, minne og I/O over minst to uker med normal last, inkludert topper, og velg deretter den minste størrelsen med slingringsmonn.

• Databehandling: gå over til nåværende generasjoner og ARM-baserte instansfamilier der programvaren din støtter det, noe som ofte senker kostnaden per arbeidsenhet.
• Kubernetes: sett realistiske ressursforespørsler og -grenser, bruk Horizontal Pod Autoscaler for å skalere pods med etterspørselen, og la en cluster autoscaler fjerne tomme noder. Forespørsler satt langt over reell bruk er en vanlig kilde til sløsing i Kubernetes.
• Serverløst og administrerte tjenester: funksjoner og administrerte databaser fjerner ubrukt kapasitet for arbeidsbelastninger med topper. For jevn høy last kan provisjonert kapasitet være billigere, så sammenlign begge.
• Lagring: bruk livssyklusregler til å flytte kalde data til billigere nivåer, slett foreldreløse volumer og gamle øyeblikksbilder, og kontroller oppbevaringstid for sikkerhetskopier mot retningslinjene.
• Nettverk: hold snakkesalige tjenester i samme tilgjengelighetssone der robusthet tillater det, bruk VPC-endepunkter i stedet for NAT til trafikk mot skytjenester, og bufre ved kanten.

Steg 4: Bruk riktig prismodell

Når forbruket er riktig dimensjonert, binder du deg for den jevne delen og bruker kapasitet som kan avbrytes for den fleksible delen.

Azure-reservasjoner og savings plans og Google Clouds committed use discounts fungerer etter samme prinsipp. Gå gjennom dekningen hver måned etter hvert som arbeidsbelastningene endrer seg.

Steg 5: Håndhev rekkverk med policy as code

Rekkverk stopper kostbare feil før de skjer, uten å bremse teamene.

• Blokker utaggede ressurser og ikke godkjente instansfamilier i pipelinen, med Open Policy Agent eller leverandørens egne policytjenester (AWS Config og Service Control Policies, Azure Policy, Google Cloud Organization Policy).
• Sett budsjetter per konto, abonnement eller prosjekt med varsler ved 50 %, 80 % og 100 % av prognosen.
• Krev en eier og en utløpsdato på sandbox-kontoer.
• Begrens GPU og store instanstyper til godkjente prosjekter, noe som blir viktigere når AI-arbeidsbelastningene vokser.

Steg 6: Bygg vanen

Kostnadsarbeid mislykkes når det er en opprydding én gang i året. Gjør det til en rutine.

• Gå gjennom de største kostnadsendringene per team i et månedlig møte på 30 minutter med utvikling og økonomi.
• Legg til en kostnadslinje i arkitekturbeslutningsloggene og i sjekklistene for ferdigdefinisjon.
• Følg noen få KPI-er: enhetskostnad per tjeneste, andel av forbruket som er merket, dekning av bindinger og kostnad for ubrukte ressurser.
• Del gevinstene åpent, slik at teamene ser at det verdsettes å spare penger og ikke bare kreves.

Hvilke resultater kan du vente? Eksemplet Branäsgruppen

Den svenske skianleggsgruppen Branäsgruppen har ekstrem sesongbelastning, med mesteparten av omsetningen mellom desember og april. Det gamle VMware-miljøet måtte skaleres for hånd i forkant av etterspørselen.

Etter flyttingen til AWS sammen med Opsio rapporterer kundecaset om Branäsgruppen en reduksjon i totale eierkostnader på 40 %. Caset tilskriver det riktig dimensjonert autoskalering kombinert med disiplinert FinOps-praksis. Frontend, mellomvare og databaser vokser og krymper nå med sesongen i stedet for å være dimensjonert for toppen hele året.

Slik hjelper Opsio

Opsio leverer FinOps og økonomistyring i skyen og kostnadsoptimalisering i skyen for AWS- og Azure-miljøer, og bygger tagging, pipelines og rekkverk som en del av vår DevOps-rådgivning. Teamene i Karlstad i Sverige og Bangalore i India dekker nordiske, europeiske og indiske tidssoner.

Ofte stilte spørsmål

Hva er FinOps for DevOps?

Det er praksisen med å gi utviklingsteamene eierskap til kostnaden av det de bygger. Økonomi setter budsjetter og rekkverk, og utviklerne får data og verktøy til å ta kostnadsbevisste valg i design og utrulling, etter FinOps-syklusen Inform, Optimize og Operate.

Hva er den raskeste måten å kutte skykostnader på?

Slett ubrukte og foreldreløse ressurser, planlegg at miljøer utenfor produksjon stopper utenfor arbeidstid, og dimensjoner de største instansene riktig. Kjøp deretter Savings Plans eller reservasjoner for den gjenværende jevne lasten. Binder du deg før du har dimensjonert riktig, låser du inne sløsingen.

Hvordan reduserer du kostnadene for CI/CD-pipelines?

Bruk autoskalering og kortlivede runnere på Spot-kapasitet, bufre avhengigheter og containerlag, kjør tunge testsuiter ved merge i stedet for ved hver push, og sett oppbevaringstid på artefakter og logger.

Hvordan reduserer du kostnadene for Kubernetes?

Sett ressursforespørsler nær reell bruk, autoskaler pods og noder, pakk arbeidsbelastninger tettere på færre noder, bruk Spot-noder til tilstandsløse arbeidsbelastninger, og fordel klyngens kostnad på namespaces eller team slik at eierne ser den.

Hvilke verktøy hjelper med kostnadsoptimalisering i skyen?

Start med leverandørenes egne verktøy: AWS Cost Explorer, Budgets og Cost Anomaly Detection, Azure Cost Management og rapportene i Google Cloud Billing. Legg til kostnadsestimering for infrastruktur som kode i pull requests og et verktøy for kostnadsfordeling i Kubernetes hvis du kjører store klynger. Multi-sky-miljøer har nytte av data i FOCUS-format samlet i én plattform.

Les også

• Cloud Cost Optimization Platform: Choosing the Right : A …
• Best Cloud Cost Optimization Tools: A How-To Guide
• Build Your Cloud Cost Optimization Dashboard: A Guide