В прошлом году к нам за поддержкой обратился клиент — крупная фармацевтическая компания, которой необходимо было обслуживать > 10 продуктовых объектов.
Помимо обычных работ над самими сайтами, в договор входило и администрирование серверов, на которых эти сайты расположены.
Однако клиент уверял, что не хочет менять хостера и не будет мигрировать на наши виртуальные сервера.
Изначально мы нейтрально отнеслись к этому решению – он хочет и хочет. Но как только мы начали настраивать базовый мониторинг сайта, началось «веселье».
Вкратце: все каналы, настроенные на уведомления, стали утопать в «оповещениях».
О причинах, попытках решения этого вопроса и наших выводах будет дальнейший лонгрид.
Классический хостинг — пустая трата денег
Здесь важно отметить, для удобства дальнейшего чтения и понимания, что «классический хостинг» в нашем понимании – это тот, который теряет свою актуальность.общий веб-хостинг , который я буду называть «хостинг», так будут называться виртуальные сервера.
Более подробную информацию можно получить на нашем Веб-сайт .
Так в чем же глобальная проблема веб-сайтов? Как вы уже догадались, проблема в том, что они были размещены.
Далее мы рассмотрим, какие основные проблемы возникают при его использовании.
Стоит сразу отметить, что ситуация здесь индивидуальна и в случае другой комбинации клиент + хостер все могло бы сложиться иначе.
Вот наши знакомства: + доступ от администраторов сайта; + FTP-доступ; — доступ по ssh; — доступ к панели управления хостингом.
Ситуация хоть и индивидуальна, но не уникальна.
Проблема с мониторингом
На хостинге не получится настроить полноценный мониторинг — это первое, с чем мы столкнулись.Причина в том, что нет доступа по ssh (точнее, нам его не дали).
В результате вы не сможете настроить ряд функций мониторинга CMS, а значит, можете что-то упустить.
Но это проблема нашей фирменной системы.
Если брать сторонние, например Zabbix или Nixstats, которые мы тоже используем, то здесь возникнет проблема, так как на хостинге не получится установить необходимые для этих систем агенты.
Однако отслеживать ряд важных моментов возможно, и с этим можно жить.
Сложно использовать Git
Мы используем Git для контроля изменений в файлах сайта, а поскольку доступ у нас был только через ftp, использовать его стало практически невозможно.Еще один момент - минус за безопасность, потому что.
мы иногда используем Git для контроля целостности файлов (решение нестандартное, но рабочее).
Вперед, продолжать.
Нет журналов
Невозможно протоколировать системные события, отслеживать атаки, ошибки в работе сайта и ряд других важных параметров.Например, невозможно установить утилиту faile2ban (если она или ее аналоги по каким-то причинам не установлены на хостере), а значит, сайт не защищен от того же перебора.
Также не будет возможности логировать POST-запросы, а это значит, что если на сайте используется CMS, не имеющая стандартной функции записи изменений на сайте, то это также не будет отслеживаться и не будет возможности идентифицировать вектор атаки.
В некоторых случаях к сайтам могут предъявляться повышенные требования безопасности, что подразумевает использование таких инструментов, как WAF (например Nemesida-WAF) или Host-based IDS (OSSEC), что также невозможно, опять же, если по каким-то причинам Хостеру было все равно.
Почему? Все просто: хостер не всегда предоставит вам необходимые для установки права.
А поскольку доступа к логам нет, то и проанализировать их не получится.
Здесь И здесь Мы уже писали о системе Graylog, которую используем, но на хостинге она, конечно, без костылей не применима (если знать, где хранятся логи веб-сервера).
Пример из реальной жизни: сайт сломался и мы понимаем, что проблема не в хостинге.
Если ее не решить, ситуация повторится.
Если вы используете виртуальный сервер, вы можете посмотреть логи, понять, в чем проблема, и исправить ее.
При их отсутствии приходится действовать вслепую, пробуя разные варианты, что оказывается и дольше, и трудозатратнее.
Проблемы с обновлениями
Хотите обновить 1С-Битрикс? Возможно, потребуется настроить параметры веб-сервера, что невозможно на хостинге, так как вы никогда не получите root-доступ.Еще один пример из реальной жизни: в CMS обнаружена уязвимость, которую необходимо срочно закрыть.
С одной стороны, мы можем дождаться обновлений, если они есть (и это не «срочно»), с другой стороны, мы возвращаемся к необходимости закрыть что-то на стороне веб-сервера и, конечно же, этого не произойдет. работа.
Проблемы с SSL-сертификатами
Настройка SSL при использовании хостинга возможна только из панели управления, доступа к которой пока нет. По этой же причине, если сертификат установлен неправильно или не работает, быстро решить этот вопрос также не удастся.
Проблема с резервным копированием
В случае с хостингом вы можете положиться только на того хостера, который: а) делает резервные копии; б) смогут быстро предоставить к ним доступ (кстати, иногда за деньги и не всегда оперативно).Более того, весь контейнер вы не сможете забрать, а это обидно.
Реальность такова, что даже если хостер делает резервные копии, не факт, что он хранит их необходимое количество достаточно долгое время, но в случае с виртуальным сервером можно настроить любой график и глубину хранения.
Проблема масштабирования
Актуальная тема для больших и нагруженных систем, переросшая в такое понятие как «кубернетес», но для обычного продуктового сайта практически неактуальна.Однако в случае с хостингом шансов быстро добавить память или вычислительную мощность в отличие от виртуального сервера практически нет. Да и узнать о такой необходимости будет сложнее.
Есть еще пара проблем, но о них невозможно рассказать, не упомянув отдельного хостера (в нашем случае это был всем известный nik.ru).
Проблема с доступностью сайта
Это база, которая не только состоит из вышеперечисленных пунктов, но и сама по себе является проблемой.Целенаправленно собирать статистику мы начали в середине сентября 2020 года.
На данный момент ситуация следующая: > 20 часов простоя; > 250 «тревог».
В течение года эти цифры, возможно, не будут выглядеть пугающими, но назвать это даже уровнем доступности уровня II было бы натяжкой.
Сразу стоит отметить, что мы считали время, когда сайт был недоступен.
Если он открывается, но нужно подождать (иногда > 30 секунд), что, по сути, тоже является недоступностью, то приведенные выше показатели можно умножить в 1,5-2. Кстати, они писали и звонили в поддержку, но их ответы нельзя назвать оперативными - те, кто обращался, поймут. Было бы нечестно не отметить позитивные сдвиги.
В конце лета, после очередного длительного спада, производительность хостинга заметно улучшилась.
2-3 раза точно.
Что касается мониторинга сбоев, то ситуация, конечно, сугубо индивидуальна, но это более ста часов работы инженеров, системного администратора и менеджера.
Не подумайте, что я жалуюсь, отчасти за это нам и платят, но возможность провести это время с пользой все же есть.
Если у вас нет поддержки, за которую вы платите, пожалейте своих сотрудников и откажитесь от хостинга!
Проблема с рейтингом сайта (SEO)
Как формируется содержание поисковых запросов — строжайшая тайна.Однако не секрет, что время простоя сайта влияет на его рейтинг, и чем чаще и продолжительнее время простоя, тем ниже шансы ресурса выйти на прибыльные позиции.
Если хостинги регулярно «зависают» или недоступны какое-то (пусть и короткое) время, то при плохом раскладе мы получаем два очевидных момента:
- пользователи, которые попытаются зайти на сайт в это время, не дождутся и уйдут, что будет негативным фактором для поисковой системы;
- Робот поисковой системы, как и пользователи, может не дождаться и не увидеть сайт, решивший отдохнуть.
Но это совсем другая история.
Последняя проблема опять же связана с хостером и его политикой безопасности.
Назовем это бонусом!
Если вы проведете нагрузочное тестирование, вас забанят!
Были договоренности с клиентом, что мы проводим нагрузочное тестирование два раза в год. Ничего криминального, никакого фанатизма.Когда пришло время первой попытки, они начали готовиться, и на всякий случай решили обратиться в поддержку и уточнить один момент. Как они вообще на это отреагируют? Мы попросили клиента связаться с ними и объяснить ситуацию, но результат не удивил: "Привет! В случае обнаружения аномальной активности на конкретном хостинге, представляющей угрозу стабильности сетей RU-CENTER, действие услуги может быть полностью или частично приостановлено в соответствии с регламентом оказания соответствующей услуги».
(С) Можно смело сказать, что тестирование прошло успешно и с минимальными трудозатратами.
Да, мы перетащили на свой хостинг копии некоторых сайтов и провели там нагрузочное тестирование, но кого это волнует? 
Что мы с этим сделали?
Нашей первой и логичной реакцией было то, что мы предложили клиенту переехать в нас .Но как я уже писал в самом начале, клиент отказывается менять хостера и это табу.
В качестве альтернативы они попросили приобрести виртуальные сервера для сайтов.
Мы много говорили на эту тему, разъясняли ситуацию, что не менее важно – нас услышали и поняли, но потом решение потонуло в череде согласований внутри компании, которая все же большая и не лишенная своих особенностей.
Мы пытались изменить «чувствительность» мониторинга, чтобы хотя бы избавиться от условно ложных срабатываний, когда сайт немного «зависал», но это не сильно помогло.
Совесть не позволяет мне реже делать проверки и тем более отключать мониторинг — я могу пропустить действительно важные ситуации.
Серия переговоров с клиентом привела к положительным изменениям: некоторые сайты перешли на виртуальные сервера, но по-прежнему живут в nik.ru. Однако при использовании виртуальных серверов ситуация значительно улучшилась: 5-10 минут простоя в квартал! Не идеально, но гораздо приятнее и адекватнее.
Нам удалось перетащить один сайт, пусть и временно, на наш хостинг (в период глобальных доработок), аптайм там 99,999%, и мы надеемся, что это может отразиться на дальнейшем общении.
Еще немного интересной статистики
Чтобы немного разбить историю, мы потратили неделю на сбор статистики с крупных и известных сайтов, таких как: всемайки.ру Лента.
ру wildberry.ru госуслуги.
ру ozon.ru Газета.
ру авто ру консультант.ру nalog.ru ponyexpress.ru Вы можете посмотреть графики здесь .
Образец очень слабый — это факт, но даже здесь мы смогли отметить пару интересных моментов:
- vsemayki.ru курируется, куратор посчитал наш мониторинг вредоносным и забанил :(
- ponyexpress.ru – время простоя > 1 часа.
(дауном мы считали таймаут в 15 секунд, в течение которого пользователь не получил ничего вразумительного).
Что хотелось бы сказать в заключение?
- Если у вас есть коммерческий веб-сайт, разместите его на виртуальном сервере, это правильно.
- Без мониторинга жить невозможно, ведь только так можно увидеть проблему раньше клиента и отреагировать на нее.
Если на вашем ресурсе нет мониторинга, срочно установите его! Настройте сами, воспользуйтесь сторонними сервисами, настройка заказа .
- Мнение со стороны никогда не будет лишним.
Проверьте свой хостинг/сотрудников; знакомое всегда ближе и теплее.
- Проблемы с хостингом означают, что вы можете потерять деньги, даже не заметив этого.
Чужие деньги не принято считать, поэтому вы можете посчитать их сами.
Здесь есть хорошая статья на эту тему.
Материал подготовлен компанией ITSOFT. Поддержка и развитие сайтов, администрирование серверов.
Размещение и аренда серверов и стоек в двух дата-центрах в Москве; колокейшн GPU-ферм и ASIC-майнеров, аренда GPU-серверов.
Лицензии на связь, SSL-сертификаты.
UPTIME в последние годы составил 100%.
Теги: #Хостинг #Системное администрирование #Администрирование серверов #мониторинг #Service Desk #хостинг-провайдеры #поддержка #виртуальный сервер #простой #клиентский сервис
-
Австрия
19 Oct, 24 -
Ретроспектива Шаг За Шагом. Рецепт
19 Oct, 24 -
Digital-Мероприятия В Москве С 15 По 21 Июня
19 Oct, 24
