Pull to refresh

Comments 17

Хабралюди, подскажите, что делать в данной ситуации?

Очевидно, что нужно как минимум задуматься о смене хостинга.
Дело в том, что мы у них размещались на другом сервере с весны 2007. И ниразу не было проблем с сервером, были только зависания - но они быстро реагировали и перезагружали. А вот месяц назад мы взяли более мощный сервер.. И вот началось :(
У другого провайдера будет всё точно так же. Ну может повезёт и глючить сервер меньше будет... Дежурные операторы - это, как правило, студенты. У всех хостеров. Соответственно они могут нажать кнопку reset очень оперативно - но что-либо более сложное это уже проблема. В том числе подключение KVM (если он не вписан в договор и не подключен постоянно). Иногда в одной из смен случаются грамотные люди - но они там долго не задерживаются (хороший специалист легко может найти себе более достойное занятие чем ночные дежурства за копейки). На это, собственно, и надо рассчитывать.

P.S. Обратите внимание на то, что дата-центр, собственно, им не принадлежит и люди, которые имеют доступ к вашему серверу круглосуточно - это не сотрудники eServer.ru. Опять-таки: это - типичная ситуация. Даже MasterHost не все сервера ставит на свои площадки, обслуживаемые сотрудниками MasterHost'а - часть ставится в другие датацентры и там тоже кроме нажатия кнопки reset что-либо сделать большая проблема...
> У другого провайдера будет всё точно так же. Ну может повезёт и глючить сервер меньше будет... Дежурные операторы - это, как правило, студенты. У всех хостеров.

Какие зп, такие и работники.
Автор, имхо, не надо истерик! все хостеры страдают временными перебоями — никто не застрахован от этих неприятностей. А поносить хостера (читаем заголовок) — последнее дело.

Общее время простоя 2 часа.

А в договоре с хостером указано минимальное время простоя и скорость реакции тех поддержки?
SLA надо написать. И заключить договор в случае его наружения. Эскалацию инцидента должен обеспечить сам хостинг. Я честно говоря не понимаю, как хостер может жить не по ITIL, хотя бы в части Change Managment и Incident Managment
А я, честно говоря, не понимаю - в какое место он должен засунуть Change Managment и Incident Managment. Речь идёт не о виртуальном хостинге, а о colocation. В этом случае практически всё чем владеет хостер - информация о том сколько ватт жрёт та или иная железяка и сколько у неё Ethernet'ов. О каких Change Managment и Incident Managment может идти речь ???

SLA можно написать, но это - верный путь к увеличению времени простоя. Ибо есть только два варианта:
1. Хостер потребует заключить договор на администрирование сервера - чего обычно люди, размещающие сервера на colocation не хотят ибо это денег стоит (и лишает этот вариант всех преимуцществ colocation к тому же ибо вряд ли хостер согласится администрировать ту конфигурацию, которая нужна заказчику - скорее всего будет настаивать на своей).
2. Хостер умоет руки и предоставит решение всех проблем администрирования представителям заказчика - с 9:00 до 18:00 по будням. Вариант возможный, но вряд ли практически полезный...

Можно заказать постоянное подключение к KVM - но это тоже денег стоит (хотя обычно небольших).
То что сервер не работает, это что?
Инцидент.
То что у него надо поставить KVM - это что: Изменения.
ВОпросы еще есть?
Eserver - ужасный хостинг. Сам им пользовался около года. Тех поддержка иногда просто хамит вместо того, чтобы исправлять их же ошибки.
У меня с ними не раз была похожая ситуация. И вправду, ни до кого кроме тех поддержки дозвониться НЕРЕАЛЬНО!
Как хостер могу сказать следующее:
- у Вас не совсем справедливый, что ли, заголовок ;)
- ответ через 1 час 10 минут, что сдох винт - это правда долго и чести им не делает;
- оборудование все железное и от подобных случаев Вы точно не затрахованны у _любого_ хостера;
- если после урегулирования ситуации они не предложат Вам адекватным бонусов и конфет в виде их извинений, это будет косяк (при условии если в договоре, конечно, не написано обратного);
- относитесь в будущем с настороженностью к услугам, около логотипом и брендов которых болтается " .... №1!" ;)
Мы хостимся у Eserver уже больше года.
Проблем за это время было много... летели рейды, терялась информация и так далее...
Перезагрузка сервера после звонка обычно происходит достаточно быстро ... минут 15.
Но если что то случилось, то все... среднее время ответа на вопрос из аккауната 9 часов, последний раз 2 суток.
В последний раз было вот что...
сервер не работает, и на него нельзя зайти никак, звоню с утра туда, говорю перезагрузите, перезагрузили, только сервер не поднимается, опять звоню, говорю не поднимается ваш сервре, они говорят хорошо будем разбираться, и оставьте тикет, вам на него ответят.
Через 2! часа спрашивают пароль рута. Ответили
Через 2 часа! отвечают что у вас слетела файловая система на /tmp (там и действительно что-то с файловой системой)
Захожу на сайт на сервере через браузер, говорит что не может соединиться с базой, но это фигня, думаю надо mysql рестартануть, ага... захожу в папку /home а там все пусто!
Пишу им, типа разберитесь, что такое
Через 9! часов говорят что у вас там что то с партицией (кто бы мог подумать, я сам посмотреть не могу, и на это надо 9!!! часов. Там было с superblock беда)
Говорю разберитесь, и попробуйте восстановить информацию.
Через какое время они форматируют партицию, и говорят типа можете работать, восстанавливайте из своих! бекапов инфу и в перед.
говорят кто то удаленно!!! удалил партицию, вообшем типа они совсем не причем!
Пользуюсь этим хостингом примерно с 2005 года, и никогда не было никаких проблем. Поддержка - вежливая и толковая. По крайней мере, тот человек, который отвечает на мои запросы в службу поддержки. Причем ответы всегда, и днем и ночью, приходят в течение 10 минут.

