Дефинитивно сте се запрашале колку чини инфраструктурата на вашиот проект. Во исто време, изненадува: растот на трошоците не е линеарен во однос на товарите. Многу сопственици на бизниси, сервисни пумпи и програмери тајно разбираат дека преплатуваат. Но, за што точно?
Вообичаено, намалувањето на трошоците едноставно се сведува на наоѓање на најевтиното решение, план AWS или, во случај на физички лавици, оптимизирање на хардверската конфигурација. Не само тоа: всушност, секој го прави ова, како што сака Бог: ако зборуваме за стартап, тогаш ова е веројатно водечки развивач кој има многу главоболки. Во поголемите канцеларии, ова го решава CMO/CTO, а понекогаш и генералниот директор лично се вклучува во проблемот заедно со главниот сметководител. Во принцип, оние луѓе кои имаат доволно „суштински“ грижи. И излегува дека сметките за инфраструктура растат, но оние кои немаат време да се справат со тоа се справуваат со тоа.
Ако треба да купите тоалетна хартија за канцеларија, тоа ќе го направи менаџерот за снабдување или одговорно лице од компанијата за чистење. Ако зборуваме за развој - води и CTO. Продажба - сè е исто така јасно. Но, уште од старите денови, кога „серверската соба“ беше име за кабинет во кој имаше обичен систем на кула со малку повеќе RAM и неколку хард дискови во рацијата, сите (или барем многумина) го игнорираат фактот дека за купување капацитет треба да се постапува и специјално обучено лице.
За жал, историската меморија и искуството укажуваат дека со децении оваа задача беше префрлена на „случајни“ луѓе: кој беше најблиску го подигна прашањето. И само неодамна професијата FinOps почна да се обликува на пазарот и да добива одредена форма. Ова е истото специјално обучено лице чија задача е да го контролира купувањето и користењето на капацитетот. И, на крајот, во намалувањето на трошоците на компанијата во оваа област.
Ние не се залагаме за напуштање на скапи и ефективни решенија: секој бизнис мора сам да одлучи што му треба за удобно постоење во однос на хардверските и облак тарифите. Но, не може, а да не се обрне внимание на фактот дека непромисленото купување „според списокот“ без последователно следење и анализа на употребата за многу компании на крајот резултира со многу, многу значајни загуби поради неефективното управување со „средствата“ на нивната заднина.
Кој е FinOps
Да речеме дека имате реномирана компанија, за која продавачите зборуваат за „претпријатие“ со здив. Веројатно, „според списокот“ сте купиле десетина или два сервери, AWS и некои други „ситници“. Што е логично: во голема компанија постојано се случува некакво движење - некои тимови растат, други се распаѓаат, други се префрлаат на соседните проекти. А комбинацијата на овие движења, заедно со механизмот за набавки „заснован на список“, на крајот доведува до нови побелени влакна кога се гледа следната месечна сметка за инфраструктура.
Па, што да правиме - трпеливо да продолжите да сивилото, да го обоите или да ги откриете причините за појавата на овие бројни страшни нули во плаќањето?
Да бидеме искрени: одобрувањето, одобрувањето и директното плаќање на апликација во компанијата за истата тарифа AWS не е секогаш (во реалноста, речиси никогаш) брзо. И токму поради постојаното корпоративно движење, некои од истите тие аквизиции може некаде да се „изгубат“. И тривијално е да останеш без работа. Ако внимателен администратор забележи багажник без сопственик во неговата серверска соба, тогаш во случај на тарифи за облак сè е многу потажно. Тие можат да се чуваат со месеци - платени, но во исто време веќе не му се потребни на никого во одделот за кој се купени. Во исто време, колегите од следната канцеларија почнуваат да ја кинат својата сè уште неседа коса не само на главите, туку и на други места - тие не можеа да платат приближно иста тарифа AWS за XNUMX-тата недела, што е очајно потребен.
Кое е најочигледното решение? Така е, предадете ги уздите на оние на кои им треба, и сите се среќни. Но, хоризонталните комуникации не се секогаш добро воспоставени. И вториот оддел можеби едноставно не знае за богатството на првиот, кој некако се покажа дека навистина не му треба ова богатство.
Кој е виновен за ова? - Всушност, никој. Така е сè наместено засега.
Кој страда од ова? - Тоа е тоа, целата компанија.
Кој може да ја поправи ситуацијата? - Да, да, FinOps.
FinOps не е само слој помеѓу програмерите и опремата што им е потребна, туку личност или тим кој ќе знае каде, што и колку добро „лежи“ во однос на истите тарифи за облак купени од компанијата. Всушност, овие луѓе мора да работат во тандем со DevOps, од една страна, и одделот за финансии од друга страна, играјќи ја улогата на ефективен посредник и, што е најважно, аналитичар.
Малку за оптимизација
Облаци. Релативно евтин и многу удобен. Но, ова решение престанува да биде евтино кога бројот на сервери ќе достигне двоцифрена или троцифрена. Покрај тоа, облаците овозможуваат користење на сè повеќе услуги кои претходно биле недостапни: тоа се бази на податоци како услуга (Amazon AWS, база на податоци Azure), апликации без сервер (AWS Lambda, Azure Functions) и многу други. Сите тие се многу кул бидејќи се лесни за употреба - купете и одете, без проблеми. Но, колку подлабоко компанијата и нејзините проекти се фрлаат во облаците, толку полошо спие финансискиот директор. И колку побрзо генералот станува сив.
Факт е дека фактурите за различни облак услуги се секогаш крајно збунувачки: за една ставка може да добиете објаснување на три страници за тоа што, каде и како оделе вашите пари. Ова, се разбира, е пријатно, но речиси е невозможно да се разбере. Покрај тоа, нашето мислење за ова прашање е далеку од единственото: за да се префрлат сметки во облак на човечки, постојат цели услуги, на пример или . Ако некој се мачеше да создаде посебна услуга за дешифрирање сметки, тогаш обемот на проблемот ги надмина трошоците за бојадисување на косата.
Значи, што прави FinOps во оваа ситуација:
- јасно разбира кога и во кои количини се купени облак решенијата.
- знае како се користат овие капацитети.
- ги прераспределува во зависност од потребите на одредена единица.
- не купува „така да биде“.
- и на крајот, тоа ви заштедува пари.
Одличен пример е облак складирање на ладна копија од база на податоци. На пример, дали го архивирате за да го намалите количеството простор и сообраќај потрошени при ажурирање на складиштето? Да, се чини дека ситуацијата е евтина - во еден специфичен случај, но севкупноста на таквите евтини ситуации подоцна резултира со високи трошоци за облак услугите.
Или друга ситуација: купивте резервен капацитет на AWS или Azure за да не паднете под максимално оптоварување. Дали можете да бидете сигурни дека ова е оптималното решение? На крајот на краиштата, ако овие случаи се неактивен 80%, тогаш едноставно давате пари на Амазон. Покрај тоа, за такви случаи, истите AWS и Azure имаат пукнати примери - зошто ви се потребни сервери во мирување, ако можете да користите алатка за решавање на проблеми со врвни оптоварувања? Или, наместо примерите на On Premise, треба да погледнете кон Резервирано - тие се многу поевтини и нудат и попусти.
Патем, за попусти
Како што кажавме на почетокот, набавката често ја врши кој било - го нашле последниот, а потоа некако сам го прави тоа. Најчесто, луѓето кои се веќе зафатени стануваат „екстремни“ и како резултат на тоа добиваме ситуација кога човекот брзо и вешто, но целосно независно одлучува што и во какви количини да купи.
Но, при интеракција со продавач од услугата облак, можете да добиете поповолни услови кога станува збор за големо купување на капацитет. Јасно е дека нема да можете да добиете такви попусти од автомобил со тивка и еднострана регистрација - но откако ќе разговарате со вистински менаџер за продажба, може да изгорите. Или овие момци можат да ви кажат на што моментално имаат попусти. Може да биде и корисно.
Во исто време, треба да запомните дека светлината не се спојува како клин на AWS или Azure. Се разбира, не станува збор за организирање на сопствена серверска соба - но има алтернативи за овие две класични решенија од гигантите.
На пример, Google ја донесе платформата Firebase на компаниите, на кои тие можат да го хостираат истиот мобилен проект клуч на рака, што може да бара брзо скалирање. Складирање, база на податоци во реално време, хостирање и синхронизација на податоци во облак користејќи го ова решение како пример се достапни на едно место.
Од друга страна, ако не зборуваме за монолитен проект, туку за нивна севкупност, тогаш централизираното решение не е секогаш корисно. Ако проектот е долготраен, има своја развојна историја и соодветна количина на податоци потребни за складирање, тогаш вреди да се размислува за пофрагментирана поставеност.
Кога ги оптимизирате трошоците за облак услугите, одеднаш може да сфатите дека за бизнис-критични апликации можете да купите помоќни тарифи кои ќе ѝ обезбедат на компанијата непречена заработка. Во исто време, чувањето на „наследството“ на развојот, старите архиви, бази на податоци итн. во скапи облаци е решение. На крајот на краиштата, за такви податоци, стандарден центар за податоци со редовни HDD и хардвер со средна моќност без никакви ѕвона и свирки е сосема соодветен.
Овде повторно, можеби мислите дека „оваа гужва не вреди“, но целиот проблем на оваа публикација се заснова на фактот дека во различни фази одговорните луѓе ги занемаруваат малите нешта и го прават она што е поудобно и побрзо. Што, на крајот, по неколку години резултира со токму тие хорор сметки.
Резултатот?
Во принцип, облаците се кул, решаваат многу проблеми за бизниси од која било големина. Но, новоста на оваа појава значи дека сè уште немаме култура на потрошувачка и управување. FinOps е организациски лост што ви помага поефикасно да ја искористите моќта на облакот. Главната работа не е да се претвори оваа позиција во аналог на стрелачки одред, чија задача ќе биде да ги фати невнимателните програмери за рака и да ги „кара“ за застој.
Програмерите треба да се развиваат, а не да ги бројат парите на компанијата. И така, FinOps треба да ги направи и процесот на купување и процесот на деактивирање или пренесување на капацитетот на облакот на други тимови, настан едноставен и пријатен за сите страни.
Извор: www.habr.com