Определено сте се чудили колко струва инфраструктурата на вашия проект. В същото време е изненадващо: нарастването на разходите не е линейно по отношение на натоварванията. Много собственици на фирми, сервизи и разработчици тайно разбират, че плащат повече. Но за какво точно?
Обикновено намаляването на разходите просто се свежда до намирането на най-евтиното решение, AWS план или, в случай на физически стелажи, оптимизиране на хардуерната конфигурация. Не само това: всъщност всеки прави това, както Бог иска: ако говорим за стартиране, тогава това вероятно е водещ разработчик, който има много главоболия. В по-големите офиси това се решава от CMO/CTO; понякога генералният директор се намесва лично в проблема заедно с главния счетоводител. Като цяло, тези хора, които имат достатъчно „основни“ грижи. И се оказва, че сметките за инфраструктура растат, но тези, които нямат време да се занимават с това, се занимават с това.
При нужда от закупуване на тоалетна хартия за офиса, това ще бъде направено от мениджър доставки или отговорно лице от фирмата за почистване. Ако говорим за развитие - лидери и CTO. Продажби - всичко също е ясно. Но от старите времена, когато „сървърна стая“ беше име за шкаф, в който имаше обикновена кула система с малко повече RAM и няколко твърди диска в рейда, всички (или поне много) игнорират Факт е, че закупуването на капацитет трябва да се извършва и от специално обучено лице.
Уви, историческата памет и опит показват, че в продължение на десетилетия тази задача е била прехвърляна на „случайни“ хора: който е бил най-близо, е подхващал въпроса. И едва наскоро професията FinOps започна да се оформя на пазара и да придобива някаква конкретна форма. Това е същият специално обучен човек, чиято задача е да контролира закупуването и използването на капацитет. И в крайна сметка в намаляването на разходите на компанията в тази област.
Ние не се застъпваме за изоставяне на скъпи и ефективни решения: всеки бизнес трябва сам да реши от какво се нуждае за комфортно съществуване по отношение на хардуерни и облачни тарифи. Но не може да не се обърне внимание на факта, че необмисленото закупуване „според списъка“ без последващ мониторинг и анализ на употребата за много компании в крайна сметка води до много, много значителни загуби поради неефективно управление на „активите“ на техния бекенд.
Кой е FinOps
Да приемем, че имате реномирано предприятие, за което хората по продажбите говорят за „предприятие“ с придишен тон. Вероятно „според списъка“ сте закупили дузина или две сървъри, AWS и някои други „дреболии“. Което е логично: в голяма компания постоянно се случва някакво движение - едни екипи растат, други се разпадат, трети се прехвърлят в съседни проекти. И комбинацията от тези движения, заедно с механизма за обществени поръчки „базиран на списък“, в крайна сметка води до нови бели коси, когато се гледа следващата месечна сметка за инфраструктура.
И така, какво да направите - търпеливо да продължите да сивеете, да го рисувате или да разберете причините за появата на тези многобройни ужасни нули в плащането?
Нека бъдем честни: одобрението, одобрението и директното плащане на приложение в рамките на компанията за една и съща тарифа на AWS не винаги (в действителност почти никога) е бързо. И точно поради постоянното корпоративно движение някои от същите тези придобивания може да се „загубят“ някъде. И е тривиално да стоиш без работа. Ако внимателен администратор забележи стелаж без собственик в сървърната си стая, тогава в случай на облачни тарифи всичко е много по-тъжно. Те могат да стоят с месеци - платени, но в същото време вече не са необходими на никого в отдела, за който са закупени. В същото време колегите от съседния офис започват да скубят още непобелелите си коси не само на главите си, но и на други места - те не могат да платят приблизително същата тарифа на AWS за n-та седмица, която е отчаяно необходим.
Кое е най-очевидното решение? Точно така, предайте юздите на нуждаещите се и всички са доволни. Но хоризонталните комуникации не винаги са добре установени. А вторият отдел може просто да не знае за богатството на първия, който някак си се оказа, че всъщност не се нуждае от това богатство.
Кой е виновен за това? - Всъщност никой. Така е настроено всичко за сега.
Кой страда от това? - Това е, цялата компания.
Кой може да оправи ситуацията? - Да, да, 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 на компаниите, на която те могат да хостват един и същ мобилен проект до ключ, което може да изисква бързо мащабиране. Съхранение, база данни в реално време, хостинг и синхронизиране на данни в облак, като се използва това решение като пример, са налични на едно място.
От друга страна, ако не говорим за монолитен проект, а за тяхната съвкупност, тогава централизирано решение не винаги е изгодно. Ако проектът е дълготраен, има собствена история на развитие и съответно количество данни, необходими за съхранение, тогава си струва да помислите за по-фрагментирано разположение.
Когато оптимизирате разходите за облачни услуги, може внезапно да осъзнаете, че за критични за бизнеса приложения можете да закупите по-мощни тарифи, които ще осигурят на компанията непрекъснати печалби. В същото време съхраняването на „наследството“ от разработки, стари архиви, бази данни и т.н. в скъпи облаци е решение. В крайна сметка за такива данни е напълно подходящ стандартен център за данни с обикновени твърди дискове и хардуер със средна мощност без никакви звънци и свирки.
Тук отново може да си помислите, че „тази врява не си струва“, но целият проблем на тази публикация се основава на факта, че на различни етапи отговорните хора пренебрегват малките неща и правят това, което е по-удобно и по-бързо. Което в крайна сметка след няколко години води до тези ужасяващи разкази.
Какъв е резултатът?
Като цяло облаците са готини, те решават много проблеми за бизнеси от всякакъв мащаб. Новостта на това явление обаче означава, че все още нямаме култура на потребление и управление. FinOps е организационен лост, който ви помага да използвате по-ефективно силата на облака. Основното нещо е да не превърнете тази позиция в аналог на разстрел, чиято задача ще бъде да хване невнимателните разработчици за ръката и да ги „скара“ за престой.
Разработчиците трябва да се развиват, а не да броят фирмените пари. И така FinOps трябва да направи както процеса на закупуване, така и процеса на извеждане от експлоатация или прехвърляне на облачен капацитет към други екипи събитие, просто и приятно за всички страни.
Източник: www.habr.com