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

MAATRIX

Тестовая среда почти всегда живёт по одному и тому же сценарию: подняли один раз, забыли выключать, и она молча работает месяцами. При этом реально в неё кто-то стучится только в рабочие часы — условно 8-10 часов в будни, если у команды нет ночных дежурств и релизов на выходных. Остальное время сервер греет воздух и потребляет ресурсы, которые вы оплачиваете. Разберёмся, сколько времени из оплаченного вы реально используете, почему для staging это не проблема, а возможность, и как настроить автоматическое расписание, чтобы среда работала тогда, когда она нужна, а не всегда.

Почему тестовая среда работает круглосуточно, хотя нужна 8-10 часов в день

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

• Тестовую среду поднимали в спешке перед релизом и не заложили в план её жизненный цикл — когда включать, когда выключать, кто отвечает.
• В команде есть люди в разных часовых поясах, и кажется, что кому-то она нужна "всегда" — хотя по факту используется узкое окно у каждого.
• Есть страх, что выключенный сервер "не поднимется" или что-то отвалится при следующем запуске, поэтому его проще не трогать.
• Расписание запуска/остановки — это отдельная задача, которую нужно написать, протестировать и поддерживать, а на фоне текущих релизов она всегда в конце списка приоритетов.

В результате возникает разрыв между временем, за которое вы платите (743 часа в месяц для одного сервера), и временем, когда среда реально нужна. Если считать грубо: пять рабочих дней по 8-10 часов — это меньше трети от 24×7. Всё остальное время — ночи, выходные, отпуска и периоды между спринтами — сервер работает вхолостую.

Считаем реальную стоимость простоя

Прежде чем что-то оптимизировать, полезно честно посмотреть, сколько именно тестовая среда простаивает лично у вас. Логика простая:

1. Возьмите фактическое рабочее окно команды — например, будни с 9:00 до 19:00 по вашему часовому поясу (10 часов).
2. Умножьте на количество рабочих дней в месяце — обычно 20-22.
3. Сравните с общим числом часов в месяце (~730-744).

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

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

Почему для тестовой среды ночной простой — это нормально

Ключевое отличие staging от production в контексте этой темы: временная недоступность тестовой среды — это допустимое поведение, а не инцидент. Если ночью упадёт production — это авария, разбор инцидента, возможно, звонок дежурному. Если ночью "упадёт" (а точнее, будет выключен по расписанию) staging — этого никто не заметит до утра, потому что в это время туда никто не ходит.

Это открывает пространство для решений, которые для боевого контура были бы неприемлемы:

• Можно жёстко останавливать сервисы по расписанию, не заботясь о graceful shutdown с той же тщательностью, что в проде — тестовые данные не критичны для бизнеса.
• Можно допускать, что первый запрос после автозапуска утром отработает на 10-20 секунд дольше — пока прогреются кеши и БД.
• Можно не поддерживать высокую доступность и резервирование — тестовой среде почти никогда не нужен second instance на случай отказа.
• Можно синхронизировать расписание с рабочим календарём команды, а не с бизнес-требованиями клиентов.

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

Два уровня экономии: приложение и сама VPS

Здесь важно разделить два разных по эффекту подхода, потому что их часто путают:

Уровень приложения. Вы оставляете сервер включённым, но останавливаете тяжёлые сервисы (докер-контейнеры, БД, воркеры) на ночь и в выходные. Это не уменьшает счёт за аренду VPS — вы всё равно платите за сам сервер по тарифу, — но снижает нагрузку на CPU/RAM/диск, продлевает ресурс железа, снижает фон в логах и мониторинге, и упрощает жизнь, если на одном сервере крутится несколько тестовых окружений и они конкурируют за ресурсы.

Уровень инфраструктуры. Вы останавливаете или полностью пересоздаёте сам сервер. Здесь экономия зависит от модели оплаты у провайдера:

Это честный момент, который стоит проговорить прямо: если вы арендуете VPS помесячно, простое выключение сервера на ночь через shutdown не снизит счёт в конце месяца — вы всё равно платите за зарезервированные ресурсы. Реальная денежная экономия на инфраструктурном уровне достигается либо через тариф с почасовой оплатой, либо через полное удаление сервера и восстановление его из образа/снапшота только на время работы — а это уже отдельная инженерная задача со своими рисками (см. раздел про грабли ниже).

Поэтому практический совет: начните с уровня приложения — он даёт реальную пользу (ресурсы, безопасность, дисциплину) при минимальном риске, а уровень инфраструктуры подключайте только если у вас почасовой тариф или вы готовы автоматизировать полный цикл create/destroy сервера.

Расписание на уровне приложения: cron + docker compose

Если тестовая среда развёрнута в Docker Compose — а это сегодня самый частый случай — расписание можно сделать буквально в несколько строк. Идея: docker compose down вечером, docker compose up -d утром, через cron на самом сервере.

Скрипт остановки /opt/testenv/stop.sh:

#!/usr/bin/env bash
set -euo pipefail

cd /opt/testenv
echo "$(date '+%F %T') stopping test environment" >> /var/log/testenv-schedule.log
docker compose down

Скрипт запуска /opt/testenv/start.sh:

#!/usr/bin/env bash
set -euo pipefail

cd /opt/testenv
docker compose up -d
echo "$(date '+%F %T') started test environment" >> /var/log/testenv-schedule.log

Делаем оба исполняемыми и прописываем в crontab (crontab -e) под тем пользователем, у которого есть права на docker:

