Диагностический маршрут для крупного роста Blob Storage: подтвердить метрику used capacity, найти контейнеры и типы объектов, учесть версии, snapshots и soft-deleted blobs, построить inventory и только потом обсуждать lifecycle.
Подтвердите масштаб и момент роста
Откройте Azure Monitor или Storage Insights и сохраните график used capacity за период до и после скачка. Отдельно запишите число транзакций и дату изменения, но не пытайтесь вывести объём только из трафика: хранение и операции измеряют разные явления. Убедитесь, что выбран правильный subscription, resource group и storage account. Общая цифра десятков терабайт ещё не называет контейнер, владельца данных или объект, поэтому удаление на этом этапе недопустимо.
Перейдите от аккаунта к контейнерам
Microsoft рекомендует для анализа ёмкости контейнеров Storage Explorer или Blob Inventory, особенно при большом числе объектов. Составьте таблицу контейнеров с размером, количеством объектов, владельцем и ожидаемым назначением. Если доступны container-level metrics, учитывайте их статус и стоимость; предварительные функции не должны становиться единственным доказательством. Цель этапа — найти несколько крупнейших вкладов и проверить, продолжают ли они расти.
Инвентаризируйте версии, снимки и удалённые объекты
Blob Inventory может включать base blobs, versions, snapshots, content length, даты и уровни доступа, а отчёт создаётся ежедневно или еженедельно. Настройте поля и фильтры так, чтобы не потерять типы объектов, способные объяснить рост. Документация отдельно указывает, что версии, snapshots и soft-deleted объекты могут накапливать ёмкость. Не делайте вывод по одному списку текущих файлов: он может не отражать исторические копии и состояние удаления.
Не приравнивайте inventory к счёту
Microsoft предупреждает, что размер и количество в inventory не следует напрямую сравнивать с биллингом: отчёт не включает часть метаданных, системных журналов и свойств, а фильтры snapshots и versions не обязательно меняют тарифицируемую работу inventory. Зафиксируйте разницу как ограничение метода. Для FinOps сравните одинаковые периоды и единицы, учтите уровни хранения и операции. Если расхождение существенно, приложите оба источника, а не подгоняйте один под другой.
Lifecycle включайте после решения о хранении
Lifecycle management умеет переводить текущие версии, предыдущие версии и snapshots в более холодные уровни или удалять их по условиям времени и фильтрам. Сначала владелец данных должен подтвердить retention, legal hold, резервное копирование и допустимость восстановления. Протестируйте правило на префиксе или тегах и отслеживайте его выполнение; изменения могут обрабатываться не мгновенно. Остановитесь до удаления, если неизвестен владелец или inventory ещё не завершён.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 30 июля 2026 года по обезличенному сигналу Microsoft Q&A и официальной документации Azure Blob Storage; имя storage account не воспроизводилось.
Источники и проверка
- Microsoft Learn — Azure Storage Blob Inventory проверено 2026-07-30
- Microsoft Learn — мониторинг Azure Blob Storage проверено 2026-07-30
- Microsoft Learn — управление жизненным циклом Blob Storage проверено 2026-07-30
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.