Оглавление:
— Практика FinOps и ITFM: как считать, распределять и планировать ИТ-расходы (часть 1 из 5)
— Как считать стоимость CPU, RAM и Storage во внутренней инфраструктуре (часть 2 из 5)
— Как учитывать стоимость ИТ-ресурсов и аллоцировать затраты по P&L-центрам (часть 3 из 5)
— Как прогнозировать потребление ресурсов и планировать ИТ-бюджет (часть 4 из 5)— Оптимизация потребления ресурсов: где теряются мощности и как внедрять FinOps без боли (часть 5 из 5)
Меня зовут Дмитрий, я руковожу отделом ИТ-инфраструктуры и сервисов в Ви.Tech, IT-дочке ВсеИнструменты.ру. В прошлой части я подробно разбирал ценообразование вычислительных ресурсов, а теперь давайте соберем все это в единую модель учета и посмотрим, как она помогает не просто считать цифры, а принимать вполне прикладные решения.
Ниже пройдемся по основным блокам, из которых этот учет складывается.
1. Отдельно стоящее оборудование
Поскольку мы планируем учитывать расходы за месяц, то стоимость покупки оборудования нам также надо привести к месячным затратам. Для этого воспользуемся амортизацией, а именно определим ее срок и тип и посчитаем ежемесячную стоимость, исходя из этого. Для примера возьмем линейную амортизацию сроком на 5 лет (60 месяцев), тогда ежемесячная стоимость отдельно стоящего оборудования будет:
HW_month_price = HW_price / 60
При этом:
Стоимость оборудования, купленного под конкретный P&L-центр, аллоцируем на него же
Стоимость коммунального оборудования равномерно распределяем по всем P&L-центрам
2. Ресурсы ЦОД (Colocation)
Тут у нас уже учтены месячные затраты по договору. Нам останется:
- Определить стоимость юнита, исходя из общего количества.
При этом:
Затраты на размещение отдельно стоящего оборудования распределяются пропорционально занимаемым юнитам по конкретным P&L-центрам
Затраты на размещение кластеров виртуализации и контейнеризации распределяются исходя из процентного соотношения их утилизации
Затраты на размещение коммунального оборудования и свободных юнитов равномерно распределяются по всем P&L-центрам
3. ИТ-ресурсы в частных и публичных облаках
Для публичных облаков все относительно просто: берем тарифы провайдера по договору и дальше считаем фактическое потребление.
Для внутренних систем виртуализации сначала надо сформировать внутренние ценники на ресурсы. О том, как это сделать, я подробно писал во второй части.
После этого остается присвоить виртуальным машинам бюджетные тэги, соответствующие P&L-центрам. Тогда мы сможем забирать данные с гипервизоров и от облачных провайдеров, сопоставлять их с этими метками и уже на этой основе аллоцировать затраты.
4. ИТ-ресурсы в контейнерах
С контейнерами схему придется немного дополнить. Хосты, которые используются как общая платформа для K8s, помечаем коммунальным тэгом и исключаем из общего расчета ресурсов виртуализации. А в самой системе управления контейнерами размечаем namespaces бюджетными тэгами.
Дальше собираем данные по потреблению, например через kubectl-cost, и рассчитываем стоимость на базе тех тарифов, которые уже сформировали раньше. После этого просто добавляем эти данные в общий отчет вместе с остальными категориями расходов.
Но сам по себе учет ради учета не очень интересен. Важнее другое: как эти данные потом использовать для планирования мощностей и бюджета.
На практике тут обычно работают два подхода:
1. Аллокация фактических затрат на конкретный P&L центр
Главный плюс такого подхода - простота реализации. Мы собираем агрегированные данные по стоимости в одном месте и на их основании выставляем внутренние счета владельцам бюджетов соответствующих P&L-центров.
Но есть и обратная сторона: чтобы такая модель не начала постоянно спотыкаться о нехватку ресурсов, приходится заранее держать заметный запас мощностей. Запросы внутренних потребителей здесь почти ничем не ограничены, а значит, предсказать их заранее бывает сложно.
Пример таких отчетов с распределением стоимости и ресурсов можно собрать, например, в Grafana.
Получается довольно просто и наглядно.
2. Выделение необходимых ресурсов и установка лимитов в соответствии с бюджетами P&L-центров
У второго подхода плюс уже в другом: он дает заметно более высокую точность и предсказуемость расходов. Заодно он помогает сократить затраты на поддержание лишнего запаса вычислительных ресурсов.
Минусы тоже вполне ощутимы.
Реализовать это сложнее. Для контроля расходования ресурсов нужна система, которая умеет выставлять лимиты на уровне гипервизоров. А если мы хотим дать внутреннему заказчику нормальный интерфейс самообслуживания, понадобится еще и платформа управления облаками или контейнерами с автоматизацией через API, Terraform и шаблоны развертывания.
Возникают и организационные трудности. Такой подход требует заранее запрашивать ресурсы под проекты, а это означает, что разработчики, тимлиды и CTO должны более точно оценивать свои потребности и работать в заданных ограничениях. На практике это получается не у всех и не сразу.
При этом именно такой вариант с точки зрения ITFM и FinOps обычно дает наибольший эффект по экономии и лучше готовит почву для нормального бюджетного планирования.
В следующей части я покажу, как на базе всей этой информации перейти уже к следующему шагу, прогнозированию потребления и планированию ИТ-бюджета.
