Физический сервер с администрированием или без него что выбрать

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

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

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

Что означает физический сервер без администрирования

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

Дальше начинается зона ответственности владельца сервера. Ему нужно установить и настроить программное окружение для сайта, обеспечить безопасность, обновлять систему, следить за свободным местом, контролировать журналы ошибок и вовремя реагировать на проблемы. Если используется Linux, это может означать работу с SSH, firewall, Nginx или Apache, PHP, базой данных, сертификатами, заданиями cron, пользователями и правами доступа.

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

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

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

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

Техническая поддержка и администрирование не одно и то же

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

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

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

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

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

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

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

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

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

Что обычно входит в управляемый физический сервер

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

В услугу могут входить первоначальная настройка операционной системы и веб-окружения, установка обновлений, базовая настройка безопасности, мониторинг служб, резервное копирование и помощь при сбоях. Иногда специалисты оптимизируют Nginx, Apache, PHP и базу данных под нагрузку проекта. В других тарифах администрирование ограничивается определённым количеством запросов в месяц.

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

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

Ответы на эти вопросы намного полезнее общей надписи полное администрирование.

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

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

Как понять какой вариант нужен вашему проекту

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

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

Если проект обслуживает веб-студия, стоит узнать, входит ли системное администрирование в её работу. Разработчик и системный администратор не всегда один специалист. Человек может прекрасно писать PHP, разрабатывать сайты на 1С-Битрикс или WordPress и при этом не заниматься безопасностью Linux-сервера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оцените статью
Рейтинг хостингов
Добавить комментарий