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