Диск растёт на три процента в неделю: считаем, когда он кончится

MAATRIX

Мониторинг показывает: диск растёт на 3% в неделю. Цифра выглядит скромно — но это не то же самое, что «15 гигабайт в неделю», даже если сегодня 3% от занятого места как раз равны 15 гигабайтам. Проценты считаются от текущего объёма, а он сам растёт — значит, и абсолютный прирост в гигабайтах будет расти от недели к неделе, а не оставаться постоянным. На конкретном числовом примере ниже разница между «посчитать линейно» и «посчитать по проценту от текущей базы» даёт почти месяц расхождения в дате, когда диск реально закончится — и в какую сторону ошибается наивный расчёт, тоже важно.

Почему рост «на N% в неделю» — это экспонента, а не прямая

Линейный рост — это когда каждую неделю к занятому месту прибавляется одна и та же величина в гигабайтах: условно, ровно 15 ГБ, независимо от того, сколько уже занято. Такой характерен для логов с примерно постоянной интенсивностью или для ежедневной выгрузки фиксированного объёма данных — прирост определяется внешним процессом, а не размером уже накопленного.

Рост «на 3% в неделю» устроен иначе: прибавка считается не от постоянной величины, а от текущего занятого объёма. Формально это записывается так:

U(n) = U0 × (1 + r)^n

где U0 — занято сейчас, r — недельная ставка роста (3% = 0.03), n — число прошедших недель. Это классическая формула сложного процента, и она даёт именно экспоненциальный, а не линейный рост: чем больше уже занято, тем больше абсолютный прирост в следующую неделю, при том что процент остаётся неизменным.

Разница видна на первых же неделях, если взять диск с 500 ГБ занятого места и ставкой роста 3% в неделю:

Процент везде один и тот же — 3%. А вот прирост в гигабайтах уже на пятой неделе на 13% больше, чем на первой. Если этого не учитывать и просто взять «текущие 15 ГБ в неделю» как константу, прогноз даты исчерпания будет систематически смещён — и, как показано ниже, не в безопасную сторону.

Пример: диск 500 из 800 ГБ, наивный линейный прогноз

Возьмём конкретные (иллюстративные) числа: диск на 800 ГБ, сейчас занято 500 ГБ, свободно 300 ГБ. По истории последней недели видно, что занятое место выросло с примерно 485,4 ГБ до 500 ГБ — то есть на 3% и на 15 ГБ одновременно, потому что 3% от 500 как раз и есть 15.

Метод из материала про ежемесячный прогноз свободного места на диске — линейная регрессия или расчёт по двум точкам — в данном случае даст: взять текущий недельный прирост как постоянную скорость и линейно продлить её до нуля свободного места.

used_now = 500    # ГБ
total = 800       # ГБ
free_now = total - used_now
weekly_increment = 15  # ГБ — прирост ЗА ПОСЛЕДНЮЮ неделю, взят как константа

weeks_left = free_now / weekly_increment
print(f"Линейный прогноз: {weeks_left:.1f} нед. ({weeks_left*7:.0f} дней)")
# Линейный прогноз: 20.0 нед. (140 дней)

Наивный линейный прогноз: диск закончится через 20 недель, то есть примерно через 140 дней. Число выглядит убедительно и вполне применимо — это ровно тот метод, который отлично работает, когда рост действительно линейный. Проблема в том, что здесь рост не линейный: он на 3% от базы, а база растёт вместе с прогнозом.

Точный расчёт: экспоненциальная формула и когда диск закончится на самом деле

Если рост описывается формулой U(n) = U0 × (1+r)^n, то момент, когда занятое место достигнет целевого значения (например, всего объёма диска), находится из того же уравнения, решённого относительно n:

n = log(target / U0) / log(1 + r)

Это логарифм отношения целевого объёма к текущему, делённый на логарифм коэффициента роста. Считается в одну строчку:

import math

def weeks_to_reach(used_now, target, weekly_rate):
    if target <= used_now:
        return 0.0
    return math.log(target / used_now) / math.log(1 + weekly_rate)

used_now = 500
total = 800
weekly_rate = 0.03

weeks = weeks_to_reach(used_now, total, weekly_rate)
print(f"Экспоненциальный прогноз: {weeks:.1f} нед. ({weeks*7:.0f} дней)")
# Экспоненциальный прогноз: 15.9 нед. (111 дней)

Точный расчёт даёт 15,9 недели — примерно 111 дней. Против 140 дней у линейной модели. Разница — почти месяц, и она не в пользу спокойствия: диск закончится раньше, чем предсказывает наивная линейная экстраполяция.

Причина в самой природе ошибки: линейная модель замораживает скорость роста на том значении, которое замерила в момент расчёта — 15 ГБ в неделю. Но при росте «на процент от базы» скорость сама растёт вместе с базой (см. таблицу приростов выше). Линейная модель не видит этого ускорения и раз за разом недооценивает будущий прирост — значит, она систематически переоценивает оставшееся время. Это важно понимать именно в эту сторону: ошибка линейной модели при экспоненциальном росте — это ошибка в сторону ложного спокойствия, а не ложной тревоги.

Сравнение: насколько расходятся прогнозы и почему разрыв растёт с горизонтом

Разница между моделями — не фиксированное число, а функция от того, как далеко в будущее вы считаете. Если посчитать обе модели не только для полного заполнения диска, а для нескольких порогов, видно, что расхождение нарастает нелинейно:

На ближнем горизонте (75% — на 4–5 недель вперёд) разница в 3,5 дня почти не влияет на решения: обе модели говорят «есть больше месяца в запасе, действовать пока не нужно». А вот на горизонте полного заполнения диска расхождение — почти четыре недели. Это ровно тот масштаб ошибки, который превращает «спокойный месяц на закупку и миграцию» в «мы уже опоздали».

Практический вывод из таблицы: чем ближе порог реакции к текущему занятому объёму, тем меньше цена ошибки от использования не той модели. Чем порог дальше — тем больше цена. Значит, если для дальних порогов (типичного «есть 90+ дней, можно не спешить») используется линейная модель, а рост на самом деле экспоненциальный, есть риск получить ложное чувство запаса времени именно там, где оно особенно опасно.

Как определить характер роста своих данных, прежде чем считать прогноз

Прежде чем применять любую из формул, стоит проверить, какая из них вообще соответствует наблюдаемому росту — а не выбирать формулу по умолчанию. Для этого нужна история использования диска за несколько недель (сбор такой истории через df и cron разобран в материале про ежемесячный прогноз, ссылка выше) и простая проверка: что стабильнее — абсолютный недельный прирост в гигабайтах или относительный прирост в процентах.

import statistics

# used — список значений занятого места по неделям, например:
# used = [485.4, 500.0, 515.0, 530.5, 546.4, 562.8]

diffs_abs = [b - a for a, b in zip(used[:-1], used[1:])]
diffs_pct = [(b - a) / a for a, b in zip(used[:-1], used[1:])]

def cv(values):
    m = statistics.mean(values)
    return statistics.pstdev(values) / m if m else float("inf")

print("Разброс абсолютного прироста (ГБ/нед):", round(cv(diffs_abs), 3))
print("Разброс процентного прироста (%/нед):", round(cv(diffs_pct), 3))

Коэффициент вариации (pstdev / mean) ближе к нулю у того ряда, который стабильнее. Если стабильнее абсолютный прирост в гигабайтах — рост линейный, и подходит метод линейной регрессии из материала про ежемесячный прогноз. Если стабильнее процент — рост экспоненциальный, и нужна формула с логарифмом из раздела выше.

По опыту эти два характера роста тяготеют к разным источникам данных:

• Линейный рост чаще у: логов с примерно постоянной интенсивностью запросов, ежедневных выгрузок фиксированного объёма, ротируемых бэкапов с предсказуемым размером снапшота.
• Экспоненциальный рост чаще у: данных, которые растут вместе с растущей пользовательской базой (а не с фиксированным внешним источником), таблиц истории изменений, которые логируют операции над уже растущим набором данных, векторных индексов, где переиндексация или расширение коллекции происходит пропорционально уже накопленному объёму — похожий сценарий разобран в материале о том, как векторная база выросла в 10 раз за неделю.

Стоит также проверить третий вариант: если сам процент прироста от недели к неделе растёт (не 3%, а 3%, потом 3.4%, потом 4.1%) — это ускоряющийся, супер-экспоненциальный рост, и обе рассмотренные модели дают слишком оптимистичный прогноз. Здесь единственный надёжный способ — не полагаться на один расчёт, а пересчитывать чаще и следить за трендом самой ставки роста, а не только за прогнозной датой.

Что делать: пороги реакции и частота пересчёта при экспоненциальном росте

Пороги реакции, разумные для линейного роста (действовать при 30 днях в запасе, тревога при 7), для экспоненциального роста нужно сдвигать раньше — именно потому, что скорость там сама нарастает, и промедление на пару недель обходится дороже:

• Порог действия — не 30, а 45–60 дней до целевого порога. При экспоненциальном росте прогноз меняется быстрее, и запас на «неожиданно ускорилось» нужен больше, чем при линейном.
• Пересчёт — не раз в месяц, а раз в неделю. Экспоненциальная ставка роста может незаметно сместиться (с 3% на 4% в неделю выглядит как мелочь, но на горизонте нескольких месяцев это совсем другая дата). Еженедельный пересчёт по свежим данным ловит это сообщение вовремя, ежемесячный — с опозданием.
• Целевой порог для расчёта — не 100%, а 75–80% занятости. Расширение диска или миграция данных редко занимают меньше нескольких дней; при ускоряющемся росте лучше посчитать расчётную дату до более раннего и консервативного порога, чем до полного заполнения. Заодно это даёт запас на случай, если ставка роста между пересчётами подрастёт. Сколько запаса закладывать при первичном планировании объёма — отдельный вопрос, разобранный в материале сколько дискового пространства закладывать с запасом.
• Сам процесс расширения стоит спланировать заранее, а не по факту тревоги — включая то, требует ли он простоя. Это разобрано в материале как расширить диск на работающем сервере.

Отдельно стоит вести не только текущий прогноз, но и историю самой ставки роста: если она растёт от расчёта к расчёту (3% → 3.5% → 4.2%), это более ранний и надёжный сигнал тревоги, чем сама прогнозная дата — дата пересчитается автоматически, а вот замеченный вовремя тренд ускорения даёт время подготовиться до того, как прогноз резко «просядет».

Частые вопросы