VPS на месяц для запуска продукта: подготовка, нагрузочный тест и закрытие стенда

Откройте календарь проекта и найдите на нём две даты. Первая обведена красным: запуск. Вторая, как правило, отсутствует вовсе, а именно она решает, будет ли у вас через полгода аккуратный архив или забытый сервер, который тихо продолжает жить своей жизнью. Если VPS берётся на месяц, у него должна быть не только дата рождения, но и дата закрытия, причём с запасом времени на то, чтобы вынести всё ценное.

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

Месяц не равен тридцати дням работы

Самая частая ошибка: считать, что месяц аренды — это месяц активного использования. На деле у временного стенда три фазы, и они неравны по длине и по смыслу.

• Подготовка. Сервер уже оплачен, но трафика нет. Вы ставите окружение, разворачиваете приложение, подключаете домен, настраиваете логи и резервное копирование.
• Активный период. Продукт принимает реальных пользователей или хотя бы реальных тестировщиков. Здесь ресурсы работают по-настоящему.
• Завершение. Трафик остановлен, идёт выгрузка данных, отключение внешних зависимостей и удаление.

Учебный план короткого проекта может выглядеть так. Это условная раскладка для примера, а не отчёт о чьём-то реальном запуске, и пропорции вы подгоните под свой продукт.

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

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

Сколько ресурсов брать: отправная точка, а не обещание

Планы MAATRIX различаются по ресурсам: Ba — 1 vCPU, 2 ГБ RAM, 40 ГБ NVMe; Uab — 2 vCPU, 4 ГБ, 80 ГБ; Heka — 4 vCPU, 8 ГБ, 160 ГБ; Maat — 8 vCPU, 16 ГБ, 240 ГБ; Djed — 16 vCPU, 32 ГБ, 320 ГБ. Эти цифры — описание конфигурации, но не гарантия того, сколько пользователей выдержит ваше приложение. Это зависит от кода, базы, кеша, размера страниц и поведения людей. Источник: публичная страница VPS MAATRIX, где также указаны NVMe, процессоры AMD EPYC, root-доступ и локации UK, US, RU и FR.

Разумный способ выбрать план для короткого проекта — не угадывать, а начать с наименьшего подходящего по объёму памяти и диска и проверить его нагрузкой. Методология оптимизации затрат от AWS предлагает смотреть на связку из функциональных требований, фактического использования ресурсов и соответствия мощности спросу (AWS Well-Architected Cost Optimization Pillar). Для нашей задачи вывод простой: размер стенда определяется требованиями запуска и измерениями, а не желанием «взять с запасом на всякий случай». Если измерение показало, что процессор простаивает, а память на пределе, переходить нужно на план с большим объёмом памяти, а не просто «на следующий».

Месячный стенд хорош тем, что ошибку выбора можно исправить дёшево по времени: заказать конфигурацию, проверить, при необходимости перенести проект на другую. Но «дёшево» работает, только если перенос подготовлен: приложение разворачивается по записанной инструкции, а не по памяти того, кто его настраивал в первый день. Условия оплаты и сроки конкретного заказа смотрите в форме заказа и в предложении: оплата картой РФ и СБП указана в публичном предложении, сервер создаётся автоматически через пару минут после оплаты, но почасовая тарификация или автоматический возврат за неиспользованные дни из этих данных не следуют, и закладывать их в расчёт не нужно.

Реестр: что вы на самом деле создаёте вместе с сервером

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

Главная мысль реестра: каждое действие закрытия должно быть парным действию создания. Выдали ключ — запишите, где его отзывать. Завели запись в DNS — запишите, кто её удаляет. Самые неприятные находки при закрытии стенда — не сам сервер, а забытый токен с широкими правами или поддомен, который по-прежнему указывает на чужой теперь IP-адрес. С таким поддоменом связаны вполне конкретные риски, и они не исчезают от того, что проект закончен.

Владелец данных назначается до первого пользователя

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

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

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

Нагрузочная проверка: место в календаре и критерии прохождения

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

В инструменте k6 есть механизм thresholds: он задаёт условия прохождения теста по метрикам, например по задержке ответов или доле ошибок, и невыполненное условие делает результат теста неуспешным (документация Grafana k6). Для месячного проекта это удобно по простой причине: критерий «достаточно ли хорош стенд» записан заранее, а не определяется на глаз под давлением дедлайна. Какие именно значения подставить, решаете вы: примеры из документации не являются целевыми показателями вашего сайта, и переносить их без размышления не стоит. Спросите себя, какая задержка для вашего продукта ещё приемлема и какая доля ошибок означает, что пользователь уйдёт.

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

1. Сначала один прогон на пустой базе. Он покажет базовое поведение приложения. Но он оптимистичен: пустая база и холодный трафик не похожи на реальность.
2. Затем прогон на наполненных данных. Загрузите объём, близкий к ожидаемому, и повторите сценарий. Многие запросы замедляются именно из-за размера таблиц.
3. Потом сценарий, похожий на запуск. Если вы рассылаете письмо, трафик придёт волной в первые минуты, а не ровной линией. Профиль нагрузки должен повторять эту волну.
4. Резерв на исправление. После теста найдутся узкие места. Оставьте два-три дня на то, чтобы их устранить и повторить прогон.

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

Логи, которые не должны съесть диск за месяц

В коротком проекте диск почему-то считают бесконечным, потому что «всё равно скоро удалим». Но именно за активный период, особенно после нагрузочных прогонов, логи способны заполнить его сильнее всего остального. Если приложение работает в контейнерах Docker с драйвером json-file, полезно знать: параметры max-size и max-file управляют ротацией логов, а по умолчанию max-size не ограничен. Кроме того, изменения настроек логирования на уровне демона применяются к новым контейнерам, а существующие автоматически не перенастраиваются (документация Docker по json-file).

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

Выгрузка результата: делайте её как репетицию, а не как спасательную операцию

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

Если для резервных копий вы используете restic, его механизм восстановления хорошо подходит для проверки. Команда restore извлекает выбранный снимок в отдельный каталог назначения; при этом флаг --path помогает выбрать снимок по пути, а --include и --exclude ограничивают набор извлекаемых файлов, и это разные действия, которые легко перепутать. Есть и фильтры, позволяющие выбрать последний снимок конкретного хоста и пути, а восстановление в отдельную директорию позволяет сначала посмотреть результат (документация restic по восстановлению). Для закрытия стенда из этого следует рабочее правило: восстанавливайте в чистый временный каталог, открывайте файлы, сверяйте количество записей, и только потом считайте копию годной.

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

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

Автоматические задачи, о которых никто не вспомнит

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

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

Домены и ключи: что остаётся после сервера

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

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

Продолжать или закрыть: решение за три дня до конца

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

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

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

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

Порядок закрытия: один вечер, который не страшно

Если всё сделано заранее, последний день закрытия скучен, и это хороший знак. Вот примерная последовательность:

1. Остановить приём новых данных: включить заглушку или закрыть форму.
2. Отключить cron, таймеры и фоновые обработчики.
3. Сделать финальную выгрузку базы и каталогов с загрузками.
4. Восстановить выгрузку в чистое место и проверить её: открыть, посчитать записи, сверить с источником.
5. Передать копию владельцу данных и получить подтверждение, что она его устраивает.
6. Сохранить конфигурацию и инструкцию развёртывания, чтобы проект можно было поднять снова.
7. Отозвать ключи и токены, удалить webhook, убрать DNS-записи и записи в белых списках.
8. Удалить сервер.
9. Сделать последнюю отметку в реестре: что закрыто, кем, когда.

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

Когда календарь сходится

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

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