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

Это финал нашей трилогии про FinOps в Cloud Director. В первых двух частях мы разобрали, как тегировать ресурсы и не сойти с ума, а сейчас посмотрим, что с этими данными делать дальше. 

Если вы не знакомы с тегированием и принципами организации ресурсов в VMware, то загляните в часть 1, где мы разобрали тегирование как таковое, и в часть 2 — про инструменты пользователя Cloud Director. 

Статьи предназначены для тех, кто только начинает разбираться с FinOps и Cloud Director. Хотя если вы уже год мучаетесь с виртуалками и никак не можете понять, куда утекает бюджет, вам тоже сюда.

Показывать буду на примере нашей платформы Cloudmaster. На самом деле, можно и в Excel — принципы-то одинаковые. Просто с Cloudmaster будет сильно быстрее, потому что не надо каждый раз переписывать формулы. Если политика безопасности позволяет, можете попробовать 14 дней бесплатно. А если нельзя или не хочется, для каждого шага добавлю альтернативу, как провернуть это в обычной табличке. Помечать буду вот так: ??. Подробности реализации формул и CLI-скриптов за рамками статьи. Там никаких хитростей, только ваше время и внимание.

Практика: считаем затраты по региональным проектам

Представим упрощенную ситуацию, что нам надо посмотреть затраты по региональным проектам. У нас есть офисы в Томске, Новосибирске, Омске, и каждый из них запускает свои проекты. А как понять, кто сколько тратит, если ресурсы разбросаны по разным VDC?

Даже (почему даже? Да потому что ситуации бывают разные) если все виртуалки и vApp размечены, а теги добавлены, нужно как-то построить отчет. Руками это делать долго и неудобно. Значит, нужен какой-то инструмент, который умеет работать с metadata и считать затраты. Можно договориться со своим провайдером о выгрузке в определенном формате и ворочить цифры в экселе. 

Шаг 0: сбор данных из Cloud Director 

Для начала нам нужна информация о списке ВМ, где они живут и какая у них конфигурация. Список виртуалок может выглядеть примерно так:

Cloudmaster собирает все это в одном месте и ведет расчет по вашему прайс-листу. Дальше, если VDC добавляются или удаляются, виртуалки мигрируют или меняют конфигурацию, все учитывается автоматически. 

??  Без сторонних инструментов вы можете выгрузить информацию с помощью CLI, запросить у вашего провайдера табличку с затратами по ВМ или рассчитать затраты самостоятельно по прайс-листу и конфигурации. Вам потребуются следующие колонки: VDC, vApp, имя ВМ, колонка для каждого ключа тегов (если вы их используете). 

Дальше, главная фишка Cloudmaster для нашей задачи – бизнес-срезы. По сути, это гибкие правила распределения затрат. Как термин звучит сложновато, но на практике все совсем просто. 

Шаг 1: создаем срез «Региональные проекты» и группу для Томска

Добавляем первую группу, допустим, «Томские проекты». Мы знаем, что томские ребята в основном используют VDC с названием Tomsk. Значит, первое условие простое: если VDC равно Tomsk, то это томские проекты.

Все расходы на виртуалки в этом VDC автоматом попадут в нужную группу.

?? В колонке с VDC отфильтровать по Tomsk. 

Шаг 2: добавляем условия через теги

Но бывает, что томские проекты используют ресурсы в других VDC. Почему? Может, там было свободное место, а может, цена подходящая. Нам важно просто добавить учет этих ресурсов через логическое ИЛИ:

• VDC равно Tomsk

• Тег office содержит tomsk

• Имя ВМ содержит tomsk

В интерфейсе выбираете Metadata, находите ключ office — и система покажет все уникальные значения этого ключа. Ставите условие: office равно tomsk.

Если коллеги писали теги по-разному (tomsk, Tomsk, tomsk_office), жесткое условие «равно» может пропустить часть ресурсов. Тогда добавляете условие «содержит» для подстраховки. В конце концов, лучше захватить лишнее, а потом отсеять, чем упустить нужное на этапе поиска.

Кстати, кто-то мог забыть поставить теги, но добавил tomsk в название виртуалки или vApp. Учтем и такие объекты. Добавляете условия по именам: имя ВМ содержит tomsk или имя vApp содержит tomsk. И все, группа «Томские проекты» готова.

?? В такой более комплексной выборке вам потребуется создать дополнительный признак для отнесения строки затрат к томским проектам и проставить его для каждой строки при помощи формул поиска совпадений.

Шаг 3: добавляем остальные регионы

Дальше по тому же принципу добавляете группы для Новосибирска, Омска и других городов. VDC плюс теги, плюс имена. 

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

?? Настраиваем нашу формулу поиска совпадений, чтобы признак отнесения строки затрат теперь учитывал и офисы в других городах. Что до частоты обновления, она будет зависеть от вас и вашего провайдера.

Шаг 4: разбираемся с неразмеченными ресурсами

После сохранения вы увидите, что в срезе «Региональные проекты» появились три группы по регионам и какая-то «Нераспределенная группа». Не пугайтесь. Это не баг, а фича.

Бизнес-срез всегда распределяет 100% затрат. Расходы на объекты, которые не попали ни в одну созданную группу, автоматом уходят в нераспределенные. Это на самом деле очень полезная штука. Так сразу видно, где были пробелы в разметке. Или где накосячили с условиями.

В идеале нераспределенная группа должна быть пустой. Значит, все затраты корректно разнесены по проектам или офисам. Если там что-то есть — либо забыли поставить теги, либо неправильно настроили условия. Либо просто есть ресурсы, которые не относятся ни к одному известному проекту.

?? Наша формула должна предусматривать дефолтное значение, которое будет означать, что ресурс не попал ни в одну из групп.

Как найти ресурсы, которые коптят воздух

Помните «нераспределенные расходы», о которых мы говорили выше? Это те самые ресурсы без тегов, с неправильными тегами или просто забытые кем-то виртуалки, которые работают сами по себе. Они и есть основные подозреваемые по делу «о растрате».

• Заходите в раздел отчетов, выбираете свой срез «Региональные проекты», кликаете на «Нераспределенная группа» — и вот он, список. Тут сразу видно, какие виртуалки выпали из всех категорий.

• Если навести курсор на ресурс, вылезает местоположение и идентификатор.

• Кликаете на виртуалку — открывается окно с подробностями: конфигурация, статус, когда создана. 

?? В Excel-табличке отфильтровать список по дефолтному значению нашего признака. 

Часто попадаются виртуалки, запущенные для проектов, которые уже закончились. Или сервисы, которые просто не успели разметить. В общем, что-нибудь да найдете. 

Для остальных групп среза работает тот же принцип. Можно посмотреть списки виртуалок и дисков внутри любой группы — например, «Томские проекты». Показать команде из Томска, сколько стоит ее инфраструктура и попросить принять решение: что оставить, а что оптимизировать. Так появляется прозрачность. А вместе с ней и ответственность. Тут уже не скажешь: «Я не знал, что это мое».

В заключении повторю основной посыл этой серии статей: если вы ищете единственный шаг, который кардинально изменит ваше отношение к облачным расходам, это Showback. Покажите каждой команде, сколько она тратит на инфраструктуру, и ответственность проявится сама собой. Когда томские ребята увидят, что их проекты стоят 200 тысяч, а новосибирские – 80, нежелание быть хуже сработает лучше любых директив сверху.