Вызначана, вы задаваліся пытаннем, у колькі абыходзіцца інфраструктура вашага праекта. Пры гэтым дзіўна: рост выдаткаў не лінеен адносна нагрузак. Многія ўладальнікі бізнесу, СТА і распрацоўшчыкі падспудна разумеюць, што пераплачваюць. Але завошта канкрэтна?
Звычайна скарачэнне выдаткаў зводзіцца проста да пошуку найболей таннага рашэння, тарыфу AWS або, калі мы кажам аб фізічных стойках, аптымізацыі канфігурацыі абсталявання. Мала таго: фактычна, гэтым займаецца хто заўгодна, як бог на душу пакладзе: калі мы гаворым аб стартапе, то гэта, верагодна, вядучы дэвелапер, у якога хапае галоўнякоў. У канторах буйнейшым гэтым займаецца CMO / CTO, часам у пытанне залазіць асабіста генеральны дырэктар на пару з галоўбухам. Увогуле, тыя людзі, у якіх і "профільных" клопатаў хапае. І атрымліваецца, што рахункі за інфраструктуру растуць, але разбіраюцца з гэтым… тыя, у каго няма часу з гэтым разбірацца.
Калі ў офіс трэба купіць туалетную паперу, гэтым зоймецца загадчык гаспадаркі або адказны чалавек з клінінгавай кампаніі. Калі гаворка аб распрацоўцы - ліды і CTO. Продажы - таксама ўсё зразумела. Але яшчэ з барадатых часоў, калі "сервернай" звалі шафу, у якім стаяла звычайная tower-сістэмнік з ледзь вялікай колькасцю аператыўнай памяці і парай хардаў у рэйдзе, усё (ці, прынамсі, шматлікія) ігнаруюць той факт, што закупамі магутнасцяў павінен займацца таксама спецыяльна навучаны чалавек.
Нажаль, гістарычная памяць і досвед кажуць аб тым, што гэтая задача дзесяцігоддзямі перакладалася на людзей "выпадковых": хто быў бліжэй, той і падхапіў пытанне. І толькі нядаўна на рынку стала афармляцца і прымаць сякія-такія пэўныя абрысы прафесія FinOps. Гэта той самы спецыяльна навучаны чалавек, чыя задача складаецца ў кантролі за пакупкай і выкарыстаннем магутнасцяў. І, у канчатковым выніку, у зніжэнні выдаткаў кампаніі па гэтым напрамку.
Мы не агітуем адмовіцца ад дарагіх і эфектыўных рашэнняў: кожны бізнэс павінен сам вырашаць, што яму трэба для камфортнага існавання ў плане жалеза і хмарных тарыфаў. Але нельга не звярнуць увагу на той факт, што бяздумная закупка "па спісе" без наступнага кантролю і аналізу выкарыстання для многіх кампаній у выніку выліваецца ў вельмі і вельмі самавітыя страты з-за неэфектыўнага кіравання "актывамі" свайго бэкэнда.
Хто такі FinOps
Дапушчальны, у вас самавітае прадпрыемства, аб якім прадажнікі з прыдыханнем кажуць «энтэрпрайз». Верагодна, "па спісе" вы прыкупілі дзясятак-іншы сервераў, AWS і яшчэ сёе-тое "па дробязі". Што і лагічна: у вялікай кампаніі ўвесь час адбываецца нейкі рух - адны каманды растуць, іншыя распадаюцца, трэція пераводзяць на суседнія праекты. І вось спалучэнне гэтых рухаў у сукупнасці з механізмам закупак "па спісе" у выніку прыводзяць да новых сівых валасоў пры праглядзе чарговага штомесячнага рахунку за інфраструктуру.
Так што рабіць - цярпліва сівець далей, зафарбоўваць або разабрацца ў прычынах з'яўлення гэтых шматлікіх жудасных нулёў у плацёжцы?
Што граху ўтойваць: узгадненне, ухвала і непасрэдна аплата заяўкі ўнутры кампаніі на той жа тарыф AWS - справа не заўсёды (у рэальнасці - амаль ніколі) хуткае. І якраз з-за сталага карпаратыўнага руху частка гэтых самых набыткаў можа дзесьці "страціцца". І банальна прастойваць. Калі безгаспадарную стойку ў сваёй сервернай уважлівы адмін заўважыць, то ў выпадку з хмарнымі тарыфамі ўсё нашмат сумней. Яны могуць стаяць "на прыколе" месяцамі - аплачаныя, але ў той жа час ужо нікому не патрэбныя ў аддзеле, пад які набываліся. Пры гэтым калегі з суседняга кабінета свае пакуль не пасівелыя валасы не толькі на галаве, але і ў іншых месцах пачынаюць ірваць - ім ужо энную тыдзень не могуць аплаціць прыкладна такі ж тарыф AWS, патрэбны да зарэзу.
Якое самае відавочнае рашэнне? Правільна, перадаць стырно якія жывуць у нястачы, і ўсё задаволеныя. Ды толькі гарызантальныя камунікацыі не заўсёды добра наладжаны. І другі аддзел можа проста не ведаць пра багацце першага, якому гэтае самае багацце неяк і не асоба патрэбным апынулася.
Хто ў гэтым вінаваты? - Наогул сказаць, ніхто. Так ужо пакуль усё ўладкована.
Хто ад гэтага церпіць? - Усё, уся кампанія.
Хто можа выправіць сітуацыю? - Так-так, FinOps.
FinOps - не проста праслойка паміж распрацоўшчыкамі і неабходным ім абсталяваннем, а чалавек ці каманда, якія будуць ведаць, дзе, што і наколькі добра «ляжыць» у плане тых жа хмарных тарыфаў, набытых кампаніяй. Фактычна, гэтыя людзі павінны працаваць у адной запрэжцы з DevOps, з аднаго боку, і фінансавым дэпартаментам з другога, выконваючы ролю эфектыўнага пасярэдніка і, што самае важнае – аналітыка.
Трохі аб аптымізацыі
Аблокі. Параўнальна танна і вельмі зручна. Але гэтае рашэнне перастае быць танным, калі колькасць сервераў становіцца двухзначным або трохзначным. Да таго ж, аблокі даюць магчымасць выкарыстоўваць усё больш сэрвісаў, якія раней былі недаступныя: гэта і базы дадзеных як сэрвіс (Amazon AWS, Azure Database), serverless-прыкладанні (AWS Lambda, Azure Functions) і многія іншыя. Яны ўсе вельмі крутыя тым, што простыя ў выкарыстанні - купіў і паехаў, ніякіх праблем. Вось толькі чым глыбей кампанія і яе праекты апускаюцца ў аблокі, тым горш спіць фінансавы дырэктар. І тым хутчэй сівее генеральны.
Справа ў тым, што рахункі за розныя хмарныя сэрвісы заўсёды вельмі заблытаныя: вам па адной пазіцыі можа прыйсці трохстаронкавая расшыфроўка, завошта, куды і як сышлі вашы грошы. Гэта, вядома, прыемна, але разабрацца ў ёй практычна нерэальна. Прычым наша меркаванне ў гэтым пытанні далёка не адзінае: для таго, каб пераводзіць хмарныя рахункі на чалавечы, існуюць цэлыя сэрвісы, напрыклад або . Калі хтосьці затлуміўся стварэннем асобнага сэрвісу для расшыфроўкі рахункаў, то маштаб праблемы перарос кошт фарбы для валасоў.
Такім чынам, што ў гэтай сітуацыі робіць FinOps:
- дакладна разумее, калі і ў якіх аб'ёмах былі закуплены хмарныя рашэнні.
- ведае, як гэтыя магутнасці выкарыстоўваюцца.
- пераразмяркоўвае іх, у залежнасці ад запатрабаванняў таго ці іншага падраздзялення.
- не купляе "каб было".
- і ў выніку - эканоміць вашыя грошы.
Выдатны прыклад - хмарнае захоўванне халоднай копіі БД. Вы, напрыклад, яе архівуеце для таго, каб скараціць аб'ёмы спажыванай прасторы і трафіку пры абнаўленні сховішча? Так, здавалася б, сітуацыя капейкавая - у асобным канкрэтна ўзятым выпадку, але сукупнасць такіх капейкавых сітуацый потым і выліваецца ў надмерныя выдаткі на хмарныя сэрвісы.
Або іншая сітуацыя: у вас набытыя пра запас магутнасці на AWS ці Azure, для таго каб не зваліцца пад віновай нагрузкай. Ці можна быць упэўненым, што гэтае аптымальнае рашэнне? Бо калі гэтыя інстансы прастойваюць 80%, тыя вы проста дорыце грошы Amazon. Тым больш, для такіх выпадкаў у тых жа AWS і Azure ёсць burstable інстансы - навошта вам ухаластую якія капцяць серверы, калі можна выкарыстоўваць прыладу для рашэння праблем як раз пікавых нагрузак? Або замест інстансаў On Premise варта паглядзець у бок Reserved - яны абыходзяцца нашмат танней і на іх яшчэ і зніжкі даюць.
Дарэчы, аб зніжках
Як мы казалі ў пачатку, закупамі часта займаецца хто заўгодна - крайняга знайшлі, а далей ён як-небудзь сам. Часцей за ўсё "крайнімі" становяцца людзі і так занятыя, і ў выніку мы атрымліваем сітуацыю, калі чалавек хутка і кваліфікавана, але цалкам самастойна вырашае, што і ў якіх колькасцях закупляць.
А бо пры ўзаемадзеянні з продажнікам з боку хмарнага сэрвісу можна атрымаць схаднейшыя ўмовы, калі гаворка ідзе аб аптовай закупцы магутнасцяў. Зразумела, што атрымаць такія зніжкі ў машыны пры маўклівым і аднабаковым афармленні не выйдзе але вось пагутарыўшы з рэальным мэнэджарам па продажах, можа і выгарэць. Альбо ж гэтыя хлопцы могуць падказаць, на што ў іх зараз скідкі. Таксама бывае карысна.
Пры гэтым трэба памятаць, што на AWS або Azure святло клінам не сышоўся. Вядома, няма гаворкі аб арганізацыі ўласнай сервернай - але і альтэрнатывы гэтым двум класічным рашэнням ад гігантаў ёсць.
Напрыклад, Google падвёз для кампаній платформу Firebase, на якой можна "пад ключ" размясціць той жа мабільны праект, які можа запатрабаваць хуткага маштабавання. Сховішчы, рэалтайм БД, хостынг і хмарная сінхранізацыя дадзеных на прыкладзе гэтага рашэння даступныя ў адным месцы.
З іншага боку, калі мы гаворым не аб маналітным праекце, а аб іх сукупнасці, то цэнтралізаванае рашэнне не заўсёды выгадна. Калі праект доўгажывучы, мае сваю гісторыю распрацоўкі і адпаведную колькасць неабходных да захоўвання дадзеных, то варта падумаць аб больш фрагментарным размяшчэнні.
Пры аптымізацыі выдаткаў на хмарныя сэрвісы вы раптам можаце ўсвядоміць, што для крытычна важных для бізнэсу прыкладанняў можна прыкупіць і больш магутныя тарыфы, якія забяспечаць кампаніі бесперабойны заробак. Пры гэтым «спадчына» распрацоўкі, старыя архівы, БД і іншае захоўваць у дарагіх аблоках - рашэнне такое сабе. Бо для падобных дадзеных суцэль падыдзе і стандартны дата-цэнтр са звычайнымі HDD і сярэднемагутным жалезам без якіх-небудзь "прымочак".
Тут зноў можна падумаць, што «гэтая валтузня таго не вартая», але ж уся праблематыка дадзенай публікацыі грунтуецца на тым, што на розных этапах адказныя людзі забіваюць на дробязі і робяць так, як зручней і хутчэй. Што, у выніку, праз пару гадоў выліваецца ў тыя самыя хорар-рахункі.
Што ў выніку?
Наогул аблокі - гэта крута, яны вырашаюць кучу праблем для бізнесу любога памеру. Аднак навізна гэтай з'явы прыводзіць да таго, што ў нас усё яшчэ няма культуры спажывання і кіраванні. FinOps - гэта арганізацыйны рычаг, які дапамагае больш эфектыўна карыстацца хмарнымі магутнасцямі. Галоўнае - не ператвараць гэтую пасаду ў аналаг расстрэльнай брыгады, чыёй задачай будзе злавіць няўважлівых распрацоўшчыкаў за руку і «атругаць» за прастоі магутнасцяў.
Распрацоўнікі павінны распрацоўваць, а не лічыць грошы кампаніі. І вось FinOps павінны зрабіць як працэс пакупкі, так і працэс спісання або перадачы хмарных магутнасцяў іншым камандам мерапрыемствам простым і прыемным для ўсіх бакоў.
Крыніца: habr.com