Kui palju sa kasutad infrastruktuuri peale? Ja kuidas sellele säästa?

Kindlasti olete mõelnud, kui palju maksab teie projekti infrastruktuur. Üllatav on see, et kulude kasv ei ole koormustega lineaarne. Paljud ettevõtete omanikud, CTO-d ja arendajad tajuvad alateadlikult, et nad maksavad üle. Kuid mille eest täpselt?

Tavaliselt vähendatakse kulusid lihtsalt odavaima lahenduse, AWS-i plaani või juhul, kui räägime füüsikalisest riistvarast, seadistuse optimeerimise otsimise kaudu. Veelgi enam: seda teevad tegelikult kõik, nagu jumal juhatab: kui räägime idufirmast, siis tõenäoliselt on see peamine arendaja, kellel on piisavalt muresid. Suuremates ettevõtetes tegelevad sellega CMO/CTO, mõnikord sekkub sellesse isiklikult tegevjuht koos pea raamatupidajaga. Ühesõnaga, teised inimesed, kellel on oma „spetsiifilised” kohustused. Ja nii juhtub, et infrastruktuuri arved kasvavad, kuid nende probleemiga tegelevad... need, kellel pole aega sellega tegeleda.

Kui kontorisse tuleb osta tualettpaberit, siis tegeleb sellega kas varahaldur või vastutav isik koristusettevõttest. Arendus osas on asjad samuti selged — sellele vastavad liidrid ja CTO-d. Müügiosakond — ka siin on kõik arusaadav. Kuid juba ammusest ajast, kui "serveriks" nimetati kappe, kus seisis tavaline tower-süsteem koos veidi suurema mäluga ja paar kõvaketast RAID-is, on kõik (või vähemalt paljud) ignoreerinud tõsiasja, et ressursi soetamisega peaks tegelema ka spetsiaalselt koolitatud inimene.

Kahjuks ütleb ajalooline mälu ja kogemus, et see ülesanne on aastakümnete jooksul olnud juhuslike inimeste käsutuses: kes lähedale sattus, see haaras probleemi enda kanda. Alles hiljuti hakkas turul kujunema ja vormuma amet FinOps. See on see spetsiaalselt koolitatud inimene, kelle ülesanne on jälgida ressursside ostmist ja kasutamist. Ja lõpuks, selle suuna kulude vähendamine ettevõttes.

Me ei propageeri kallite ja tõhusate lahenduste tagasilükkamist: iga ettevõte peab ise otsustama, mis on vajalik mugavaks eksisteerimiseks riistvara ja pilveteenuste osas. Kuid ei saa ignoreerida fakti, et mõtlematu ostmine nimekirja alusel, ilma edasise jälgimise ja kasutuse analüüsita, toob paljudele ettevõtetele lõpuks kaasa väga suured kahjumid, mis tulenevad nende bännerdide "varade" ebaefektiivsest haldamisest.

Kes on FinOps

Oletame, et teil on tõsine ettevõte, millest müügiesindajad öökähedalt räägivad kui „ettevõtte tasemest”. Tõenäoliselt olete nimekirja alusel soetanud paari tosinaga servereid, AWS-i ja veel midagi “pisiasjade” kohta. Mis on mõistetav: suures ettevõttes toimub pidevalt mingi tegevus - mõned meeskonnad kasvavad, teised lagunevad, kolmandad liiguvad naaberprojektidesse. Need liikumised koos nimekirja alusel ostmise mehhanismiga toovad lõpuks uued hallid juuksed, kui vaatate järgmist igakuist arvet infrastruktuuri eest.

Nii et mida teha — kannatlikult edasi istuda, värvida või uurida, miks need arvukad kohutavad nullid arvel on ilmnenud?

