Sigurisht, ju kanë shkuar në mendje se sa kushton infrastruktura e projektit tuaj. Por është befasuese: rritja e shpenzimeve nuk është liniar në raport me ngarkesat. Shumë pronarë biznesesh, CTO dhe zhvillues kanë një ndjenjë në sfond se po paguajnë më shumë nga ç'nevojitet. Por për çfarë konkretisht?
Zakonisht, reduktimi i shpenzimeve lidhet thjesht me gjetjen e zgjidhjes më të lirë, një plani në AWS, ose, nëse flasim për stenda fizik, optimizimin e konfiguracionit të pajisjeve. Më tej: në të vërtetë, kjo bëhet nga kushdo, siç e ka qejfi: nëse flasim për një startup, kjo është ndoshta një zhvillues kryesor që ka mjaft probleme për t'u marrë me to. Në kompanitë më të mëdha, kjo është në përgjegjësi të CMO/CTO, ndonjëherë përfshihet edhe vetë drejtorin e përgjithshëm me financat. Në përgjithësi, ata janë njerëz që kanë mjaft shërbime të 'profesionalizuara'. Dhe duket se faturat për infrastrukturën po rriten, por ato⊠që merret me këtë janë ata që s'kanë kohë për t'u marrë me të.
NĂ«se nĂ« zyrĂ« duhet tĂ« blihen letra higjienike, kjo do tĂ« merret nga menaxheri i pĂ«rgatitjeve ose ndonjĂ« person pĂ«rgjegjĂ«s nga kompania e pastrimit. NĂ« rastin e zhvillimit â liderĂ«t dhe CTO. Shitjet â gjithashtu janĂ« tĂ« qarta. Por qĂ« nga koha kur "serveri" quhej dollap, ku ishte njĂ« sistem tower me pak mĂ« shumĂ« memorie dhe disa hard disqe nĂ« RAID, tĂ« gjithĂ« (ose, tĂ« paktĂ«n, shumĂ«) injorojnĂ« faktin se blerjet e kapacitetit duhet tĂ« bĂ«hen nga njĂ« person i trajnuar posaçërisht.
Fatkeqësisht, kujtesa historike dhe përvoja tregojnë se kjo detyrë është kaluar për dekada me radhë tek njerëz "rastësorë": ai që ishte më afër, e mori përsipër këtë çështje. Dhe vetëm kohët e fundit, në treg, profesioni i FinOps ka filluar të marrë disa forma konkrete. Ky është personi i trajnuar posaçërisht, i cili ka për detyrë të kontrollojë blerjen dhe përdorimin e kapaciteteve. Dhe, në fund, të zvogëlojë shpenzimet e kompanisë për këtë drejtim.
Ne inkurajojmë të heqin dorë nga zgjidhjet e shtrenjta dhe efektive: çdo biznes duhet të vendosë vetë se çfarë i nevojitet për një ekzistencë komode sa i përket harduerit dhe tarifave në cloud. Por nuk mund të injorohet fakti se blerja pa mendim "sipër një liste" pa kontroll dhe analiza pasuese të përdorimit për shumë kompani në përfundim rezulton në humbje të konsiderueshme për shkak të menaxhimit të paefektshëm të "aktivave" të backend-it të tyre.
Kush është FinOps
Supozoni se keni një ndërmarrje të madhe, për të cilën shitësit flasin me frymëmarrje "enterprise". Më së shumti, ju keni blerë një duzinë serverësh dhe ndoshta disa shërbime të tjera "për detaje". Kjo është logjike: në një kompani të madhe gjithmonë ka ndodhi të caktuara - disa ekipe rriten, të tjera shpërbëhen, të trejat transferohen në projekte të afërta. Dhe ky kombinim i lëvizjeve, përveç mekanizmit të blerjeve "sipër një liste", në fund sjell shumë stres kur shihni faturat mujore për infrastrukturën.
Pra ndaj, çfarĂ« tĂ« bĂ«jmĂ« â tĂ« qĂ«ndrojmĂ« qetĂ«, tĂ« mbushim si zakonisht apo tĂ« kuptojmĂ« shkaqet e shfaqjes sĂ« kĂ«tyre numrave tĂ« tmerrshĂ«m nĂ« faturĂ«?
Nuk ka çfarĂ« tĂ« fshehim: miratimi, aprovimi dhe pagesa e kĂ«rkesĂ«s brenda kompanisĂ« pĂ«r tĂ« njĂ«jtin plan AWS nuk Ă«shtĂ« gjithmonĂ« (nĂ« realitet, pothuajse kurrĂ«) njĂ« proces i shpejtĂ«. Dhe pikĂ«risht pĂ«r shkak tĂ« lĂ«vizjeve tĂ« vazhdueshme nĂ« korporatĂ«, disa nga kĂ«to blerje mund tĂ« "humben" diku. Dhe tĂ« mbesin thjesht tĂ« papĂ«rdorura. NĂ«se njĂ« administrator i kujdesshĂ«m e vĂ«ren ndonjĂ« kabinet tĂ« braktisur nĂ« server, situata me planet cloud Ă«shtĂ« shumĂ« mĂ« e trishtueshme. Ato mund tĂ« qĂ«ndrojnĂ« "nĂ« pritje" pĂ«r muaj tĂ« tĂ«rĂ« â tĂ« paguara, por nĂ« tĂ« njĂ«jtĂ«n kohĂ« tashmĂ« tĂ« papĂ«rdorura nĂ« departamentin pĂ«r tĂ« cilin janĂ« blerĂ«. NdĂ«rkohĂ«, kolegĂ«t nga kabina e afĂ«rt po kĂ«rkojnĂ« me angth flokĂ«t qĂ« u janĂ« mbetur jo vetĂ«m nĂ« kokĂ«, por edhe nĂ« vende tjera â ata po presin prej njĂ« jave qĂ« tĂ« miratohet njĂ« plan tĂ« ngjashĂ«m AWS, qĂ« Ă«shtĂ« urgjentisht i nevojshĂ«m.
Cila është zgjidhja më e dukshme? E gjitha, të transferosh përgjegjësitë tek ata që kanë nevojë, dhe të gjithë janë të kënaqur. Por komunikimet horizontale nuk janë gjithmonë të mirëorganizuar. Dhe departamenti i dytë mund të mos e dijë fare për pasurinë e departamentit të parë, që këtyre pasurisë në fakt nuk u duket shumë e nevojshme.
Kush Ă«shtĂ« fajtori pĂ«r kĂ«tĂ«? â NĂ« tĂ« vĂ«rtetĂ«, askush. KĂ«shtu janĂ« rregullat deri tani.
Kush Ă«shtĂ« ai qĂ« e vuan kĂ«tĂ«? â TĂ« gjithĂ«, e gjithĂ« kompania.
Kush mund ta rregullojĂ« situatĂ«n? â Po, FinOps.
FinOps nuk Ă«shtĂ« thjesht njĂ« shtresĂ« mes zhvilluesve dhe pajisjeve qĂ« ata kanĂ« nevojĂ«, por njĂ« person ose ekip qĂ« do tĂ« dinĂ« se ku, çfarĂ« dhe sa mirĂ« Ă«shtĂ« âvendosurâ nĂ« lidhje me tarifat e shĂ«rbimeve cloud qĂ« kompania ka blerĂ«. NĂ« fakt, kĂ«ta njerĂ«z duhet tĂ« punojnĂ« nĂ« njĂ« linjĂ« me DevOps nga njĂ«ra anĂ«, dhe me departamentin financiar nga ana tjetĂ«r, duke luajtur rolin e njĂ« ndĂ«rmjetĂ«si tĂ« efektshĂ«m dhe, mĂ« e rĂ«ndĂ«sishmja â analist.
Pak për optimizimin
Reku. Relativisht e lirĂ« dhe shumĂ« e pĂ«rshtatshme. Por kjo zgjidhje ndalon sĂ« qeni e lirĂ« kur numri i serverĂ«ve bĂ«het dyshifror ose treçifror. Po ashtu, reku ofrojnĂ« mundĂ«sinĂ« pĂ«r tĂ« pĂ«rdorur gjithnjĂ« e mĂ« shumĂ« shĂ«rbime qĂ« mĂ« parĂ« nuk ishin tĂ« disponueshme: kjo pĂ«rfshin databaza si shĂ«rbim (Amazon AWS, Azure Database), aplikacione pa server (AWS Lambda, Azure Functions) dhe shumĂ« tĂ« tjera. Ato janĂ« shumĂ« tĂ« bukura sepse janĂ« tĂ« lehta pĂ«r t'u pĂ«rdorur â bleje dhe fillo, pa kurrfarĂ« problemesh. MegjithatĂ«, sa mĂ« thellĂ« tĂ« zhytet njĂ« kompani dhe projektet e saj nĂ« reku, aq mĂ« keq fle drejtori financiar. Dhe aq mĂ« shpejt i jepet mendja e bardhĂ« drejtorit tĂ« pĂ«rgjithshĂ«m.
ĂĂ«shtja Ă«shtĂ« se faturat pĂ«r shĂ«rbime tĂ« ndryshme nĂ« reku janĂ« gjithmonĂ« jashtĂ«zakonisht tĂ« ngatĂ«rruara: pĂ«r njĂ« pozicion ju mund tĂ« merrni njĂ« detajim trefaqĂ«sh pĂ«r atĂ« çfarĂ«, ku dhe si janĂ« shkuar paratĂ« tuaja. Kjo, sigurisht, Ă«shtĂ« e kĂ«ndshme, por Ă«shtĂ« praktikisht e pamundur tĂ« kuptohet. PĂ«r mĂ« tepĂ«r, mendimi ynĂ« nĂ« kĂ«tĂ« çështje nuk Ă«shtĂ« aspak i vetmi: pĂ«r tĂ« pĂ«rkthyer faturat e reku nĂ« njĂ« gjuhĂ« mĂ« tĂ« kuptueshme, ekzistojnĂ« shĂ«rbime tĂ« tĂ«ra, pĂ«r shembull ose . NĂ«se dikush Ă«shtĂ« angazhuar nĂ« krijimin e njĂ« shĂ«rbimi tĂ« veçantĂ« pĂ«r dekodimin e faturave, problemi Ă«shtĂ« rritur pĂ«rtej koston e bojrave pĂ«r flokĂ«t.
Pra, çfarë bën FinOps në këtë situatë:
- e kupton qartë kur dhe në cilat sasi janë blerë zgjidhjet cloud.
- e di se si përdoren këto kapacitete.
- i riaplikon ato, në varësi të nevojave të departamenteve të ndryshme.
- nuk blen "për t'u siguruar".
- dhe në fund - kursen paratë tuaja.
Një shembull i shkëlqyer - ruajtja cloud e kopjeve të ftohta të DB-së. P.sh., e arkivoni atë për të zvogëluar volumet e hapësirës së konsumuar dhe trafikut gjatë përditësimit të magazinës? Po, duke parë, situata duket e vogël - në një rast të veçantë, por grumbulli i këtyre situatave të vogla e shndëron më pas në shpenzime të mëdha për shërbimet cloud.
Ose njĂ« situatĂ« tjetĂ«r: keni blerĂ« fuqi rezervĂ« nĂ« AWS ose Azure, nĂ« mĂ«nyrĂ« qĂ« tĂ« mos bini nĂ«n ngarkesat maksimale. A mund tĂ« jeni tĂ« sigurt se kjo Ă«shtĂ« zgjidhja optimale? Sepse, nĂ«se kĂ«to instance janĂ« tĂ« papĂ«rdorura 80% tĂ« kohĂ«s, thjesht po ndihmoni Amazon. Po ashtu, pĂ«r kĂ«to raste, AWS dhe Azure ofrojnĂ« instance me burstable â pĂ«rse duhet tĂ« keni servera qĂ« mbesin bosh, kur mund tĂ« pĂ«rdorni mjete pĂ«r tĂ« zgjidhur problemet e ngarkesave maksimale? Ose nĂ« vend tĂ« instanceve On Premise, ndoshta duhet tĂ« shikoni nĂ« rezervuar â ato janĂ« shumĂ« mĂ« tĂ« lira dhe pĂ«r to jepen edhe zbritje.
Në fakt, për zbritjet
Siç kemi thĂ«nĂ« nĂ« fillim, blerjet shpesh bĂ«hen nga kushdo â e gjejmĂ« njĂ« tĂ« fundit, dhe pastaj ai do e menaxhojĂ« si tĂ« mundet. Shpesh, âtĂ« funditâ janĂ« njerĂ«z qĂ« janĂ« gjithashtu shumĂ« tĂ« angazhuar, dhe nĂ« fund tĂ« fundit ne pĂ«rfundojmĂ« nĂ« njĂ« situatĂ« ku njĂ« person, shpejt dhe me profesionalizĂ«m, por krejtĂ«sisht vetĂ«, vendos se çfarĂ« dhe nĂ« cilat sasi tĂ« blerĂ«.
Por ndĂ«rveprimin me agjentin shitjes nĂ« anĂ«n e shĂ«rbimit tĂ« cloud, mund tĂ« merrni kushte mĂ« tĂ« favorshme nĂ«se bĂ«het fjalĂ« pĂ«r blerje me shumicĂ« tĂ« kapaciteteve. ĂshtĂ« e qartĂ« se nuk do tĂ« merrni tĂ« tilla zbritje nĂ« mĂ«nyrĂ« tĂ« heshtur dhe njĂ«anshĂ«m â por duke biseduar me njĂ« menaxher tĂ« vĂ«rtetĂ« shitjesh, ndoshta do tĂ« arrini. NdĂ«rkaq, kĂ«ta djem mund tĂ« tregojnĂ« pĂ«r zbritjet qĂ« kanĂ« aktualisht. Kjo gjithashtu mund tĂ« jetĂ« e dobishme.
NĂ« kĂ«tĂ« mĂ«nyrĂ«, duhet tĂ« mbani mend se nĂ« AWS ose Azure nuk Ă«shtĂ« e vetmja zgjedhje. Sigurisht, nuk bĂ«het fjalĂ« pĂ«r ndĂ«rtimin e njĂ« serveri tĂ« vetin â por ka alternativa pĂ«r kĂ«to dy zgjidhje klasike nga gjigandĂ«t.
Për shembull, Google ka sjellë për kompanitë platformën Firebase, ku mund të vendosni një projekt të tillë mobil "në çelës", i cili mund të kërkojë një shkallëzim të shpejtë. Ruajtja, baza e të dhënave në kohë reale, hostimi dhe sinkronizimi i të dhënave në cloud në këtë zgjidhje janë të disponueshme në një vend.
Nga ana tjetër, nëse flasim jo për një projekt monolitik, por për kombinimin e tyre, atëherë një zgjidhje qendrore nuk është gjithmonë e leverdisshme. Nëse projekti ka një jetëgjatësi të gjatë, ka historinë e vet të zhvillimit dhe përkatësisht sasinë e nevojshme të të dhënave për ruajtje, duhet të mendohet për një shpërndarje më fragmentare.
Kur optimizoni shpenzimet pĂ«r shĂ«rbimet cloud, mund tĂ« kuptoni papritur se pĂ«r aplikacionet kritike pĂ«r biznesin mund tĂ« blini tarifa mĂ« tĂ« fuqishme, tĂ« cilat do tĂ« sigurojnĂ« njĂ« fitim pa ndĂ«rprerje pĂ«r kompaninĂ«. NdĂ«rkohĂ«, ruajtja e âtrashĂ«gimisĂ«â sĂ« zhvillimit, arkivave tĂ« vjetra, bazave tĂ« tĂ« dhĂ«nave dhe tĂ« tjera nĂ« hapĂ«sira tĂ« shtrenjta cloud Ă«shtĂ« njĂ« zgjidhje e diskutueshme. Sepse pĂ«r kĂ«to tĂ« dhĂ«na, Ă«shtĂ« e mjaftueshme njĂ« qendĂ«r tĂ« dhĂ«nash standarde me HDD tĂ« zakonshĂ«m dhe harduer tĂ« mesĂ«m pa ndonjĂ« âgjĂ«â.
KĂ«tu prapĂ« mund tĂ« mendohet se âkĂ«to shqetĂ«sime nuk vlejnĂ«â, por problematika e kĂ«saj publikimi bazohet nĂ« faktin se nĂ« etapa tĂ« ndryshme, njerĂ«zit pĂ«rgjegjĂ«s injorojnĂ« detajet dhe bĂ«jnĂ« ashtu siç Ă«shtĂ« mĂ« e lehtĂ« dhe mĂ« e shpejtĂ«. Ăka, nĂ« fund tĂ« fundit, pas disa vitesh shndĂ«rrohet nĂ« ato llogaritĂ« horror.
ĂfarĂ« doli pĂ«rfundimisht?
Në përgjithësi, rekujt janë të shkëlqyera; ato zgjidhin shumë probleme për bizneset e çdo përmasash. Megjithatë, risitë që sjellin këto teknologji shkaktojnë mungesën e një kulture të konsumit dhe menaxhimit. FinOps është një mekanizëm organizativ që ndihmon në përdorimin më efikas të burimeve të reve. E rëndësishme është që kjo detyrë të mos transformohet në një grup ndëshkimi, i cili ka si objektiv kapjen e zhvilluesve të papërqendruar dhe 'ndëshkimin' e tyre për papërdorimin e burimeve.
Zhvilluesit duhet të zhvillojnë, jo të llogarisin paratë e kompanisë. Dhe kjo është aty ku FinOps duhet të bëjë që si procesi i blerjes ashtu edhe ai i shkarkimit ose kalimit të burimeve të reve në ekipet e tjera të jenë një ngjarje e thjeshtë dhe e këndshme për të gjitha palët.
Burimi: habr.com
