Дорогие товарищи из мастерхоста!

[dil]

Попросите, пожалуйста, свой саппорт читать вопросы, прежде чем на них отвечать.
Потому что когда я явно спрашиваю о происхождении проблем, наблюдавшихся несколько дней назад, и привожу логи, мне несколько непонятно назначение ответа "сейчас всё работает". Это я и сам вижу.

Upd: "К сожалению, мы не можем точно установить причину, по которой контент не
отдавался 24 июля.
Скорее всего, в тот момент была высокая нагрузка на сервер, вследствие чего
наблюдалась вышеописанная проблема."

Comments

[ufm.livejournal.com]

Слушай, а зачем тебе?

[dil.livejournal.com]

ну как тебе сказать..
В течение довольно заметного времени (минут 15) я стабильно получаю error 502. причём на саму машину по ssh я зайти могу. Мне интересно, насколько проблема серьёзна, и собирается ли повторяться в будущем.

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

[ufm.livejournal.com]

Если тебе расскажут "что было" - ты не узнаешь ни на сколько серьёзная был проблема, ни будет ли она повторяться в будущем.

P.S. Вдруг ты не знаешь - я уже полгода в .м не работаю. А то решишь еще, что я как сотрудник с тобой общаюсь. :)

[dil.livejournal.com]

да, но рассказывать мне сначала, что проблемы вовсе нет, а потом, что они не знают - это как-то несерьёзно.

P.S. я знаю.

[ru-toor.livejournal.com]

Если в мастерхосте схема frontend-backend, а 502 ошибку отдал frontend, то наверняка backend (апач обычно) был не доступен. Ну а что уж там конкретно было с апачём - чьи-то кривые скрипты всё повесили, или MaxClients, или ещё что - поди теперь разберись...

[dil.livejournal.com]

да, там именно так. снаружи nginx, внутри апач. но мониторинг-то должен быть? я понимаю, если один раз что-то не отдалось, это фигня. но за 15 минут ничего не заметить..

[ru-toor.livejournal.com]

Ну даже если заметили мониторингом, в логи-то всё-равно конкретные причины обычно не пишутся - по логам их можно только косвенно расследовать, да и то не всегда.
Что равносильно "К сожалению, мы не можем точно установить причину, по которой контент не отдавался"

[kevit.livejournal.com]

сценарий (не имеет ничего общего с реальностью, но все же:)

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

[dil.livejournal.com]

я искренне надеюсь, что администраторы в мастерхосте достаточно грамотны, чтобы такую ситуацию понять

[titov.livejournal.com]

Конечно грамотны. Ну а толку?

Это же традиционный виртуальный хостинг, а не cloud, до конца решить такую проблему с повышенными нагрузками нереально. Ну, N сайтов на другую машинку перенести. И дальше существовать как-то. А делать хостинговый cloud - долго, дорого и незачем.

Вот то что саппорты стали отвечать на тикеты не читая, это беда .м.

[titov.livejournal.com]

Насчет ответа о причинах тоже не все просто. Проблема в том, что не все, спрашивающие о причинах, достаточно грамотны; фактически, если принять решение давать внятный и честный ответ на вопрос "а что было?", нужно будет по каждой 15-минутной проблеме писать текст с полстраницы А4. Кто этим будет заниматься? Зачем?

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

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

[dil.livejournal.com]

меня бы устроил ответ типа "были проблемы, связанные с тем-то, мы предприняли то-то, надеемся, что ситуация не повторится". А рассказывать клиенту, что хостер не владеет ситуацией..