Меня зовут Дмитрий, я руковожу отделом ИТ-инфраструктуры и сервисов в Ви.Tech, IT-дочке ВсеИнструменты.ру. В прошлой части я рассказывал, как мы собираем и считаем потребление вычислительных ресурсов, а теперь хочу перейти к следующему шагу - планированию ИТ-бюджета на базе этих данных.
Для этого я обычно использую два дополняющих друг друга подхода:
Прогноз потребления ресурсов на основе истории, текущей утилизации и доступных остатков
Отдельный учет крупных инициатив, которые не укладываются в обычный рост, например новых проектов или закупки выделенного оборудования
Со вторым пунктом все обычно довольно прозрачно. А вот первый как раз интереснее, потому что именно здесь собранные ранее данные начинают работать не как отчетность ради отчетности, а как инструмент планирования.
Сначала нам нужно зафиксировать текущее распределение ресурсов по P&L-центрам и посчитать долю каждого из них в общей инфраструктуре. На выходе получится базовая таблица, от которой дальше можно строить и прогноз, и бюджетную модель.
После этого собираем историю общего потребления за прошлый расчетный период, с разбивкой по месяцам или кварталам. Такая статистика позволяет увидеть динамику, выделить тренд и уже на его основе оценить потребление на следующий период, например на год вперед.
Когда у нас есть и структура распределения, и историческое потребление, дальше модель уже можно применять вполне прикладным образом:
Рассчитать целевые пулы ресурсов для каждого P&L-центра на следующий период, опираясь на коэффициенты распределения и прогноз роста
Посчитать стоимость этих пулов и обсудить ее с владельцами бюджетов и CTO, а затем при необходимости скорректировать объемы в большую или меньшую сторону
После этого выйти на расчет закупок и понять, сколько оборудования действительно нужно докупить с учетом рыночной стоимости, остатков ресурсов, требований по кратности, резерву под отказоустойчивость и, если нужно, размещению в нескольких датацентрах
При таком подходе почти наверняка останется часть нераспределенных ресурсов. Их можно либо размазать по всем P&L-центрам, либо отнести на отдельное сервисное подразделение как резерв мощностей. Мне второй вариант кажется честнее, потому что он не искажает картину потребления конкретных команд.
Эту же модель можно использовать и для планирования в условиях ограничений. Допустим, финансовый директор заметно сократил бюджет на ИТ-оборудование, и теперь нам надо в него уложиться. Тогда задача сводится к подбору допустимых коэффициентов роста за период, чтобы итоговая стоимость закупки не вышла за заданный лимит:
При этом доступные к заказу ресурсы все равно распределяются по P&L-центрам по тем же коэффициентам, которые мы получили раньше. То есть даже при жестком бюджетном ограничении сама логика модели не ломается, меняются только абсолютные объемы.
В следующей части я покажу уже обратную сторону этой схемы: где именно теряются мощности, как искать избыточное потребление и за счет чего можно проводить оптимизацию без боли для команд и сервисов.
