После заказа виртуального сервера обычно хочется сразу загрузить файлы, подключить домен и запустить проект. Доступ уже получен, операционная система установлена, IP-адрес отвечает — кажется, что инфраструктура готова.
Но именно первые настройки определяют, насколько спокойно сервер переживёт обновление, перезагрузку, рост нагрузки или попытку взлома. До переноса рабочего проекта стоит потратить немного времени на проверку доступа, безопасности, резервного копирования и мониторинга.
Проверьте, что вы получили именно заказанную конфигурацию
Начать следует с базовой сверки. Проверьте установленную операционную систему, объём оперативной памяти, число процессорных ядер и доступное дисковое пространство. Ошибки при выдаче услуги случаются редко, но обнаружить расхождение до переноса данных намного проще.
Одновременно стоит уточнить:
- какая версия операционной системы установлена;
- доступна ли консоль управления;
- как выполняется переустановка системы;
- можно ли загрузить собственный ISO-образ;
- как восстановить доступ при ошибке в сетевых настройках;
- кто отвечает за администрирование операционной системы.
Последний пункт особенно важен. В большинстве случаев провайдер поддерживает работу физического оборудования и сети, а настройка приложений, обновлений, firewall и резервного копирования остаётся задачей клиента.
Обновите систему до запуска приложений
Готовый образ операционной системы мог быть создан несколько недель или месяцев назад. За это время для установленных компонентов могли выйти исправления безопасности.
Поэтому сначала следует обновить систему и только затем устанавливать веб-сервер, базу данных, панель управления или среду выполнения приложения. Если обновление требует перезагрузки, лучше сделать её сразу, пока сервер ещё не обслуживает пользователей.
Также необходимо проверить системное время и часовой пояс. Неверное время приводит к ошибкам в журналах, заданиях по расписанию, сертификатах и системах авторизации.
Создайте отдельную учётную запись администратора
Постоянная работа от имени root увеличивает последствия любой ошибки. Безопаснее создать отдельного пользователя с административными правами и использовать повышение привилегий только для конкретных действий.
Для подключения по SSH желательно применять ключи вместо обычного пароля. Закрытый ключ хранится на компьютере администратора и не передаётся серверу.
Отключать вход по паролю или запрещать подключение root нужно только после проверки новой учётной записи. Иначе одна опечатка в настройках может полностью заблокировать удалённый доступ. Желательно заранее убедиться, что аварийная консоль провайдера действительно открывается.
Оставьте доступными только необходимые порты
На новом сервере не должны быть публично доступны службы, которыми никто не пользуется. Для обычного сайта чаще всего требуются SSH, HTTP и HTTPS. Остальные порты открываются только при наличии конкретной задачи.
Базы данных, Redis, служебные панели и интерфейсы мониторинга не следует без необходимости выставлять в интернет. Доступ к ним можно ограничить определёнными IP-адресами, внутренней сетью или VPN.
После настройки firewall полезно проверить сервер с внешнего подключения. Важно увидеть не только открытые, но и случайно оставленные доступными порты. Если планируется изменение порта SSH, новое правило сначала добавляют в firewall и проверяют отдельным подключением — только после этого закрывают старое.
Проверьте сервер под реальной нагрузкой
Синтетический тест процессора или диска показывает возможности отдельного компонента, но не гарантирует нормальную работу проекта. Лучше развернуть копию приложения и воспроизвести типовые действия:
- открыть несколько страниц сайта;
- выполнить запросы к базе данных;
- загрузить и скачать файл;
- запустить фоновое задание;
- обработать несколько одновременных обращений к боту или API.
Во время теста следует наблюдать за процессором, оперативной памятью, диском и сетью. Если приложение сразу использует почти все ресурсы, после запуска в рабочей среде запаса для пиков, обновлений и резервного копирования уже не останется.
Медленная работа не всегда означает, что нужен более дорогой тариф. Причиной может оказаться неоптимальный запрос к базе данных, ошибочная конфигурация кеша, слишком тяжёлое расширение CMS или постоянно растущий журнал.
Настройте контроль свободного места
Заполненный диск способен остановить базу данных, нарушить запись журналов и сделать приложение недоступным, даже если процессор и память почти не загружены.
Чаще всего пространство постепенно занимают:
- системные журналы;
- временные файлы;
- кеш приложения;
- старые резервные копии;
- загруженные пользователями материалы;
- Docker-образы и остановленные контейнеры.
Для журналов следует настроить автоматическую ротацию, а для диска — уведомления о приближении к установленному пределу. Старые копии и временные данные нужно удалять по понятным правилам, а не вручную после возникновения проблемы.
Не храните единственную резервную копию на том же VPS
Архив, лежащий рядом с рабочими файлами, помогает после случайного удаления отдельных данных. Но при повреждении файловой системы, потере доступа или компрометации сервера основная информация и её копия могут исчезнуть одновременно.
Резервные копии следует отправлять в отдельное хранилище. Нужно заранее определить:
- какие данные копируются;
- как часто создаются копии;
- сколько версий хранится;
- кто контролирует успешность задания;
- сколько времени займёт восстановление.
Наличие архива ещё не доказывает, что восстановление работает. До переноса проекта полезно вернуть из копии тестовый файл или базу данных и убедиться, что приложение запускается.
Проверьте автоматический запуск после перезагрузки
Веб-сервер может запуститься автоматически, а бот, очередь заданий или отдельный контейнер — нет. Пока администратор работает внутри системы, это легко не заметить.
Перед публикацией проекта сервер стоит перезагрузить и проверить:
- открылся ли сайт;
- подключилась ли база данных;
- запустились ли контейнеры;
- принимает ли бот сообщения;
- работают ли задания по расписанию;
- отправляет ли мониторинг уведомления.
Такой тест позволяет обнаружить зависимости от вручную запущенных процессов и неправильного порядка старта служб.
Переносите проект с возможностью отката
Новый сервер лучше сначала подготовить параллельно со старым. На него копируют файлы и базу данных, проверяют приложение через временный адрес, а затем выполняют финальную синхронизацию.
Перед переключением домена желательно заранее уменьшить время кеширования DNS-записей. Для динамического сайта на время последней синхронизации может потребоваться кратковременно остановить приём новых заказов или изменений.
Старую площадку не следует отключать сразу после смены DNS. Её стоит сохранить на несколько дней, не внося новых данных. Если на новом сервере обнаружится критическая ошибка, это позволит быстрее выполнить обратное переключение.
Если собственной экспертизы для переноса и дальнейшего обслуживания нет, при заказе VPS/VDS в HSTQ можно отдельно согласовать помощь с миграцией и администрированием. До начала работ важно зафиксировать, кто переносит данные, настраивает приложения, создаёт резервные копии и отвечает за проверку после запуска.
Контрольный список перед переключением домена
Рабочий проект можно переносить, если выполнены основные проверки:
- система обновлена;
- доступ по SSH защищён;
- ненужные порты закрыты;
- приложение проверено под нагрузкой;
- свободное место контролируется;
- резервная копия хранится отдельно;
- тестовое восстановление выполнено;
- службы запускаются после перезагрузки;
- внешний мониторинг работает;
- старая площадка остаётся доступной для отката.
Сервер готов к эксплуатации не тогда, когда на него удалось войти, а когда проект способен самостоятельно восстановить работу после перезагрузки, предупредить о нехватке ресурсов и вернуть данные из резервной копии. Такая подготовка занимает меньше времени, чем поиск причин аварии уже после переключения пользователей.