Mida salata: ettevõtte sees sama AWS tariifi taotluse kooskõlastamine, heakskiitmine ja otsene maksmine ei ole alati (reaalsus on see, et peaaegu kunagi) kiire. Just pideva korporatiivse liikumise tõttu võivad need ostud kuskil «kaduma minna». Ja tõeliselt öeldes seisma jääda. Kui tähelepanelik administraator märkab oma serveriruumis hüljatud riiulit, siis pilvedeenuste tariifide puhul on olukord palju halvem. Need võivad «nöörida» kuude kaupa — makstud, kuid samal ajal juba kellelegi teistele mitte vajalikud, allüksusele, kelle jaoks need osteti. Samas hakkavad naaberbüroos kolleegid oma veel tumedad juuksed mitte ainult peas, vaid ka muudes kohtades rebima — neil ei ole juba nädal aega õnnestunud maksta umbes sellise AWS tariifi eest, mis on hädasti vajalik.

Mis on kõige ilmsem lahendus? Õige, anda võim vajaduses, ja kõik on rahul. Kuid horisontaalsed suhted ei ole alati hästi korraldatud. Ja teine osakond ei pruugi lihtsalt teada, et esimesel on rikkust, mille järgi nad ei ole tegelikult nõudnud.

Kes on selles süüdi? — Tegelikult, keegi. Nii on asjad praegu korraldatud.
Kes selle all kannatab? — Kõik, kogu ettevõte.
Kes saab olukorda parandada? — Jah, just, FinOps.

FinOps ei ole lihtsalt kiht arendajate ja neile vajaliku varustuse vahel, vaid inimene või meeskond, kes teab, kus, mis ja kui hästi on näiteks pilveteenuste hinnad, mida ettevõte on ostnud. Tegelikult peaksid need inimesed töötama koos DevOps'iga ühise eesmärgina ja finantsosakonnaga teiselt poolt, olles tõhusad vahendajad ja, mis kõige tähtsam, analüütikud.

Natuke optimeerimisest

Pilved. Suhteliselt odavad ja väga mugavad. Kuid see lahendus lõpetab odav olemise, kui serverite arv muutub kahekohaliseks või kolmekohaliseks. Lisaks võimaldavad pilved kasutada järjest rohkem teenuseid, mis olid varem kätte saamata: need on andmebaasid teenusena (Amazon AWS, Azure Database), serverita rakendused (AWS Lambda, Azure Functions) ja paljud teised. Need on kõik suurepärased oma lihtsuse tõttu — ostsid ja said kohe kohe kasutada, mingeid probleeme pole. Kuid mida sügavamale ettevõte ja tema projektid pilve sukelduvad, seda halvemini magab finantsjuht. Ja seda kiiremini hallineb tegevjuht.

Asi on selles, et erinevate pilveteenuste arved on alati äärmiselt segased: ühel real võib tulla kolm lehekülge seletusi, kuhu, mis ja kuidas teie raha kadus. See on muidugi tore, aga selles aru saada on praktiliselt võimatu. Ja see ei ole meie arvamus üksi: et tõlkida pilveteenuseid inimlikuks, eksisteerivad terve hulga teenuseid, näiteks www.cloudyn.com või www.cloudability.com. Kui keegi on vaeva näinud eraldi teenuse loomisega arveid dešifreerimiseks, siis probleem on ületanud juuste värvimise maksumuse.

N nii, mida sellises olukorras teeb FinOps:

• mõistab selgelt, millal ja millistes kogustes on pilveteenuseid soetatud.
• teab, kuidas neid võimsusi kasutatakse.
• jaotab neid ümber vastavalt erinevate osakondade vajadustele.
• ei osta "et olla".
• ja lõpuks — säästab teie raha.

Hea näide on pilve külmkonna DB salvestamine. Kas te, näiteks, arhiveerite seda, et vähendada kulutatavat ruumi ja liiklust salvestuse värskendamisel? Jah, olukord tundub esmapilgul odav — konkreetse juhtumi puhul, kuid selliste odavate olukordade kogum toob lõpuks kaasa ülemäärased kulutused pilveteenustele.

