Хабрахабр

Сколько вы тратите на инфраструктуру? И как на этом сэкономить?

При этом удивительно: рост расходов не линеен относительно нагрузок. Определенно, вы задавались вопросом, во сколько обходится инфраструктура вашего проекта. Но за что конкретно? Многие владельцы бизнеса, СТО и разработчики подспудно понимают, что переплачивают.

Мало того: фактически, этим занимается кто угодно, как бог на душу положит: если мы говорим о стартапе, то это, вероятно, ведущий девелопер, у которого хватает головняков. Обычно сокращение расходов сводится просто к поиску наиболее дешевого решения, тарифа AWS или, если мы говорим о физических стойках, оптимизации конфигурации оборудования. В общем, те люди, у которых и «профильных» забот хватает. В конторах покрупнее этим занимается CMO/CTO, временами в вопрос влезает лично генеральный директор на пару с главбухом. Если речь о разработке — лиды и CTO. И получается, что счета за инфраструктуру растут, но разбираются с этим… те, у кого нет времени с этим разбираться.
Если в офис надо купить туалетную бумагу, этим займется завхоз либо ответственный человек из клининговой компании. Но ещё с бородатых времен, когда «серверной» называли шкаф, в котором стоял обычный tower-системник с чуть большим количеством оперативной памяти и парой хардов в рейде, все (или, как минимум, многие) игнорируют тот факт, что закупками мощностей должен заниматься тоже специально обученный человек. Продажи — тоже всё понятно.

И лишь недавно на рынке стала оформляться и принимать кое-какие конкретные очертания профессия FinOps. Увы, историческая память и опыт говорят о том, что эта задача десятилетиями перекладывалась на людей «случайных»: кто был ближе, тот и подхватил вопрос. И, в конечном итоге, в снижении расходов компании по этому направлению. Это тот самый специально обученный человек, чья задача состоит в контроле за покупкой и использованием мощностей.

Но нельзя не обратить внимание на тот факт, что бездумная закупка «по списку» без последующего контроля и анализа использования для многих компаний в итоге выливается в очень и очень солидные убытки из-за неэффективного управления «активами» своего бэкэнда. Мы не агитируем отказаться от дорогих и эффективных решений: каждый бизнес должен сам решать, что ему нужно для комфортного существования в плане железа и облачных тарифов.

Кто такой FinOps

Допустим, у вас солидное предприятие, о котором продажники с придыханием говорят «энтерпрайз». Вероятно, «по списку» вы прикупили десяток-другой серверов, AWS и ещё кое-что “по мелочи”. Что и логично: в большой компании постоянно происходит какое-то движение — одни команды растут, другие распадаются, третьи переводят на соседние проекты. И вот сочетание этих движений в совокупности с механизмом закупок “по списку” в итоге приводят к новым седым волосам при просмотре очередного ежемесячного счёта за инфраструктуру.

Так что делать — терпеливо седеть дальше, закрашивать или разобраться в причинах появления этих многочисленных ужасных нулей в платёжке?

И как раз из-за постоянного корпоративного движения часть этих самых приобретений может где-то «потеряться». Что греха таить: согласование, одобрение и непосредственно оплата заявки внутри компании на тот же тариф AWS — дело не всегда (в реальности — почти никогда) быстрое. Если бесхозную стойку в своей серверной внимательный админ заметит, то в случае с облачными тарифами все намного печальнее. И банально простаивать. При этом коллеги из соседнего кабинета свои пока не поседевшие волосы не только на голове, но и в прочих местах начинают рвать — им уже энную неделю не могут оплатить примерно такой же тариф AWS, нужный позарез. Они могут стоять «на приколе» месяцами — оплаченные, но в то же время уже никому не нужные в отделе, под который приобретались.

Правильно, передать бразды нуждающимся, и все довольны. Какое самое очевидное решение? И второй отдел может просто не знать о богатстве первого, которому это самое богатство как-то и не особо нужным оказалось. Да только горизонтальные коммуникации не всегда хорошо налажены.

— Вообще сказать, никто. Кто в этом виноват? — Все, вся компания.
Кто может исправить ситуацию? Так уж пока всё устроено.
Кто от этого страдает? — Да-да, FinOps.

Фактически, эти люди должны работать в одной упряжке с DevOps, с одной стороны, и финансовым департаментом с другой, выполняя роль эффективного посредника и, что самое важное — аналитика. FinOps — не просто прослойка между разработчиками и необходимым им оборудованием, а человек или команда, которые будут знать, где, что и насколько хорошо «лежит» в плане тех же облачных тарифов, купленных компанией.

Немного об оптимизации

Облака. Сравнительно дешево и очень удобно. Но это решение перестает быть дешевым, когда количество серверов становится двузначным или трехзначным. К тому же, облака дают возможность использовать всё больше сервисов, которые ранее были недоступны: это и базы данных как сервис (Amazon AWS, Azure Database), serverless-приложения (AWS Lambda, Azure Functions) и многие другие. Они все очень круты тем, что просты в использовании — купил и поехал, никаких проблем. Вот только чем глубже компания и ее проекты погружаются в облака, тем хуже спит финансовый директор. И тем быстрее седеет генеральный.

