ITsumma
34

FinOps: как сэкономить на инфраструктуре?

В закладки

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

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

Исходная ситуация

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

Обычно сокращение расходов сводится просто к поиску наиболее дешевого решения, тарифа AWS или, если мы говорим о физических стойках, оптимизации конфигурации оборудования. Загвоздка в том, что зачастую этим занимается кто угодно — как бог на душу положит: если мы говорим о стартапе, то это, вероятно, ведущий девелопер, у которого хватает головняков. В конторах покрупнее этим занимается CMO/CTO, а временами в вопрос влезает лично генеральный директор на пару с главбухом. В общем, как раз те люди, у которых и “профильных” забот хватает. И получается, что счета за инфраструктуру растут, но разбираются с этим… те, у кого нет времени с этим разбираться.

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

Кто такой FinOps

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

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

  • Кто в этом виноват? — Вообще сказать, никто. Так уж пока всё устроено.

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

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

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

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

Что в этой ситуации делает FinOps:

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

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

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

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

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

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

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

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

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

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

Резюмируя

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

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

А уж вводить эту должность в штатное расписание или отдать на аутсорс профессионалам — вам решать.

{ "author_name": "ITsumma", "author_type": "editor", "tags": [], "comments": 0, "likes": 1, "favorites": 0, "is_advertisement": false, "subsite_label": "itsumma", "id": 73706, "is_wide": false, "is_ugc": false, "date": "Tue, 02 Jul 2019 12:41:52 +0300", "is_special": false }
0
{ "id": 73706, "author_id": 199364, "diff_limit": 1000, "urls": {"diff":"\/comments\/73706\/get","add":"\/comments\/73706\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/73706"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199364, "last_count_and_date": null }
Комментариев нет
Популярные
По порядку
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ] { "page_type": "default" }