Ju patjetër keni pyetur veten se sa kushton infrastruktura e projektit tuaj. Në të njëjtën kohë, është befasuese: rritja e kostove nuk është lineare në lidhje me ngarkesat. Shumë pronarë biznesesh, stacione shërbimi dhe zhvillues e kuptojnë fshehurazi se po paguajnë tepër. Por për çfarë saktësisht?
Në mënyrë tipike, ulja e kostove thjesht zbret në gjetjen e zgjidhjes më të lirë, një plan AWS, ose, në rastin e rafteve fizike, optimizimin e konfigurimit të harduerit. Jo vetëm kaq: në fakt, kushdo po e bën këtë, si të dojë Zoti: nëse po flasim për një startup, atëherë ky është ndoshta një zhvillues kryesor që ka shumë dhimbje koke. Në zyrat më të mëdha, kjo trajtohet nga CMO/CTO, dhe ndonjëherë drejtori i përgjithshëm personalisht përfshihet në këtë çështje së bashku me llogaritarin kryesor. Në përgjithësi, ata njerëz që kanë mjaft shqetësime "thelbësore". Dhe rezulton se faturat e infrastrukturës po rriten, por ata që nuk kanë kohë të merren me të po merren me të.
Nëse keni nevojë të blini letër higjienike për zyrën, kjo do të bëhet nga menaxheri i furnizimit ose një person përgjegjës nga kompania e pastrimit. Nëse po flasim për zhvillim - drejton dhe CTO. Shitjet - gjithçka është gjithashtu e qartë. Por që nga kohërat e lashta, kur një "dhomë serveri" ishte një emër për një kabinet në të cilin kishte një njësi të zakonshme të sistemit të kullës me pak më shumë RAM dhe disa disqe të ngurtë në bastisje, të gjithë (ose të paktën shumë) injoroni faktin që kapaciteti blerës duhet të trajtohet edhe nga një person i trajnuar posaçërisht.
Mjerisht, kujtesa historike dhe përvoja tregojnë se për dekada kjo detyrë u zhvendos te njerëzit "të rastësishëm": kushdo që ishte më afër e merrte pyetjen. Dhe vetëm kohët e fundit profesioni FinOps filloi të merrte formë në treg dhe të merrte një formë konkrete. Ky është i njëjti person i trajnuar posaçërisht, detyra e të cilit është të kontrollojë blerjen dhe përdorimin e kapacitetit. Dhe, në fund të fundit, në uljen e kostove të kompanisë në këtë fushë.
Ne nuk po mbrojmë braktisjen e zgjidhjeve të shtrenjta dhe efektive: çdo biznes duhet të vendosë vetë se çfarë i nevojitet për një ekzistencë komode për sa i përket tarifave të harduerit dhe cloud. Por nuk mund të mos i kushtohet vëmendje faktit që blerja e pamenduar "sipas listës" pa monitorim dhe analizë të mëvonshme të përdorimit për shumë kompani, përfundimisht rezulton në humbje shumë, shumë të rëndësishme për shkak të menaxhimit joefektiv të "aseteve" të tyre.
Kush është FinOps
Le të themi se keni një ndërmarrje me reputacion, për të cilën shitësit flasin për "sipërmarrje" me një ton të fryrë. Ndoshta, "sipas listës" keni blerë një duzinë ose dy serverë, AWS dhe disa "gjëra të vogla" të tjera. E cila është logjike: në një kompani të madhe një lloj lëvizjeje po ndodh vazhdimisht - disa ekipe rriten, të tjerët shpërbëhen, të tjerët transferohen në projekte fqinje. Dhe kombinimi i këtyre lëvizjeve, së bashku me mekanizmin e prokurimit "të bazuar në listë", përfundimisht çon në flokë të rinj gri kur shikohet fatura e ardhshme mujore e infrastrukturës.
Pra, çfarë të bëni - vazhdoni me durim të grini, të lyeni mbi të ose të kuptoni arsyet e shfaqjes së këtyre zerave të shumta të tmerrshme në pagesë?
Le të jemi të sinqertë: miratimi, miratimi dhe pagesa direkte e një aplikacioni brenda kompanisë për të njëjtën tarifë AWS nuk është gjithmonë (në realitet, pothuajse kurrë) i shpejtë. Dhe pikërisht për shkak të lëvizjes së vazhdueshme të korporatës, disa nga këto blerje të njëjta mund të "humben" diku. Dhe është e parëndësishme të qëndrosh kot. Nëse një administrator i vëmendshëm vëren një raft pa pronar në dhomën e serverit të tij, atëherë në rastin e tarifave të cloud gjithçka është shumë më e trishtuar. Ato mund të vendosen për muaj - të paguar, por në të njëjtën kohë nuk i nevojiten më askujt në departamentin për të cilin janë blerë. Në të njëjtën kohë, kolegët nga zyra tjetër fillojnë të shqyejnë flokët e tyre ende jo të thinjura jo vetëm në kokë, por edhe në vende të tjera - ata nuk kanë qenë në gjendje të paguajnë përafërsisht të njëjtën tarifë AWS për javën e nëntë, e cila është dëshpërimisht e nevojshme.
Cila është zgjidhja më e dukshme? Ashtu është, dorëzojini frenat atyre në nevojë dhe të gjithë janë të lumtur. Por komunikimet horizontale nuk janë gjithmonë të vendosura mirë. Dhe departamenti i dytë thjesht mund të mos dijë për pasurinë e të parit, i cili disi doli se nuk kishte vërtet nevojë për këtë pasuri.
Kush e ka fajin për këtë? - Në fakt, askush. Kështu është vendosur gjithçka për momentin.
Kush vuan nga kjo? - Kaq, e gjithë kompania.
Kush mund ta rregullojë situatën? - Po, po, FinOps.
FinOps nuk është thjesht një shtresë midis zhvilluesve dhe pajisjeve që u nevojiten, por një person ose ekip që do të dijë se ku, çfarë dhe sa mirë "shtrihet" në lidhje me të njëjtat tarifa cloud të blera nga kompania. Në fakt, këta njerëz duhet të punojnë së bashku me DevOps, nga njëra anë, dhe departamentin e financave nga ana tjetër, duke luajtur rolin e një ndërmjetësi efektiv dhe, më e rëndësishmja, një analist.
Pak për optimizimin
retë. Relativisht i lirë dhe shumë i përshtatshëm. Por kjo zgjidhje pushon së qeni e lirë kur numri i serverëve arrin dyshifror ose treshifror. Për më tepër, retë bëjnë të mundur përdorimin gjithnjë e më shumë shërbime që më parë nuk ishin të disponueshme: këto janë bazat e të dhënave si shërbim (Amazon AWS, Azure Database), aplikacione pa server (AWS Lambda, Azure Functions) dhe shumë të tjera. Ata janë të gjithë shumë të lezetshëm sepse janë të lehtë për t'u përdorur - blini dhe shkoni, pa probleme. Por sa më thellë kompania dhe projektet e saj të zhyten në re, aq më keq do të flejë CFO. Dhe aq më shpejt gjenerali bëhet gri.
Fakti është se faturat për shërbime të ndryshme cloud janë gjithmonë jashtëzakonisht konfuze: për një artikull mund të merrni një shpjegim në tre faqe se çfarë, ku dhe si shkuan paratë tuaja. Kjo, natyrisht, është e këndshme, por është pothuajse e pamundur ta kuptosh. Për më tepër, mendimi ynë për këtë çështje është larg nga i vetmi: për të transferuar llogaritë cloud tek ato njerëzore, ekzistojnë shërbime të tëra, për shembull ose . Nëse dikush shqetësohej të krijonte një shërbim të veçantë për deshifrimin e faturave, atëherë shkalla e problemit ka tejkaluar koston e bojës së flokëve.
Pra, çfarë bën FinOps në këtë situatë:
- kupton qartë se kur dhe në çfarë vëllimesh janë blerë zgjidhjet cloud.
- e di se si përdoren këto kapacitete.
- i rishpërndan ato në varësi të nevojave të një njësie të caktuar.
- nuk blen "që të mund të jetë".
- dhe në fund, ju kursen para.
Një shembull i shkëlqyeshëm është ruajtja në renë kompjuterike e një kopjeje të ftohtë të një baze të dhënash. Për shembull, a e arkivoni atë për të zvogëluar sasinë e hapësirës dhe trafikut të konsumuar gjatë përditësimit të hapësirës ruajtëse? Po, duket se situata është e lirë - në një rast të vetëm specifik, por tërësia e situatave të tilla të lira më vonë rezulton në kosto të tepruara për shërbimet cloud.
Ose një situatë tjetër: keni blerë kapacitet rezervë në AWS ose Azure në mënyrë që të mos bini nën ngarkesën e pikut. A jeni i sigurt se kjo është zgjidhja optimale? Në fund të fundit, nëse këto raste janë boshe 80%, atëherë thjesht po i jepni para Amazon. Për më tepër, për raste të tilla, të njëjtat AWS dhe Azure kanë raste të shpërthyeshme - pse keni nevojë për serverë të papunë, nëse mund të përdorni një mjet për të zgjidhur problemet e ngarkesave të pikut? Ose, në vend të rasteve On Premise, duhet të shikoni drejt Rezervuar - ato janë shumë më të lira dhe ofrojnë gjithashtu zbritje.
Nga rruga, në lidhje me zbritjet
Siç thamë në fillim, prokurimi shpesh kryhet nga kushdo - ata e gjetën të fundit, dhe më pas ai disi e bën vetë. Më shpesh, njerëzit që janë tashmë të zënë bëhen "ekstreme", dhe si rezultat kemi një situatë ku një person shpejt dhe me shkathtësi, por plotësisht në mënyrë të pavarur, vendos se çfarë dhe në çfarë sasie të blejë.
Por kur ndërveproni me një shitës nga shërbimi cloud, mund të merrni kushte më të favorshme kur bëhet fjalë për blerjen me shumicë të kapacitetit. Është e qartë se nuk do të mund të merrni zbritje të tilla nga një makinë me një regjistrim të heshtur dhe të njëanshëm - por pasi të flisni me një menaxher të vërtetë shitjesh, mund të digjeni. Ose këta djem mund t'ju tregojnë se për çfarë kanë aktualisht zbritje. Mund të jetë gjithashtu i dobishëm.
Në të njëjtën kohë, duhet të mbani mend se drita nuk konvergonte si një pykë në AWS ose Azure. Sigurisht, nuk bëhet fjalë për organizimin e dhomës tuaj të serverit - por ka alternativa për këto dy zgjidhje klasike nga gjigantët.
Për shembull, Google solli platformën Firebase për kompanitë, në të cilat ato mund të presin të njëjtin projekt celular me çelësa në dorë, gjë që mund të kërkojë shkallëzim të shpejtë. Magazinimi, baza e të dhënave në kohë reale, hostimi dhe sinkronizimi i të dhënave cloud duke përdorur këtë zgjidhje si shembull janë të disponueshme në një vend.
Nga ana tjetër, nëse nuk po flasim për një projekt monolit, por për tërësinë e tyre, atëherë një zgjidhje e centralizuar nuk është gjithmonë e dobishme. Nëse projekti është jetëgjatë, ka historinë e vet të zhvillimit dhe një sasi korresponduese të të dhënave të kërkuara për ruajtje, atëherë ia vlen të mendoni për vendosje më të fragmentuara.
Kur optimizoni kostot për shërbimet cloud, mund të kuptoni papritur se për aplikacionet kritike për biznesin mund të blini tarifa më të fuqishme që do t'i ofrojnë kompanisë fitime të pandërprera. Në të njëjtën kohë, ruajtja e “trashëgimisë” së zhvillimit, arkivave të vjetra, bazave të të dhënave etj. në retë e shtrenjta është një zgjidhje. Në fund të fundit, për të dhëna të tilla, një qendër standarde e të dhënave me HDD të rregullt dhe pajisje me fuqi të mesme pa asnjë zile dhe bilbil është mjaft e përshtatshme.
Edhe këtu, mund të mendoni se "kjo bujë nuk ia vlen", por i gjithë problemi i këtij botimi bazohet në faktin se në faza të ndryshme njerëzit përgjegjës neglizhojnë gjërat e vogla dhe bëjnë atë që është më e përshtatshme dhe më e shpejtë. E cila, në fund, pas nja dy vitesh rezulton në ato llogari tmerri.
Rezultati?
Në përgjithësi, retë janë të lezetshme, ato zgjidhin shumë probleme për bizneset e çdo madhësie. Megjithatë, risia e këtij fenomeni do të thotë se ne ende nuk kemi një kulturë të konsumit dhe menaxhimit. FinOps është një levë organizative që ju ndihmon të përdorni fuqinë cloud në mënyrë më efektive. Gjëja kryesore është të mos e ktheni këtë pozicion në një analog të një skuadre pushkatimi, detyra e të cilit do të jetë të kapë zhvilluesit e pavëmendshëm për dore dhe t'i "qortojë" ata për pushime.
Zhvilluesit duhet të zhvillojnë, jo të llogarisin paratë e kompanisë. Dhe kështu FinOps duhet ta bëjë procesin e blerjes dhe procesin e çmontimit ose transferimit të kapacitetit të resë kompjuterike te ekipet e tjera një ngjarje të thjeshtë dhe të këndshme për të gjitha palët.
Burimi: www.habr.com