Александр Либкинд, руководитель направления развития сервисов управления затратами в Cloud.ru и эксперт Практики FinOps, поделился материалом о том, почему ручная инвентаризация инфраструктуры редко приводит к устойчивой экономии и как перейти от разовых проверок к управляемой модели.
Поводом могут быть GPU-инстансы, тестовые окружения, неиспользуемые диски, свободные IP-адреса или любые другие ресурсы, которые продолжают потреблять бюджет после завершения задачи. Но проблема почти всегда шире, чем один тип инфраструктуры.
Если у ресурса нет владельца, команды, среды и приложения, компания не управляет затратами. Она просто периодически пытается разобраться, что можно отключить без последствий.
Почему ручная очистка быстро ломается
«Казнить server-01 нельзя помиловать», стандартная проблема при инвентаризации ИТ-инфраструктуры.
Инициатива по очистке облака от неиспользуемых мощностей редко проходит безболезненно. Обычно процесс выглядит так: руководство назначает ответственного, тот неделями собирает данные по отделам и системам, а затем пытается понять, нужен ли конкретный актив бизнесу или перед ним просто лишняя строка в счёте провайдера.
Следующий шаг, запросы по компании в попытке найти владельцев ресурсов. В ответ часто тишина, потому что внутри команды никто не знает, чьи это мощности и для какой задачи они создавались.
Тогда появляется логика крайних мер: если не ответили, значит, ресурс не нужен. Его можно остановить или удалить.
Именно в этот момент очистка может привести к инциденту. Под отключение случайно попадает критически важный компонент, падает боевой сервис, сотрудники и клиенты недовольны, дежурные инженеры восстанавливают работу на ходу. Настоящего владельца ресурса так и не нашли, но бизнес уже сделал вывод: трогать неразмеченные ресурсы слишком рискованно.
Когда инцидент исчерпан, а руководство всё равно требует снизить суммы в счетах, начинается новая волна проверок. Удаляются давно не запускаемые виртуальные машины, свободные IP-адреса, неиспользуемые диски. В следующем месяце счёт действительно становится меньше.
На первый взгляд, это результат. Но к FinOps такая разовая зачистка имеет ограниченное отношение. Она даёт временный эффект, но не меняет модель потребления ресурсов. Через пару месяцев инфраструктура снова начинает обрастать объектами без владельцев, сроков жизни и понятной бизнес-привязки.
Причина простая: поиск владельцев держится на человеческой памяти, а удаление, на ручном анализе сырых данных. Инженер по-прежнему может в два клика создать мощный сервер, переключиться на другую задачу, забыть про него или уйти из компании. Сервер при этом продолжит потреблять бюджет до следующей проверки.
Чтобы проблема ушла системно, нужно отказываться не от очистки, а от ручного контроля как основного механизма управления.
Почему красивые дашборды не решают проблему
После первых инцидентов и ручных разборов обычно возникает идея: если нужны данные, значит, нужны дашборды.
Компании умеют строить аккуратные графики, круговые диаграммы и топы самых дорогих проектов. Например, на дашборде по самому затратному проекту может быть видно:
-
вычислительные ресурсы, 1,5 млн рублей;
-
контейнеры, 1,2 млн рублей;
-
базы данных, 900 тыс. рублей.
Графики выглядят убедительно. Но стоит задать несколько простых вопросов, как становится понятно, что визуализация сама по себе не даёт управляемости.
Кто отвечает за эти 1,5 млн рублей?
Как сумма распределена между продом, тестом и разработкой?
Какую бизнес-задачу решает система за 3,6 млн рублей в месяц?
Без понимания владельцев аналитика остаётся неполной. Мы видим, что именно было куплено у провайдера, но не понимаем, нужно ли это бизнесу, кто принимает решение по ресурсу и кто может изменить конфигурацию.
Это похоже на выписку по карте, где указаны только магазины: маркетплейс, 100 тыс. рублей; супермаркет, 50 тыс. рублей. Куда ушли деньги, формально понятно. Но кто их потратил, зачем и какой результат получил бизнес, из такой выписки не следует.
Дашборд без привязки к владельцам показывает симптомы, но не помогает принять решение.
Базовая политика атрибуции
Решение начинается с политики атрибуции затрат. У каждого ресурса должны быть понятные признаки, которые отвечают на два вопроса: кто создал ресурс и для какой задачи он нужен.
Не обязательно сразу строить сложную систему из десятков тегов. На первом этапе достаточно четырёх параметров:
-
команда или отдел;
-
ответственный;
-
среда;
-
приложение.
Например:
-
команда: отдел продаж;
-
ответственный: ivan.ivanov@company.ru;
-
среда: dev;
-
приложение: BI по МСБ.
Разница между ресурсом с техническим названием server-01 и тем же ресурсом с корректными атрибутами принципиальная.
В первом случае дежурный инженер не понимает, можно ли его остановить. Возможно, это забытый тестовый сервер. Возможно, важный компонент боевой системы. Без контекста любое действие рискованно.
Во втором случае ресурс становится управляемым активом. По нему можно сформировать конкретное уведомление:
Иван, ты указан как ответственный за dev-конфигурацию
server-01для BI по МСБ. Ресурс не используется более 14 дней и стоит 25 тыс. рублей в месяц. Удали его или настрой отключение в нерабочее время. Инструкция ниже.
Здесь нет угадывания. Есть адресат, контекст, стоимость и понятное действие.
Как закрепить атрибуцию на уровне инфраструктуры
Главный вопрос после описания тегов звучит так: откуда возьмутся корректные метки?
Административным приказом проблему не решить. Инженеры запускают ресурсы под задачу, переключаются на другой приоритет, а разметка часто остаётся на потом. Поэтому процесс нужно закреплять на уровне инфраструктуры.
Первый шаг, обязательные теги для новых ресурсов.
Создание ресурса без владельца, команды, среды и приложения должно либо блокироваться политикой, либо закрываться автоматической атрибуцией.
Например, ресурс может наследовать теги от проекта, рабочей области, сервисного контура или автора задачи. Тогда команда меньше зависит от ручного заполнения полей, а вероятность пустых атрибутов снижается.
При этом важны исключения. Жёсткий запрет не должен ломать системные аккаунты, CI/CD-пайплайны, автоскейлинг и сервисные ресурсы. Во многих случаях гибкая автоматизация атрибуции безопаснее, чем правило «запретить всё без тегов».
Второй шаг, отдельный процесс для старых ресурсов.
Новые объекты можно размечать сразу по правилам. Но старые неразмеченные ресурсы никуда не исчезнут. Для них нужен отдельный регламент.
Примерная логика может быть такой.
На первой и второй неделе скрипт помечает ресурсы как unassigned и отправляет уведомления потенциальным владельцам: «Мы нашли этот ресурс в вашей подсети, подтвердите владение».
На третьей неделе неразмеченные ресурсы попадают в общий алерт: «Через неделю ресурсы без заполненных тегов будут остановлены».
На четвёртой неделе включается безопасный карантин. Ресурсы без владельца не удаляются сразу, а сначала останавливаются. Если ресурс действительно нужен, владелец появится и исправит разметку. Удаление возможно только после периода ожидания и отсутствия реакции.
Это важный принцип. Сразу удалять неразмеченные ресурсы рискованно. Остановка на несколько дней безопаснее: она помогает найти реального владельца без необратимых последствий.
Почему прозрачность работает лучше ручных проверок
Когда у каждого расхода есть команда, владелец, среда и приложение, дашборды становятся рабочим инструментом.
Руководитель видит не общий счёт провайдера, а расходы своего контура. Команда видит тестовые среды, лишние мощности и ресурсы без понятной нагрузки. Разговор меняется: обсуждается не абстрактное снижение затрат, а конкретные ресурсы, владельцы и действия.
Прозрачность часто работает лучше штрафов. Не потому что все сразу начинают экономить, а потому что у расходов появляется адрес. Если ресурс стоит денег, понятно, к какому приложению он относится, в какой среде работает и кто отвечает за решение по нему.
Финальный тест на зрелость простой:
можете ли вы за две минуты назвать владельцев пяти неразмеченных ресурсов в вашей инфраструктуре?
Если ответ «нет» или «нужно уточнять», начинать стоит не с новой аналитической платформы. Сначала нужны атрибуция, теги и порядок в данных.
Эффективный учёт затрат держится на точной привязке ресурсов к владельцу, приложению, отделу и среде. Без этого любая оптимизация идёт вслепую.
Разовая очистка может снизить счёт на месяц. Атрибуция и автоматизация меняют саму модель управления инфраструктурой.
ссылка на оригинал статьи https://habr.com/ru/articles/1053562/