We bê guman meraq kir ku binesaziya projeya we çiqas lêçû. Di heman demê de, ew ecêb e: mezinbûna lêçûnên li gorî bargiraniyê ne rêzek e. Gelek xwedan karsaz, qereqolên karûbar û pêşdebiran bi dizî fam dikin ku ew zêde drav didin. Lê tam ji bo çi?
Bi gelemperî, qutkirina lêçûn tenê bi dîtina çareseriya herî erzan, plansaziyek AWS, an jî, di rewşa rafikên laşî de, xweşbînkirina veavakirina hardware tê dakêşandin. Ne tenê ew: bi rastî, her kes vê yekê dike, wekî Xwedê bixwaze: heke em behsa destpêkek dikin, wê hingê ev dibe ku pêşdebirek pêşeng e ku pir serêş heye. Di ofîsên mezintir de, ev ji hêla CMO/CTO ve tê rêve kirin, û carinan jî rêveberê giştî bi kesane bi hev re bi hesabgirê sereke re têkildar dibe. Bi gelemperî, ew kesên ku têra xwe fikarên "bingeh" hene. Û derket holê ku fatûreyên binesaziyê zêde dibin, lê yên ku wextê wan tune ku pê re mijûl bibin, bi wê re mijûl dibin.
Heke hûn hewce ne ku ji bo nivîsgehê kaxezek destavê bikirin, ev ê ji hêla gerînendeyê peydakirinê an berpirsiyarek ji pargîdaniya paqijkirinê ve were kirin. Ger em li ser pêşveçûnê dipeyivin - rêber û CTO. Sales - her tişt jî zelal e. Lê ji rojên berê ve, gava ku "odeya serverê" navek ji kabîneyek bû ku tê de pergalek birca asayî ya bi RAMek piçûktir û çend dîskên hişk di serdegirtinê de hebû, her kes (an bi kêmanî gelek) guh nade bi rastî ku kirîna kapasîteyê jî divê kesek bi taybetî perwerdekirî were rêve kirin.
Mixabin, bîr û serpêhatiya dîrokî nîşan dide ku bi dehsalan ev peywir li ser mirovên "random" hate guheztin: kê herî nêzîk bû pirs hildigirt. Û tenê di van demên dawî de pîşeya FinOps dest pê kir ku li sûkê şikil bigire û hin şeklek konkret bigire. Ev heman kesê perwerdekirî yê taybetî ye ku peywira wî kontrolkirina kirîn û karanîna kapasîteyê ye. Û, di dawiyê de, di kêmkirina lêçûnên pargîdaniyê de di vî warî de.
Em nahêlin ku dev ji çareseriyên biha û bi bandor berdin: Divê her karsazî bixwe biryarê bide ku ji bo hebûnek rehet di warê hardware û tarîfên ewr de çi hewce dike. Lê meriv nikare bala xwe bide ser vê yekê ku kirîna bêhiş "li gorî navnîşê" bêyî şopandin û analîza paşîn a karanîna ji bo gelek pargîdaniyan di dawiyê de dibe sedema windahiyên pir, pir girîng ji ber rêveberiya bêserûber a "malbatên" pişta wan.
FinOps kî ye
Em bibêjin ku we pargîdaniyek navdar heye, ku kesên firoşkar bi dengek nefes li ser "karsaziyê" diaxivin. Dibe ku, "li gorî navnîşê" we bi dehan an du server, AWS û hin "tiştên piçûk" kirî. Kîjan mentiqî ye: di pargîdaniyek mezin de celebek tevger bi domdarî diqewime - hin tîm mezin dibin, yên din perçe dibin, yên din ji projeyên cîran re têne veguheztin. Û tevhevkirina van tevgeran, ligel mekanîzmaya kirînê ya "li ser bingeha lîsteyê", dema ku li fatûreya binesaziya mehane ya din dinêre di dawiyê de dibe sedema porên gewr ên nû.
Ji ber vê yekê çi bikin - bi bîhnfirehî gewr bidomînin, li ser wê boyax bikin, an sedemên xuyangkirina van gelek sifirên tirsnak di dravdanê de bibînin?
Werin em rastdar bin: pejirandin, pejirandin û dravê rasterast a serîlêdanek di hundurê pargîdaniyê de ji bo heman tarîfa AWS ne her gav (di rastiyê de, hema hema qet) zû ne. Û bi rastî ji ber tevgera pargîdanî ya domdar, dibe ku hin ji van heman destkeftiyan li cîhek "winda bibin". Û bêkar rawestin ne tiştekî biçûk e. Ger rêveberek baldar di odeya servera xwe de refikek bêxwedî dibîne, wê hingê di mijara tarîfên ewr de her tişt pir xemgîntir e. Ew dikarin bi mehan werin danîn - ji bo wan têne dayîn, lê di heman demê de êdî hewce ne kesek di beşa ku ew lê hatine kirîn. Di heman demê de, hevkarên ji ofîsa din dest pê dikin porê xwe yê hê gewr ne tenê li ser serê xwe, lê di heman demê de li deverên din jî dirijînin - wan nekariye hema hema heman tarîfa AWS-ê ya hefteya n-an bidin, ku bi zor hewce ye.
Çareya herî eşkere çi ye? Rast e, destê xwe bidin kesên hewcedar û her kes kêfxweş e. Lê peywendiyên horizontî her gav baş nayên damezrandin. Û dibe ku beşa duyemîn bi tenê di derbarê dewlemendiya yekem de nizane, ku bi rengek xuya bû ku bi rastî ne hewceyê vê dewlemendiyê ye.
Kî ji vê yekê re sûcdar e? - Bi rastî, kes tune. Ji bo niha her tişt bi vî rengî ye.
Kî ji vê yekê diêşe? - Ew e, tevahiya şirket.
Kî dikare rewşê rast bike? - Erê, erê, FinOps.
FinOps ne tenê qateyek e di navbera pêşdebiran û alavên ku ew hewce ne, lê kesek an tîmek e ku dê bizanibe li ku, çi û çiqas baş "derew" e di warê heman tarîfên ewr de ku ji hêla pargîdaniyê ve hatî kirîn. Di rastiyê de, divê ev mirov ji aliyekî ve bi DevOps re, û ji hêla din ve bi beşa darayî re, bi hev re bixebitin, rola navbeynkarek bi bandor û, ya herî girîng, analîstek bilîzin.
Piçek li ser optimîzasyonê
Clouds. Bi nisbet erzan û pir rehet. Lê ev çareserî dema ku hejmara pêşkêşkeran digihîje jimareyên ducarî an sê-hejmarî erzaniyê rawestîne. Wekî din, ewr gengaz dike ku meriv bêtir û bêtir karûbarên ku berê tunebûn bikar bîne: ev databas wekî karûbar (Amazon AWS, Database Azure), serîlêdanên bê server (AWS Lambda, Azure Functions) û gelekên din in. Ew hemî pir xweş in ji ber ku karanîna wan hêsan in - bikirin û biçin, bê pirsgirêk. Lê her ku pargîdanî û projeyên wê di nav ewran de kûrtir dibin, CFO xirabtir radizê. Û her ku zûtir general gewr dibe.
Rastî ev e ku fatûreyên ji bo karûbarên ewr ên cihêreng her gav zehf tevlihev in: ji bo yek babetekê hûn dikarin ravekirinek sê-rûpelî bistînin ka dravê we çi, li ku û çawa çûye. Ev, bê guman, xweş e, lê hema hema ne gengaz e ku meriv wê fêm bike. Wekî din, nêrîna me li ser vê mijarê ji yekane dûr e: ji bo ku hesabên ewr ji mirovan re veguhezînin, hemî karûbar hene, mînakî an . Ger kesek ji bo deşîfrekirina fatoreyan karûbarek cihê biafirîne, wê hingê pîvana pirsgirêkê ji lêçûna boyaxa porê mezintir bûye.
Ji ber vê yekê FinOps di vê rewşê de çi dike:
- bi zelalî fêm dike kengê û di kîjan cildan de çareseriyên ewr hatine kirîn.
- dizane ku ev kapasîteyên çawa têne bikaranîn.
- wan li gorî hewcedariyên yekîneyek taybetî ji nû ve belav dike.
- nakire "da ku bibe".
- û di dawiyê de, ew drav dide we.
Mînakek mezin hilanîna ewr a kopiyek sar a databasê ye. Mînakî, hûn wê arşîv bikin da ku dema nûvekirina hilanînê mîqdara cîh û seyrûseferê kêm bikin? Erê, wusa dixuye ku rewş erzan e - di yek rewşek taybetî de, lê tevahî rewşên weha erzan paşê ji bo karûbarên ewr dibe sedema lêçûnên giran.
An jî rewşek din: we kapasîteya rezervê li ser AWS an Azure kirî da ku nekeve bin barkirina lûtkeyê. Ma hûn dikarin piştrast bin ku ev çareseriya çêtirîn e? Beriya her tiştî, heke ev mînak %80 bêkar bin, wê hingê hûn bi tenê drav didin Amazonê. Digel vê yekê, ji bo rewşên weha, heman AWS û Azure xwedan mînakên teqîner in - hûn çima hewceyê serverên bêkar in, ger hûn dikarin amûrek bikar bînin da ku pirsgirêkên bargiraniyên pez çareser bikin? An jî, li şûna bûyerên On Premise, divê hûn li Reserved binêrin - ew pir erzan in û ew jî dakêşan pêşkêş dikin.
Bi awayê, di derbarê dakêşan de
Wekî ku me di destpêkê de got, kirînê bi gelemperî ji hêla her kesî ve tête kirin - wan ya paşîn dît, û dûv re ew bi rengek xwe wiya dike. Bi gelemperî, mirovên ku jixwe mijûl in, dibin "zehmet", û di encamê de em dibin rewşek ku meriv zû û jêhatî, lê bi tevahî serbixwe, biryar dide ka çi û bi çi qasê bikire.
Lê gava ku bi firoşkarek ji karûbarê ewr re têkilî daynin, hûn dikarin şert û mercên xweştir bistînin dema ku ew tê ser kirîna kapasîteyê ya bi tevahî. Eşkere ye ku hûn ê nikaribin ji otomobîlek bi qeydek bêdeng û yekalî erzaniyên weha bistînin - lê piştî ku bi rêvebirek firotanê ya rastîn re biaxifin, dibe ku hûn bişewitin. An jî ev zilam dikarin ji we re bibêjin ku ew niha li ser çi dakêşan hene. Ew jî dikare bikêr be.
Di heman demê de, hûn hewce ne ku ji bîr mekin ku ronî li ser AWS an Azure mîna kulmekê li hev nekir. Bê guman, Pirsgirêka organîzekirina odeya servera xwe tune - lê ji van du çareseriyên klasîk ên ji dêw re alternatîf hene.
Mînakî, Google platforma Firebase anî ji pargîdaniyan re, ku li ser wê ew dikarin heman projeya mobîl li ser bingehek kilît mêvandar bikin, ku dibe ku pîvana bilez hewce bike. Storage, databasa-a-time-ê, mêvandar û hevdengkirina daneya cloudê ku vê çareseriyê wekî mînak bikar tînin li yek cîhek peyda dibin.
Ji aliyê din ve, eger em ne behsa projeyek yekparêz, lê li ser tevahîya wan bikin, wê gavê çareseriyek navendî ne her gav bi fêde ye. Ger proje demdirêj be, xwedan dîroka xwe ya pêşkeftinê ye û pêvek daneya ku ji bo hilanînê hewce ye, wê hingê hêja ye ku meriv li ser cîhê perçebûyî bifikire.
Dema ku lêçûnên ji bo karûbarên cloudê xweş bikin, dibe ku hûn ji nişkê ve fêm bikin ku ji bo serîlêdanên karsaziyê-krîtîk hûn dikarin tarîfên bihêztir bikirin ku dê pargîdaniyê bi dahatiyên bênavber peyda bike. Di heman demê de, hilanîna "mîrata" ya pêşkeftinê, arşîvên kevn, databas û hwd di ewrên biha de çareseriyek e. Beriya her tiştî, ji bo daneyên wusa, navendek daneya standard bi HDD-yên birêkûpêk û hardware-hêza navîn bêyî zengil û bilbilan pir maqûl e.
Li vir dîsa, dibe ku hûn bifikirin ku "ev tevlihevî ne hêja ye", lê tevahiya pirsgirêka vê weşanê li ser vê yekê ye ku di qonaxên cihêreng de kesên berpirsiyar tiştên piçûk paşguh dikin û tiştê ku hêsantir û zûtir dikin dikin. Ya ku, di dawiyê de, piştî çend salan encamên wan hesabên pir tirsnak çêdibe.
Di dawiyê de çi ye?
Bi gelemperî, ewr xweş in, ew ji bo karsaziyên her mezinahiyê gelek pirsgirêkan çareser dikin. Lêbelê nûbûna vê diyardeyê tê wê maneyê ku hîna jî çanda mezlûm û rêvebirinê tuneye. FinOps rêgezek rêxistinî ye ku ji we re dibe alîkar ku hûn hêza ewr bi bandortir bikar bînin. Ya sereke ev e ku meriv vê pozîsyonê neke analogek tîmê gulebaranê, ku peywira wê ew e ku pêşdebirên bêhiş bi destê xwe bigire û wan ji bo demdirêjiyê "şermezar bike".
Pêdivî ye ku pêşdebir pêşde bibin, ne ku dravê pargîdaniyê bihesibînin. Ji ber vê yekê FinOps divê hem pêvajoya kirînê û hem jî pêvajoya hilweşandin an veguheztina kapasîteya ewr ji tîmên din re bûyerek hêsan û kêfxweş bike ji bo hemî aliyan.
Source: www.habr.com