# Остановка в 20:00 по будням
0 20 * * 1-5 /opt/testenv/stop.sh
# Запуск в 8:30 по будням
30 8 * * 1-5 /opt/testenv/start.sh
# Полная остановка на выходные (пятница вечером она и так упадёт по правилу выше, но явно продублируем для надёжности)
0 20 * * 5 /opt/testenv/stop.sh

Если вы не пользуетесь Docker и сервисы работают через systemd, тот же принцип реализуется через systemctl stop/systemctl start конкретных unit-файлов в тех же скриптах, либо через systemd-таймеры вместо cron — они удобнее, если нужна логика "пропустить, если сервер был выключен в момент срабатывания":

# /etc/systemd/system/testenv-stop.timer
[Unit]
Description=Stop test environment nightly

[Timer]
OnCalendar=Mon..Fri 20:00
Persistent=false

[Install]
WantedBy=timers.target

Такой подход не требует прав на управление самой VPS — только доступ на сервер по SSH и права на docker/systemctl. Это самый низкорисковый и быстрый способ начать, и его стоит внедрить в первую очередь, даже если вы не планируете трогать сам сервер.

Расписание на уровне инфраструктуры: старт/стоп самого сервера

Если тариф у вас почасовой, или вы держите тестовую среду на отдельном сервере, который в принципе не нужен ночью целиком (включая ОС, сеть, диск), имеет смысл останавливать саму VPS, а не только сервисы внутри неё. Здесь возможны два варианта.

Остановка через саму ОС плюс внешний планировщик. Если провайдер поддерживает "мягкую" остановку сервера (не destroy, а именно stop с сохранением диска), можно из ОС инициировать shutdown по расписанию, а включение делать через панель управления или API провайдера — потому что выключенная машина не может сама себя включить изнутри. Это ключевое отличие от уровня приложения: запуск должен инициироваться снаружи — из панели, по API, либо по расписанию на стороне провайдера, если такая функция есть в тарифе.

Минимальный пример остановки самого сервера по расписанию (только для тестовых машин — на проде так делать нельзя):

# в crontab на самом сервере
0 20 * * 1-5 /sbin/shutdown -h now

Обратный запуск изнутри уже не сделать — понадобится внешний триггер: cron-задача на другой, постоянно работающей машине, которая дёргает API управления сервером, либо расписание в панели провайдера, если она это поддерживает. Прежде чем полагаться на этот сценарий, уточните у своего провайдера, поддерживает ли он программный старт остановленного сервера и как тарифицируется время простоя — у части провайдеров резерв диска и IP оплачивается даже для выключенной машины.

Пересоздание из снапшота. Более радикальный, но иногда более выгодный вариант для по-настоящему эпизодических тестовых сред (например, окружение поднимается на пару часов раз в неделю под конкретный прогон): держать не сам сервер, а его образ/снапшот, и разворачивать новую машину по расписанию, а после работы — удалять. Это снимает плату за вычислительные ресурсы полностью в неактивное время, оставляя только плату за хранение образа, которая обычно на порядок меньше. Плата за такой подход — сложность автоматизации (нужен полноценный provisioning-скрипт, а не просто start/stop) и риск, что окружение "поплывёт" от запуска к запуску, если инфраструктура как код описана не полностью.

Грабли: что легко сломать автоматическим расписанием

Расписание — это автоматизация, которая работает без присмотра, и именно поэтому её стоит один раз тщательно продумать, а не только написать.

• Долгие процессы, которые режутся на середине. Если ночной прогон нагрузочных тестов или миграция данных попадает под то же самое время остановки — вы получите не экономию, а испорченный тестовый прогон. Разведите расписание остановки и расписание тяжёлых задач по времени с запасом, либо добавьте в скрипт остановки проверку, не выполняется ли сейчас что-то важное.
• CI/CD, который ночью деплоит на staging. Если у вас есть ночные автоматические деплои или сборки, которые ожидают, что окружение доступно, расписание выключения их сломает. Либо перенесите такие задачи на рабочее окно, либо явно исключите их из логики "по умолчанию всё выключено".
• Часовые пояса и переход на летнее/зимнее время. Если сервер и cron живут в UTC, а команда — в другом поясе, расписание "поедет" при смене времени. Явно фиксируйте таймзону в cron (TZ=Europe/Moscow в начале crontab) вместо того, чтобы полагаться на системную по умолчанию.
• Состояние, которое теряется при остановке. Если у сервисов есть in-memory кеши, временные сессии или несохранённые данные в оперативной памяти — они пропадут при docker compose down. Для тестовой среды это обычно приемлемо, но команду стоит предупредить заранее, а не давать людям узнать об этом в 9 утра понедельника.
• Мониторинг и алерты, которые не в курсе расписания. Если у вас настроен внешний мониторинг доступности (uptime-проверки, health checks), он будет честно сообщать "сервер недоступен" каждую ночь. Либо отключайте мониторинг тестовой среды на время простоя тем же расписанием, либо заведите отдельное правило, которое не шлёт алерты в нерабочие часы.
• Ручной запуск "на всякий случай", который никто не выключает обратно. Если кто-то из команды разово поднял среду вне расписания (например, для вечернего дебага), она снова рискует остаться работать бесконтрольно. Полезно добавить в скрипт запуска логирование инициатора и напоминание через несколько часов, что среда всё ещё работает вручную.

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

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