Когда компании пора уходить с VPS: история одного затянувшегося переезда

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

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

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

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

Первые тревожные сигналы

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

Разработчики увеличили объём оперативной памяти и процессорные ресурсы. На некоторое время это помогло.

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

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

Компания могла снова перейти на более дорогой VPS. Однако команда уже понимала, что проблема не только в объёме ресурсов. Приложение, база данных, файлы и резервные копии по-прежнему зависели от одной виртуальной машины.

В этот момент компания начала рассматривать не очередной тариф VPS, а полноценную облачную инфраструктуру, в которой отдельные компоненты системы можно разместить на разных виртуальных машинах, связать собственной сетью и масштабировать независимо друг от друга. Например, инфраструктура Сервер Молл Cloud работает на базе OpenStack и позволяет управлять виртуальными машинами, сетями и томами хранения как отдельными ресурсами.

Сбой, после которого откладывать уже не получилось

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

Переломный момент наступил после очередного обновления приложения.

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

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

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

После этого VPS перестали воспринимать как удобное и недорогое решение. Он стал единой точкой отказа, от которой зависела работа всего продукта.

Почему увеличение VPS уже не решало задачу

У компании оставалось три варианта.

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

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

Второй вариант — арендовать несколько независимых VPS. На одном разместить приложение, на другом базу данных, на третьем резервные копии.

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

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

Не потому, что VPS «плохой». Компания просто переросла формат, который хорошо подходил ей на старте.

Как разделили систему

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

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

После аудита новую инфраструктуру разделили на несколько частей.

Приложение перенесли на отдельные виртуальные машины. База данных получила собственный сервер и диск. Пользовательские файлы перестали храниться в одной папке рядом с кодом приложения. Резервные копии вынесли из основной рабочей среды.

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

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

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

Самым сложным оказался не перенос

Команда предполагала, что основная проблема возникнет при копировании базы данных. На практике больше времени заняла подготовка.

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

Пришлось отделять действительно нужные компоненты от технического наследия.

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

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

Фактически компания получила пользу ещё до окончательного переезда. Команда впервые за долгое время увидела, как на самом деле устроен её продукт.

Переезжали в два этапа

Полностью остановить сервис на день было нельзя, поэтому миграцию разделили.

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

Затем настроили перенос рабочей базы. На заключительном этапе сервис остановили на короткое техническое окно, синхронизировали последние изменения и переключили пользователей на новую среду.

Старый VPS не отключили сразу. Его оставили в резерве на случай, если команда обнаружит проблему, которую не заметили во время тестирования.

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

Что изменилось после перехода

Пользователи не увидели радикально нового интерфейса. Продукт выглядел так же, как раньше. Главное изменение почувствовала команда.

Разработчики перестали согласовывать каждое техническое действие с вопросом: «А сервер выдержит?»

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

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

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

Стало ли дешевле

В первый месяц — нет.

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

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

Экономический смысл проявлялся в другом.

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

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

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

Пять признаков, что компания переросла VPS

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

Второй — сервер регулярно приходится увеличивать целиком, хотя ресурсов не хватает только одному компоненту.

Третий — резервные копии хранятся рядом с основной системой или их восстановление никогда не проверялось на практике.

Четвёртый — производительность зависит не столько от количества пользователей, сколько от случайного совпадения фоновых задач, отчётов и обновлений.

Пятый — простой уже можно перевести в конкретные потери: сорванные операции, обращения клиентов, штрафы или репутационный ущерб.

Ни один из этих признаков сам по себе не требует немедленного переезда. Но если компания узнаёт сразу несколько, очередное увеличение VPS, вероятно, лишь отложит решение.

VPS не нужно покидать раньше времени

После подобных историй легко сделать вывод, что VPS подходит только для самых маленьких проектов. Это не так.

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

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

Компания из нашего кейса не ушла с VPS из-за одного сбоя. Сбой только сделал заметной проблему, которая накапливалась несколько лет: продукт вырос, а инфраструктура осталась на уровне первого рабочего прототипа.

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

Потому что переход в облако под давлением аварии — это спасательная операция. А запланированный переход — обычный этап взросления продукта.