Куда бежать от хостера

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

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

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

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

Смена хостера не должна быть единственным шагом после аварии по следующим причинам:

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

- неполнота информации о качестве услуг конкурентов;

- беззащитность перед аналогичными проблемами конкурентов;

- наличие в большинстве случаев богатых возможностей по принципиальному уменьшению перечисленных выше рисков.

Частые проблемы - это одна проблема

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

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

В поисках аптайма

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

Сущности смертны

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

1. Сбой индивидуальной сущности возможен;

2. Механизма более или менее точного предсказания вероятности сбоя у клиента нет.

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

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

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

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

Все девятки хороши

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

- проблемы бывают у всех;

- продолжительность проблем - разная, но простои по нескольку часов - та реальность, с которой вполне возможно столкнуться во всем диапазоне от пупкинхоста до амазона со всеми остановками;

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

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

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

Борьба за независимость

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

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

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

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

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

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


Редакция Roem.ru может не разделять мнения авторов статей.

С предложениями по публикации материалов на темы интернет-бизнеса обращайтесь к главному редактору Roem.ru Людмиле Кудрявцевой по адресу kud@roem.ru

Лучшие комментарии

  • Контекст комментария

    dvasnicholas

    phil — ну, WordPress, например, с каким-то разумным набором плагинов перепилился за пару неделек. «Битрикс веб-кластер» вообще разбрасывается по виртуалкам (ОК, ты их не любишь. По железным сервакам ;) как влитой и прекрасно там себе работает, если что-то положить. А по поводу шареда — я исхожу из реалий, а не из теоретических возможностей. Я знаю, что можно сделать и «кластерный шаред», и все, что угодно — хоть черта в ступе можно сделать на шареде — но я исхожу из того, что продается сейчас. funvit — да, одна зона — не айс совсем. Собственно, после ввода у нас зонирования, мы ни разу не испытывали проблем на более, чем одной зоне. spsh — «Идеальное решение — 2-3 поставщика, но это не под силу 99% бизнесам, представленным в интернете». Тут ключевое слово «представленный». Если представлен чтобы было — то это не то чтобы не под силу, а просто не нужно. Если это «представление» имеет какую-то финансовый выхлоп — то проблема решается просто. «Те, у кого основной заработок компании (не одного человека-фрилансера, а компании хотя бы в пару десятков человек) зависит от аптайма их сервера/виртуалки, как правило, прибегают к резервированию заранее (т.е. до проблем с хостером)» — вот это очень хороший мир, где так происходит. К сожалению, мы с вами живем в разных реальностях. Увы, не прибегают. Прибегают те, кому повезло найти хорошего техдира или даже комдира, который может ничего не понимать в хостинге-шмостинге, но понимать, что не надо складывать все риски в одну корзину. Что исключение, но не правило. medin — спасибо, учимся, слушаем вас. По поводу родовой травмы нашей отрасли и клиентских коммуникаций — вы тут правы, и, честно говоря, мы пытаемся это всеми правдами и неправдами преодолеть. Проблем на этому пути много, но мы стараемся. Что касается консультации в Вашем конкретном случае — пишите прямо мне на dvas@clodo.ru. Да, у нас пока нет массового решения, которое было бы просто упакованным, и в то же время отличалось от хостинга «100 рублей в месяц, безлимитный трафик, аптайм 100%». Лучшее, чего мы достигли пока — это сделали бриф для случая примерно соответствующего описанного вами. Через год все должно стать совсем по-другому. Можете ловить на слове.

  • Контекст комментария

    ak

    1. Уходить от деградирующих хостеров нужно, чтобы не поддерживать деградацию сервиса рублем. 2. «Как я ждал этих ссылок на Хабр. Были косяки, были. Хорошо, что мы всеми техногенными болезнями роста смогли переболеть, уложившись в 3 месяца.» — а вот такая уверенность в случайности предыдущих ошибок настораживает. 3. Что касается отказоустойчивости, то у VPS и железных серверов есть концептуальная проблема с обеспечением отказоустойчивой работы приложения, потому что для клиента и для хостера это разные приложения. И для хостера приложение — линукс! :-)) Но мало кому нужен отказоустойчивый доступ к линуксу. Клиенту нужна отказоустойчивая работа веб-приложения. А так как в линуксах веб-приложения изначально строятся из говна и палок, то обеспечить абстрактную среду выполнения для них трудно. В чем автор статьи сам признается: «Например, ни один хостер при всем желании не может разнести работу вашего PHP-скрипта по двум и более серверам, не зная, как у вас внутри происходит работа с пользовательскими сессиями или с загружаемыми пользователем файлами.» На самом деле, конечно, такие хостеры есть, только биллинг там обычно идет на гораздо более высоком уровне, чем для VPS, и хостер обеспечивает среду выполнения веб-приложения, а не линукса. (самый простейший пример для веб-хостинга статических файлов — это биллинг за трафик+сторейдж+пейджвьюс).

  • Контекст комментария

    Филипп Кулин ООО Дремучий Лес

    > а вот такая уверенность в случайности предыдущих ошибок настораживает Я хочу поддержать коллегу в этом вопросе. Это уверенность не в случайности. Это вполне себе «плановые ошибки». Не ошибается тот, кто ничего не делает. Иногда бывают заблуждения, иногда не удаётся всё предусмотреть в тестовой среде, иногда меняются условия. И как правильно сказал коллега — не всегда это можно починить за 5 минут. Не поменять за один день ни стораджи, ни провайдера, ни даже систему внутренней маршрутизации. Уверенность, насколько я понимаю её, состоит в том, что такие ошибки будут исправлены. > Что касается отказоустойчивости, то у VPS и железных серверов есть концептуальная проблема с обеспечением отказоустойчивой работы приложения, потому что, по большому счету, для хостера это приложение — линукс! :-)) Но мало кому нужен отказоустойчивый доступ к линуксу, вместо этого нужна отказоустойчивая работа веб-приложения. Но так как в линуксах веб-приложения изначально строятся из говна и палок, то обеспечить абстрактную среду выполнения для них трудно Я вынесу это куда-нибудь в цитаты. Несмотря на то что там пропущена прослойка вебокружения — сути это не меняет :)

