Оглавление:

— Практика FinOps и ITFM: как считать, распределять и планировать ИТ-расходы (часть 1 из 5)
— Как считать стоимость CPU, RAM и Storage во внутренней инфраструктуре (часть 2 из 5)
— Как учитывать стоимость ИТ-ресурсов и аллоцировать затраты по P&L-центрам (часть 3 из 5)
— Как прогнозировать потребление ресурсов и планировать ИТ-бюджет (часть 4 из 5)— Оптимизация потребления ресурсов: где теряются мощности и как внедрять FinOps без боли (часть 5 из 5)

Меня зовут Дмитрий, я руковожу отделом ИТ-инфраструктуры и сервисов в Ви.Tech, IT-дочке ВсеИнструменты.ру. В предыдущих частях я рассказывал про P&L-центры, ценообразование, учет ресурсов и планирование бюджета, а теперь хочу перейти к самой чувствительной части всей этой истории - оптимизации потребления.

Здесь уже недостаточно просто собрать цифры в отчет. Нужно понять, где ресурсы реально тратятся неэффективно, что с этим можно сделать без вреда для сервисов и с какими организационными проблемами мы почти наверняка столкнемся по дороге.

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

Ресурсы выделены, но хосты выключены

Ресурсы выделены, хосты включены, но фактически простаивают

Ресурсов выделено заметно больше, чем сервис потребляет на практике
На словах решение выглядит очень простым: забрать лишнее и отдать туда, где мощностей не хватает. Но чугунная реальность быстро показывает, что делать это надо очень аккуратно и обязательно с учетом контекста.
Мониторинг и инструменты right sizing должны смотреть не на случайную точку во времени, а хотя бы на 95-й перцентиль за длинный период. Иначе утром мы увидим overprovisioning, сократим ресурсы, а вечером сервис уже упрется в потолок под нагрузкой.

Нужно учитывать специфику бизнеса. У кого-то есть сезонность, у кого-то тяжелые операции запускаются по выходным, у кого-то расчетные задачи идут раз в месяц. Если этого не видеть, оптимизация быстро превращается в источник инцидентов.

Часть ресурсов может простаивать вполне осознанно, потому что архитектурно это standby-хосты под отказоустойчивость.

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

Вторая частая проблема - перекос в распределении ресурсов между P&L-центрами. Бывает, что команда заранее запросила заметный объем мощностей под проекты, которые потом заморозились, сдвинулись или вообще не состоялись. В результате бюджет уже нагружен, ресурсы заняты, а пользы от этого никакой.

Здесь тоже не стоит рубить с плеча. Иногда такой запас действительно скоро понадобится, но это надо подтверждать вместе с владельцами бюджетов, а не оставлять в системе вечные "зарезервировано на всякий случай".

Следующая частая причина неоптимального потребления вычислительных ресурсов – это неоптимизированное ПО, например:

- Используются неоптимальные алгоритмы и структуры данных

- Неоптимальная архитектура используемого ПО

- В используемых системах очень много legacy

- Выбран неоптимальный инструмент реализации (язык, компилятор…)

- Используется точность не нужная для решения конкретных задач

Подробно в тему оптимизации самого ПО я сейчас уходить не буду, это правда отдельный большой разговор. Вместо этого лучше коротко перечислю типовые трудности, которые обычно всплывают при внедрении FinOps и ITFM:

Нужны культурные изменения, а стейкхолдеры не всегда сразу понимают, зачем это вообще нужно
На внедрение часто не выделяют отдельную команду, время и бюджет
Возникают проблемы с формированием P&L-центров и назначением ответственных
Технические команды могут сопротивляться оптимизации, особенно если привыкли жить с запасом
Есть устойчивая привычка решать любую нехватку производительности просто добавлением железа
Процессы не любят документировать, пока они еще "и так у всех в голове"
Почти всегда приходится дорабатывать или подстраивать используемые инструменты под свою реальность

Как и любой новый процесс в компании, FinOps и ITFM требует вовлечения и заинтересованности высшего руководства и тщательно проработанной документации, учитывающей:

- Списки PnL центров и лиц, ответственных за планирование и контроль расходов

- Списки лиц, ответственных за оптимизацию потребления ресурсов

- Процессы и модели предоставления ИТ-ресурсов

- Модели учета и распределения ресурсов, а также систему ценообразования

- Жизненный цикл используемого оборудования, включая сроки и тип его амортизации

- Процессы, связанные с подачей и утверждением ИТ бюджета

Если этот путь все же пройти, результат обычно становится вполне осязаемым:

Появляется понятная картина распределения затрат на ИТ-ресурсы
Часть вычислительных мощностей удается высвободить и использовать повторно
Снижается объем лишних закупок
Новые проекты можно оценивать по ИТ-затратам еще на этапе планирования
Бюджеты становится проще и планировать, и защищать

На этом я завершаю цикл статей про FinOps и ITFM. За кадром, конечно, осталось еще много деталей, но базовую логику учета, аллокации, планирования и оптимизации мы с вами собрали в одну цельную картину.