Определено, вие сте се чудили колко струва инфраструктурата на вашия проект. Учудващо е, че растежът на разходите не е линеен спрямо натоварванията. Много собственици на бизнес, CTO и разработчици подсъзнателно разбират, че плащат прекалено много. Но за какво точно?
Обикновено намалението на разходите се свежда до търсене на най-евтиното решение, тарифата на AWS или, що се отнася до физическите стелажи, оптимизация на конфигурацията на оборудването. Освен това: всъщност, с това се занимава всеки, който се сети: ако говорим за стартап, това вероятно е водещият разработчик, който има достатъчно проблеми. В по-големите компании с това се занимава CMO/CTO, понякога лично генералният директор заедно с главния счетоводител. В общи линии, тези хора имат достатъчно „професионални“ ангажименти. И така, сметките за инфраструктура растат, но с това се заемат... тези, за които няма време да се занимават.
Ако в офиса трябва да се купи тоалетна хартия, с това ще се занимае завхозът или отговорният човек от почистващата компания. Ако става въпрос за разработка — лидери и CTO. Продажби — също е ясно. Но още от бородатите времена, когато „сървърна“ наричаха шкафа, в който стоеше обикновен tower-системник с малко повече RAM и няколко хард диска в RAID, всички (или поне много) игнорират факта, че закупуването на мощности също трябва да бъде възложено на специално обучен човек.
Уви, историческата памет и опитът показват, че тази задача десетилетия наред е била прехвърляна на „случайни“ хора: който е бил най-близо, той е поемал въпроса. И едва наскоро на пазара започна да се оформя и приемат конкретни очертания професията FinOps. Именно това е специално обучен човек, чиято задача е да контролира покупката и използването на мощности. И в крайна сметка, да намали разходите на компанията в това направление.
Не призываем отказываться от дорогих и эффективных решений: каждое предприятие должно самостоятельно решать, что ему нужно для комфортной работы в сфере серверов и облачных тарифов. Однако нельзя не обратить внимание на тот факт, что бездумная закупка «по списку» без последующего контроля и анализа использования для многих компаний оборачивается значительными убытками из-за неэффективного управления своими «активами» в бэкэнде.
Кой е FinOps
Да предположим, че вашето предприятие е внушително и търговците дълго говорят за него като за „ентерпрайз“. Вероятно, „по списък“ сте закупили десетина-два сървъра, AWS и няколко неща „по дребно“. И това е логично: в голямата компания постоянно се случва нещо — едни екипи растат, други се разпадат, трети се местят на съседни проекти. И ето, съчетанието на тези движения, в комбинация с механизма за поръчки „по списък“, в крайна сметка води до нови белези на стрес при прегледа на поредната месечна сметка за инфраструктура.
Какво да правим — да чакаме търпеливо, да боядисваме или да разберем причините за появата на тези ужасни нули в сметката?
Какво да крия: одобрението, приемането и самото плащане на заявка вътре в компанията за същия тариф Amazon AWS не е винаги (в реалността — почти никога) бързо. И точно поради постоянните корпоративни движения част от тези покупки може да се „изгубят“ някъде. И просто да стоят без работа. Ако внимателният администратор забележи изоставена ракла в сървърната стая, то при облачните тарифи всичко е много тъжно. Те могат да стоят „на завет“ с месеци — платени, но вече ненужни на отдела, за който са закупени. В същето време, колегите от съседния кабинет, които все още не са оплешивели, започват да се ядосват — вече седмица не могат да платят подобен тариф на AWS, който им е крайно необходим.
Какво е най-очевидното решение? Правилно, да предадем браздите на нуждаещите се, и всички са доволни. Но хоризонталните комуникации не винаги са добре настроени. И вторият отдел просто може да не знае за богатството на първия, което на всичкото отгоре не изглежда да е необходимо.
Кой е виновен? — Всъщност, никой. Просто так е подредено.
Кой страда от това? — Всички, цялата компания.
FinOps не е просто посредник между разработчиците и нужните ресурси, а човек или екип, който знае къде, какво и в какъв обем „лъжи“ в контекста на облачните тарифи, закупени от компанията. Всъщност, тези хора трябва да работят в тясно сътрудничество с DevOps от една страна, и с финансовия отдел от друга, изпълнявайки ролята на ефективен посредник и, най-важното — анализатор.
Няколко думи за оптимизацията
Облаци. Сравнително евтино и много удобно. Но това решение спира да бъде икономично, когато броят на сървърите стане двуцифрен или трицифрен. Освен това, облаците предоставят възможност за използване на все повече услуги, които по-рано не бяха достъпни: бази данни като услуга (Amazon AWS, Azure Database), безсървърни приложения (AWS Lambda, Azure Functions) и много други. Всички те са страхотни, защото са лесни за използване — купуваш и започваш, без проблеми. Само че, колкото по-дълбоко компанията и проектите ѝ навлизат в облаците, толкова по-трудно спи финансовият директор. И толкова по-бързо побелява главния изпълнителен директор.
Факт е, че сметките за различни облачни услуги винаги са изключително заплетени: за една позиция може да дойде трислойно уточнение, за което, къде и как са отишли вашите пари. Това, разбира се, е приятно, но да се разбереш в нея е почти невъзможно. И нашето мнение по този въпрос далеч не е единственото: за да се преведат облачните сметки на разбираем език, съществуват цели услуги, например
www.cloudyn.com или И така, какво прави FinOps в тази ситуация:
ясно разбира кога и в какви обеми са закупени облачни решения.
- знае как се използват тези мощности.
- преразпределя ги в зависимост от нуждите на конкретните отдели.
- не купува „за всеки случай“.
- и в крайна сметка — спестява вашите пари.
- и в итоге — экономит ваши деньги.
Отличен пример — облачно хранене на студена копия на БД. Например, архивирате я, за да намалите обема на потребленото пространство и трафика при актуализиране на хранилището? Да, изглежда, че ситуацията е малка — в конкретния случай, но общото натрупване на такива малки ситуации впоследствие води до непропорционални разходи за облачни услуги.
Или друга ситуация: имате резервни мощности закупени в AWS или Azure, за да не паднете под пикова натовареност. Можете ли да сте сигурни, че това е оптимално решение? Все пак, ако тези инстанции са бездействащи 80% от времето, вие просто подарявате пари на Amazon. Още повече, за подобни случаи AWS и Azure предлагат burstable инстанции — защо да имате бездействуващи сървъри, когато можете да използвате инструмент, който да решава проблемите точно в моменти на пикова натовареност? Или вместо On Premise инстанции, може да помислите за Reserved — те са много по-евтини и предлагат отстъпки.
Между другото, за отстъпки
Както споменахме в началото, покупките често се извършват от когото и да е — намираме крайния, а след това той ще се справи сам. Най-често "крайни" стават хора, които вече са заети, и в крайна сметка получаваме ситуация, при която човек бързо и квалифицирано, но напълно сам решава какво и в какви количества да закупи.
Важното е, че при взаимодействие с търговец от страна на облачната услуга можете да получите по-изгодни условия, ако става дума за оптови покупки на мощности. Ясно е, че няма как да извлечете такива отстъпки от машина при мълчаливо и едностранно оформление — но като поговорите с истински мениджър по продажбите, може да постигнете успех. Или тези хора могат да ви подскажат за какво в момента имат отстъпки. Това също е полезно.
Трябва да помните, че AWS или Azure не са единствените опции. Разбира се, не става въпрос за организиране на собствен сървър — но съществуват и алтернативи на тези две класически решения от гигантите.
Например, Google предлага за компании платформата Firebase, където можете "на ключ" да разположите същия мобилен проект, който може да изисква бързо мащабиране. Хранилища, реалтайм БД, хостинг и облачна синхронизация на данни с този пример са на разположение на едно място.
От друга страна, ако говорим не за монолитен проект, а за тяхната съвкупност, централизираното решение не винаги е изгодно. Ако проектът е дългосрочен, има своя собствена история на разработка и съответното количество данни, които трябва да се съхраняват, си струва да се помисли за по-фрагментирано разполагане.
При оптимизация на разходите за облачни услуги можете внезапно да осъзнаете, че за критично важни бизнес приложения може да се закупят и по-мощни тарифи, които да осигурят безпроблемен доход за компанията. В същото време съхраняването на "наследството" на разработки, стари архиви, бази данни и подобни в скъпи облаци е доста съмнително решение. За такива данни съвсем спокойно може да се ползва стандартен дата център с обикновени HDD и средно мощен хардуер без никакви "прищевки".
Тук отново може да се помисли, че "тези занимания не струват", но проблематиката, разгледана в тази публикация, се основава на факта, че на различни етапи отговорните лица пренебрегват подробности и действат по-удобно и бързо. В крайна сметка, след няколко години това довежда до онези ужасни сметки.
Какво в крайна сметка?
Всъщност облаците са страхотни, те решават множество проблеми за бизнес от всякакъв размер. Въпреки това, новизната на това явление води до факта, че все още нямаме култура на потребление и управление. FinOps е организационен механизъм, който помага за по-ефективно използване на облачните ресурси. Основното е да не се превръща тази позиция в подобие на разстрелна бригада, чиято задача е да хваща невнимателните разработчици и да ги "наказва" за простои на ресурсите.
Разработчиците трябва да разработват, а не да смятат парите на компанията. FinOps трябва да направи както процеса на покупка, така и процеса на списване или предаване на облачни ресурси на други екипи прост и приятен за всички участници.
Източник: habr.com