Добавить 19 комментариев

  • Ответить

    «Все хостеры одинаковы, менять их не стоит, скорость решения проблемы высока в любом, а в интернете нельзя качественно проанализировать работу хостинга?» ой-ли.. __ Менять, конечно, хостера не стоит по причине разовых неполадок с компенсациями, решённых быстро и качественно для этой сферы, особенно если проблема возникла обыденная или не по вине хостера. Проблемка в том, что помимо пресловутого «мастерхоста» существует с десяток адекватных предложений, превосходящих. Цена/поддержка/профессионализм. P.S. От статьи с названием «Куда бежать от хостера?» ожидал конкретно разобранных вариантов, отвечающие на обозначенный выше вопрос. Конкретику, господа, конкретику. А не то всё скатывается в защиту/оправдание того, что у мастерхостика всё плохо. Кстати, не пользовался, не знаю.

  • Ответить
    Альтер Эго

    нормальных облачных хостингов в России нет. Clodo — один из примеров плохого хостинга. http://habrahabr.ru/blogs/hosting/126140/ http://habrahabr.ru/blogs/hosting/121080/ http://habrahabr.ru/blogs/hosting/114073/ http://habrahabr.ru/blogs/hosting/119657/ Удосужилось с ними связаться, хорошо, что не на долго и удалось быстренько свалить

  • Ответить

    Привет, Альтер эго. Как я ждал этих ссылок на Хабр. Были косяки, были. Хорошо, что мы всеми техногенными болезнями роста смогли переболеть, уложившись в 3 месяца. Плохо, что они с нами приключились — но что было, то было. Мы многому научились. То, что Вам «удалось» свалить — это, конечно, везение. Как-то с трудом, правда, представляется клиент, который хочет свалить — и ему не удается. Но, наверное, это возможно. Отдельно хотелось бы спросить, к чему, собственно, Ваш коммент про то, что «нормальных облачных хостингов в России нет». В тексте слово «облачный» вроде есть один раз — и то, в подписи.

  • Ответить
    Филипп Кулин ООО Дремучий Лес

    Начал за здравие, а кончил за упокой. > Хорошая новость заключается в том, что для проектов на большинстве популярных CMS это минимальная проблема Можно озвучит список с тезисным описанием методик минимализации проблемы в этих CMS. > Особенно тут преуспел “1С-Битрикс” И его тоже. Вопросы собственно заключаются в том, что при правильной постановке задачи и вообще подходе самой статьи, вдруг делается вывод о победоносной кнопке «щасье» на все случаи жизни. Хотелось бы прояснить, что же имелось ввиду. > Про обычный (виртуальный, shared) хостинг необходимо, увы, забыть Это простите, коллега, из чего исходит? Из той мысли, что вам хочется продать свою маркетинговую клюкву — «облака»? Или есть какое-то обоснование кроме голого резюме в конце статьи?

  • Ответить

    самое неприятное — облачники с одной зоной (внутри которой всего одна большая дисковая система). они очень уязвимы. я наблюдаю проблеммы с дисками и на scalaxy. read-only на неизвестное время = нерабочий nginx (если он работает как прокси). тут уже понимаешь что многозонность амазона — не спроста. однако размещение сайта в нескольких зонах ведет к удорожанию хостинга. а к этому мелкие сайты совершенно не готовы.

  • Ответить

    Clodo и Selectel сейчас одни из лучших поставщиков облачного счастья (других особо и нет в пределах двух столиц, но всё же, всё же). У меня и там и там сервера располагаются, т.ч. на предмет их качества сложно говорить, конкретно я проблем за ними не помню. Разве что перестройка архитектуры у селектела вынудила перенести новый проект на клодо. __ Ну а оверсан — да, няша. =)

  • Ответить

    не дочитал статьи до конца, ибо длинна и водяниста, потому хочу оставить комменты на первые несколько абзацев. менять поставщика услуг стОит, если он не развивается. Если говорить про мастерхост, то он визуально не развивается давно (панель пятилетней давности, линейка услуг немного претерпела изменения за 5 лет, но как-то уж очень слабо, служба поддержки как не отвечала на телефон в течение 20 минут, так и не отвечает ну и т.д.). Недавно писал про то, что с ужасом узнал, что все ДНС-сервера стоят в одном ДЦ. Почему-то изначально принимается за истину, что все хостеры одинаково плохи (или хороши). Это не так. Да, в России с этим однозначные проблемы, но найти стабильного хостера можно. Как правило, сакральным знанием обладают люди, которые лет 10 ставят сервера по десяткам ДЦ. Их камменты можно найти. Идеальное решение — 2-3 поставщика, но это не под силу 99% бизнесам, представленным в интернете. Те, у кого основной заработок компании (не одного человека-фрилансера, а компании хотя бы в пару десятков человек) зависит от аптайма их сервера/виртуалки, как правило, прибегают к резервированию заранее (т.е. до проблем с хостером). Все гОвны льются от тех, кто именно и не может осилить несколько ДЦ одновременно. А это самый массовый клиент. И уж если возникла какая-то глобальная проблема, то она не должна нести последствия в течение месяцев (а если помните, масетрхост стал барахлить в декабре еще).

  • Ответить

    Я не администратор ниразу и не обладаю сокральными знаниями в области выживания на хостинге. Но вот я столкнулся с проблемой. Куда идти? Автор пишет про умеренную плату специалистам без имени, которые, судя по сказанному, могут мне помочь. Автор выше тоже что-то знает, но отделывается общими словами. Я вырос из обычного виртуального хостинга, конкуренты иногда насылают ddos чуму, но vps/облако/что-то новое для меня темный лес. У меня нет супер программиста в штате и администратора и … В общем я готов к 2-3 поставщикам и готов оплатить консультацию за умеренные деньги. Куда мне пойти?

  • Ответить

    Кстати большая проблема российского бизнеса всех мастей в том, что он не любит с клиентом разговаривать и решать его проблему. >Идеальное решение — 2-3 поставщика, но это не под силу 99% бизнесам, представленным в интернете. Те, у кого основной заработок компании (не одного человека-фрилансера, а компании хотя бы в пару десятков человек) зависит от аптайма их сервера/виртуалки, как правило, прибегают к резервированию заранее (т.е. до проблем с хостером). Кто же спорит что идеальное? А кто достойно предлагает и разъясняет? Ну никто. И не надо говорить про 99% бизнесов — это было давно и не правда. Это так кажется и только потому, что между «мне хватит и хостинга за 100 рублей» и профессиональными решениями НИЧИГО НЕТ. А если есть, то эти деятели об этом молчат, но это уже другая проблема. Как решается? Как у всех — семинары/вебинары и прочее образование, платные консультации, ПРОФЕССИОНАЛЬНЫЕ продажники/специалисты. С помощью этих инструментов из 99% выходят те, кто хочет большего, но им не рассказали про это лучшее.

  • Ответить

    phil — ну, WordPress, например, с каким-то разумным набором плагинов перепилился за пару неделек. «Битрикс веб-кластер» вообще разбрасывается по виртуалкам (ОК, ты их не любишь. По железным сервакам ;) как влитой и прекрасно там себе работает, если что-то положить. А по поводу шареда — я исхожу из реалий, а не из теоретических возможностей. Я знаю, что можно сделать и «кластерный шаред», и все, что угодно — хоть черта в ступе можно сделать на шареде — но я исхожу из того, что продается сейчас. funvit — да, одна зона — не айс совсем. Собственно, после ввода у нас зонирования, мы ни разу не испытывали проблем на более, чем одной зоне. spsh — «Идеальное решение — 2-3 поставщика, но это не под силу 99% бизнесам, представленным в интернете». Тут ключевое слово «представленный». Если представлен чтобы было — то это не то чтобы не под силу, а просто не нужно. Если это «представление» имеет какую-то финансовый выхлоп — то проблема решается просто. «Те, у кого основной заработок компании (не одного человека-фрилансера, а компании хотя бы в пару десятков человек) зависит от аптайма их сервера/виртуалки, как правило, прибегают к резервированию заранее (т.е. до проблем с хостером)» — вот это очень хороший мир, где так происходит. К сожалению, мы с вами живем в разных реальностях. Увы, не прибегают. Прибегают те, кому повезло найти хорошего техдира или даже комдира, который может ничего не понимать в хостинге-шмостинге, но понимать, что не надо складывать все риски в одну корзину. Что исключение, но не правило. medin — спасибо, учимся, слушаем вас. По поводу родовой травмы нашей отрасли и клиентских коммуникаций — вы тут правы, и, честно говоря, мы пытаемся это всеми правдами и неправдами преодолеть. Проблем на этому пути много, но мы стараемся. Что касается консультации в Вашем конкретном случае — пишите прямо мне на dvas@clodo.ru. Да, у нас пока нет массового решения, которое было бы просто упакованным, и в то же время отличалось от хостинга «100 рублей в месяц, безлимитный трафик, аптайм 100%». Лучшее, чего мы достигли пока — это сделали бриф для случая примерно соответствующего описанного вами. Через год все должно стать совсем по-другому. Можете ловить на слове.

  • Ответить
    Филипп Кулин ООО Дремучий Лес

    > вообще разбрасывается по виртуалкам Он разбрасывается по шаредам, как правильно сказал — по железным сервакам, по виртуалкам. Ты ведь имеешь ввиду какой-то особый способов работы бесперебойной этого WordPress? Какой? В чём его методика? Тезисно конечно. > но я исхожу из того, что продается сейчас «Имя, сударыня, имя!!!!» (c) Две ссылки WordPress, или вот Bitrix продаваемых с методикой кластеризации X (которую надеюсь тезисно обозначит хоть кто-нибудь из вас). Одна ссылка на одного поставщика, вторая на второго. Если из ссылок прямо не исходит про WordPress или Bitrix, то можно просто пояснить что вот тут это берём, тут это. А то у нас пока разговор о тоннах хлопка и литрах надоев. > Я знаю, что можно сделать и «кластерный шаред» И это не значит, что «можно забыть». Это означает только, что .masterhost и Кулин этого не сделали.

  • Ответить

    1. Уходить от деградирующих хостеров нужно, чтобы не поддерживать деградацию сервиса рублем. 2. «Как я ждал этих ссылок на Хабр. Были косяки, были. Хорошо, что мы всеми техногенными болезнями роста смогли переболеть, уложившись в 3 месяца.» — а вот такая уверенность в случайности предыдущих ошибок настораживает. 3. Что касается отказоустойчивости, то у VPS и железных серверов есть концептуальная проблема с обеспечением отказоустойчивой работы приложения, потому что для клиента и для хостера это разные приложения. И для хостера приложение — линукс! :-)) Но мало кому нужен отказоустойчивый доступ к линуксу. Клиенту нужна отказоустойчивая работа веб-приложения. А так как в линуксах веб-приложения изначально строятся из говна и палок, то обеспечить абстрактную среду выполнения для них трудно. В чем автор статьи сам признается: «Например, ни один хостер при всем желании не может разнести работу вашего PHP-скрипта по двум и более серверам, не зная, как у вас внутри происходит работа с пользовательскими сессиями или с загружаемыми пользователем файлами.» На самом деле, конечно, такие хостеры есть, только биллинг там обычно идет на гораздо более высоком уровне, чем для VPS, и хостер обеспечивает среду выполнения веб-приложения, а не линукса. (самый простейший пример для веб-хостинга статических файлов — это биллинг за трафик+сторейдж+пейджвьюс).

  • Ответить
    Филипп Кулин ООО Дремучий Лес

    > а вот такая уверенность в случайности предыдущих ошибок настораживает Я хочу поддержать коллегу в этом вопросе. Это уверенность не в случайности. Это вполне себе «плановые ошибки». Не ошибается тот, кто ничего не делает. Иногда бывают заблуждения, иногда не удаётся всё предусмотреть в тестовой среде, иногда меняются условия. И как правильно сказал коллега — не всегда это можно починить за 5 минут. Не поменять за один день ни стораджи, ни провайдера, ни даже систему внутренней маршрутизации. Уверенность, насколько я понимаю её, состоит в том, что такие ошибки будут исправлены. > Что касается отказоустойчивости, то у VPS и железных серверов есть концептуальная проблема с обеспечением отказоустойчивой работы приложения, потому что, по большому счету, для хостера это приложение — линукс! :-)) Но мало кому нужен отказоустойчивый доступ к линуксу, вместо этого нужна отказоустойчивая работа веб-приложения. Но так как в линуксах веб-приложения изначально строятся из говна и палок, то обеспечить абстрактную среду выполнения для них трудно Я вынесу это куда-нибудь в цитаты. Несмотря на то что там пропущена прослойка вебокружения — сути это не меняет :)

  • Ответить

    Ну коллега же пишет «смогли переболеть, уложившись в 3 месяца». Т.е. я эти слова понял так, будто дальше обещают только здоровое светлое будущее. Но его не будет. У всех периодически бывают крупные аварии, у Гугла, у Амазона, у Яндекса, вчера вон у DigitalRiver вендоры в лице Sun и HP почти сутки чинили некий NAS, из-за поломки которого практически все сервисы DR ушли в оффлайн. Т.е. ссылки на Хабр были и будут дальше. Что изменилось?

  • Ответить

    Пользовался услугами Мастерхоста с 2004 по 2008 год. Сбежал к eserver.ru , чего и всем желаю — более стабильного и дружелюбного хостера в России не встречал (надеюсь, с ростом клиентской базы они останутся такими же дружелюбными).

  • Ответить

    слушайте, а о чем эта статья ваще? есть два вектора — готовые решения, чтобы поднять типовой тот или иной сайт.. или давать сервера.. первый — Я.Народ и прочие Юкозы.. когда она станут _решениями.. второй — «правильные» облака, но это не про Клодо, скорее всего

  • Ответить

    Что-то такое впечатление от прочитанного, что все зависит от гамма-распределений, статистических норм отказов и пр… Типа, рано или поздно каждый хостер упадет. Не согласен. Все решают люди (или кадры, если вам нравится). На облачных конференциях одним из плюсов облаков декларируют — уменьшение расходов на персонал. Типа зачем держать админа на 5 серверов, когда можно отдать все в облако где один админ обслуживает 100 серверов, да и квалификация этого админа — выше. Но может быть и не выше? А может быть и текучка кадров? И вдруг обстоятельства… Да и вообще Облака и Удаленные Дата-Центры нам объявляют как панацею сокращения издержек и пр. А разве хостеры и облачники издержки не контролируют? Раз пошла «война за издержки» — жди граблей. Люди и оборудование не любят когда на нем экономят. Мастер хост — не первый удар граблями получает. Так может это не «консервировании проблема»? Может нужно подумать что не так в своем огороде? P.S. Кстати, сам я сижу на DreamHoste-е. Недавно у них тоже случился болкаут и даже на ТехКранче об этом написали. Но как они вышли из ситуации?! Какие письма клиентам разослали?! Кстати, сам я никаких проблем даже на заметил. Яндекс.Метрика падения серверов не заметило.