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

Изначально мы нейтрально отнеслись к такому решению – хочет и хочет. Но в тот момент, когда мы начали настраивать базовый мониторинг сайтов началось “веселье”. Если кратко: все каналы, настроенные на оповещение начали утопать в “алертах”. О причинах, попытках решить этот вопрос и о наших выводах и будет дальнейший лонгрид.

Классический хостинг – это потеря денег

Тут важно отметить, для удобства дальнейшего чтения и понимания, что “классический хостинг” в нашем понимании – это теряющий свою актуальность shared web hosting, который я буду называть “хостинг”, виртуальные же серверы так и будут называться. Более подробная информация есть на нашем сайте.

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

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

Вот наши вводные: 

+ доступы от админки сайтов;

+ ftp-доступы;

– доступы по ssh;

– доступ к панели управления хостингом.

Ситуация хоть и индивидуальная, но не уникальная.

Проблема с мониторингом

Не получится настроить полноценный мониторинг на хостинге – это первое, с чем мы столкнулись.

Причина – нет доступов по ssh (точнее, нам их не дали). Как следствие, не получится настроить ряд функций мониторинга CMS, а значит, что-то можно пропустить. Но это проблема нашей проприетарной системы. Если же брать сторонние, например, Zabbix или Nixstats, которыми мы тоже пользуемся, то и тут возникнет проблема, так как на хостинг не получится установить агенты, которые необходимы для этих систем.

Тем не менее мониторинг ряда важных моментов возможен, и с этим можно жить.

Затруднено использование Git

Мы используем Git для контроля внесений изменений в файлы сайта, а так как у нас был доступ только по ftp, то его использование становится практически невозможным. Еще один момент - минус к безопасности, т.к. мы иногда используем Git для контроля целостности файлов (решение нестандартное, но рабочее). Идем дальше.

Отсутствие логов

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

Логировать POST-запросы тоже не получится, а значит, если на сайте используется CMS, которая не имеет штатной функции фиксации изменений на сайте, то это тоже отслеживаться не будет, выявить вектор атаки не получится. В ряде случаев к сайтам могут предъявляться повышенные требования безопасности, что подразумевает использование таких инструментов как WAF (например Nemesida-WAF) или host-based IDS (OSSEC), что тоже не представляется возможным, опять же, если об этом по какой-то причине не позаботился хостер. 

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

Тут и тут мы уже писали про систему Graylog, которой пользуемся, но на хостинге, само собой, она не применима без костылей (в случае, если известно, где хранятся логи веб-сервера).

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

Проблемы с обновлениями

Захотели обновить 1С-Битрикс? Может возникнуть необходимость сконфигурировать параметры веб-сервера, что не представляется возможным на хостинге, так как рутовый доступ вы никогда не получите.

Еще один жизненный пример: нашлась уязвимость в CMS, которую нужно срочно закрыть. С одной стороны, можно дождаться обновлений, если они будут (и это не “срочно”), с другой, мы возвращаемся к необходимости закрыть что-то на стороне веб-сервера и, само собой, сделать так не получится.

Проблемы с SSL-сертификатами

Установка SSL при использовании хостинга возможна только из панели управления, куда доступов все еще нет. По той же причине, в случае, если сертификат некорректно “встал” или не работает, оперативно решить этот вопрос тоже не получится.

Проблема с резервным копированием

В случае с хостингом остается надеяться только на хостера, который:

а) делает резервные копии;

б) сможет оперативно предоставить доступ к ним (кстати, иногда за деньги и не всегда оперативно).

Более того, забрать контейнер целиком вы тоже не сможете, а это уже обидно.

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

Проблема с масштабированием

Актуальная тема для больших и нагруженных систем, которая выросла в такое понятие как “kubernetes”, но для обычного продуктового сайта практически неактуальная. Однако в случае с хостингом шансов оперативно добавить памяти или процессорной мощности нет в принципе, в отличие от виртуального сервера.

Да и узнать о такой необходимости будет сложнее.

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

Проблема с доступностью сайтов

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

Целенаправленно собирать статистику мы начали в середине сентября 2020 года. На данный момент ситуация следующая:

