{"id":35224,"date":"2019-10-31T22:03:02","date_gmt":"2019-10-31T19:03:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/skolko-vy-tratite-na-infrastrukturu-i-kak-na-etom-sekonomit\/"},"modified":"2019-10-31T22:03:02","modified_gmt":"2019-10-31T19:03:02","slug":"skolko-vy-tratite-na-infrastrukturu-i-kak-na-etom-sekonomit","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/skolko-vy-tratite-na-infrastrukturu-i-kak-na-etom-sekonomit","title":{"rendered":"Hvor meget bruger du p\u00e5 infrastruktur? Og hvordan kan man spare p\u00e5 det?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hvor
\n
\nBestemt, du har sikkert spurgt dig selv, hvad infrastrukturen for dit projekt koster. Det er bem\u00e6rkelsesv\u00e6rdigt: omkostningsv\u00e6ksten er ikke line\u00e6r i forhold til belastningerne. Mange virksomhedsejere, CTO'er og udviklere forst\u00e5r p\u00e5 et underbevidst niveau, at de betaler for meget. Men hvad betaler de egentlig for?<\/p>\n

Oftest handler nedsk\u00e6ring af omkostninger om at finde den billigste l\u00f8sning, en AWS-plan eller, n\u00e5r vi taler om fysiske servere, at optimere hardwarekonfigurationen. Faktisk er det ofte enhver, der kan finde p\u00e5 det: hvis vi taler om start-ups, er det sandsynligvis en f\u00f8rende udvikler, der har nok at se til. I st\u00f8rre virksomheder er det CMO\/CTO, og nogle gange blander direkt\u00f8ren og \u00f8konomichefen sig personligt i sagen. Generelt er det de folk, der ogs\u00e5 har rigeligt med 'faglige' opgaver. Resultatet er, at regningerne til infrastrukturen vokser, men dem, der kan finde tid til at tage h\u00e5nd om det, er sj\u00e6ldne.
\n<\/a><\/noindex>
\nHvis der skal k\u00f8bes toiletpapir til kontoret, s\u00e5 tager det ansvarsfulde s\u00f8de menneske fra reng\u00f8ringsfirmaet sig af det. N\u00e5r det drejer sig om udvikling \u2014 s\u00e5 er det leads og CTO'er. Salg \u2014 det er ogs\u00e5 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\u00f8b af kapaciteter ogs\u00e5 skal h\u00e5ndteres af en specialuddannet person. <\/p>\n

Desv\u00e6rre viser historisk hukommelse og erfaring, at denne opgave i \u00e5rtier er blevet overladt til 'tilf\u00e6ldige' personer: den, der var t\u00e6ttest p\u00e5, greb sp\u00f8rgsm\u00e5let. Og kun for nylig har professionen FinOps begyndt at tage form p\u00e5 markedet. Det er den specifikt uddannede person, hvis opgave det er at kontrollere indk\u00f8b og brug af kapaciteter. Og i sidste ende at reducere virksomhedens omkostninger p\u00e5 dette omr\u00e5de.<\/p>\n

Vi opfordrer ikke til at afskedige dyre og effektive l\u00f8sninger: hver virksomhed m\u00e5 selv v\u00e6lge, hvad der er n\u00f8dvendigt for at opretholde en komfortabel tilstand med hensyn til hardware og cloud-tariffer. Men man kan ikke undg\u00e5 at bem\u00e6rke, at en tankel\u00f8s indk\u00f8b \"efter liste\" uden efterf\u00f8lgende kontrol og analyse af brugen for mange virksomheder ender med at medf\u00f8re betydelige tab p\u00e5 grund af ineffektiv styring af backend-\"aktiverne\".<\/p>\n

Hvad er FinOps?<\/h4>\n

\nLad os sige, at du har en solid virksomhed, som s\u00e6lgerne bev\u00e6ger sig sp\u00e6ndt i retning af at kalde \"enterprise\". Sandsynligvis har du \"efter liste\" k\u00f8bt et dusin servere, AWS og lidt ekstra \"sm\u00e5ting\". Det giver mening: i en stor virksomhed sker der konstant bev\u00e6gelse \u2014 nogle teams vokser, andre splittes op, tredje flyttes til naboprojekter. Denne kombination af bev\u00e6gelser sammen med indk\u00f8bsmetoden \"efter liste\" f\u00f8rer til ny gr\u00e5 h\u00e5r, n\u00e5r man ser den n\u00e6ste m\u00e5nedlige infrastrukturregning. <\/p>\n

Hvad skal man s\u00e5 g\u00f8re \u2014 t\u00e5lmodigt blive gr\u00e5h\u00e5ret, male over eller finde \u00e5rsagerne til de mange forf\u00e6rdelige nuller p\u00e5 regningen? <\/p>\n

Hvad skal man skjule: godkendelse, accept og selve betalingen af anmodningen inden for virksomheden til den samme AWS-tarif \u2014 er ikke altid (i virkeligheden n\u00e6sten aldrig) en hurtig sag. Netop p\u00e5 grund af den konstante bev\u00e6gelse i virksomheden kan en del af disse indk\u00f8b g\u00e5 \"tabt\" et sted. Og simpelthen st\u00e5 stille. Hvis en opgivet rack i din serverrum bliver bem\u00e6rket af en opm\u00e6rksom administrator, s\u00e5 er det meget v\u00e6rre med cloud-tarifferne. De kan st\u00e5 \"frossen\" i m\u00e5neder \u2014 betalt, men samtidig allerede un\u00f8dvendig for det team, der k\u00f8bte dem. Imens fratager kollegerne fra det n\u00e6rliggende kontor deres endnu ikke-gr\u00e5 h\u00e5r, ikke kun p\u00e5 hovedet, men ogs\u00e5 andre steder \u2014 de har i ugevis ikke kunnet f\u00e5 betalt en lignende AWS-tarif, som de akut har brug for.<\/p>\n

Hvad er den mest \u00e5benlyse l\u00f8sning? Rigtig, at overdrage ansvaret til dem, der har brug for det, og s\u00e5 er alle glade. Men de horisontale kommunikationer er ikke altid godt etableret. Og den anden afdeling kan simpelthen ikke v\u00e6re klar over, hvilken rigdom den f\u00f8rste har, som de faktisk ikke har brug for.<\/p>\n

Hvem er skyld i dette? \u2014 Egentlig, ingen. S\u00e5dan er det simpelthen sat op nu.
\nHvem lider under dette? \u2014 Alle, hele virksomheden.
\nHvem kan rette op p\u00e5 situationen? \u2014 Ja, ja, FinOps.<\/p>\n

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\u00f8bt. Faktisk skal disse personer arbejde i t\u00e6t samarbejde med DevOps p\u00e5 den ene side og finansafdelingen p\u00e5 den anden side, og fungere som en effektiv m\u00e6gler og, vigtigst af alt, analyst.<\/p>\n

Lidt om optimering<\/h4>\n

\nCloud-l\u00f8sninger. Relativt billige og meget praktiske. Men denne l\u00f8sning stopper med at v\u00e6re billig, n\u00e5r antallet af servere bliver tosifret eller tresifret. Desuden giver cloud'en mulighed for at bruge flere og flere tjenester, som tidligere var utilg\u00e6ngelige: 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 \u2014 k\u00f8bte og afsted, ingen problemer. Men jo dybere virksomheden og dens projekter dykker ned i cloud-l\u00f8sninger, desto d\u00e5rligere sover finansdirekt\u00f8ren. Og jo hurtigere bliver direkt\u00f8ren gr\u00e5h\u00e5ret.<\/p>\n

Det, der er problemet, er, at regningerne for forskellige cloud-tjenester altid er ekstremt forvirrende: du kan modtage en tre-siders opg\u00f8relse for en enkelt post, hvor dine penge er g\u00e5et hen. Det er selvf\u00f8lgelig rart, men at forst\u00e5 det er praktisk talt umuligt. Og vores mening om dette emne er langt fra den eneste: for at overs\u00e6tte cloud-regninger til menneskelig forst\u00e5else, findes der hele tjenester, for eksempel www.cloudyn.com<\/a><\/noindex> eller www.cloudability.com<\/a><\/noindex>. Hvis nogen har taget sig tid til at oprette en separat tjeneste til afkodning af regninger, s\u00e5 er problemets omfang st\u00f8rre end omkostningen til h\u00e5rfarve.<\/p>\n

S\u00e5, hvad g\u00f8r FinOps i denne situation:<\/p>\n