Современная архитектура сайта. Выбор сервера или хостинга в 2024 году

Устаревшая архитектура ПО. Связка используемых решений, которая морально и технически устарела. Зачастую это устаревшая СУБД MySQL 5.7 вместо версии  8.0+ (или MariaDB 10.9+). Это ограничивает возможности использования современных решений. Например, чтобы запустить Интернет-магазин на платформе RadicalMart, нужна актуальная версия MySQL/MariaDB. Кроме того, зачастую у хостеров в разном сочетании используются устаревшие версии: ОС, веб-сервера, хостинг панели, PHP, модулей и скриптов, задействованных в архитектуре сервера — что-то из перечисленного обычно устаревшее. Но зачастую проблема именно с СУБД. У вас не Интернет-магазин, а корпоративный сайт? Тогда распространённый пример: вы не можете добавить модуль для применения AVIF формата (более лёгкая версия изображений, превосходящая формат WEBP).

Потенциальные уязвимости ПО. Когда используется версия ПО, находящаяся в статусе EOL (End of Life - конец цикла развития), это означает, что патчей безопасности больше не будет. Вынес это в отдельный пункт, поскольку одно дело — техническое ограничение, когда невозможно запустить скрипт, другое дело — использование скриптов в статусе «мины замедленного действия», когда сайт могут взломать не через уязвимость в CMS, а в серверной архитектуре.

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

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

Ограничение ресурсов в рамках тарифного плана. Сам принцип хостинга — ограничение лимитов для органичного распределения мощностей. Дисковое пространство, трафик, время выполнения скриптов, кол-во файлов. Когда сайт запущен, всё хорошо. Но вот вы решили вложиться в продвижение и на сайт повалил народ. При экспоненциальном увеличении посещаемости сайта, могут обнаружиться неприятные сюрпризы вплоть до отключения сайта. Другая проблема: из-за ограничения не кол-во обрабатываемых файлов, некоторые изображения, генерируемые билдером, отваливаются (при включении webp/avif). Нет, это не проблема скрипта, а проблема лимитов хостинга и техническая поддержка в такой ситуации предлагает перейти на VDS. Почему бы и да?!

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

Сотни сайтов на одном сервере. Как известно, хостинг - это маленький кусочек с ограниченными ресурсами на сервере. Когда таких сайтов много, то это чревато двумя последствиями: DDOS атака на один из сайтов приводит к быстрому расходованию ресурсов и торможению сайтов (например, нет анти-DDOS защиты, а её зачастую нет, или в панели не предусмотрены ограничения по ресурсам). Но самое большое коварство таится в попадании IP сервера в чёрный список почтовых серверов. На конкретном примере: некоторые сайты, размещённые у хостера, созданы на WordPress и подвергаются взлому (читай статью: Статистика взломов WordPress) и с таких сайтов начинают массово рассылаться спам-рассылки. Через некоторое время сайту отрубают php mail функцию или блокируют аккаунт, однако если таких сайтов не один и не два, то IP сервера засвечивается в черных списках, которые используют почтовые программы. Это приводит к тому, что уведомления, рассылаемые с вашего сайта, по-просту перестают работать. Вы не получите уведомления о новых заказах или сообщения, отправленные через форму обратной связи. Безусловно, сайты с вирусами заблокируют и хостер инициализирует удаление из черных списков, но это занимает время, а не прочитанное вовремя письмо может оказаться критичным для вашей конкретной сделки и отрицательно сказажется на конверсии продаж.

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

Ошибка целостности бэкапов. Показательна история Александра Куртеева и его Центра Обучения Joomla, который функционировал на протяжении 13 лет. Из-за ошибки при создании резервной копии базы данных, которая весила более 10 гб, архив создавался не полным. Хостер инициировал перенос на новый сервер, а старый отключил. В результате файлы перенеслись без самого главного - базы данных, а оригинального сервера не осталось. В результате проект погиб.

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

Взаимодействие с технической поддержкой.