Jūs tikrai susimąstėte, kiek kainuoja jūsų projekto infrastruktūra. Kartu stebina: kaštų augimas apkrovų atžvilgiu nėra tiesinis. Daugelis verslo savininkų, degalinių ir kūrėjų slapta supranta, kad permoka. Bet už ką būtent?
Paprastai išlaidų mažinimas yra susijęs su pigiausio sprendimo, AWS plano, arba, fizinių stelažų atveju, aparatinės įrangos konfigūracijos optimizavimu. Negana to: iš tikrųjų, bet kas tai daro, kaip Dievui patinka: jei kalbame apie startuolį, tai tikriausiai yra pirmaujantis kūrėjas, kuriam skauda galvą. Didesniuose biuruose tai sprendžia CMO/CTO, o kartais generalinis direktorius asmeniškai įsitraukia į šį klausimą kartu su vyriausiuoju buhalteriu. Apskritai tie žmonės, kuriems užtenka „pagrindinių“ rūpesčių. Ir pasirodo, kad infrastruktūros sąskaitos auga, bet tie, kurie neturi laiko su tuo susitvarkyti, su tuo užsiima.
Jei reikia nusipirkti tualetinio popieriaus biurui, tai padarys tiekimo vadovas arba atsakingas asmuo iš valymo įmonės. Jei kalbame apie plėtrą – veda ir CTO. Pardavimai – viskas irgi aišku. Tačiau nuo senų laikų, kai „serverio kambarys“ buvo vadinamas kabinetu, kuriame buvo įprasta bokšto sistema su šiek tiek daugiau RAM ir pora kietųjų diskų, visi (ar bent jau daugelis) ignoruoja tai, kad pajėgumų pirkimas turėtų būti tvarkomas taip pat specialiai apmokytas asmuo.
Deja, istorinė atmintis ir patirtis rodo, kad dešimtmečius ši užduotis buvo perduota „atsitiktiniams“ žmonėms: klausimą pakėlė kas buvo arčiausiai. Ir tik neseniai FinOps profesija pradėjo formuotis rinkoje ir įgauti konkrečią formą. Tai tas pats specialiai apmokytas asmuo, kurio užduotis – kontroliuoti pajėgumų pirkimą ir panaudojimą. Ir galiausiai sumažinant įmonės išlaidas šioje srityje.
Mes nesiūlome atsisakyti brangių ir efektyvių sprendimų: kiekvienas verslas turi pats nuspręsti, ko jam reikia patogiam egzistavimui, kalbant apie techninės įrangos ir debesų tarifus. Tačiau negalima nekreipti dėmesio į tai, kad neapgalvotas pirkimas „pagal sąrašą“ be tolesnio naudojimo stebėjimo ir analizės daugeliui įmonių galiausiai sukelia labai, labai didelius nuostolius dėl neefektyvaus savo užpakalinio „turto“ valdymo.
Kas yra FinOps
Tarkime, kad turite gerą reputaciją turinčią įmonę, apie kurią pardavėjai kvėpuojančiu tonu kalba apie „įmonę“. Tikriausiai „pagal sąrašą“ įsigijote tuziną ar du serverius, AWS ir dar keletą „smulkmenų“. Kas yra logiška: didelėje įmonėje nuolat vyksta kažkoks judėjimas – vienos komandos auga, kitos išyra, kitos perkeliamos į kaimyninius projektus. Ir šių judesių derinys kartu su „sąrašais pagrįstu“ viešųjų pirkimų mechanizmu galiausiai sukelia naujų žilų plaukų, žiūrint į kitą mėnesinę infrastruktūros sąskaitą.
Taigi, ką daryti – kantriai toliau pilki, dažyti ant jo ar išsiaiškinti priežastis, kodėl mokėjime atsirado daugybė baisių nulių?
Būkime atviri: paraiškos patvirtinimas, patvirtinimas ir tiesioginis apmokėjimas įmonės viduje dėl to paties AWS tarifo ne visada (realiai beveik niekada) nėra greitas. Ir būtent dėl nuolatinio įmonių judėjimo kai kurie iš tų pačių įsigijimų gali būti kažkur „pamesti“. O stovėti be darbo yra nereikšminga. Jei dėmesingas administratorius savo serverio patalpoje pastebi bešeimininkę stelažą, tai debesų tarifų atveju viskas yra daug liūdniau. Jas galima guldyti ištisus mėnesius – sumokėta, bet tuo pačiu niekam nebereikalinga skyriuje, kuriam jie buvo įsigyti. Tuo pat metu kolegos iš gretimo kabineto pradeda draskyti dar nežilus plaukus ne tik ant galvų, bet ir kitose vietose – jau n-tą savaitę negali susimokėti už maždaug tokį patį AWS tarifą, kuris yra labai reikalingas.
Koks ryškiausias sprendimas? Teisingai, perduok vadžias tiems, kuriems reikia pagalbos, ir visi laimingi. Tačiau horizontalūs ryšiai ne visada yra gerai sukurti. O antrasis skyrius gali tiesiog nežinoti apie pirmojo turtus, kuriems kažkodėl pasirodė, kad šio turto tikrai nereikia.
Kas dėl to kaltas? - Tiesą sakant, niekas. Taip kol kas viskas nustatyta.
Kas nuo to kenčia? – Tai viskas, visa kompanija.
Kas gali ištaisyti situaciją? - Taip, taip, FinOps.
„FinOps“ yra ne tik sluoksnis tarp kūrėjų ir jiems reikalingos įrangos, bet žmogus ar komanda, kuri žinos, kur, kas ir kaip gerai „guli“ pagal tuos pačius įmonės perkamus debesų tarifus. Tiesą sakant, šie žmonės turi dirbti kartu su DevOps, iš vienos pusės, ir finansų skyriumi, kita vertus, atlikti veiksmingo tarpininko ir, svarbiausia, analitiko vaidmenį.
Šiek tiek apie optimizavimą
Debesys. Santykinai pigu ir labai patogu. Tačiau šis sprendimas nustoja būti pigus, kai serverių skaičius pasiekia dviženklį ar triženklį skaičių. Be to, debesys suteikia galimybę naudotis vis daugiau paslaugų, kurios anksčiau nebuvo pasiekiamos: tai duomenų bazės kaip paslauga (Amazon AWS, Azure Database), programos be serverių (AWS Lambda, Azure Functions) ir daugelis kitų. Jie visi labai šaunūs, nes juos paprasta naudoti – nusipirk ir eik, jokių problemų. Tačiau kuo giliau įmonė ir jos projektai pasineria į debesis, tuo prasčiau miega finansų direktorius. Ir kuo greičiau generolas papilkėja.
Faktas yra tai, kad sąskaitos už įvairias debesijos paslaugas visada yra labai painios: už vieną prekę galite gauti trijų puslapių paaiškinimą, kas, kur ir kaip nukeliavo jūsų pinigai. Tai, žinoma, malonu, bet beveik neįmanoma to suprasti. Be to, mūsų nuomonė šiuo klausimu toli gražu nėra vienintelė: norint perkelti debesies paskyras į žmonių paskyras, yra ištisos paslaugos, pvz. arba . Jei kas nors pasivargino sukurti atskirą sąskaitų iššifravimo paslaugą, vadinasi, problemos mastas išaugo plaukų dažų kaina.
Taigi, ką FinOps daro šioje situacijoje:
- aiškiai supranta, kada ir kokiais kiekiais buvo įsigyti debesų sprendimai.
- žino, kaip šie pajėgumai naudojami.
- perskirsto juos priklausomai nuo konkretaus padalinio poreikių.
- neperka „kad būtų“.
- ir galiausiai sutaupysite pinigų.
Puikus pavyzdys yra šaltos duomenų bazės kopijos saugykla debesyje. Pavyzdžiui, ar archyvuojate jį, kad sumažintumėte vietos kiekį ir sunaudojamą srautą atnaujindami saugyklą? Taip, atrodytų, kad situacija yra pigi – vienu konkrečiu atveju, tačiau tokių pigių situacijų visuma vėliau lemia milžiniškas debesų paslaugų išlaidas.
Arba kita situacija: įsigijote AWS arba Azure rezervinį pajėgumą, kad nepatektumėte į didžiausią apkrovą. Ar galite būti tikri, kad tai yra optimalus sprendimas? Galų gale, jei šie atvejai neveikia 80%, tada jūs tiesiog duodate pinigus „Amazon“. Be to, tokiais atvejais tie patys AWS ir Azure turi sugadintus egzempliorius – kam jums reikia tuščiosios eigos serverių, jei galite naudoti įrankį didžiausios apkrovos problemoms išspręsti? Arba vietoj On Premise atvejų verčiau pažvelgti į Reserved – jie yra daug pigesni ir siūlo nuolaidas.
Beje, apie nuolaidas
Kaip sakėme pradžioje, pirkimą dažnai vykdo bet kas – rado paskutinį, o paskui kažkaip tai daro pats. Dažniausiai jau užsiėmę žmonės tampa „ekstremaliais“, dėl to gauname situaciją, kai žmogus greitai ir sumaniai, bet visiškai savarankiškai nusprendžia, ką ir kokiais kiekiais pirkti.
Tačiau bendraudami su pardavėju iš debesies paslaugos galite gauti palankesnes sąlygas didmeniniam pajėgumų pirkimui. Aišku, kad iš automobilio su tylia ir vienpusiška registracija tokių nuolaidų negausite - bet pabendravęs su tikru pardavimų vadybininku galite perdegti. Arba šie vaikinai gali pasakyti, kam šiuo metu taikomos nuolaidos. Tai taip pat gali būti naudinga.
Tuo pačiu metu turite atsiminti, kad šviesa nesusiliejo kaip pleištas AWS ar Azure. Žinoma, nėra jokios kalbos apie savo serverių kambario organizavimą – tačiau yra ir alternatyvų šiems dviems klasikiniams milžinų sprendimams.
Pavyzdžiui, „Google“ pristatė „Firebase“ platformą įmonėms, kuriose jos gali priglobti tą patį mobilųjį projektą „iki rakto“, todėl gali prireikti greito mastelio. Saugykla, duomenų bazė realiuoju laiku, priegloba ir debesies duomenų sinchronizavimas naudojant šį sprendimą kaip pavyzdį yra vienoje vietoje.
Kita vertus, jei kalbame ne apie monolitinį projektą, o apie jų visumą, tai centralizuotas sprendimas ne visada yra naudingas. Jei projektas yra ilgaamžis, turi savo kūrimo istoriją ir atitinkamą kiekį duomenų, reikalingų saugojimui, tuomet verta pagalvoti apie fragmentiškesnį talpinimą.
Optimizuodami debesijos paslaugų kaštus staiga galite suprasti, kad verslui svarbioms programoms galite įsigyti galingesnius tarifus, kurie užtikrins įmonės nepertraukiamą uždarbį. Kartu brangiuose debesyse saugoti plėtros „palikimą“, senus archyvus, duomenų bazes ir pan. Juk tokiems duomenims visai tinka standartinis duomenų centras su įprastais HDD ir vidutinės galios aparatūra be jokių varpelių ir švilpukų.
Čia vėlgi galima pagalvoti, kad „neverta šito šurmulio“, tačiau visa šio leidinio problema paremta tuo, kad įvairiais etapais atsakingi žmonės apleidžia smulkmenas ir daro tai, kas patogiau ir greičiau. Galų gale, po poros metų susidaro tokios siaubo istorijos.
Rezultatas?
Apskritai debesys yra šaunūs, jie išsprendžia daugybę problemų bet kokio dydžio įmonėms. Tačiau šio reiškinio naujumas reiškia, kad mes vis dar neturime vartojimo ir valdymo kultūros. „FinOps“ yra organizacinis svertas, padedantis efektyviau panaudoti debesies galią. Svarbiausia nepaversti šios pozicijos šaudymo būrio analogu, kurio užduotis bus sugauti nedėmesingus kūrėjus už rankos ir „barti“ dėl prastovų.
Kūrėjai turėtų vystytis, o ne skaičiuoti įmonės pinigus. Taigi „FinOps“ turėtų paversti tiek pirkimo, tiek eksploatavimo nutraukimo ar debesijos pajėgumų perdavimo kitoms komandoms procesą paprastu ir maloniu įvykiu visoms šalims.
Šaltinis: www.habr.com