Куда бежать от хостера | Roem.ru

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

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

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

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

Частые проблемы - это одна проблема
“В последнее время хостинг имярек совсем не тот”, - легко это встретить после того, как 1-2 недели у хостера и впрямь было не все в порядке. На самом деле, если проблемы продолжаются неделю-две - то это с большой вероятностью одна и та же проблема. Хостинг - это комплекс технически сложных услуг, оказываемых обычно не самыми худшими специалистами в своей области. Если что-то пошло не так, то велика вероятность, что проблема комплексная и устраняется на самом деле не один час или даже день. За то время, которое вы потратите на подготовку переезда - выбор хостинга, подготовку технической площадки, тестирование, переезд (часто сопряженный с даунтаймом) - проблема как раз успеет решиться. Велика ли разница, ждать новых проблем у нового хостера (о котором вы с большой вероятностью не знаете ничего) или у старого (о котором что-то вы все-таки знаете)?

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

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

Сущности смертны
Добропорядочный хостер (а мы исходим из предположения, что вы пользуетесь услугами именно такого) предпринимает все возможные и разумные усилия для того, чтобы увеличить жизнеспособность индивидуальной сущности (VPS, виртуального хостинга, сервера). Тем не менее, стоит принять два факта:

1. Сбой индивидуальной сущности возможен;
2. Механизма более или менее точного предсказания вероятности сбоя у клиента нет.

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

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

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

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

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

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

Иными словами, смена поставщика (хостера) без смены отношения к хостингу как к элементу цепочки поставок - это, скорее, шаг отчаяния, чем шаг на пути к повышению стабильности работы проекта.

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

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

- Перестроить логику приложения так, чтобы оно допускало разнесение по нескольким кластеризованным сущностям. Звучит страшно, на деле - сотрудники Clodo неоднократно выполняли такую работу для клиентов. Цена вопроса - рабочая неделя и совсем небольшие деньги. Конечно, в ситуациях совсем патологических, этот пункт трудновыполним. Хорошая новость заключается в том, что для проектов на большинстве популярных CMS это минимальная проблема. Особенно тут преуспел “1С-Битрикс”, в котором для организации кластера требуются только навыки кликов мышкой и немножко copy-paste.

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

- Выбрать схему построения решения: размещать сегменты кластера у одного провайдера или у нескольких. В принципе, один провайдер в ситуации, когда он предоставляет услуги в нескольких ЦОДах, практически не хуже, чем два и более. Ситуаций, когда у хостера ложатся сегменты в нескольких датацентрах одновременно пока не было. Однако, во-первых, такие ситуации теоретически возможны (все помнят, как полегло ядро сети у “Яндекса” - на его месте, теоретически, мог быть и Амазон); во-вторых, с хостером, как и с любой компанией, могут случиться и неприятности финансово-организационного характера - тут резервирование ЦОДов не поможет. Однако схлопывания хостеров, имеющих сегменты в нескольких ЦОДах пока тоже не приключалось.

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

Николай Двас, директор по маркетингу облачного хоcтинга Clodo.ru

• Комментарии