Vi certe scivolis kiom kostas la infrastrukturo de via projekto. Samtempe, estas surprize: la kresko de kostoj ne estas lineara rilate al ŝarĝoj. Multaj komercaj posedantoj, benzinejoj kaj programistoj sekrete komprenas, ke ili tro pagas. Sed por kio ĝuste?
Tipe, tranĉi kostojn simple signifas trovi la plej malmultekostan solvon, AWS-planon aŭ, en la kazo de fizikaj rakoj, optimumigi la aparataron. Ne nur tio: fakte, iu ajn faras ĉi tion, laŭplaĉe al Dio: se ni parolas pri starto, tiam ĉi tiu verŝajne estas ĉefa programisto, kiu havas multajn kapdolorojn. En pli grandaj oficejoj, tion traktas la CMO/CTO, kaj foje la ĝenerala direktoro persone okupiĝas pri la afero kune kun la ĉefkontisto. Ĝenerale, tiuj homoj, kiuj havas sufiĉe da "kernaj" zorgoj. Kaj rezultas, ke infrastrukturaj fakturoj altiĝas, sed tiuj, kiuj ne havas tempon por trakti ĝin, traktas ĝin.
Se vi bezonas aĉeti necesejan paperon por la oficejo, tion faros la provizestro aŭ respondeca persono de la purigadkompanio. Se ni parolas pri disvolviĝo - kondukoj kaj CTO. Vendoj - ĉio estas ankaŭ klara. Sed ekde la malnova tempo, kiam "servila ĉambro" estis nomo por kabineto, en kiu estis ordinara tursistemo kun iom pli da RAM kaj kelkaj malmolaj diskoj en la atako, ĉiuj (aŭ almenaŭ multaj) ignoras la fakto ke la aĉeto de kapablo devus esti pritraktita ankaŭ speciale trejnita persono.
Ve, historia memoro kaj sperto indikas, ke dum jardekoj ĉi tiu tasko estis translokita al "hazarda" homoj: kiu estis plej proksima prenis la demandon. Kaj nur lastatempe la profesio FinOps komencis formiĝi sur la merkato kaj preni iun konkretan formon. Ĉi tiu estas la sama speciale trejnita persono, kies tasko estas kontroli la aĉeton kaj uzon de kapablo. Kaj, finfine, reduktante la kostojn de la kompanio en ĉi tiu areo.
Ni ne pledas por forlasi multekostajn kaj efikajn solvojn: ĉiu komerco devas mem decidi, kion ĝi bezonas por komforta ekzisto koncerne aparataron kaj nubajn tarifojn. Sed oni ne povas ne atenti la fakton, ke senpripensa aĉetado "laŭ la listo" sen posta kontrolado kaj analizo de uzo por multaj kompanioj finfine rezultigas tre, tre gravajn perdojn pro neefika administrado de la "aktivoj" de ilia backend.
Kiu estas FinOps
Ni diru, ke vi havas bonfaman entreprenon, pri kiu vendistoj parolas pri "entrepreno" en spira tono. Verŝajne, "laŭ la listo" vi aĉetis dekduon aŭ du servilojn, AWS kaj iujn aliajn "etalojn". Kio estas logika: en granda firmao konstante okazas ia movado - iuj teamoj kreskas, aliaj disiĝas, aliaj estas translokigitaj al najbaraj projektoj. Kaj la kombinaĵo de ĉi tiuj movadoj, kune kun la "list-bazita" akirmekanismo, finfine kondukas al novaj grizaj haroj kiam oni rigardas la venontan monatan infrastrukturan fakturon.
Do kion fari - pacience daŭre grizi, pentri super ĝi aŭ eltrovi la kialojn de la apero de ĉi tiuj multnombraj teruraj nuloj en la pago?
Ni estu honestaj: aprobo, aprobo kaj rekta pago de kandidatiĝo ene de la kompanio por la sama AWS-tarifo ne ĉiam (fakte, preskaŭ neniam) estas rapida. Kaj ĝuste pro la konstanta kompania movado, iuj el ĉi tiuj samaj akiroj povas esti "perditaj" ie. Kaj estas bagatela stari senlabore. Se atentema administranto rimarkas senposedan rakon en sia servila ĉambro, tiam en la kazo de nubaj tarifoj ĉio estas multe pli malĝoja. Ili povas esti enmetitaj dum monatoj - pagitaj, sed samtempe ne plu bezonataj de iu ajn en la fako por kiu ili estis aĉetitaj. Samtempe, kolegoj de la sekva oficejo komencas elŝiri siajn ankoraŭ ne grizajn harojn ne nur sur la kapoj, sed ankaŭ en aliaj lokoj - ili ne povis pagi proksimume por la sama AWS-tarifo por la n-a semajno, kiu estas ege bezonata.
Kio estas la plej evidenta solvo? Ĝuste, transdonu la kondukilojn al la bezonantoj, kaj ĉiuj estas feliĉaj. Sed horizontalaj komunikadoj ne ĉiam estas bone establitaj. Kaj la dua fako eble simple ne scias pri la riĉeco de la unua, kiu iel montriĝis ne vere bezoni ĉi tiun riĉaĵon.
Kiu kulpas pri tio? - Efektive, neniu. Tiel ĉio estas aranĝita nuntempe.
Kiu suferas pro tio? - Jen, la tuta kompanio.
Kiu povas ripari la situacion? - Jes, jes, FinOps.
FinOps ne estas nur tavolo inter programistoj kaj la ekipaĵo, kiun ili bezonas, sed persono aŭ teamo, kiu scios kie, kio kaj kiel bone ĝi "kuŝas" laŭ la samaj nubaj tarifoj aĉetitaj de la kompanio. Fakte, ĉi tiuj homoj devas labori kune kun DevOps, unuflanke, kaj la financa fako aliflanke, ludante la rolon de efika peranto kaj, plej grave, analizisto.
Iom pri optimumigo
Nuboj. Relative malmultekosta kaj tre oportuna. Sed ĉi tiu solvo ĉesas esti malmultekosta kiam la nombro da serviloj atingas duoblajn aŭ trioblajn ciferojn. Krome, nuboj ebligas uzi pli kaj pli da servoj antaŭe neatingeblaj: temas pri datumbazoj kiel servo (Amazon AWS, Azure Database), senservilaj aplikaĵoj (AWS Lambda, Azure Functions) kaj multaj aliaj. Ili ĉiuj estas tre bonegaj ĉar ili estas facile uzeblaj - aĉetu kaj foriru, sen problemoj. Sed ju pli profunde la kompanio kaj ĝiaj projektoj plonĝas en la nubojn, des pli malbone dormas la CFO. Kaj ju pli rapide la generalo griziĝas.
Fakto estas, ke fakturoj por diversaj nubaj servoj estas ĉiam ege konfuzaj: por unu ero vi povas ricevi tri-paĝan klarigon pri kio, kie kaj kiel via mono iris. Ĉi tio, kompreneble, estas agrabla, sed estas preskaŭ neeble kompreni ĝin. Krome, nia opinio pri ĉi tiu afero estas malproksima de la sola: por transdoni nubajn kontojn al homaj, ekzistas tutaj servoj, ekzemple aŭ . Se iu ĝenis krei apartan servon por deĉifri fakturojn, tiam la skalo de la problemo superis la koston de harfarbo.
Do kion faras FinOps en ĉi tiu situacio:
- klare komprenas kiam kaj en kiuj volumoj nubaj solvoj estis aĉetitaj.
- scias kiel ĉi tiuj kapabloj estas uzataj.
- redistribuas ilin depende de la bezonoj de aparta unuo.
- ne aĉetas "por ke ĝi estu".
- kaj finfine, ĝi ŝparas al vi monon.
Bonega ekzemplo estas nuba stokado de malvarma kopio de datumbazo. Ekzemple, ĉu vi arkivas ĝin por redukti la kvanton de spaco kaj trafiko konsumita dum ĝisdatigo de la stokado? Jes, ŝajnus, ke la situacio estas malmultekosta - en ununura specifa kazo, sed la totalo de tiaj malmultekostaj situacioj poste rezultigas troajn kostojn por nubaj servoj.
Aŭ alia situacio: vi aĉetis rezervan kapaciton sur AWS aŭ Azure por ne fali sub pinta ŝarĝo. Ĉu vi povas esti certa, ke ĉi tio estas la optimuma solvo? Post ĉio, se ĉi tiuj kazoj estas neaktivaj 80%, tiam vi simple donas monon al Amazon. Krome, por tiaj kazoj, la sama AWS kaj Azure havas kreveblajn petskribojn - kial vi bezonas neaktivajn servilojn, se vi povas uzi ilon por solvi problemojn de pintŝarĝoj? Aŭ, anstataŭ On Premise kazoj, vi devus rigardi al Rezervita - ili estas multe pli malmultekostaj kaj ili ankaŭ ofertas rabatojn.
Cetere, pri rabatoj
Kiel ni diris komence, aĉetado estas ofte farata de iu ajn - ili trovis la lastan, kaj tiam li iel mem faras tion. Plej ofte, homoj, kiuj jam estas okupataj, fariĝas "ekstremaj", kaj kiel rezulto ni ricevas situacion, kie persono rapide kaj lerte, sed tute sendepende, decidas kion kaj en kiaj kvantoj aĉeti.
Sed interagante kun vendisto de la nuba servo, vi povas akiri pli favorajn kondiĉojn kiam temas pri pogranda aĉeto de kapacito. Estas klare, ke vi ne povos akiri tiajn rabatojn de aŭto kun silenta kaj unuflanka registriĝo - sed post parolado kun vera vendisto, vi eble elĉerpiĝas. Aŭ ĉi tiuj uloj povas diri al vi pri kio ili nuntempe havas rabatojn. Ĝi ankaŭ povas esti utila.
Samtempe, vi devas memori, ke la lumo ne konverĝis kiel kojno sur AWS aŭ Azure. Kompreneble, ne temas pri organizi vian propran servilan ĉambron - sed ekzistas alternativoj al ĉi tiuj du klasikaj solvoj de la gigantoj.
Ekzemple, Google alportis la Firebase-platformon al kompanioj, sur kiuj ili povas gastigi la saman moveblan projekton laŭŝlosilbaze, kiu povas postuli rapidan skalon. Stokado, realtempa datumbazo, gastigado kaj nuba datuma sinkronigo uzante ĉi tiun solvon kiel ekzemplon disponeblas en unu loko.
Aliflanke, se ni ne parolas pri monolita projekto, sed pri ilia tutaĵo, tiam centralizita solvo ne ĉiam estas utila. Se la projekto estas longdaŭra, havas sian propran evoluhistorion kaj respondan kvanton da datumoj necesaj por stokado, tiam indas pensi pri pli fragmenta lokigo.
Optimumante kostojn por nubaj servoj, vi eble subite rimarkos, ke por komercaj kritikaj aplikoj vi povas aĉeti pli potencajn tarifojn, kiuj provizos al la kompanio seninterrompajn enspezojn. Samtempe, stoki la "heredaĵon" de disvolviĝo, malnovaj arkivoj, datumbazoj ktp en multekostaj nuboj estas solvo. Post ĉio, por tiaj datumoj, norma datumcentro kun regulaj HDD-oj kaj mezpotenca aparataro sen sonoriloj kaj fajfiloj sufiĉe taŭgas.
Ĉi tie denove, vi povus pensi, ke "ĉi tiu tumulto ne valoras ĝin", sed la tuta problemo de ĉi tiu eldonaĵo baziĝas sur la fakto, ke en diversaj stadioj la respondecaj homoj neglektas la malgrandajn aferojn kaj faras tion, kio estas pli oportuna kaj pli rapida. Kiu, finfine, post kelkaj jaroj rezultigas tiujn tre terurajn kontojn.
Kio en la fino?
Ĝenerale, nuboj estas bonegaj, ili solvas multajn problemojn por entreprenoj de ajna grandeco. Tamen, la noveco de ĉi tiu fenomeno signifas, ke ni ankoraŭ ne havas kulturon de konsumado kaj administrado. FinOps estas organiza levilo, kiu helpas vin pli efike utiligi nuban potencon. La ĉefa afero estas ne turni ĉi tiun pozicion en analogon de ekzekuttrupo, kies tasko estos kapti senatentajn programistojn per la mano kaj "riproĉi" ilin por malfunkcio.
Programistoj devus disvolviĝi, ne kalkuli kompanian monon. Kaj do FinOps devus fari kaj la aĉetprocezon kaj la procezon de malmendi aŭ transdono de nuba kapacito al aliaj teamoj evento simpla kaj agrabla por ĉiuj partioj.
fonto: www.habr.com