Меня зовут Дмитрий, я руковожу отделом ИТ-инфраструктуры и сервисов в Ви.Tech, IT-дочке ВсеИнструменты.ру. В предыдущих частях я рассказывал про P&L-центры, ценообразование, учет ресурсов и планирование бюджета, а теперь хочу перейти к самой чувствительной части всей этой истории - оптимизации потребления.
Здесь уже недостаточно просто собрать цифры в отчет. Нужно понять, где ресурсы реально тратятся неэффективно, что с этим можно сделать без вреда для сервисов и с какими организационными проблемами мы почти наверняка столкнемся по дороге.
Начать стоит с самого очевидного, с неэффективного использования ресурсов. Обычно оно проявляется в одном из трех сценариев:
Ресурсы выделены, но хосты выключены
Ресурсы выделены, хосты включены, но фактически простаивают
Ресурсов выделено заметно больше, чем сервис потребляет на практике
На словах решение выглядит очень простым: забрать лишнее и отдать туда, где мощностей не хватает. Но чугунная реальность быстро показывает, что делать это надо очень аккуратно и обязательно с учетом контекста.
Мониторинг и инструменты right sizing должны смотреть не на случайную точку во времени, а хотя бы на 95-й перцентиль за длинный период. Иначе утром мы увидим overprovisioning, сократим ресурсы, а вечером сервис уже упрется в потолок под нагрузкой.
Нужно учитывать специфику бизнеса. У кого-то есть сезонность, у кого-то тяжелые операции запускаются по выходным, у кого-то расчетные задачи идут раз в месяц. Если этого не видеть, оптимизация быстро превращается в источник инцидентов.
Часть ресурсов может простаивать вполне осознанно, потому что архитектурно это standby-хосты под отказоустойчивость.
Если после этого остается понимание, что ресурсы все же надо сокращать, дальше уже идем к владельцу сервиса или тимлиду и разбираем ситуацию предметно: сколько мощностей действительно можно высвободить, а где запас пока трогать не стоит.
Вторая частая проблема - перекос в распределении ресурсов между P&L-центрами. Бывает, что команда заранее запросила заметный объем мощностей под проекты, которые потом заморозились, сдвинулись или вообще не состоялись. В результате бюджет уже нагружен, ресурсы заняты, а пользы от этого никакой.
Здесь тоже не стоит рубить с плеча. Иногда такой запас действительно скоро понадобится, но это надо подтверждать вместе с владельцами бюджетов, а не оставлять в системе вечные "зарезервировано на всякий случай".
Следующая частая причина неоптимального потребления вычислительных ресурсов – это неоптимизированное ПО, например:
- Используются неоптимальные алгоритмы и структуры данных
- Неоптимальная архитектура используемого ПО
- В используемых системах очень много legacy
- Выбран неоптимальный инструмент реализации (язык, компилятор…)
- Используется точность не нужная для решения конкретных задач
Подробно в тему оптимизации самого ПО я сейчас уходить не буду, это правда отдельный большой разговор. Вместо этого лучше коротко перечислю типовые трудности, которые обычно всплывают при внедрении FinOps и ITFM:
Нужны культурные изменения, а стейкхолдеры не всегда сразу понимают, зачем это вообще нужно
На внедрение часто не выделяют отдельную команду, время и бюджет
Возникают проблемы с формированием P&L-центров и назначением ответственных
Технические команды могут сопротивляться оптимизации, особенно если привыкли жить с запасом
Есть устойчивая привычка решать любую нехватку производительности просто добавлением железа
Процессы не любят документировать, пока они еще "и так у всех в голове"
Почти всегда приходится дорабатывать или подстраивать используемые инструменты под свою реальность
Как и любой новый процесс в компании, FinOps и ITFM требует вовлечения и заинтересованности высшего руководства и тщательно проработанной документации, учитывающей:
- Списки PnL центров и лиц, ответственных за планирование и контроль расходов
- Списки лиц, ответственных за оптимизацию потребления ресурсов
- Процессы и модели предоставления ИТ-ресурсов
- Модели учета и распределения ресурсов, а также систему ценообразования
- Жизненный цикл используемого оборудования, включая сроки и тип его амортизации
- Процессы, связанные с подачей и утверждением ИТ бюджета
Если этот путь все же пройти, результат обычно становится вполне осязаемым:
Появляется понятная картина распределения затрат на ИТ-ресурсы
Часть вычислительных мощностей удается высвободить и использовать повторно
Снижается объем лишних закупок
Новые проекты можно оценивать по ИТ-затратам еще на этапе планирования
Бюджеты становится проще и планировать, и защищать
На этом я завершаю цикл статей про FinOps и ITFM. За кадром, конечно, осталось еще много деталей, но базовую логику учета, аллокации, планирования и оптимизации мы с вами собрали в одну цельную картину.
