Купили VPS. Кто теперь должен за ним следить?

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

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

Вы арендовали сервер или его обслуживание?

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

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

В описаниях тарифов встречаются два обозначения:

• Unmanaged — сервер без полноценного администрирования. Обслуживание системы и сайта нужно организовать со своей стороны; объём помощи провайдера уточняется отдельно.
• Managed — сервер с обслуживанием в согласованном объёме. За этим словом могут стоять разовая настройка, работы по заявкам, регулярные обновления или наблюдение за сбоями. Важно выяснить конкретный состав.

Само слово managed не объясняет, кто восстановит магазин после неудачного обновления модуля. А фраза «техподдержка есть» не означает, что кто-то проверяет ваш сайт без обращения.

Спросите провайдера: «Что вы делаете регулярно без моей заявки, а что — только после обращения?»

Что нужно обслуживать, пока магазин работает

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

Обновления и проверка после них

Операционная система сервера, программы для работы сайта и сам 1С-Битрикс — разные уровни. Обновление системы не означает, что обновлены CMS и её модули. Даже при автоматической установке обновлений кто-то должен проверять результат.

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

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

Место на диске и нагрузка

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

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

Сертификаты и доступы

У HTTPS-сертификата должен быть ответственный за срок действия и успешное продление — даже если оно автоматизировано.

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

Резервные копии и восстановление

Ответ «бэкап настроен» оставляет вопросы. Попадают ли в копию файлы, база и необходимые настройки? Где она хранится и как долго? Кто узнает об ошибке копирования? Можно ли получить копию, если основной VPS недоступен, и не зависит ли доступ к ней только от этого сервера?

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

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

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

Сервер отвечает — а магазин работает?

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

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

Но уведомление — ещё не помощь. Оно должно приходить тому, кто обязан разобраться и может действовать. Зафиксируйте:

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

Срок первого ответа и время устранения неисправности — разные вещи. «Заявку приняли» не значит «магазин снова принимает заказы». Реакцию ночью и в выходные тоже нужно согласовать: она не подразумевается самим фактом аренды VPS.

Как разделить работу без споров «это не к нам»

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

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

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

С чего начать, если VPS уже куплен

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

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

Результат — не просто телефон человека на случай аварии. Вы знаете, кто следит за сервером, кто заметит проблему и кто возьмёт её в работу.

Если рассматриваете 404.by, обсудите состав администрирования и резервирования для вашего магазина: какие работы входят в услугу, что выполняется по заявке, каковы условия реакции и где понадобится разработчик.