Это, конечно, приятно, но разобраться в ней практически нереально. Дело в том, что счета за различные облачные сервисы всегда крайне запутаны: вам по одной позиции может прийти трёхстраничная расшифровка, за что, куда и как ушли ваши деньги. Если кто-то заморочился созданием отдельного сервиса для расшифровки счетов, то масштаб проблемы перерос стоимость краски для волос. Причем наше мнение в этом вопросе далеко не единственное: для того, чтобы переводить облачные счета на человеческий, существуют целые сервисы, например www.cloudyn.com или www.cloudability.com.

Итак, что в этой ситуации делает FinOps:

  • четко понимает, когда и в каких объемах были закуплены облачные решения.
  • знает, как эти мощности используются.
  • перераспределяет их, в зависимости от потребностей того или иного подразделения.
  • не покупает «чтоб было».
  • и в итоге — экономит ваши деньги.

Отличный пример — облачное хранение холодной копии БД. Вы, например, её архивируете для того, чтобы сократить объемы потребляемого пространства и трафика при обновлении хранилища? Да, казалось бы, ситуация копеечная — в отдельном конкретно взятом случае, но совокупность таких копеечных ситуаций потом и выливается в непомерные расходы на облачные сервисы.

Можно ли быть уверенным, что это оптимальное решение? Или другая ситуация: у вас куплены про запас мощности на AWS или Azure, для того чтобы не упасть под пиковой нагрузкой. Тем более, для таких случаев у тех же AWS и Azure есть burstable инстансы — зачем вам вхолостую коптящие серверы, если можно использовать инструмент для решения проблем как раз пиковых нагрузок? Ведь если эти инстансы простаивают 80%, то вы просто дарите деньги Amazon. Или вместо инстансов On Premise стоит посмотреть в сторону Reserved — они обходятся намного дешевле и на них еще и скидки дают.

Кстати, о скидках

Чаще всего «крайними» становятся люди и так занятые, и в итоге мы получаем ситуацию, когда человек быстро и квалифицированно, но полностью самостоятельно решает, что и в каких количествах закупать. Как мы говорили в начале, закупками часто занимается кто угодно — крайнего нашли, а дальше он как-нибудь сам.

Понятно, что получить такие скидки у машины при молчаливом и одностороннем оформлении не выйдет — но вот пообщавшись с реальным менеджером по продажам, может и выгореть. А ведь при взаимодействии с продажником со стороны облачного сервиса можно получить более выгодные условия, если речь идет об оптовой закупке мощностей. Тоже бывает полезно. Либо же эти ребята могут подсказать, на что у них сейчас скидки.

Конечно, нет речи об организации собственной серверной — но и альтернативы этим двум классическим решениям от гигантов есть. При этом нужно помнить, что на AWS или Azure свет клином не сошелся.

Хранилища, реалтайм БД, хостинг и облачная синхронизация данных на примере этого решения доступны в одном месте. Например, Google подвез для компаний платформу Firebase, на которой можно «под ключ» разместить тот же мобильный проект, могущий потребовать быстрого масштабирования.

Если проект долгоживущий, имеет свою историю разработки и соответствующее количество необходимых к хранению данных, то стоит подумать о более фрагментарном размещении. С другой стороны, если мы говорим не о монолитном проекте, а об их совокупности, то централизованное решение не всегда выгодно.

При этом «наследие» разработки, старые архивы, БД и прочее хранить в дорогостоящих облаках — решение такое себе. При оптимизации расходов на облачные сервисы вы внезапно можете осознать, что для критически важных для бизнеса приложений можно прикупить и более мощные тарифы, которые обеспечат компании бесперебойный заработок. Ведь для подобных данных вполне подойдет и стандартный дата-центр с обычными HDD и среднемощным железом без каких-либо «примочек».

Что, в итоге, через пару лет выливается в те самые хоррор-счета. Тут опять можно подумать, что «эта возня того не стоит», но ведь вся проблематика данной публикации основывается на том, что на различных этапах ответственные люди забивают на мелочи и делают так, как удобнее и быстрее.

Что в итоге?

Вообще облака — это круто, они решают кучу проблем для бизнеса любого размера. Однако новизна этого явления приводит к тому, что у нас все еще нет культуры потребления и управления. FinOps — это организационный рычаг, который помогает эффективнее пользоваться облачными мощностями. Главное — не превращать эту должность в аналог расстрельной бригады, чьей задачей будет поймать невнимательных разработчиков за руку и «отругать» за простои мощностей.

И вот FinOps должны сделать как процесс покупки, так и процесс списания или передачи облачных мощностей другим командам мероприятием простым и приятным для всех сторон. Разработчики должны разрабатывать, а не считать деньги компании.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть