Что проверить на сервере раз в квартал, чтобы не удивиться в декабре

MAATRIX

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

Зачем нужна именно квартальная ревизия

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

• ёмкость растёт быстрее, чем вы успеваете это заметить по графикам;
• договор с хостером автоматически продлевается на невыгодных условиях;
• DR-план последний раз проверяли на бумаге, а не на реальном сервере;
• бюджет на следующий квартал верстается по цифрам полугодовой давности.

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

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

Нагрузочный тест или прогноз пиковой нагрузки

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

Шаг 1. Соберите базовые метрики за квартал. Не гадайте, а посмотрите, как менялась нагрузка:

# Загрузка CPU и очередь за последние 90 дней (если метрики хранятся в Prometheus)
curl -s 'http://localhost:9090/api/v1/query_range?query=avg(rate(node_cpu_seconds_total{mode!="idle"}[5m]))&start=$(date -d "90 days ago" +%s)&end=$(date +%s)&step=3600'

# Быстрый снимок текущей загрузки без Prometheus
vmstat 1 5
iostat -xz 1 5

Если метрик за квартал нет вообще — это уже находка ревизии: без истории нагрузки любой прогноз на декабрь — гадание.

Шаг 2. Прогоните нагрузочный тест на конфигурации, близкой к боевой. Не на ноутбуке разработчика и не с той же машины, где крутится продакшн (иначе тест меряет сам себя). Простой вариант через wrk:

wrk -t4 -c200 -d60s --latency https://your-service.example.com/api/checkout

Для более реалистичного сценария с несколькими эндпоинтами и постепенным наращиванием нагрузки — k6:

// loadtest.js
import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 50 },
    { duration: '5m', target: 300 },  // ожидаемый пик x N от обычной нагрузки
    { duration: '2m', target: 0 },
  ],
};

export default function () {
  http.get('https://your-service.example.com/');
  sleep(1);
}

k6 run loadtest.js

Смотрите не только на RPS, а на то, где начинает расти латентность p95/p99 и когда появляются ошибки 5xx — это и есть реальный потолок текущей конфигурации, а не паспортные характеристики сервера.

Шаг 3. Если нагрузочный тест невозможен (например, тестировать боевой checkout рискованно) — делайте прогноз на исторических данных. Возьмите пиковый день прошлого декабря (если он был) или ближайший аналог — распродажу, релиз, публикацию в СМИ — и сравните с текущей средней нагрузкой. Если прошлый пик был x3 от обычной нагрузки, а сейчас средняя нагрузка выросла в 1.5 раза за счёт органического роста, планируйте резерв с учётом обоих факторов, а не только исторического множителя. Подробнее о том, как считать конфигурацию под нагрузку, — в статье как рассчитать конфигурацию сервера под нагрузку.

Зафиксируйте результат в одном документе: текущий потолок по CPU/RAM/сети, во сколько раз вырос трафик за последний аналогичный пик, и требуется ли апгрейд до конца года.

Ревизия бюджета на инфраструктуру на следующий квартал

Бюджет на инфраструктуру редко пересматривают вовремя — обычно его продлевают "как в прошлый раз" и вспоминают о нём, когда счёт вырос вдвое без видимой причины. Квартальная ревизия — момент сверить факт с планом.

Что смотреть:

• Фактические расходы за квартал по каждой статье — серверы, трафик, бэкапы, мониторинг, лицензии, поддержка. Разница между "предполагали" и "заплатили" — первый сигнал.
• Утилизация оплаченных мощностей. Если резервный сервер держится в горячем режиме "на всякий случай", а загружен на 8% весь квартал — это осознанная плата за спокойствие или забытая статья расходов? Оба варианта нормальны, но должны быть осознанными.
• Скрытые статьи, которые легко забыть при планировании: исходящий трафик сверх лимита, снапшоты и бэкапы, которые накапливаются и не удаляются, лицензии, продлевающиеся автоматически.
• Резерв на непредвиденное. Даже консервативный бюджет должен закладывать запас на случай, если пиковая нагрузка потребует срочного апгрейда в ноябре-декабре, когда договариваться о скидках уже некогда.

Практический подход — свести всё в простую таблицу и обновлять её каждый квартал:

Строка с отклонением +180% по трафику — типичный пример находки, которую иначе заметили бы только в декабрьском счёте, когда сумма выросла ещё сильнее из-за сезонного трафика. О том, какой процент запаса закладывать в бюджет на инфраструктуру и почему "точно в ноль" — плохая стратегия, подробнее в статье сколько запаса закладывать в бюджет на инфраструктуру.

Проверка договоров и сроков продления у провайдеров

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

Чек-лист по каждому провайдеру (хостинг, CDN, DNS, почта, мониторинг, лицензии ПО):

• Дата окончания текущего периода и правило автопродления. Продлевается автоматически или требует подтверждения? За сколько дней провайдер уведомляет о продлении?
• Условия расторжения. Сколько занимает вывод данных и миграция, если решите сменить провайдера — это особенно важно проверить заранее, а не в декабре, когда времени на миграцию не будет.
• SLA и что реально в нём написано. Проценты аптайма звучат солидно, но важнее — что считается инцидентом, как считается компенсация и распространяется ли SLA на резервные каналы и DNS.
• Актуальность тарифа. Провайдеры регулярно обновляют линейки тарифов — иногда старый тариф оказывается дороже нового с теми же характеристиками просто потому, что никто не проверял.
• Контактные лица и эскалация. Если с момента подписания договора сменился ответственный менеджер или техподдержка перешла на другой канал — зафиксируйте актуальные контакты сейчас, а не во время инцидента.

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

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

План резервирования мощностей под сезонный пик

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

Три уровня резерва, между которыми выбирают в зависимости от бюджета и критичности:

1. Холодный резерв. Инфраструктура описана как код (Terraform/Ansible), но не развёрнута. Дёшево, но время на разворачивание — часы, а не минуты, и есть риск, что образы или зависимости за это время устарели.
2. Тёплый резерв. Минимальная конфигурация уже поднята и обновляется вместе с продакшном, масштабируется под нагрузку за минуты. Компромисс между стоимостью и скоростью реакции.
3. Горячий резерв / автоскейлинг. Дополнительные мощности либо уже в строю и принимают часть трафика, либо поднимаются автоматически по метрикам. Дороже всего, но не требует ручного вмешательства в момент пика.

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

Что зафиксировать в плане резервирования на квартальной ревизии:

• Дату, к которой резерв должен быть готов (обычно за 2-3 недели до ожидаемого пика — не в последний рабочий день перед ним).
• Кто отвечает за активацию резерва — конкретный человек и запасной на случай отпуска.
• Порог по метрикам, при котором резерв включается: например, "если p95 latency стабильно выше 800 мс на протяжении 10 минут — поднимаем дополнительные воркеры".
• Проверку квот у провайдера. Если план — заказать серверы под пик, убедитесь заранее, что у провайдера физически есть свободные мощности в нужной локации: в декабре у хостеров тоже сезонный спрос.
• Тест масштабирования до пика, а не во время него: подняли узел, убедились, что балансировщик его подхватывает, а конфиги совпадают с боевыми, а не с шаблоном полугодовой давности.

Если сезонного пика у бизнеса нет — так и зафиксируйте в ревизии явно, с датой следующей проверки этого допущения. Отсутствие пика тоже может измениться.

DR-план: отработает ли он на практике

DR-план (disaster recovery), который никогда не проверялся восстановлением, — это документ, а не план. Квартальная ревизия — правильный момент устроить контролируемую проверку, а не ждать инцидента.

Минимальный набор вопросов, на которые ревизия должна ответить:

• Восстанавливается ли бэкап на самом деле? Не "задача бэкапа завершилась успешно в логах", а именно восстановление на чистую машину и проверка целостности данных.

# Пример проверки восстановления PostgreSQL из бэкапа на отдельном тестовом сервере
pg_restore -d test_restore_db /backups/latest/db_dump.custom
psql -d test_restore_db -c "SELECT count(*) FROM orders WHERE created_at > now() - interval '1 day';"

• Сколько реально занимает восстановление — и укладывается ли это время в заявленный RTO (recovery time objective). Если план обещает "восстановление за 1 час", а тест показал 4 часа — это надо знать сейчас, а не при реальном сбое.
• Сколько данных теряется при восстановлении из последней точки — это RPO (recovery point objective). Если бэкапы делаются раз в сутки, а бизнес считает потерю 24 часов транзакций неприемлемой — частоту бэкапов нужно менять уже сейчас.
• Актуальны ли инструкции. DR-runbook, написанный полтора года назад, может ссылаться на серверы, которых уже нет, или на человека, который уволился. Проверяйте, может ли восстановление провести не тот, кто писал план, а любой дежурный инженер.
• Работает ли переключение DNS/балансировщика на резервную площадку — и сколько времени занимает распространение изменений с учётом TTL записей.

Полный разбор того, как выглядит рабочий DR-план для небольшой компании и какие ошибки встречаются чаще всего, — в статье disaster recovery plan для малого бизнеса.

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

Как собрать всё это в рабочий регламент

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

Практическая схема, которая работает без лишней бюрократии:

1. Фиксированная дата. Например, первая полная неделя после закрытия квартала — так проще привязать ревизию к финансовой отчётности, которая всё равно готовится в это время.
2. Один документ на квартал, а не разрозненные заметки — таблица или страница в вики с разделами: нагрузка, бюджет, договоры, резерв, DR. В конце — три-пять конкретных задач с ответственными и сроками, не абстрактные "надо подумать над масштабированием".
3. Явное решение по каждому пункту, даже если это "оставить как есть". Молчание по пункту в следующем квартале означает "то же решение, что и в прошлый раз" — это должно быть зафиксировано, а не подразумеваться.
4. Сравнение с прошлой ревизией. Тренд важнее снимка: растёт ли утилизация резерва квартал к кварталу, сокращается ли бюджетный запас, накапливаются ли просроченные пункты DR-плана.
5. Отдельная пометка для Q3→Q4. Ревизия в конце августа-сентябре должна явно отвечать на вопрос "готовы ли мы к декабрю", а не сливаться в общий шаблон, одинаковый для всех кварталов.

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

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