Диск забился незаметно: почему сервисы падают ночью

Ночью падает CRM или сайт. Утром в логах короткое и злое: «No space left on device». Админ полдня ищет, что удалить, чистит логи, перезапускает базу. К обеду сервис поднимается. Через месяц — то же самое.

Диск не «ломается внезапно». Он заполняется предсказуемо: логи, WAL или binlog, бэкапы на том же томе, загрузки пользователей, слои контейнеров. Просто никто не смотрел порог, пока место не кончилось в самый неудобный час.

Для бизнеса это не «техническая мелочь». Когда диск полный, база перестаёт писать, заказы зависают, бэкап не создаётся — и вы остаётесь без точки восстановления именно в момент аварии.

Откуда берётся тихий рост

Логи оставили на debug «на пару дней» и забыли. Access-лог за месяц съедает десятки гигабайт. Бэкапы складывают рядом с продовыми данными — удобно, пока не забили тот же volume. В PostgreSQL растёт WAL, в MySQL — binlog, в Docker — старые образы и volumes.

Отдельный сюжет — «мониторинг есть». Grafana красивая, агент стоит, алерт на 90% диска не настроен или улетает в канал, который никто не читает ночью. Формально наблюдаемость есть. Фактически сигнал приходит от клиентов.

Ошибки после аварии

Удалить «всё большое» под давлением. Так сносят нужные бэкапы или данные, которые ещё не успели уехать offsite.

Расширить диск и считать задачу закрытой. Место появилось — политика retention не появилась. Через квартал история повторяется на большем объёме и большем счёте.

Чинить только один сервер. Если такая же схема на тестовом контуре и соседних нодах, следующий инцидент уже запланирован.

Что работает на практике

Три слоя: наблюдаемость, гигиена данных, запас ёмкости. Без любого из них вы снова проснётесь от падения.

Наблюдаемость. Метрики свободного места и inode по каждому mount point, тренд за 7 и 30 дней. Пороги: предупреждение около 75–80%, критично около 90%. Алерт должен будить не «красивый график», а человека с правом чинить.

Гигиена. Ротация логов, срок жизни бэкапов, архивация старых данных БД, очистка temp и политику загрузок. Бэкапы — на отдельный том или в объектное хранилище, не рядом с продом «на всякий случай».

Ёмкость. План расширения до кризиса: когда растём, куда переносим тяжёлую статику, что уезжает в Object Storage.

После инцидента полезно короткое post-mortem: какой каталог съел место, почему не сработал алерт, какой retention отсутствует. Иначе команда запомнит только «почистили логи».

Мини-чеклист на неделю

• какие тома критичны для записи БД и приложений;
• куда пишутся логи и включена ли ротация;
• где лежат бэкапы и не конкурируют ли они с продом;
• есть ли алерт по диску и кто дежурит;
• проверяли ли восстановление хоть раз за квартал.

Пороги, которые имеют смысл

Алерт «диск 100%» бесполезен: он приходит одновременно с падением. Нужны ранние пороги и тренд. Если за неделю свободное место тает предсказуемо, реагировать надо на скорости заполнения, а не только на абсолютном проценте.

Разведите алерты по томам: системный раздел, данные БД, логи, бэкапы. Смешанный сигнал «где-то мало места» заставляет дежурного гадать. Отдельно следите за inode — иногда место есть, а файлов создать уже нельзя.

Ночная смена должна иметь короткий регламент: какие каталоги смотреть первыми, что можно чистить безопасно, кого будить, если это том базы. Без регламент каждый инцидент снова превращается в импровизацию.

Раз в месяц проверяйте, что ротация логов и жизненный цикл бэкапов реально срабатывают. Политика на бумаге не освобождает гигабайты. И вынесите бэкапы с продового диска — это правило номер один против повторного сюжета.

Связка диска с бизнес-сервисами

В мониторинге подпишите тома человеческими именами: «база заказов», «логи витрины», «бэкапы». Дежурному в три ночи некогда вспоминать буквы разделов.

Добавьте синтетические проверки записи: иногда график ещё зелёный, а приложение уже не может создать временный файл. Простая проверка «можно ли писать» ловит край раньше пользователей.

Если используете контейнеры, отдельно мониторьте место docker-данных и политику очистки образов. Классический сюрприз — root-раздел чистый, а контейнерный том забит слоями.

После расширения диска обязательно пересмотрите пороги и retention. Новый объём без политики — лишь отложенный повтор инцидента на более дорогом хранилище.

Полезный приём — прогноз «дней до заполнения» на основе тренда. Даже грубая оценка меняет поведение команды: вместо тушения ночных пожаров появляется плановая очистка и расширение. Этот показатель стоит вынести рядом с процентом занятости.

Согласуйте с разработкой уровни логирования по окружениям. На проде debug, оставленный «на неделю», — одна из самых дорогих привычек. То же касается временных дампов и выгрузок «на диск сервера, потом удалим».

Если сервис в облаке, отдельно проверьте, не маскирует ли авторасширение тома проблему. Счёт растёт тихо, политика хранения не появляется, а привычка «место само добавится» закрепляется. Алерт по стоимости хранения здесь такой же важный, как алерт по процентам.

В конце зафиксируйте ответственного за ёмкость: кто получает критичные алерты и кто имеет право расширять том. Пока это «общее дело», диск снова забьётся незаметно.

Итог

«Диск забился незаметно» — почти всегда про отсутствие порогов и политики хранения, а не про злой рок. Ночной простой и полдня восстановления обходятся дороже, чем настройка алертов и retention.

Сделайте заполнение диска видимым заранее и уберите привычку складировать бэкапы и логи «на том же диске, там места много». Тогда ночные падения перестанут быть регулярным ритуалом.