Jo hawwe jo grif ôffrege hoefolle de ynfrastruktuer fan jo projekt kostet. Tagelyk is it ferrassend: de groei fan kosten is net lineêr mei respekt foar loads. In protte bedriuwseigners, tankstasjons en ûntwikkelders begripe temûk dat se tefolle betelje. Mar foar wat krekt?
Typysk komt it besunigjen fan kosten gewoan del op it finen fan de goedkeapste oplossing, in AWS-plan, of, yn it gefal fan fysike rekken, it optimalisearjen fan de hardwarekonfiguraasje. Net allinich dat: yn feite docht elkenien dit, lykas God wol: as wy it oer in opstart hawwe, dan is dit wierskynlik in liedende ûntwikkelder dy't in protte hoofdpijn hat. Yn gruttere kantoaren wurdt dat behannele troch de CMO/CTO, en soms wurdt de algemien direkteur tegearre mei de haadaccountant persoanlik belutsen by de kwestje. Yn it algemien, dy minsken dy't hawwe genôch "kearn" soargen. En it docht bliken dat de rekkens foar ynfrastruktuer omheech geane, mar dejingen dy't gjin tiid hawwe om dermei te dwaan, binne der mei te krijen.
As jo húskepapier keapje moatte foar it kantoar, dan sil dat dien wurde troch de oanfiermanager of in ferantwurdlike persoan fan it skjinmakbedriuw. As wy it hawwe oer ûntwikkeling - leads en CTO. Ferkeap - alles is ek dúdlik. Mar sûnt de âlde dagen, doe't in "serverkeamer" in namme wie foar in kabinet wêryn d'r in gewoan toersysteem wie mei wat mear RAM en in pear hurde skiven yn 'e raid, negearje elkenien (of teminsten in protte) de feit dat de oankeap fan kapasiteit moat wurde ôfhannele ek in spesjaal oplaat persoan.
Och, histoarysk ûnthâld en ûnderfining jouwe oan dat dizze taak foar tsientallen jierren ferpleatst waard nei "willekeurige" minsken: wa't it tichtste wie, pakte de fraach op. En pas koartlyn begon it berop fan FinOps foarm te krijen op 'e merke en wat konkrete foarm oan te nimmen. Dit is deselde spesjaal oplaat persoan waans taak is om de oankeap en gebrûk fan kapasiteit te kontrolearjen. En, úteinlik, yn it ferminderjen fan de kosten fan it bedriuw op dit gebiet.
Wy pleite net foar it ferlitten fan djoere en effektive oplossingen: elk bedriuw moat foar himsels beslute wat it nedich is foar in noflik bestean yn termen fan hardware en wolktariven. Mar men kin net helpe, mar omtinken te jaan oan it feit dat gedachteleaze oankeap "neffens de list" sûnder folgjende tafersjoch en analyse fan gebrûk foar in protte bedriuwen úteinlik resultearret yn heul, heul substansjele ferliezen troch in effektyf behear fan 'e "aktiva" fan har backend.
Wa is FinOps
Litte wy sizze dat jo in renommearre ûndernimming hawwe, dy't ferkeapers prate oer "bedriuw" yn in adembenemende toan. Wierskynlik hawwe jo "neffens de list" in tsiental of twa servers kocht, AWS en wat oare "lytse dingen". Dat is logysk: yn in grut bedriuw bart der hieltyd in soarte fan beweging - guon teams groeie, oaren disintegrearje, oaren wurde oerbrocht nei oanbuorjende projekten. En de kombinaasje fan dizze bewegingen, tegearre mei it "list-basearre" oanbestegingsmeganisme, liedt úteinlik ta nije grize hieren as jo sjogge nei de folgjende moanlikse ynfrastruktuerrekken.
Dus wat te dwaan - geduldich fierder te griis, skilderje oer it, of útfine de redenen foar it ferskinen fan dizze tal fan skriklike nullen yn 'e betelling?
Litte wy earlik wêze: goedkarring, goedkarring en direkte betelling fan in oanfraach binnen it bedriuw foar deselde AWS-taryf is net altyd (yn werklikheid, hast noait) fluch. En krekt fanwegen de konstante bedriuwsbeweging kinne guon fan dizze deselde oanwinsten earne "ferlern" wurde. En it is triviaal om stil te stean. As in opmerklike behearder in eignerleas rack yn syn serverkeamer opmerkt, dan is yn 't gefal fan wolktariven alles folle tryster. Se kinne moannen oplein wurde - betelle, mar tagelyk net mear nedich troch elkenien yn 'e ôfdieling wêrfoar se kocht binne. Tagelyk begjinne kollega's fan it folgjende kantoar har noch net grize hier net allinnich op 'e holle, mar ek op oare plakken út te skuorjen - se hawwe foar de nde wike sawat itselde AWS-taryf net betelje kinnen, wat is wanhopich nedich.
Wat is de meast foar de hân lizzende oplossing? Dat kloppet, jou de teugels oer oan dyjingen yn need, en elkenien is bliid. Mar horizontale kommunikaasje is net altyd goed fêstlein. En de twadde ôfdieling kin gewoan net witte oer de rykdom fan 'e earste, dy't op ien of oare manier blykte dat dizze rykdom net echt nedich wie.
Wa is dêr skuldich oan? - Eins gjinien. Sa sit alles foar no.
Wa hat hjir lêst fan? - Dat is it, it hiele bedriuw.
Wa kin de situaasje reparearje? - Ja, ja, FinOps.
FinOps is net allinich in laach tusken ûntwikkelders en de apparatuer dy't se nedich binne, mar in persoan of team dy't wit wêr't, wat en hoe goed it "liigt" yn termen fan deselde wolktariven kocht troch it bedriuw. Yn feite moatte dizze minsken gearwurkje mei DevOps, oan 'e iene kant, en de ôfdieling finansjeel oan' e oare, en spylje de rol fan in effektive tuskenpersoan en, it wichtichste, in analist.
In bytsje oer optimalisaasje
Wolken. Relatyf goedkeap en hiel handich. Mar dizze oplossing hâldt op mei goedkeap te wêzen as it oantal tsjinners dûbele of trije sifers berikt. Dêrnjonken meitsje wolken it mooglik om mear en mear tsjinsten te brûken dy't earder net beskikber wiene: dit binne databases as in tsjinst (Amazon AWS, Azure Database), serverless applikaasjes (AWS Lambda, Azure Functions) en in protte oaren. Se binne allegear heul cool, om't se maklik te brûken binne - keapje en gean, gjin problemen. Mar hoe djipper it bedriuw en har projekten yn 'e wolken dûke, hoe slimmer de CFO sliept. En hoe flugger de generaal griis wurdt.
It feit is dat faktueren foar ferskate wolktsjinsten altyd ekstreem betiizjend binne: foar ien item kinne jo in trije-side-útlis krije fan wat, wêr en hoe't jo jild gie. Dit is fansels noflik, mar it is hast net te begripen. Boppedat is ús miening oer dizze kwestje lang net de iennichste: om wolkakkounts oer te setten nei minsklike binne d'r folsleine tsjinsten, bygelyks of . As immen de muoite hat om in aparte tsjinst te meitsjen foar it ûntsiferjen fan rekkens, dan is de skaal fan it probleem de kosten fan hierferve te groeien.
Dus wat docht FinOps yn dizze situaasje:
- dúdlik begrypt wannear en yn hokker folumes wolk oplossings waarden kocht.
- wit hoe't dizze kapasiteiten wurde brûkt.
- redistributes se ôfhinklik fan de behoeften fan in bepaalde ienheid.
- keapet net "sadat it kin wêze".
- en op it lêst, it besparret jo jild.
In geweldich foarbyld is wolk opslach fan in kâlde kopy fan in databank. Argivearje jo it bygelyks om de hoemannichte romte en ferkear te ferminderjen by it bywurkjen fan de opslach? Ja, it liket derop dat de situaasje goedkeap is - yn ien spesifyk gefal, mar de totaliteit fan sokke goedkeape situaasjes resultearret letter yn exorbitante kosten foar wolktsjinsten.
Of in oare situaasje: jo hawwe reservekapasiteit kocht op AWS of Azure om net ûnder pyklast te fallen. Kin jo der wis fan wêze dat dit de optimale oplossing is? As dizze gefallen ommers 80% idle binne, jouwe jo gewoan jild oan Amazon. Boppedat, foar sokke gefallen hawwe deselde AWS en Azure burstable eksimplaren - wêrom hawwe jo idling tsjinners nedich, as jo in ark brûke kinne om problemen fan pyklasten op te lossen? Of, ynstee fan On Premise-ynstânsjes, soene jo moatte sjen nei Reserved - se binne folle goedkeaper en se biede ek koartingen.
Trouwens, oer koartingen
Lykas wy oan it begjin seine, wurdt de oankeap faak troch elkenien útfierd - se fûnen de lêste, en dan docht hy it sels op ien of oare manier. Meastentiids wurde minsken dy't al dwaande binne "ekstreem", en as gefolch krije wy in situaasje wêryn in persoan fluch en feardigens, mar folslein selsstannich, beslút wat en yn hokker hoemannichten te keapjen.
Mar as jo ynteraksje mei in ferkeaper fan 'e wolktsjinst, kinne jo geunstigere betingsten krije as it giet om de oankeap fan kapasiteit. It is dúdlik dat jo sokke koartingen net kinne krije fan in auto mei in stille en iensidige registraasje - mar nei it praten mei in echte ferkeapmanager kinne jo burn out. Of dizze jonges kinne jo fertelle wêr't se op it stuit koartingen op hawwe. It kin ek nuttich wêze.
Tagelyk moatte jo betinke dat it ljocht net konvergearre as in wig op AWS of Azure. Fansels is d'r gjin sprake fan it organisearjen fan jo eigen serverkeamer - mar d'r binne alternativen foar dizze twa klassike oplossingen fan 'e reuzen.
Bygelyks, Google brocht it Firebase-platfoarm oan bedriuwen, wêryn't se itselde mobyl projekt op turnkey basis kinne hostje, wat rappe skaalfergrutting nedich is. Opslach, real-time database, hosting en syngronisaasje fan wolkgegevens mei dizze oplossing as foarbyld binne op ien plak beskikber.
Oan 'e oare kant, as wy it net hawwe oer in monolitysk projekt, mar oer har totaliteit, dan is in sintralisearre oplossing net altyd foardielich. As it projekt lang libben hat, in eigen ûntwikkelingsskiednis hat en in oerienkommende hoemannichte gegevens nedich foar opslach, dan is it wurdich te tinken oer mear fragminteare pleatsing.
By it optimalisearjen fan kosten foar wolktsjinsten, kinne jo ynienen realisearje dat jo foar saaklike krityske applikaasjes machtiger tariven kinne keapje dy't it bedriuw mei ûnûnderbrutsen fertsjinsten sille leverje. Tagelyk is it opslaan fan de "legacy" fan ûntwikkeling, âlde argiven, databases, ensfh yn djoere wolken in oplossing. Ommers, foar sokke gegevens is in standert datasintrum mei reguliere HDD's en medium-power hardware sûnder toeters en bellen hiel geskikt.
Hjirnei kinne jo tinke dat "dizze gedoe it net wurdich is", mar it hiele probleem fan dizze publikaasje is basearre op it feit dat yn ferskate stadia de ferantwurdlike minsken de lytse dingen negearje en dwaan wat handiger en flugger is. Wat, úteinlik, nei in pear jier resultearret yn dy tige horror accounts.
Wat op it ein?
Yn 't algemien binne wolken cool, se losse in protte problemen op foar bedriuwen fan elke grutte. De nijheid fan dit ferskynsel betsjut lykwols dat wy noch altyd gjin kultuer fan konsumpsje en behear hawwe. FinOps is in organisatoaryske lever dy't jo helpt om wolkmacht effektiver te benutten. It wichtichste is om dizze posysje net te feroarjen yn in analoog fan in fjoerploech, waans taak sil wêze om ûnopmerklike ûntwikkelders troch de hân te fangen en se te "skolden" foar downtime.
Ûntwikkelers moatte ûntwikkelje, net telle bedriuw jild. En sa soe FinOps sawol it oankeapproses as it proses fan ûntmanteling of oerdracht fan wolkkapasiteit oan oare teams in evenemint ienfâldich en noflik meitsje foar alle partijen.
Boarne: www.habr.com