Või teine olukord: teil on ostetud reservvõimsus AWS-is või Azure's, et mitte jääda kõrge koormuse alla. Kas on kindel, et see on optimaalne lahendus? Kui need instantsid seisavad 80% ajast, siis annate lihtsalt raha Amazonile. Veelgi enam, selliste olukordade jaoks on AWS-il ja Azure'l olemas burstable instantsid — miks kasutada ülearuseid servereid, kui saab kasutada tööriista probleemide lahendamiseks just kõrgendatud koormuse ajal? Või oleks mõistlik otsida Reserved instantside poole, need on palju odavamad ja nende peale antakse veel allahindlusi.

Muide, allahindlustest

Nagu me alguses ütlesime, siis ostudega tegeleb tihti keegi, kes on selleks viimane — viimane leitud inimene, kes siis üksi hakkab asju enda kätesse võtma. Tihti saavad «viimased» inimesest, kes on juba kinni muudes asjades, ja lõppkokkuvõttes saame olukorra, kus inimene teeb kiiresti ja oskuslikult, aga täiesti iseseisvalt otsuseid selle kohta, mida ja millistes kogustes osta.

Koostöös pilveteenuse müüjaga on võimalik saada soodsamaid tingimusi, kui tegemist on hulgiressursside ostmisega. On selge, et niisuguseid allahindlusi ei saavuta automaatsete ning ühepoolsete tellimustega - kuid reaalse müügiinimesega vesteldes võib see õnnestuda. Või võivad nad anda nõu, millistel asjadel neil nüüd allahindlused on. See võib ka kasulik olla.

Samas tuleks meeles pidada, et AWS või Azure ei ole ainukesed lahendused turul. Loomulikult ei ole jutt oma serveri loomisest - kuid ka alternatiive nendele kahlele klassikalisele lahendusele on.

Näiteks on Google välja töötanud ettevõtetele Firebase platvormi, mille abil saab „võtmed kätte” paigutada sama mobiiliprojekti, mis võib vajada kiiret skaleerimist. Andmehoidlad, reaalajas andmebaasid, hostimine ja pilvesünkroniseerimine on selle lahenduse kaudu saadaval ühes kohas.

Teiselt poolt, kui me räägime mitte monoliitsest projektist, vaid nende kogumist, ei pruugi keskne lahendus alati olla kasulik. Kui projekt on pikaajaline, omab oma arendusajalugu ja vastavat andmete hulka, siis tasub mõelda rohkem fraktsioneeritud majutamise peale.

Pilveteenuste kulude optimeerimisel võite äkki mõista, et kriitiliste äride rakendustes on võimalik osta ka võimsamaid pakette, mis tagavad ettevõttele katkematu teenimise. Samas ei ole mõistlik hoida arenduse 'pärandit', vanu arhiive, andmebaase ja muud kallites pilvedes; selliste andmete jaoks sobib täiesti ka standardne andmekeskus koos tavaliste HDD-de ja keskmisevõimsusega riistvaraga, ilma igasuguste 'võludeta'.

Siin võib jälle mõelda, et 'see sebimine ei ole seda väärt', kuid kogu selle väljaande probleemistik põhineb sellel, et erinevates etappides jätavad vastutavad inimesed tähelepanuta pisiasjad ja teevad nii, nagu on mugavam ja kiirem. Mis lõpuks paari aasta pärast viib just nende kohutavate arvete tekkeni.

Mis on lõpptulemus?

Tõeliselt, pilvetehnoloogia on suurepärane, see lahendab paljusid probleeme, olenemata ettevõtte suurusest. Siiski toob selle uudsus endaga kaasa, et meil ei ole veel välja kujunenud kultuuri selle kasutamiseks ja haldamiseks. FinOps on organisatsiooniline vahend, mis aitab tõhusamalt kasutada pilveressursse. Peamine on mitte muuta seda ametit sarnaseks hukkamiskohaks, kelle ülesanne on tabada hooletuid arendajaid ja „karistada” neid ressursside raiskamise eest.

Arendajad peaksid keskenduma arendamisele, mitte ettevõtte rahandusele. FinOps peab tuvastama nii pilvealluvate ressursside ostmisprotsessi kui ka nende ülesannete delegeerimise või edastamise teistele meeskondadele, et see oleks kõigi osaliste jaoks lihtne ja meeldiv sündmus.

Allikas: habr.com