Определено, вие сте се питали колко струва инфраструктурата на вашия проект. Изненадващо е, че растежът на разходите не е линеен спрямо натоварванията. Мнозина собственици на бизнес, CTO и разработчици интуитивно разбират, че плащат прекалено много. Но за какво конкретно?
Обикновено съкращаването на разходите се свежда просто до търсене на най-евтиното решение, тарифата на AWS или, ако говорим за физически стелажи, оптимизация на конфигурацията на оборудването. Освен това: всъщност, това е работа на всеки, който му е удобно: ако говорим за стартъп, вероятно това е водещият разработчик, който има доста проблеми. В по-големите компании с това се занимават CMO/CTO, понякога лично генералният директор заедно с главния счетоводител. Общо взето, това са хора, които имат и
Ако в офиса трябва да се купи тоалетна хартия, с това ще се занимава завеждащият или отговорното лице от фирмата за почистване. Ако става дума за разработка — лидерите и CTO. Продажбите — също е ясно. Но още от отдавна, когато „сървърната“ означаваше шкаф, в който стоеше обикновен tower системник с малко повече оперативна памет и няколко харддиска в RAID, всички (или поне много) игнорират факта, че за закупуването на мощности трябва да се занимава и специално обучен човек.
Уви, историческата памет и опитът показват, че тази задача десетилетия наред е била прехвърляна на „случайни“ хора: кой беше по-близо, той пое въпроса. И едва наскоро на пазара започна да се оформя и приема конкретни очертания професията 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
