Привет, Хабр! Меня зовут Лиля Ермакова, Service Delivery Manager в Cloudmaster. В своей работе нам часто приходится помогать компаниям настраивать отображение затрат по инфраструктуре в соответствии с бизнес-потребностями.
Сначала я хотела рассказать, как просто и быстро проставить метаданные (теги) на виртуалках в VMware Cloud Director и получить первый отчет о расходах. Но, начав писать, пришла к мысли, что FinOps и тегирование — это целая модель учета. Если внедрять ее абы как, без правил, можно сделать еще хуже. А нам этого не надо. Поэтому будем делать по уму и разберем все в подробностях.
Чтобы полностью раскрыть тему и не перегружать информацией, я разбила статью на три части:
Модель тегирования (эта статья): разбираем теоретическую основу тегирования, которая должна стать вашим внутренним стандартом.
Инструменты Cloud Director: расскажу, как применить эту модель на практике.
Учет: на примере Cloudmaster объясню, как считать затраты, работать с распределенными расходами и принимать решения.
Если вы новичок в FinOps и Cloud Director, вам точно будет полезно.
Итак, начнем с фундамента FinOps практики — обеспечить showback. Или, простыми словами, дать командам счетчик, который будет считать затраты по инфраструктуре. Теги в этом отношении — одновременно самый гибкий и самый заковыристый в применении инструмент. Кстати, недавно увидела отличное определение тегирования в одном телеграм-канале — что называется, не в бровь, а в глаз.
Правило трех вопросов: Какие данные вы должны извлечь о VM?
Перед тем, как бежать клеить ярлыки на все подряд, надо понять, для чего вы это делаете. От того, какую проблему вы хотите решить, зависеть, какие теги надо использовать.
Поэтому, когда смотрите на список виртуалок, задайте себе следующие вопросы:
К какому проекту она относится?
Кто должен платить?
Можно ли ее вообще выключить или она критичная?
Как только ответите на эти вопросы, сразу станет понятно, какие теги нужны.
Обычно получается три большие категории. Но оговоримся: использовать сразу все необязательно. Уже достаточно, что вы про них просто знаете.
Управление затратами. Тут все про деньги. Без этих тегов вы просто никогда не узнаете, кто сливает весь бюджет. А узнать стоит хотя бы для того, чтобы более осмысленно ругаться на планерках.
department — какой отдел платит (finance, marketing, engineering, operations)
project — конкретный проект (crm_migration, mobile_app_v2, data_warehouse)
customer — если работаете с несколькими клиентами (client_alfa, client_beta)
cost_center — центр затрат по вашей финмодели (cc_1001, cc_2045)
billing_code — код для внутреннего биллинга, если он у вас есть
Жизненный цикл ресурса. Это не только про деньги, но и про управление. Он помогает принимать решения и автоматизировать процессы:
environment — окружение (dev, test, staging, prod)
application — приложение или сервис (web_frontend, api_backend, database)
version — версия (v1.2.3, legacy, canary)
owner — кто отвечает (ivan.petrov, devops_team, dba_team)
created_by — кто создал, для аудита
schedule — график работы (24x7, business_hours, weekend_off)
expires_at — когда можно удалить, для временных ресурсов
Критичность и безопасность. Насколько важен ресурс? Какие риски с ним связаны? Для этого тоже есть теги:
criticality — критичность для бизнеса (critical, high, medium, low)
data_classification — тип данных (public, internal, confidential, restricted)
compliance — требования соответствия (gdpr, pci_dss, hipaa, sox)
backup_policy — политика бэкапов (daily, weekly, none)
Только не создавайте сходу миллион тегов. Это хуже, чем их полное отсутствие. Максимум 7-10. Будет больше — и вы сами не вспомните, что они значат. Проверено.
Я лично видела систему с 47 тегами, из которых использовали только 6. Остальное было просто наследием от админа, который ушел в 2019-м.
Как спроектировать систему тегов
С категориями определились. Теперь нужно прописать сами теги так, чтобы ими было удобно пользоваться.
Начните с того, что выпишите ключи. Только не мельчите. Вместо department_finance или department_marketing лучше сделать один ключ department, а к нему уже значения finance и marketing. Потому что через месяц вы точно забудете, как правильно писать, и понаделаете кучу вариантов с ошибками, а кто-то потом будет разбираться, один это отдел или разные.
Затем сформулируйте возможные значения для каждого ключа. Начать лучше с основных категорий. Описывать сразу весь мир не надо. Слишком подробная номенклатура приведет к тому, что половина тегов будет проставлена неправильно, а вторая половина не проставлена вообще. Потому что никто не помнит, чем project_alpha_submodule_backend_v2 отличается от project_alpha_backend_v2_module.
Договоритесь о написании. Это вообще чуть ли не самое важное. Чтобы не гадать, использовать заглавные буквы или строчные, подчеркивания или дефисы, кириллицу или латиницу, вот вам универсальный рецепт.
Только латиница, только строчные буквы, только подчеркивания вместо пробелов.
Это работает везде и не создает проблем с кодировкой. Плюс — минимизирует вариативность: Marketing или MARKETING уже не напишешь. Есть только один правильный вариант.
Ну и финальный этап — проверьте документацию Cloud Director и вашего провайдера на ограничения по длине тегов и символам. Уточните у провайдера, сколько тегов вообще можно повесить на один объект. Бывает, что там есть лимиты, и узнать об этом лучше до того, как вы распланировали 50 тегов.
Типичные ошибки при тегировании
Раз уж мы тут про планирование, вот вам примеры того, как делать НЕ НАДО:
Слишком детальная номенклатура. Создали 50 значений для одного ключа. Половину никто не помнит, используют 5-7 самых популярных, остальное в забытье.
Разночтения в написании. Один пишет prod, другой production, третий PROD. Получается три разных тега вместо одного.
Нет обязательных тегов. Не договорились, какие теги должны быть на каждом ресурсе обязательно. В итоге у половины виртуалок нет project, у другой половины нет owner. Кому жаловаться непонятно.
Забыли про автоматизацию. Уже были скрипты, которые ищут ресурсы по тегу environment:prod. Переименовали в env:production. Скрипты сломались, все упало, начальство недовольно.
Не обновляют теги. Проект закрылся полгода назад, а виртуалки до сих пор вися�� с его тегом и жрут бюджет, и никто не знает, можно ли их выключить.
Кириллица в тегах. Потом не можете экспортировать в CSV или интегрировать с внешними системами. Сплошные кракозябры вместо нормальных данных.
Нет документации. Через полгода никто не помнит, что значит тег stage:qa2. Это тестовое окружение? Или что-то другое? Пойди разберись.
Сложно? Да, в общем, нет. Главное, не танцевать на этих граблях, а просто обойти их, уделив время планированию и документированию. Ну и периодически проверять, что все ресурсы имеют теги.
Лучше только автоматизация. Хотя многие считают, что автоматизировать FinOps нужно в последнюю очередь, на деле видно, что подход Shift Left работает отлично. Это когда инженеры встраивают в пайплайны развертывания проверку: «Нет тега? Нет деплоя». Это гарантирует, что хаос просто не успеет возникнуть.
В следующей статье посмотрим, как применить разметку и теги в Cloud Director. Если у вас другая виртуализация, то можно сразу перейти к третьей части, где разберем, как организовать showback при помощи подручных инструментов.