У cloud-инфраструктуры есть неприятная привычка: инженер ушел, инстанс остался, счет продолжает тикать. Владельцы cloud-ресурсов должны быть не в памяти команды и не в старом треде Slack, а в инвентаре, политиках и журнале аудита, пишет The New Stack.
15 сентября 2026 года издание опубликовало материал Zeen Rachidi о довольно приземленной, но дорогой проблеме platform engineering: как понять, кто отвечает за каждый найденный ресурс в AWS, Google Cloud или Azure. Текст спонсирован env zero, поэтому к нему стоит относиться как к практическому гайду с продуктовым акцентом, а не как к независимому исследованию. Но сама боль узнаваемая: EC2-инстанс, виртуальная машина или окружение для нагрузочного теста переживают проект, владельца и иногда несколько реорганизаций.
Сценарий знаком почти любой команде, которая достаточно долго живет в облаке. Финансовый аудит находит ресурс, который никто не помнит. SRE или платформа ищет его ID в чатах, проверяет Terraform-репозитории, спрашивает соседние команды, доходит до фразы «кажется, это делала команда Priya до ее ухода». Выключить страшно: вдруг это часть критичной цепочки. Оставить тоже неприятно: ресурс может стоить денег, держать доступы, мешать миграции или создавать ложное чувство порядка.
Предлагаемая схема держится на трех вещах: синхронизируемый инвентарь, жесткие политики тегирования и аудит, который переживает увольнения. В статье приводится пример с CloudQuery: инвентарь регулярно собирается в таблицы вроде aws_ec2_instances, gcp_compute_instances и azure_compute_virtual_machines. После этого можно обычным SQL-запросом найти ресурсы без owner-тега или label: сначала AWS EC2, затем GCP Compute, затем Azure Virtual Machines. Никакой магии, зато есть список, с которым можно идти к командам, бюджету или security.
Вторая часть — не искать бесхозные ресурсы постфактум, а блокировать их появление. Здесь в пример приводится env zero, который проверяет планы через правила Open Policy Agent до применения изменений. Правило простое: если создается новый ресурс и у него нет tags.owner, план отклоняется. Для разработчика это выглядит как раздражающее, но полезное ограничение: хотел поднять окружение быстро, а система попросила назвать ответственного. Облако в этот момент чуть меньше похоже на общий гараж, где каждый оставляет что-то «на пять минут».
Теги, правда, отвечают только на вопрос «кто владелец сейчас». Они не объясняют, кто запросил ресурс, кто одобрил создание, зачем он нужен и к какому тикету привязан. Поэтому третья часть схемы — audit trail. В статье приводится пример записи resource.created с resource_id, requested_by, approved_by, approval_ref, stated_purpose и timestamp. Такая запись полезнее, чем археология в чатах: она фиксирует контекст в момент создания, пока участники еще работают в компании и помнят, почему это вообще понадобилось.
Контекст здесь не только технический. Автор ссылается на добровольную текучесть в частном секторе США на уровне 22–25% в год: компания на 100 человек может терять около двух десятков сотрудников ежегодно. Даже если цифра зависит от отрасли и рынка труда, логика для IT-команд понятна. Люди уходят, команды сливаются, схемы тегирования меняются, старые политики заменяются новыми, а инфраструктура продолжает жить. Владельцы cloud-ресурсов становятся не вопросом дисциплины отдельных инженеров, а частью операционной модели.
Для русскоязычных команд, особенно тех, кто пережил быстрый рост, релокации, сокращения или хаотичные миграции между облаками, это не академическая тема. Бесхозный ресурс может быть не только лишней строкой в счете. Он может означать забытый тестовый стенд с доступом к данным, зависший публичный endpoint, устаревший образ, неконтролируемый storage bucket или инфраструктуру, которую никто не патчит, потому что никто не считает своей. В FinOps это превращается в лишние расходы, в security — в поверхность атаки, в DevOps — в ручную работу без владельца и SLA.
Практический вывод довольно жесткий: тег owner сам по себе не спасает. Нужна связка из инвентаря, политики на входе и истории решений. Если разрешить создавать ресурсы без владельца, платформа потом будет бесконечно догонять собственный хаос. Если хранить владельца только в теге, он устареет после первой реорганизации. Если не сохранять цель и одобрение, через полгода команда снова будет решать, можно ли выключить инстанс, по косвенным признакам и интонации старого сообщения в чате.
Похоже, следующий нормальный уровень зрелости cloud governance — это не очередная таблица «кто за что отвечает», а исполняемая политика: ресурс без владельца не создается, ресурс без назначения попадает в отчет, ресурс без истории вызывает вопрос до того, как счет прилетел в финансы. Владельцы cloud-ресурсов в такой модели перестают быть героической памятью старожилов и становятся обычным полем данных. Скучно, зато счета и инциденты тоже любят скуку.