Смотреть
30 дней бесплатно
Смотреть
30 дней бесплатно
Условия просмотра: clck.ru/h7Vx2
18+
УЖЕ В ПОДПИСКЕ
Сервисы
ITSOFT

Как клиенты теряют деньги из-за хостинга, но даже не знают об этом

В прошлом году к нам на поддержку пришел клиент – крупная фармкомпания, которой требовалось обслуживать >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%.

0
15 комментариев
Написать комментарий...
Николай Лискин

Статью нужно посветить конкретному хостингу, а не бросать тень на весь виртуальный хостинг. У beget нет большинства проблем которые Вы озвучили. Также нужно говорить о размере проекта, а не бросаться громко на весь бизнес. Для некоторых обычного виртуального за глаза

Ответить
Развернуть ветку
Igor Tarasov

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

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

Ответить
Развернуть ветку
Николай Лискин

Для всех поголовно бизнесов нужен мониторинг? Я так понимаю Вы из отдела продаж раз сказки про вмиг понизят рассказываете?😁

Ответить
Развернуть ветку
Igor Tarasov

Если вас позиции в ТОП выдачи не волнуют или у вас конкурентов нет и вы и так в выдаче на первом месте, то вам пофиг на uptime. До ЖЭК местного или полиции всегда все дозвонятся ибо куда ж ещё звонить.

Ответить
Развернуть ветку
Николай Лискин

Не выдумывайте

Ответить
Развернуть ветку
ITSOFT
Автор

Есть опыт работы и с beget'ом. Если не против, поделимся в личке.

Ответить
Развернуть ветку
Николай Лискин

Я хорошо знаю все нюансы работы с beget и timeweb которых рекомендую, и знаю помойки nic.ru reg.ru с которых нужно бежать

Ответить
Развернуть ветку
Igor Tarasov

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

И есть сервисы мониторинга типа того же ping-admin, только не видел я на пинг-админе ни никру и регру, ни ваших бегетов с таймвеб. Закрыта у них инфа по uptime.

Ответить
Развернуть ветку
Николай Лискин

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

Ответить
Развернуть ветку
Igor Tarasov

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

Ответить
Развернуть ветку
Николай Лискин

Мне кажется Вы из тех впаривателей близких к Инфоциганям. Для успешного бизнеса нужен не мониторинг сайта, а много других факторов

Ответить
Развернуть ветку
Igor Tarasov

Вам кажется. Другие факторы тоже нужны. И мониторинг тоже нужен.

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

Ответить
Развернуть ветку
ITSOFT
Автор

Немного негативно получилось, вы правы. Мы привели пример с конкретным хостингом, но не ругаем провайдера. Обозначаем проблему, дабы не было как у Райкина: "Кто сшил костюм?"

Ответить
Развернуть ветку
Nix

Фиг знает, лет 15 уже пользуюсь амазоном, но 70% указанных проблем были решены на российских хостинг площадках уже 15-16лет назад. Ну или имели простое решение. Вероятно 30% оставшихся тоже.

Впрочем я с вами согласен. С хостинга надо съезжать, главное не к вам, а куда-нибудь на Амазон итп.

Ответить
Развернуть ветку
Иван Петров

И где же ответ на главный вопрос? Сколько денег вы смогли помочь клиенту не потерять?

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

При все описанных минусах вы забыли написать о плюсах. Если что-то упадет на хостинге, то этим будут заниматься специальные люди,а вот аптайм на нормальных хостингах на уровне 99,9%. А вот если выделенный сервер екнется ночью, то пока админ не проснется, проблема не решится.

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

Ответить
Развернуть ветку
Читать все 15 комментариев
null