Пробный VPS для бизнеса: какие проверки провести до переноса клиентов

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

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

Выбираем одну операцию, которая болит сильнее остальных

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

• Какая операция самая тяжёлая для процессора, диска или базы данных?
• Какая операция происходит в самый неудобный момент, когда пользователей больше всего?
• После какой операции ошибку замечает клиент, а не только администратор?

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

Сформулируйте вопрос письменно, с числами, которые вы выбрали сами: «Вечерний пакет из такого-то числа отчётов завершается за время, которое нас устраивает, пока одновременно работает обычное число сотрудников». Числа здесь ваши, они вытекают из вашего бизнеса. Не берите их из чужих статей и не переносите значения из примеров документации: чужое «p95 меньше 500 мс» не является требованием к вашему сайту.

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

Ещё одна полезная привычка: сразу записать, что считается провалом. Например, не только «не уложились во время», но и «часть писем не ушла», «PDF получился пустым», «после прогона на диске не осталось места под вложения». Критичная операция может завершиться формально успешно и при этом испортить результат, а секундомер этого не заметит.

Как ресурсы тарифа связаны с вопросом

У MAATRIX в публичном предложении есть тарифы от Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) до Djed (16 vCPU, 32 ГБ, 320 ГБ), между ними Uab, Heka и Maat. Эти цифры — отправная точка, а не обещание ёмкости. Нельзя сказать заранее, что ваша система заявок уместится в Uab; можно только выбрать тариф, который выглядит разумным по текущему потреблению старого сервера, и проверить гипотезу на своей операции. Если рендеринг PDF упирается в процессор, то при тесте вы увидите это по загрузке ядер и сможете осознанно решить, нужен ли тариф крупнее. Если упирается в память, картина будет другой. Пробный период как раз и нужен, чтобы увидеть, что именно становится узким местом.

Безопасные данные и зависимости: что взять с собой

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

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

Объём данных влияет на результат сильнее, чем кажется. Запрос, который на пустой базе отрабатывает мгновенно, на реальном объёме может перебирать таблицу целиком. Если вы заодно меняете СУБД, например переходите с MySQL на PostgreSQL, отдельные запросы поведут себя иначе, и об этом есть разбор подводных камней такого переноса. В этом случае пробный период стоит считать проверкой не только сервера, но и самой миграции.

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

Измерять нужно из той сети, откуда придут люди

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

Для разовой диагностики подходит curl с выводом временных меток. В руководстве curl описано, что time_namelookup, time_connect и time_appconnect отсчитывают время от начала операции до завершения DNS, TCP-соединения и TLS-рукопожатия. Там же сказано, что time_starttransfer включает обработку запроса сервером до первого байта, а time_total — полную длительность. Важная деталь: эти показатели накопительные, и складывать их как независимые этапы нельзя. Чтобы понять, сколько заняло именно соединение по TLS, нужно вычесть time_connect из time_appconnect, а не прибавлять одно к другому.

Практический смысл такой разбивки в диагностике. Если большая часть времени ушла до time_connect, проблема в сети или DNS, и более мощный тариф её не исправит. Если между time_appconnect и time_starttransfer прошла почти вся длительность, виновато приложение или база. Если time_total сильно больше time_starttransfer, значит, дело в передаче тела ответа: большие файлы, медленный канал на стороне клиента. Три разные причины требуют трёх разных решений, и без разбивки вы бы просто увидели «медленно».

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

Заодно полезно сравнить холодный и тёплый запросы. Первый после простоя может занять больше времени из-за пустых кэшей; если вечерний пакет запускается раз в сутки, то именно «холодный» сценарий для него и является рабочим, и усреднять его с тёплыми повторами не стоит.

Сделайте замер несколько раз в разное время суток, а не один раз. Один замер показывает момент, а не поведение. Запишите условия: откуда мерили, во сколько, что одновременно происходило в приложении.

Повторяем операцию и смотрим на сервер, а не только на секундомер

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

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

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

• загрузка процессора по ядрам: все ли ядра заняты или работает только одно;
• занятая память и использование подкачки: если подкачка растёт, памяти не хватает;
• свободное место на диске до и после серии прогонов;
• число соединений с базой и время самых медленных запросов;
• размер очереди задач в начале и в конце прогона.

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

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

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

Внешний API: проверяем не себя, а дорогу

Наша система обращается к стороннему сервису. На новом сервере другой IP-адрес и, возможно, другая страна размещения. Внешний сервис может иначе отвечать на запросы из этой сети, ограничивать адрес по списку допустимых или просто работать медленнее на новом маршруте. Заранее об этом ничего не известно, и обещать доступность стороннего API с иностранного адреса нельзя. Поэтому вызов API нужно проверить именно с пробного VPS, с реальными, но безопасными тестовыми ключами и в тестовой среде поставщика, если она есть.

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

Письмо, которое должно дойти

Если система отправляет письма клиентам, пробный период — удобный момент проверить почтовую часть. Для отправителей Gmail требует SPF или DKIM, корректные прямые и обратные DNS-записи и TLS, а для массовой рассылки требования строже. Из этого следует практический порядок: убедиться, что у IP-адреса нового сервера настроена обратная запись, что домен отправителя содержит нужные записи, и что соединение шифруется.

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

Бывает и так, что транзакционные письма удобнее отдавать внешнему почтовому сервису, а не отправлять напрямую с VPS. Это решение стоит принимать по результатам пробной отправки, а не заранее.

Восстановить один файл, а не весь сервер

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

Если вы используете restic, то согласно документации по восстановлению, restore извлекает выбранный снимок в отдельный целевой каталог. Опция --path влияет на выбор снимка, а --include и --exclude ограничивают извлекаемые файлы, и это разные действия: перепутав их, можно получить не тот результат. Есть фильтры для выбора последнего снимка конкретного хоста и пути. Восстановление в отдельную директорию позволяет сначала проверить результат и только потом переносить файл на место.

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

Чего короткий опыт не может проверить

Теперь самая честная часть. Пробный период — это недели, а иногда дни. За это время нельзя увидеть:

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

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

Запись решения

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

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

Как воспользоваться временем, пока оно идёт

Практически это значит следующее. Закажите VPS с ресурсами, которые выглядят разумно для вашей операции; у MAATRIX это один из тарифов от Ba до Djed с NVMe, процессорами AMD EPYC и root-доступом, а в публичном предложении указаны локации UK, US, RU и FR. Точные условия, наличие нужной ОС и образов, например n8n или Nextcloud с установкой, проверяйте в форме заказа: одинаковая доступность всех образов во всех локациях не подтверждена. Оплата картой РФ и по СБП, а сервер создаётся автоматически через пару минут после оплаты, так что на подготовку стенда не уйдёт много времени. Условия самого пробного периода и возможные ограничения уточняйте до заказа: здесь мы ничего не утверждаем.

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

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