Olete kindlasti mõelnud, kui palju teie projekti infrastruktuur maksab. Samas on üllatav: kulude kasv ei ole koormuste suhtes lineaarne. Paljud ettevõtete omanikud, teenindusjaamad ja arendajad saavad salaja aru, et nad maksavad rohkem. Aga milleks täpselt?
Tavaliselt taandub kulude kärpimine lihtsalt odavaima lahenduse, AWS-plaani leidmisele või füüsiliste riiulite puhul riistvarakonfiguratsiooni optimeerimisele. Vähe sellest: tegelikult teeb seda igaüks, nagu jumalale meeldib: kui me räägime startupist, siis ilmselt on tegemist juhtiva arendajaga, kellel on peavalu küllaga. Suuremates büroodes tegeleb sellega CMO/CTO ning vahel sekkub teemasse peadirektor isiklikult koos pearaamatupidajaga. Üldiselt need inimesed, kellel on piisavalt "põhimuresid". Ja selgub, et infrastruktuuriarved tõusevad, aga need, kellel pole aega sellega tegeleda, tegelevad sellega.
Kui teil on vaja kontorisse tualettpaberit osta, teeb seda tarnejuht või puhastusettevõtte vastutav isik. Kui me räägime arengust - viib ja CTO. Müük - kõik on samuti selge. Kuid vanast ajast, kui "serveriruum" nimetati kabinetti, milles oli tavaline tornisüsteem, millel oli veidi rohkem RAM-i ja paar kõvaketast, ignoreerivad kõik (või vähemalt paljud) asjaolu, et võimsuse ostmisega peaks tegelema ka spetsiaalselt koolitatud isik.
Paraku näitavad ajaloomälu ja kogemused, et aastakümneid oli see ülesanne "juhuslike" inimeste õlule nihutatud: küsimuse tõstatas see, kes oli kõige lähemal. Ja alles hiljuti hakkas FinOpsi elukutse turul kuju võtma ja konkreetse kuju võtma. See on sama eriväljaõppe saanud inimene, kelle ülesanne on kontrollida võimsuse ostu ja kasutamist. Ja lõpuks ettevõtte kulude vähendamisel selles valdkonnas.
Me ei poolda kallitest ja tõhusatest lahendustest loobumist: iga ettevõte peab ise otsustama, mida ta mugavaks eksisteerimiseks vajab riistvara- ja pilvetariifide osas. Kuid ei saa jätta tähelepanuta asjaolu, et mõtlematu "nimekirja järgi" ostmine ilma hilisema kasutamise jälgimise ja analüüsita toob paljudele ettevõtetele lõppkokkuvõttes kaasa väga-väga märkimisväärse kahju, mis on tingitud nende taustaprogrammi "varade" ebaefektiivsest haldamisest.
Kes on FinOps
Oletame, et teil on mainekas ettevõte, mille müügiinimesed räägivad "ettevõttest" õhkava tooniga. Tõenäoliselt ostsite "nimekirja järgi" kümmekond või kaks serverit, AWS-i ja mõnda muud "pisiasja". Mis on loogiline: suures ettevõttes toimub pidevalt mingisugune liikumine - ühed meeskonnad kasvavad, teised lagunevad, teised kanduvad üle naaberprojektidesse. Ja nende liikumiste kombinatsioon koos "nimekirjapõhise" hankemehhanismiga toob lõpuks kaasa uued hallid karvad, kui vaadata järgmist igakuist infrastruktuuriarvet.
Mida siis teha – jätkata kannatlikult hallitamist, üle värvida või välja mõelda, miks need arvukad kohutavad nullid maksesse ilmusid?
Olgem ausad: ettevõttesisese taotluse kinnitamine, kinnitamine ja otsemaksmine sama AWS-i tariifi eest ei ole alati (tegelikkuses peaaegu mitte kunagi) kiire. Ja just pideva korporatiivse liikumise tõttu võib mõni neist samadest omandamistest kuhugi “kadunud”. Ja jõude seista on tühine. Kui tähelepanelik administraator märkab oma serveriruumis omanikuta riiulit, siis pilvetariifide puhul on kõik palju kurvem. Neid saab kuude kaupa laduda – nende eest on tasutud, kuid samal ajal pole neid enam vaja kellelegi selles osakonnas, mille jaoks need osteti. Samal ajal hakkavad kolleegid kõrvalkontorist oma veel mitte halle juukseid välja kiskuma mitte ainult peast, vaid ka mujalt – nad ei ole saanud juba n-ndat nädalat maksta ligikaudu sama AWS-i tariifi eest, mis on hädasti vaja.
Mis on kõige ilmsem lahendus? Õige, andke ohjad abivajajate kätte ja kõik on rahul. Kuid horisontaalne side ei ole alati hästi välja kujunenud. Ja teine osakond ei pruugi lihtsalt teada esimese rikkusest, mis millegipärast osutus, et seda rikkust tegelikult ei vajata.
Kes on selles süüdi? - Tegelikult mitte keegi. Nii on praegu kõik seadistatud.
Kes selle all kannatab? - See on kõik, kogu seltskond.
Kes saab olukorra parandada? - Jah, jah, FinOps.
FinOps ei ole pelgalt kiht arendajate ja neile vajalike seadmete vahel, vaid inimene või meeskond, kes teab, kus, mis ja kui hästi see ettevõtte poolt ostetud samade pilvetariifide osas “valeb”. Tegelikult peavad need inimesed töötama ühelt poolt koos DevOpsiga ja teiselt poolt finantsosakonnaga, täites tõhusa vahendaja ja, mis kõige tähtsam, analüütiku rolli.
Natuke optimeerimisest
Pilved. Suhteliselt odav ja väga mugav. Kuid see lahendus ei ole enam odav, kui serverite arv jõuab kahe- või kolmekohalise numbrini. Lisaks võimaldavad pilved kasutada üha rohkem teenuseid, mis varem ei olnud kättesaadavad: need on andmebaasid teenusena (Amazon AWS, Azure Database), serverita rakendused (AWS Lambda, Azure Functions) ja paljud teised. Need on kõik väga lahedad, sest neid on lihtne kasutada – osta ja minna, pole probleeme. Kuid mida sügavamale ettevõte ja selle projektid pilvedesse sukelduvad, seda halvemini finantsjuht magab. Ja mida kiiremini kindral halliks läheb.
Fakt on see, et erinevate pilveteenuste arved on alati äärmiselt segased: ühe kauba kohta võid saada kolmeleheküljelise selgituse, mis, kuhu ja kuidas raha läks. See on muidugi meeldiv, kuid sellest on peaaegu võimatu aru saada. Pealegi pole meie arvamus selles küsimuses kaugeltki ainus: pilvekontode ülekandmiseks inimeste kontodele on olemas näiteks terved teenused või . Kui keegi viitsis luua arvete dešifreerimiseks eraldi teenuse, siis on probleemi ulatus juuksevärvi maksumusest üle kasvanud.
Mida FinOps sellises olukorras teeb:
- saab selgelt aru, millal ja millises mahus pilvelahendusi osteti.
- teab, kuidas neid võimsusi kasutatakse.
- jaotab need ümber vastavalt konkreetse üksuse vajadustele.
- ei osta "et see oleks".
- ja kokkuvõttes säästab see teie raha.
Suurepärane näide on andmebaasi külmkoopia pilvesalvestus. Näiteks kas arhiveerite selle, et salvestusruumi värskendamisel vähendada ruumi ja liiklust? Jah, tundub, et olukord on odav – üksikul konkreetsel juhul, kuid selliste odavate olukordade kogusumma põhjustab hiljem pilveteenuste jaoks üüratuid kulusid.
Või mõni muu olukord: ostsite AWS-i või Azure'i reservvõimsuse, et mitte langeda tippkoormuse alla. Kas võite olla kindel, et see on optimaalne lahendus? Lõppude lõpuks, kui need juhtumid on jõude 80%, siis annate lihtsalt raha Amazonile. Veelgi enam, sellistel juhtudel on samadel AWS-il ja Azure'il purunevad eksemplarid – milleks on vaja tühikäiguservereid, kui saate tippkoormuse probleemide lahendamiseks kasutada tööriista? Või tasuks On Premise eksemplaride asemel vaadata Reservedi poole – need on palju odavamad ja pakuvad ka allahindlusi.
Muide, allahindluste kohta
Nagu me alguses ütlesime, viib hanke sageli läbi igaüks - nemad leidsid viimase ja siis ta teeb seda kuidagi ise. Kõige sagedamini muutuvad “ekstreemseks” inimesed, kes on niigi hõivatud, ning selle tulemusena saame olukorra, kus inimene otsustab kiiresti ja oskuslikult, kuid täiesti iseseisvalt, mida ja mis kogustes osta.
Pilveteenusest müüjaga suheldes saab aga võimsuse hulgimüügiks soodsamad tingimused. On selge, et vaikse ja ühepoolse registreeringuga autolt selliseid allahindlusi ei saa - kuid pärast tõelise müügijuhiga rääkimist võite läbi põleda. Või võivad need tüübid teile öelda, millistele toodetele nad praegu allahindlusi teevad. See võib olla ka kasulik.
Samal ajal peate meeles pidama, et valgus ei koondunud AWS-i ega Azure'i kiiluna. Oma serveriruumi korraldamisest pole muidugi juttugi – aga neile kahele hiiglaste klassikalisele lahendusele on alternatiive.
Näiteks tõi Google ettevõteteni Firebase'i platvormi, millel saavad nad võtmed kätte sama mobiiliprojekti majutada, mis võib vajada kiiret skaleerimist. Salvestusruum, reaalajas andmebaas, hostimine ja pilvandmete sünkroonimine selle lahenduse näitel on saadaval ühes kohas.
Teisest küljest, kui me ei räägi monoliitsest projektist, vaid nende tervikust, siis ei ole tsentraliseeritud lahendus alati kasulik. Kui projekt on pikaealine, sellel on oma arenduslugu ja vastav kogus talletamiseks vajalikke andmeid, siis tasub mõelda killustatumale paigutusele.
Pilveteenuste kulusid optimeerides võite ootamatult mõista, et ärikriitiliste rakenduste jaoks saate osta võimsamaid tariife, mis tagavad ettevõttele katkematu tulu. Samas on lahenduseks arenduse “pärandi”, vanade arhiivide, andmebaaside jms talletamine kallitesse pilvedesse. Selliste andmete jaoks sobib ju täiesti tavapärane andmekeskus tavaliste kõvaketaste ja keskmise võimsusega riistvaraga ilma igasuguste kellade ja viledeta.
Siin võib jällegi mõelda, et “see kisa pole seda väärt”, kuid kogu selle väljaande probleem põhineb sellel, et erinevatel etappidel jätavad vastutustundlikud inimesed pisiasjad tähelepanuta ja teevad seda, mis on mugavam ja kiirem. Mis lõpuks paari aasta pärast toob kaasa need väga õudsed kontod.
Ja tulemus?
Üldiselt on pilved lahedad, need lahendavad palju probleeme igas suuruses ettevõtetele. Selle nähtuse uudsus tähendab aga seda, et meil puudub endiselt tarbimis- ja majandamiskultuur. FinOps on organisatsiooniline hoob, mis aitab teil pilvevõimsust tõhusamalt kasutada. Peaasi, et seda positsiooni ei muudetaks laskekomando analoogiks, kelle ülesandeks on tähelepanematud arendajad käest kinni püüda ja neid seisakute pärast “noomida”.
Arendajad peaksid arenema, mitte ettevõtte raha lugema. Seega peaks FinOps muutma nii ostuprotsessi kui ka tegevuse lõpetamise või pilvevõimsuse teistele meeskondadele ülekandmise protsessi lihtsaks ja nauditavaks kõigile osapooltele.
Allikas: www.habr.com