> 20 часов даунтайма;

> 250 “алертов”.

На отрезке в год эти цифры могут не выглядеть страшно, но назвать это уровнем доступности даже Tier II получится с натяжкой. Сразу стоит отметить, что мы считали то время, когда сайт именно недоступен. Если он открывается, но нужно подождать (иногда >30 секунд), что, по сути, тоже недоступность, то вышеназванные показатели можно умножать на 1,5-2. Кстати, в поддержку писали и звонили, но назвать их ответы оперативными не получится – кто обращался, тот поймет.

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

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

Проблема с ранжированием сайтов (SEO)

Как формируется содержание поисковых запросов - тайна за семью печатями. Тем не менее, не секрет, что даунтайм сайта влияет на его ранжирование и чем даунтайм чаще и продолжительнее, тем ниже шансы ресурса попасть на выгодные позиции. Если сайты на хостинге регулярно “залипают” или бывают недоступны некоторое (пусть и непродолжительное) время, то при плохом сценарии мы получаем два очевидных момента:

• пользователи, которые пытаются зайти на сайт в это время, не дождутся и уйдут, что будет негативным фактором для поисковой системы;

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

А еще есть интересная статья о том, как “соседство” на shared-хостинге влияет на ранжирование сайтов (оригинал на английском, перевод). Но это совсем другая история.

Последняя же проблема снова связана с хостером и его политикой безопасности ...

Назовем это бонусом!

Проведешь нагрузочное тестирование – забанят!

С клиентом были договоренности, что два раза в год мы проводим нагрузочное тестирование. Ничего криминального, без фанатизма. Когда настало время первой попытки – начали готовиться, а для перестраховки решили обратиться в поддержку и уточнить один момент… А как они вообще на это отреагируют? 

Попросили клиента с ними связаться, объяснить ситуацию, результат же не удивил:

“Здравствуйте!

В случае обнаружения аномальной активности на той или иной услуге хостинга, которая создает угрозу стабильности работы сетей RU-CENTER,

работа услуги может быть полностью или частично приостановлена в соответствии с регламентом оказания соответствующей услуги.” (с)

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

Что же мы с этим делали?

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

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

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

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

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

Череда переговоров с клиентом привела к позитивным изменениям: некоторые сайты мигрировали на виртуальные сервера, но они все еще живут в ник.ру. Тем не менее, при использовании виртуальных серверов ситуация значительно улучшилась: минут 5-10 простоя в квартал! Не идеально, но гораздо приятнее и адекватнее.

Один сайт, пусть и временно, удалось утащить и на наш хостинг (на время глобальных доработок), там аптайм – 99,999%, и мы надеемся, что это может сказаться на дальнейшем общении.

Еще немного интересной статистики

Чтобы немного разбавить повествование, мы на протяжении недели собирали статистику с крупных и известных сайтов, таких как:

vsemayki.ru

lenta.ru

wildberries.ru

gosuslugi.ru

ozon.ru

gazeta.ru

auto.ru

consultant.ru

nalog.ru

ponyexpress.ru

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

• vsemayki.ru – за куратором, куратор наш мониторинг счел вредоносным и забанил :(

• ponyexpress.ru – даунтайм > 1 часа. (даунтаймом мы считали таймаут в 15 секунд, в течение которых пользователь ничего внятного не получил).

Что хотелось бы сказать в заключение

• Если у вас коммерческий сайт – пожалуйста, размещайте его на виртуальном сервере, это правильно.

• Без мониторинга жить нельзя, потому что только так получится увидеть проблему раньше клиентов и отреагировать на нее. Если на вашем ресурсе нет мониторинга – устанавливайте, срочно! Настройте сами, используйте сторонние сервисы, закажите настройку.

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

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

Не бросайте свои сайты – позвольте клиентам пользоваться вашими услугами!

Материал подготовлен компанией ITSOFT. Поддержка и разработка сайтов, администрирование серверов. Размещение и аренда серверов и стоек в двух ЦОДах в Москве; colocation GPU-ферм и ASIC-майнеров, аренда GPU-серверов. Лицензии связи, SSL-сертификаты. UPTIME за последние годы составляет 100%.