Դուք հաստատ մտածել եք, թե որքան արժե ձեր նախագծի ենթակառուցվածքը: Միևնույն ժամանակ, զարմանալի է. ծախսերի աճը բեռների նկատմամբ գծային չէ։ Շատ ձեռնարկատերեր, սպասարկման կայաններ և ծրագրավորողներ թաքուն հասկանում են, որ գերավճար են տալիս: Բայց կոնկրետ ինչի՞ համար:
Որպես կանոն, ծախսերի կրճատումը պարզապես հանգում է ամենաէժան լուծումը, AWS պլանը կամ, ֆիզիկական դարակաշարերի դեպքում, ապարատային կոնֆիգուրացիան օպտիմալացնելուն: Ոչ միայն դա. իրականում ցանկացած մարդ դա անում է, ինչպես Աստված կամենում է. եթե մենք խոսում ենք ստարտափի մասին, ապա սա հավանաբար առաջատար ծրագրավորող է, ով շատ գլխացավեր ունի: Ավելի մեծ գրասենյակներում դրանով զբաղվում է CMO/CTO-ն, և երբեմն գլխավոր տնօրենն անձամբ է մասնակցում այդ խնդրին գլխավոր հաշվապահի հետ միասին: Ընդհանուր առմամբ, այն մարդիկ, ովքեր բավականաչափ «հիմնական» մտահոգություններ ունեն։ Եվ պարզվում է, որ ենթակառուցվածքների վճարները բարձրանում են, բայց նրանք, ովքեր ժամանակ չունեն դրանով զբաղվելու, զբաղվում են դրանով։
Եթե գրասենյակի համար զուգարանի թուղթ գնելու կարիք ունեք, դա կանի մատակարարման մենեջերը կամ մաքրող ընկերությունից պատասխանատու անձը: Եթե մենք խոսում ենք զարգացման մասին՝ առաջատարներ և CTO: Վաճառք - ամեն ինչ նույնպես պարզ է: Բայց հին ժամանակներից ի վեր, երբ «սերվերի սենյակը» կաբինետի անունն էր, որտեղ սովորական աշտարակային համակարգ կար՝ մի փոքր ավելի շատ RAM և մի քանի կոշտ սկավառակներով, բոլորը (կամ գոնե շատերը) անտեսում են. այն փաստը, որ կարողությունների գնման դեպքում պետք է զբաղվի նաև հատուկ պատրաստված անձը:
Ավաղ, պատմական հիշողությունն ու փորձը ցույց են տալիս, որ տասնամյակներ շարունակ այդ խնդիրը դրված էր «պատահական» մարդկանց վրա. ով մոտիկից էր, հարցնում էր: Եվ միայն վերջերս FinOps մասնագիտությունը սկսեց ձևավորվել շուկայում և որոշակի ձևավորվել: Սա այն նույն հատուկ պատրաստված անձն է, ում խնդիրն է վերահսկել հզորության գնումն ու օգտագործումը։ Եվ, ի վերջո, նվազեցնելով ընկերության ծախսերը այս ոլորտում:
Մենք չենք քարոզում հրաժարվել թանկարժեք և արդյունավետ լուծումներից. յուրաքանչյուր բիզնես պետք է ինքնուրույն որոշի, թե ինչ է իրեն անհրաժեշտ հարմարավետ գոյության համար՝ սարքավորումների և ամպային սակագների առումով: Բայց չի կարելի ուշադրություն չդարձնել այն փաստին, որ չմտածված գնումները «ըստ ցանկի» առանց հետագա մոնիտորինգի և օգտագործման վերլուծության շատ ընկերությունների համար, ի վերջո, հանգեցնում են շատ, շատ զգալի կորուստների՝ իրենց հետին պլանի «ակտիվների» անարդյունավետ կառավարման պատճառով:
Ով է FinOps-ը
Ենթադրենք, դուք ունեք հեղինակավոր ձեռնարկություն, որի մասին վաճառողները խոսում են «ձեռնարկության» մասին շնչահեղձ տոնով։ Հավանաբար, «ըստ ցուցակի» դուք գնել եք մեկ տասնյակ կամ երկու սերվեր, AWS և մի քանի այլ «փոքր բաներ»: Ինչը տրամաբանական է. մեծ ընկերությունում անընդհատ ինչ-որ շարժում է տեղի ունենում. որոշ թիմեր աճում են, մյուսները քայքայվում են, մյուսները տեղափոխվում են հարևան նախագծեր: Եվ այս շարժումների համադրությունը, «ցուցակի վրա հիմնված» գնումների մեխանիզմի հետ միասին, ի վերջո հանգեցնում են նոր մոխրագույն մազերի՝ հաջորդ ամսական ենթակառուցվածքների օրինագիծը դիտարկելիս:
Այսպիսով, ի՞նչ անել. համբերատար շարունակել մոխրագույնը, ներկել դրա վրա, թե՞ պարզել վճարման մեջ այս բազմաթիվ սարսափելի զրոների հայտնվելու պատճառները:
Եկեք անկեղծ լինենք. նույն AWS սակագնի համար ընկերության ներսում հայտի հաստատումը, հաստատումը և ուղղակի վճարումը միշտ չէ, որ (իրականում, գրեթե երբեք) արագ: Եվ հենց անընդհատ կորպորատիվ շարժման պատճառով այս նույն ձեռքբերումներից որոշները կարող են ինչ-որ տեղ «կորչել»: Եվ պարապ մնալը չնչին է: Եթե ուշադիր ադմինիստրատորն իր սերվերի սենյակում նկատում է անտեր դարակ, ապա ամպային սակագների դեպքում ամեն ինչ շատ ավելի տխուր է։ Դրանք կարող են պահվել ամիսներով՝ վճարովի, բայց միևնույն ժամանակ այլևս կարիք չունեն որևէ մեկին այն բաժնում, որի համար դրանք գնվել են: Միևնույն ժամանակ, հաջորդ գրասենյակի գործընկերները սկսում են պոկել իրենց դեռևս չմոխրագույն մազերը ոչ միայն իրենց գլխին, այլև այլ վայրերում. նրանք չեն կարողացել վճարել մոտավորապես նույն AWS սակագինը XNUMX-րդ շաբաթվա համար, որը խիստ անհրաժեշտ է.
Ո՞րն է ամենաակնհայտ լուծումը: Այդպես է, սանձը փոխանցեք կարիքավորներին, և բոլորը երջանիկ են: Բայց հորիզոնական հաղորդակցությունները միշտ չէ, որ լավ հաստատված են: Իսկ երկրորդ գերատեսչությունը կարող է պարզապես չիմանալ առաջինի հարստության մասին, որը ինչ-որ կերպ պարզվեց, որ այդ հարստությունն իրականում կարիք չունի։
Ո՞վ է մեղավոր սրա համար։ - Փաստորեն, ոչ ոք: Առայժմ ամեն ինչ այդպես է դրված։
Ո՞վ է տուժում սրանից: -Վերջ, ամբողջ ընկերությունը։
Ո՞վ կարող է շտկել իրավիճակը: - Այո, այո, FinOps:
FinOps-ը ոչ միայն շերտ է մշակողների և նրանց անհրաժեշտ սարքավորումների միջև, այլ անձ կամ թիմ, ով կիմանա, թե որտեղ, ինչ և որքանով է այն «ստեղված» ընկերության կողմից գնված նույն ամպային սակագների առումով: Փաստորեն, այս մարդիկ պետք է աշխատեն մի կողմից DevOps-ի, մյուս կողմից՝ ֆինանսական բաժնի հետ՝ կատարելով արդյունավետ միջնորդի և, որ ամենակարևորը, վերլուծաբանի դերը։
Մի քիչ օպտիմալացման մասին
Ամպեր. Համեմատաբար էժան և շատ հարմար։ Բայց այս լուծումը դադարում է էժան լինել, երբ սերվերների թիվը հասնում է երկնիշ կամ եռանիշ թվի։ Բացի այդ, ամպերը հնարավորություն են տալիս օգտագործել ավելի ու ավելի շատ ծառայություններ, որոնք նախկինում անհասանելի էին. դրանք տվյալների բազաներ են որպես ծառայություն (Amazon AWS, Azure Database), առանց սերվերի հավելվածներ (AWS Lambda, Azure Functions) և շատ ուրիշներ: Նրանք բոլորն էլ շատ լավն են, քանի որ դրանք հեշտ է օգտագործել՝ գնեք և գնացեք, խնդիրներ չկան: Բայց որքան խորն է ընկերությունն ու նրա նախագծերը սուզվում ամպերի մեջ, այնքան վատ է քնում ֆինանսական տնօրենը: Եվ որքան արագ է գեներալը մոխրագույն դառնում։
Փաստն այն է, որ տարբեր ամպային ծառայությունների հաշիվ-ապրանքագրերը միշտ չափազանց շփոթեցնող են. մեկ ապրանքի համար կարող եք ստանալ երեք էջանոց բացատրություն, թե ինչ, որտեղ և ինչպես են գնացել ձեր գումարները: Սա, իհարկե, հաճելի է, բայց դա հասկանալը գրեթե անհնար է։ Ավելին, այս հարցի վերաբերյալ մեր կարծիքը հեռու է միակից. ամպային հաշիվները մարդկային հաշիվներին փոխանցելու համար կան ամբողջ ծառայություններ, օրինակ. կամ . Եթե ինչ-որ մեկը անհանգստացել է հաշիվների վերծանման առանձին ծառայություն ստեղծելու համար, ապա խնդրի մասշտաբները գերազանցել են մազերի ներկի արժեքը:
Այսպիսով, ինչ է անում FinOps-ը այս իրավիճակում.
- հստակ հասկանում է, թե երբ և ինչ ծավալներով են գնվել ամպային լուծումները:
- գիտի, թե ինչպես են օգտագործվում այդ կարողությունները:
- վերաբաշխում է դրանք՝ կախված որոշակի միավորի կարիքներից:
- չի գնում «որպեսզի լինի»:
- և, ի վերջո, դա ձեզ գումար է խնայում:
Հիանալի օրինակ է տվյալների բազայի սառը պատճենի ամպային պահպանումը: Օրինակ, արխիվացնու՞մ եք այն, որպեսզի նվազեցնեք տարածքի և երթևեկի սպառված քանակությունը պահեստը թարմացնելու ժամանակ: Այո, թվում է, թե իրավիճակը էժան է. մեկ կոնկրետ դեպքում, բայց նման էժան իրավիճակների ամբողջությունը հետագայում հանգեցնում է ամպային ծառայությունների չափազանց մեծ ծախսերի:
Կամ մեկ այլ իրավիճակ. դուք գնել եք պահուստային հզորություն AWS-ում կամ Azure-ում, որպեսզի չընկնեք գագաթնակետային բեռի տակ: Կարո՞ղ եք վստահ լինել, որ սա օպտիմալ լուծում է: Ի վերջո, եթե այս դեպքերը 80%-ով անգործության են մատնված, ապա դուք պարզապես գումար եք տալիս Amazon-ին: Ավելին, նման դեպքերի համար նույն AWS-ն ու Azure-ն ունեն պայթող դեպքեր. ինչի՞ն են ձեզ անհրաժեշտ պարապ սերվերները, եթե կարող եք գործիք օգտագործել գագաթնակետային բեռների խնդիրները լուծելու համար: Կամ, On Premise օրինակների փոխարեն, դուք պետք է նայեք դեպի Reserved. դրանք շատ ավելի էժան են և առաջարկում են նաև զեղչեր:
Ի դեպ, զեղչերի մասին
Ինչպես սկզբում ասացինք, հաճախ գնումներ կատարում է ցանկացած մեկը՝ գտել են վերջինը, հետո ինքն էլ մի կերպ անում է։ Ամենից հաճախ արդեն զբաղված մարդիկ դառնում են «էքստրեմալ», և արդյունքում մենք ստանում ենք մի իրավիճակ, երբ մարդը արագ և հմտորեն, բայց լիովին ինքնուրույն որոշում է, թե ինչ և ինչ քանակությամբ գնել:
Բայց ամպային ծառայության վաճառողի հետ շփվելիս կարող եք ավելի բարենպաստ պայմաններ ստանալ, երբ խոսքը վերաբերում է հզորության մեծածախ գնմանը: Հասկանալի է, որ դուք չեք կարողանա նման զեղչեր ստանալ լուռ և միակողմանի գրանցումով մեքենայից, բայց իրական վաճառքի մենեջերի հետ խոսելուց հետո կարող եք այրվել: Կամ այս տղաները կարող են ձեզ ասել, թե ինչի վրա են նրանք ներկայումս զեղչեր անում: Այն կարող է նաև օգտակար լինել։
Միևնույն ժամանակ, դուք պետք է հիշեք, որ լույսը AWS-ի կամ Azure-ի վրա սեպի պես միաձուլվեց: Իհարկե, ձեր սեփական սերվերի սենյակը կազմակերպելու հարց չկա, բայց այս երկու դասական լուծումներին այլընտրանքներ կան հսկաներից:
Օրինակ, Google-ը Firebase պլատֆորմը բերեց ընկերություններին, որոնց վրա նրանք կարող են հյուրընկալել նույն բջջային նախագիծը բանտի հիմունքներով, ինչը կարող է պահանջել արագ մասշտաբավորում: Պահպանումը, իրական ժամանակի տվյալների բազան, հոսթինգը և ամպային տվյալների համաժամացումը՝ օգտագործելով այս լուծումը որպես օրինակ, հասանելի են մեկ տեղում:
Մյուս կողմից, եթե խոսքը ոչ թե մոնոլիտ նախագծի, այլ դրանց ամբողջականության մասին է, ապա կենտրոնացված լուծումը միշտ չէ, որ ձեռնտու է։ Եթե նախագիծը երկարակյաց է, ունի իր զարգացման պատմությունը և պահպանման համար անհրաժեշտ տվյալների համապատասխան քանակությունը, ապա արժե մտածել ավելի մասնատված տեղաբաշխման մասին։
Ամպային ծառայությունների համար ծախսերը օպտիմալացնելիս կարող եք հանկարծ հասկանալ, որ բիզնեսի համար կարևոր հավելվածների համար կարող եք գնել ավելի հզոր սակագներ, որոնք ընկերությանը կապահովեն անխափան եկամուտներ: Միևնույն ժամանակ, լուծում է զարգացման «ժառանգությունը», հին արխիվները, տվյալների բազաները և այլն պահել թանկարժեք ամպերում։ Ի վերջո, նման տվյալների համար ստանդարտ տվյալների կենտրոնը սովորական HDD-ներով և միջին հզորության ապարատով առանց որևէ զանգի և սուլիչի բավականին հարմար է:
Այստեղ կրկին կարող եք մտածել, որ «այս աղմուկը չարժե», բայց այս հրապարակման ամբողջ խնդիրը հիմնված է այն բանի վրա, որ տարբեր փուլերում պատասխանատուները անտեսում են մանրուքները և անում են այն, ինչ ավելի հարմար և արագ է։ Ինչը, ի վերջո, մի երկու տարի հետո հանգեցնում է հենց այդ սարսափելի պատմությունների:
Արդյունքը:
Ընդհանրապես, ամպերը զով են, դրանք շատ խնդիրներ են լուծում ցանկացած չափի բիզնեսի համար։ Սակայն այս երեւույթի նորությունը նշանակում է, որ մենք դեռ չունենք սպառման ու կառավարման մշակույթ։ FinOps-ը կազմակերպչական լծակ է, որն օգնում է ձեզ ավելի արդյունավետ օգտագործել ամպային հզորությունը: Հիմնական բանը այս դիրքը չվերածել կրակահերթի անալոգի, որի խնդիրն է լինելու անուշադիր ծրագրավորողներին ձեռքից բռնել և «կշտամբել» նրանց պարապուրդի համար:
Մշակողները պետք է զարգանան, այլ ոչ թե հաշվենեն ընկերության փողերը: Եվ այսպես, FinOps-ը պետք է թե՛ գնման գործընթացը, թե՛ շահագործումից հանելու կամ ամպային հզորությունը այլ թիմերին փոխանցելու գործընթացը դարձնի պարզ և հաճելի իրադարձություն բոլոր կողմերի համար:
Source: www.habr.com