Перебои в работе самого популярного российского хостинга привели к тому, что многие известные, малоизвестные и никому не известные клиенты “Мастерхоста” начали искать нового хостера - ругая компанию, сервисом которой еще пару месяцев назад были довольны.
На самом деле - по крайней мере так подсказывает взгляд с другой стороны хостингового прилавка - смена хостинг-провайдера - это не первая и не главная мера, которую следует предпринимать при недовольстве стабильностью сервисов хостинга.
Для веб-сервиса, зарабатывающего деньги, хостинг-провайдер - это поставщик. При этом бизнес-риски, связанные с некорректной работой поставщика достаточно велики: прямая потеря выручки за период простоя, потеря лояльности клиентов или рекламодателей, потеря накопленных позиций в поисковиках.
В управлении рисками, связанными с поставками, методика выбора единственного поставщика исходя из метрик качества его работы, хотя и имеет право на жизнь, не считается ни универсальной, ни единственной эффективной, ни даже самой эффективной. Организация резервных поставок, уменьшение зависимости от одного поставщика, перестройка производственной цепочки с целью расширения номенклатуры приемлемых поставок - все это прекрасно работающие методы, применимые в отношениях с хостинг-провайдером.
Смена хостера не должна быть единственным шагом после аварии по следующим причинам:
- недостаточная очистка фактов от вполне объяснимых эмоций, вызванных наступлением весьма неприятного риска;
- неполнота информации о качестве услуг конкурентов;
- беззащитность перед аналогичными проблемами конкурентов;
- наличие в большинстве случаев богатых возможностей по принципиальному уменьшению перечисленных выше рисков.
Частые проблемы - это одна проблема
“В последнее время хостинг имярек совсем не тот”, - легко это встретить после того, как 1-2 недели у хостера и впрямь было не все в порядке. На самом деле, если проблемы продолжаются неделю-две - то это с большой вероятностью одна и та же проблема. Хостинг - это комплекс технически сложных услуг, оказываемых обычно не самыми худшими специалистами в своей области. Если что-то пошло не так, то велика вероятность, что проблема комплексная и устраняется на самом деле не один час или даже день. За то время, которое вы потратите на подготовку переезда - выбор хостинга, подготовку технической площадки, тестирование, переезд (часто сопряженный с даунтаймом) - проблема как раз успеет решиться. Велика ли разница, ждать новых проблем у нового хостера (о котором вы с большой вероятностью не знаете ничего) или у старого (о котором что-то вы все-таки знаете)?
Поэтому сам по себе переезд после нескольких сбоев у хостера в течение короткого промежутка времени имеет под собой не вполне рациональное обоснование. Если он сопровождается мотивацией “хостинг должен не падать никогда” - то он является нерациональным в той же степени.
В поисках аптайма
Предположим, что у хостера, который вам внезапно разонравился, вы арендуете площадку виртуального хостинга, VPS, или железный сервер. Если вы ищете другого хостера, у которого вы сможете арендовать похожую конфигурацию - плохая новость заключается в том, что вы получите примерно ту же самую услугу, аналогично не защищенную от проблем хостера. Ваше знание об истинных проблемах - скорее всего ограниченное. Несмотря на кажущуюся простоту задачи публичных систем мониторинга простых и в то же время осмысленных показателей качества для хостинг-провайдеров не существует. Вы будете зависеть от проблем провайдера в той же степени - просто теперь это будет другой провайдер.
Сущности смертны
Добропорядочный хостер (а мы исходим из предположения, что вы пользуетесь услугами именно такого) предпринимает все возможные и разумные усилия для того, чтобы увеличить жизнеспособность индивидуальной сущности (VPS, виртуального хостинга, сервера). Тем не менее, стоит принять два факта:
1. Сбой индивидуальной сущности возможен;
2. Механизма более или менее точного предсказания вероятности сбоя у клиента нет.
Таким образом, стоит по возможности не зависеть от работы индивидуальной сущности. Хостинг провайдер (опять же добросовестный - других мы не обсуждаем; если хостер кажется вам недобросовестным - то его надо, конечно, покидать, сверкая пятками) со своей стороны делает все, чтобы вы не зависели от одного интернет-канала, от одного ввода питания, от одного жесткого диска - короче, резервирует все, что поддается резервированию.
Тем не менее, есть часть резервирования, которая может быть осуществлена только тесным взаимодействием клиентским уровнем. Например, ни один хостер при всем желании не может разнести работу вашего PHP-скрипта по двум и более серверам, не зная, как у вас внутри происходит работа с пользовательскими сессиями или с загружаемыми пользователем файлами. Это лишь пара примеров - но общий факт заключается в том, что типичная картина резервирование такова:
Два разных энерговвода (плюс резервный дизель) питают стойки, к которым подведено два (в реальности больше) разных канала. В серверах стоят стойки, любые ваши данные хранятся на двух и более дисках. И из всех этих ресурсов (серверы, канал, энерговводы, хранилище) вы арендуете некоторое подмножество, причем - единственное.
Если работа сайта/приложения критична, обеспечить резервирование с учетом того, что отдельная сущность (не только атомарная сущность - диск, канал, энерговвод), но и “упакованная” сущность, продаваемая клиенту, у любого хостера может отказать - идея более чем здравая.
Все девятки хороши
По долгу службы автор является клиентом многих российских и зарубежных хостингов. На субъективном уровне разница между хостерами с точки зрения работоспособности индивидуальных сущностей не слишком велика:
- проблемы бывают у всех;
- продолжительность проблем - разная, но простои по нескольку часов - та реальность, с которой вполне возможно столкнуться во всем диапазоне от пупкинхоста до амазона со всеми остановками;
- откровенный “криминал” в списке топ-провайдеров не встречается, на уровне персонального восприятия, без цифр и графиков, все работают более или менее одинаково.
Иными словами, смена поставщика (хостера) без смены отношения к хостингу как к элементу цепочки поставок - это, скорее, шаг отчаяния, чем шаг на пути к повышению стабильности работы проекта.
Итого: все хорошие хостеры работают примерно одинаково, развиваются примерно в равном темпе, повышают стабильность и ошибаются примерно поровну. Слабая зависимость от работы индивидуальной сущности у среднего хостера - это куда лучше, чем сильная зависимость от “практически идеального”.
Борьба за независимость
Практических способов ослабления зависимости от индивидуальной сущности у хостера существует масса. Базовый алгоритм в общих терминах:
- Перестроить логику приложения так, чтобы оно допускало разнесение по нескольким кластеризованным сущностям. Звучит страшно, на деле - сотрудники Clodo неоднократно выполняли такую работу для клиентов. Цена вопроса - рабочая неделя и совсем небольшие деньги. Конечно, в ситуациях совсем патологических, этот пункт трудновыполним. Хорошая новость заключается в том, что для проектов на большинстве популярных CMS это минимальная проблема. Особенно тут преуспел “1С-Битрикс”, в котором для организации кластера требуются только навыки кликов мышкой и немножко copy-paste.
- Выбрать набор услуг для реализации одного сегмента кластера: какие требуются хостинговые сервисы и для чего, как должны быть построены связи между ними. Например, определить, какие нужны виртуальные серверы, “железные” серверы, балансировщики нагрузки, файловые хранилища. Про обычный (виртуальный, shared) хостинг необходимо, увы, забыть: провайдеронезависимое решение тут не построить, да и даже зависимость от сущности не преодолеть.
- Выбрать схему построения решения: размещать сегменты кластера у одного провайдера или у нескольких. В принципе, один провайдер в ситуации, когда он предоставляет услуги в нескольких ЦОДах, практически не хуже, чем два и более. Ситуаций, когда у хостера ложатся сегменты в нескольких датацентрах одновременно пока не было. Однако, во-первых, такие ситуации теоретически возможны (все помнят, как полегло ядро сети у “Яндекса” - на его месте, теоретически, мог быть и Амазон); во-вторых, с хостером, как и с любой компанией, могут случиться и неприятности финансово-организационного характера - тут резервирование ЦОДов не поможет. Однако схлопывания хостеров, имеющих сегменты в нескольких ЦОДах пока тоже не приключалось.
Решение всех этих задач вполне под силу небольшому набору технических сотрудников: в нетяжелых случаях хватит нескольких дней работы одного человека, знакомого с системным администрированием и веб-программированием. Если ресурсы такого человека компании недоступны (в идеальном мире интернет-магазин с небольшими продажами вполне может жить без своего программиста/администратора), экспертная консультация при осуществлении такого цикла работ - это исходя из нашего опыта задача решаемая в конечные сроки и за небольшие (по сравнению с возможным ущербом от неработоспособности сайта) деньги.
Николай Двас, директор по маркетингу облачного хоcтинга Clodo.ru
Редакция Roem.ru может не разделять мнения авторов статей.
С предложениями по публикации материалов на темы интернет-бизнеса обращайтесь к главному редактору Roem.ru Людмиле Кудрявцевой по адресу kud@roem.ru
phil — ну, WordPress, например, с каким-то разумным набором плагинов перепилился за пару неделек. «Битрикс веб-кластер» вообще разбрасывается по виртуалкам (ОК, ты их не любишь. По железным сервакам ;) как влитой и прекрасно там себе работает, если что-то положить. А по поводу шареда — я исхожу из реалий, а не из теоретических возможностей. Я знаю, что можно сделать и «кластерный шаред», и все, что угодно — хоть черта в ступе можно сделать на шареде — но я исхожу из того, что продается сейчас. funvit — да, одна зона — не айс совсем. Собственно, после ввода у нас зонирования, мы ни разу не испытывали проблем на более, чем одной зоне. spsh — «Идеальное решение — 2-3 поставщика, но это не под силу 99% бизнесам, представленным в интернете». Тут ключевое слово «представленный». Если представлен чтобы было — то это не то чтобы не под силу, а просто не нужно. Если это «представление» имеет какую-то финансовый выхлоп — то проблема решается просто. «Те, у кого основной заработок компании (не одного человека-фрилансера, а компании хотя бы в пару десятков человек) зависит от аптайма их сервера/виртуалки, как правило, прибегают к резервированию заранее (т.е. до проблем с хостером)» — вот это очень хороший мир, где так происходит. К сожалению, мы с вами живем в разных реальностях. Увы, не прибегают. Прибегают те, кому повезло найти хорошего техдира или даже комдира, который может ничего не понимать в хостинге-шмостинге, но понимать, что не надо складывать все риски в одну корзину. Что исключение, но не правило. medin — спасибо, учимся, слушаем вас. По поводу родовой травмы нашей отрасли и клиентских коммуникаций — вы тут правы, и, честно говоря, мы пытаемся это всеми правдами и неправдами преодолеть. Проблем на этому пути много, но мы стараемся. Что касается консультации в Вашем конкретном случае — пишите прямо мне на dvas@clodo.ru. Да, у нас пока нет массового решения, которое было бы просто упакованным, и в то же время отличалось от хостинга «100 рублей в месяц, безлимитный трафик, аптайм 100%». Лучшее, чего мы достигли пока — это сделали бриф для случая примерно соответствующего описанного вами. Через год все должно стать совсем по-другому. Можете ловить на слове.