Мне кажется, нельзя по вашим единичным случаям делать такие выводы, что техподдержка ужасная.
никто не спорит, случаи бывают разные... может у вас не было серьезных проблем...
Я им на телефон бываю дозваниваюсь иногда по пол часа... а вы говорите ответ за 10 минут.
Но у нас далеко не единичный случай. И если вопрос такой, что требуется админ, то все происходит очень-очень долго. И что самое плохое нельзя по телефону поговорить с админом, что бы проконсультироваться или что бы получить толковое объяснение почему это произошло. По телефону обычно отвечают: с вашей проблемой разбираются, вам ответят на тикет... Оно конечно подождать можно, но когда 9 часов.. и я у них спрашиваю что прям щас разбираются, они говорят да, все это время разбираются... но я то вижу что кроме меня на серваке никого нет и не было.
Давно бы ушли с eserver, только мне кажеться в России ожидать лучшего не приходиться.
> Давно бы ушли с eserver, только мне кажеться в России ожидать лучшего не приходиться.
согласен
Новые подробности:
Оказываеться, тогда когда слетел один хард - они его не заменили, а запустили сервер без него. И заменять его они собирались в течение 24 часов, но меня они об этом не оповестили.

А на следующий день, около 15:00 сдох второй хард. В 21:00 они начали восставливать информацию через биос:
Мы поставили ребилд первого диска на новый. Однако первый диск также показывает FAIL и также подлежит замене. Дабы избежать потери данных мы поставили ребилд в биосе контроллера. В принципе сервер можно запустить, но если диск будет сбоить, то это же и скопируется на новый диск и может быть непредвиденный результат.
Это на Ваше усмотрение. Ребилд долгий - может до завтра протянуться. Давайте хотя бы подождем до 30% процесса.

Сегодня в 12:00 было восстанолвенно только 25%. Следовательно информация полностью будет восстановлена завтра к 21:00. А запускать сервер с угрозой, что потерям всю инфу - не хочеться, так как инфы на 30 с лишнем гигов...
Ситуация конечно пренеприятнейшая, но бывает всякое.

Вопрос оч. простой, какие обязательства на себя берет хостер или компания, которая предоставляет Вам сервер в аренду, подписывайте SLA (если хостер подпишет конечно). Четко проговаривайте где чья зона ответственности.
Арендуйте сервера с встроенными модулями KVM, IPMI, дабы не зависеть от того, спит или не спит админ в каком то стороннем ДЦ.

Я «наевшися» в свое время всей этой ерунды, будучи клиентом у хостеров, сейчас оч. аккуратно подхожу к таким вопросам. Кстати как показывает практика, в большинстве случаев клиент сам является виновником всякого рода неполадок.
Sign up to leave a comment.

Articles