Комментарии 43
Что хуже – сайты могут выпасть из выдачи поисковых систем, поскольку поисковые роботы видят вместо сайта какую-нибудь 503-ю или 404-ю ошибки или не видят вообще ничего.
Уточните, пожалуйста, о каких системах идёт речь, а то за гуглом я что-то не замечал такого. Через гугл можно даже удалённые статьи с хабра читать, не говоря уж о лежащих сайтах.
0
Читать из сайт кеша безусловно можно, но мнению сеошников понижается позиция сайта в выдаче (как есть на самом деле знают только поисковики).
+2
Тогда предлагаю добавить третий пункт:
3. Что ещё хуже — могут отобрать доменное имя
Просто так. Основываясь ни на чём.
3. Что ещё хуже — могут отобрать доменное имя
Просто так. Основываясь ни на чём.
-5
Если страница выдает 404 или другой ошибочный код несколько раз — она точно будет исключена из выдачи.
А может даже с первого, это на усмотрение поисковой машины.
А может даже с первого, это на усмотрение поисковой машины.
+2
Потому что это написано в документации того же Яндекса)
+1
ну 404 по каждому чиху отдавать — это ССЗБ.
А вообще все что описано в статье делается через 302, его поисковики нормально обрабатывают, и не нужны танцы с dns.
А вообще все что описано в статье делается через 302, его поисковики нормально обрабатывают, и не нужны танцы с dns.
-1
Простите — а если сервер у хостера упал — кто вам будет 302 выдавать?
0
а 404 кто отдает?
а если без ерничаний — если упал фронт, то никто. Если бэк или база — то собственно фронт и должен это отдавать.
а если без ерничаний — если упал фронт, то никто. Если бэк или база — то собственно фронт и должен это отдавать.
0
1. А 404 тут причем?
Хостинг упал, сайт лежит — наружу может отдаваться 404 (хостер не прочитал конфиг, аккаунт хостинга выключен за неоплату или нарушение), 500 (ошибка на сервере хостинга или в сайте), 200 (сайт работает или ошибка внутри сайта), может отдаваться еще какой-то код. Речь идет о том, что если не отдается нормальный контент — сайт может выпасть или понизиться в выдаче.
2. Настраивать свои 302-е редиректы при ошибках можно если у вас свой сервер/VDS и есть способ определять что бэкенд лежит чтобы отдать 302-й редирект. Врядли у владельцу сайта получится договориться о такой настройке с провайдером виртуального хостинга (которого кстати достаточно для большинства интернет-магазинов).
Смена A-записи решает эти задачи и работает в том числе с дешевым виртуальным хостингом, от которого тоже практически ничего не требуется — главное чтобы небыло требования работать только со своими dns-серверами. Но такого обычно нет.
Хостинг упал, сайт лежит — наружу может отдаваться 404 (хостер не прочитал конфиг, аккаунт хостинга выключен за неоплату или нарушение), 500 (ошибка на сервере хостинга или в сайте), 200 (сайт работает или ошибка внутри сайта), может отдаваться еще какой-то код. Речь идет о том, что если не отдается нормальный контент — сайт может выпасть или понизиться в выдаче.
2. Настраивать свои 302-е редиректы при ошибках можно если у вас свой сервер/VDS и есть способ определять что бэкенд лежит чтобы отдать 302-й редирект. Врядли у владельцу сайта получится договориться о такой настройке с провайдером виртуального хостинга (которого кстати достаточно для большинства интернет-магазинов).
Смена A-записи решает эти задачи и работает в том числе с дешевым виртуальным хостингом, от которого тоже практически ничего не требуется — главное чтобы небыло требования работать только со своими dns-серверами. Но такого обычно нет.
0
только со своими dns-серверами
— в смысле только с dns-серверами хостера.
0
>с провайдером виртуального хостинга
давайте завершим разговор — vps стоит от 400 рублей в месяц.
давайте завершим разговор — vps стоит от 400 рублей в месяц.
0
К VPS должен прилагаться администратор, который умеет с VPS работать, а он стоит уже заметно больше 400 рублей в месяц.
кроме того VPS тоже может упасть как сам по себе так и вместе с физическим сервером хостера, тогда 302-ю снова отдавать никто не может.
кроме того VPS тоже может упасть как сам по себе так и вместе с физическим сервером хостера, тогда 302-ю снова отдавать никто не может.
+1
если vps падает сам по себе, то я за два часа поменяю вместе с dns записями еще и хостера. А по поводу навыков — большой разницы между администрированием vps и виртуального хостинга я не вижу. По мне так vps попроще будет. Или виртуальный хостинг сам работает, без админа?
Это раз. Если падает vps(на и виртуальный хостинг тоже) то проблемой занимаетесь не вы лично или ваш эникейщик, а техподдержка хостера, которая, если хостер нормальный — 24/7/365. У меня лично за три года работы — два инцидента, один на пол дня, но там не хостер а магистраль, второй — чисто хостера косяк, поправили за полтора часа.
Это раз. Если падает vps(на и виртуальный хостинг тоже) то проблемой занимаетесь не вы лично или ваш эникейщик, а техподдержка хостера, которая, если хостер нормальный — 24/7/365. У меня лично за три года работы — два инцидента, один на пол дня, но там не хостер а магистраль, второй — чисто хостера косяк, поправили за полтора часа.
0
Разница между VPS (даже с панелью) и виртуальным хостингом огромна в момент когда внутри VPS что-то наворачивается (например тупо место закончилось из-за того что кеш движка не чистился и всё встало). С VPS клиент предоставлен сам себе и сам должен понять что внутри его сервера случилось и как это чинить, для этого нужен человек который знает как работать с сервером. Если такого человека нет — его надо искать, а это небыстро.
А виртуальный хостинг — да, спокойно работает без админа (со стороны владельца сайта) по многу лет, т.к. ломаться там особо нечему + если всё же сломалось всегда можно просто восстановиться из резервной копии по кнопке из личного кабинета.
А виртуальный хостинг — да, спокойно работает без админа (со стороны владельца сайта) по многу лет, т.к. ломаться там особо нечему + если всё же сломалось всегда можно просто восстановиться из резервной копии по кнопке из личного кабинета.
+1
ok. тогда я тем более не понимаю. Виртуальный хостинг работает сам по себе, ломаться там нечему. Если упало — это поднимает хостер. Так получается, смысл статьи — что делать если хостер не чешется, а менять его не хочется?
0
Знаете, есть еще более дешевое решение — стоит оно аж целых 0 рублей, называется cloudflare(есть и альтернативные CDN) с включенной функцией Always online
+5
А если к нему прикрутить runbook.io (стоит в целых 10 раз дороже, правда), то можно полноценный фейловер сделать.
0
Да, про cloudflare знаю.
Кроме стоимости 0 рублей есть и другие отличия:
Я не говорю о том что cloudflare плохой — просто этот инструмент подходит не для всех задач.
Кроме стоимости 0 рублей есть и другие отличия:
- Cloudflare определяет падение сайта по http-коду 500 или невозможности подключения к серверу, т.е. если навернется база данных и на сайте будет каша — cloudflare может посчитать это нормой и если не повезет — даже закешировать её для always online.
- Нельзя задать какие именно страницы будут попадать в кеш — это cloudflare определяет сам, это могут оказаться не те страницы которые важны с точки зрения бизнеса, а просто самые посещаемые (например страница справки, а не того товара который начал рекламироваться вчера).
- Нельзя сделать свою заглушку на несуществующие страницы — будет показываться ошибка cloudflare, которая говорит что сайт упал. При этом методе — будет показываться условно главная страницы и телефон оператора (заглушку можно сделать и отличающуюся от сайта — это уже по желанию).
- При использовании использовании CDN все запросы проксируются через него, у Cloudflare нет серверов в России — скорость открытия страниц вырастает на скакание трафика до заграницы и обратно дважды если хостинг в России (от клиента до CDN и от CDN до хостинга).
Я не говорю о том что cloudflare плохой — просто этот инструмент подходит не для всех задач.
0
Да, по поводу алгоритма определения кешированных страниц и принципу кеширования есть ряд вопросов к cloudflare, однако такая «реализация», если ее так можно назвать существенно проще вашей (и да, если вы рекламируете определенную посадочную страничку, на которую много переходов — с большой долей вероятности cloudflare все же ее закеширует).
По поводу TTB для России через cloudflare — я бы не сказал, что существенно возрастает пинг (у меня к примеру, direct — 45-46 / cloudflare — 74-76), наоборот, если ваш сайт посещают НЕ ТОЛЬКО жители России а и жители из других регионов то это им даст существенное преимущество(да, я понимаю что это редко оправдано для интернет-коммерции).
По поводу TTB для России через cloudflare — я бы не сказал, что существенно возрастает пинг (у меня к примеру, direct — 45-46 / cloudflare — 74-76), наоборот, если ваш сайт посещают НЕ ТОЛЬКО жители России а и жители из других регионов то это им даст существенное преимущество(да, я понимаю что это редко оправдано для интернет-коммерции).
0
Это, наверное, какой-то очень хороший движок у сайта, который при ошибке базы данных всё равно отдаёт 200 OK и ту кашу, которая в результате получилась. Вот только в таком хорошем движке и код яндекс-метрики и гуглоаналитики тоже будет на месте, ибо в таких хороших движках они обычно захардкожены в шаблонах.
0
Специально проверил только что — например так делает joomla 1.5:
«Database Error: Unable to connect to the database:Could not connect to MySQL», код шаблона не выводит.
И битрикс:
DB query error.
Please try later.
Оба выдают код 200, оба выводят текст ошибки о базе и оба НЕ выводят шаблон. Проверил только эти две cms, других под руками нет но и эти две покрывают сразу заметный процент сайтов.
Для остальных код проверки можно вставить в текст, выдергиваемый из базы — это не проблема и тоже никакой поддержки со стороны сайта не требует, там хоть ключевое слово, хоть невидимый html-тег/комментарий.
«Database Error: Unable to connect to the database:Could not connect to MySQL», код шаблона не выводит.
И битрикс:
DB query error.
Please try later.
Оба выдают код 200, оба выводят текст ошибки о базе и оба НЕ выводят шаблон. Проверил только эти две cms, других под руками нет но и эти две покрывают сразу заметный процент сайтов.
Для остальных код проверки можно вставить в текст, выдергиваемый из базы — это не проблема и тоже никакой поддержки со стороны сайта не требует, там хоть ключевое слово, хоть невидимый html-тег/комментарий.
+1
Может, там все-таки какой-то отладочный режим включен? Джумла — ладно, с ней все ясно, но битрикс за большие деньги продают, так совсем нельзя.
0
Нет, никаких спец. режимов — просто установил свежий битрикс на пустой сайт в пустую базу и поставил в настройках неправильный пароль подключения.
В отладочном режиме битрикс выдает более подробную информацию.
В отладочном режиме битрикс выдает более подробную информацию.
0
Мда, в гугле по запросу «DB query error. Please try later. -ошибка -битрикс -форум» (отфильтровал вопросы на форумах) все понятно. Serious business.
Ну, можно воткнуть адов костыль — включить в php.ini/.htaccess output_buffering и auto_append_file, в котором проверять наличие подстроки в буфере и если что — отдавать 500-ю. Но это жесть.
Ну, можно воткнуть адов костыль — включить в php.ini/.htaccess output_buffering и auto_append_file, в котором проверять наличие подстроки в буфере и если что — отдавать 500-ю. Но это жесть.
0
Может я чего-то не понимаю, но я всегда считал, что смена записей в DNS туда и обратно может для конечного посетителя занять больше времени, чем ремонт сайта.
0
Это зависит от TTL. Обычно у А-записей он 1 час (иногда больше) — тогда да, чинить бывает быстрее. В данном случае TTL устанавливается на 90 секунд, т.е. уже быстрее переключать.
0
А ещё есть кеширующие DNS, которым стандарт не писан. Они могут сутками отдавать старые записи. И их количество статистически весьма заметное.
+3
Да, есть и такие, но по опыту переносов я бы не сказал что их сильно много — через сутки на старом IP я замечал только роботов, скачивающих картинки, в основном Bing. Подавляющая часть запросов переезжают примерно за TTL.
Для того чтобы сохранить остальных есть кластер, где при переезде между ДЦ IP-адреса сохраняются, а маршруты меняются через BGP, о нём я писал в предыдущем посте.
Этот вариант для тех у кого нет кластера или кому размещаться в кластере по каким-то причинам не хочется/не можется.
Для того чтобы сохранить остальных есть кластер, где при переезде между ДЦ IP-адреса сохраняются, а маршруты меняются через BGP, о нём я писал в предыдущем посте.
Этот вариант для тех у кого нет кластера или кому размещаться в кластере по каким-то причинам не хочется/не можется.
0
По закону подлости падения случаются на выходных или когда ты где-нибудь в отпуске далеко от интернета. Т.е. кроме времени ремонта, надо учитывать и время от возникноваения проблемы до начала ремонта.
+2
Если у резервного сервера хватает возможностей на «занимается мониторингом основного и при сбое меняет IP-адрес на адрес резервного сервера» — то почему-бы там не держать полную версию сайта? В табличке заказов автоинкремент побольше поставить чтобы заказы не пересекались и готово.
0
Развернуто могу отвечать долго, ограничусь двумя пунктами
Потому что это:
1. Заметно сложнее в настройке, а репликация например в MySQL еще и работает плохо — её надо периодически чинить.
2. Нужен полный резерв мощностей на запасной площадке чтобы при сбое принять на себя всю нагрузку.
Ну и перечитайте еще раз раздел поста: «Преимущества перед кластером».
Потому что это:
1. Заметно сложнее в настройке, а репликация например в MySQL еще и работает плохо — её надо периодически чинить.
2. Нужен полный резерв мощностей на запасной площадке чтобы при сбое принять на себя всю нагрузку.
Ну и перечитайте еще раз раздел поста: «Преимущества перед кластером».
0
Вы пишете:
Не требует никакой поддержки со стороны основного сайта, работает с любыми движками и технологиями.
Хотя до этого писали:
Для поддержания актуальности (цены, изменения в дизайне и т. п.) такой сайт-заглушка автоматически обновляется раз в неделю.
Лукавите, всё же нужно допиливать периодическую автогенерацию html. А так недалеко и до полноценной html-копии сайта дойти.
Не требует никакой поддержки со стороны основного сайта, работает с любыми движками и технологиями.
Хотя до этого писали:
Для поддержания актуальности (цены, изменения в дизайне и т. п.) такой сайт-заглушка автоматически обновляется раз в неделю.
Лукавите, всё же нужно допиливать периодическую автогенерацию html. А так недалеко и до полноценной html-копии сайта дойти.
-2
А где тут лукавство?
Я же и пишу что
Конечно для поддержания актуальности на резервный сервер должен эту актуальность поддерживать, но это не предъявляет никаких требований к основному сайту — он может быть написан как угодно, на чем угодно и ничего про запасной вариант не знать, он не занимается специальным генерированием кода заглушки.
Заглушка генерируется резервным сервером путем запроса страниц с основного сайта, в самом простом виде это может быть например wget …
Я же и пишу что
Не требует никакой поддержки со стороны основного сайта, работает с любыми движками и технологиями.
Конечно для поддержания актуальности на резервный сервер должен эту актуальность поддерживать, но это не предъявляет никаких требований к основному сайту — он может быть написан как угодно, на чем угодно и ничего про запасной вариант не знать, он не занимается специальным генерированием кода заглушки.
Заглушка генерируется резервным сервером путем запроса страниц с основного сайта, в самом простом виде это может быть например wget …
+1
> Клиенты не могут достучаться до сайта и вы теряете заказы
Если магазину заплатить 3-4 тысячи дорого, то и клиентов у него единицы, и шанс, что во время падения такой редкий клиент зайдет — не сильно большой. Если же поток такой, что прям час простоя — это очень «дорого» для магазина, то на постраховку денежка как-то, да найдется.
Да, у Cloudflare есть такая фича, что, если ваш сервер не отвечает, Cloudflare отдает его страницы из своего кеша с припиской «это кешированная версия». По идее, можно как-то внутри кода страницы такие моменты отловить, и либо прятать форму заказа, либо просить звонить в магазин по телефону — как вариант.
Если магазину заплатить 3-4 тысячи дорого, то и клиентов у него единицы, и шанс, что во время падения такой редкий клиент зайдет — не сильно большой. Если же поток такой, что прям час простоя — это очень «дорого» для магазина, то на постраховку денежка как-то, да найдется.
Да, у Cloudflare есть такая фича, что, если ваш сервер не отвечает, Cloudflare отдает его страницы из своего кеша с припиской «это кешированная версия». По идее, можно как-то внутри кода страницы такие моменты отловить, и либо прятать форму заказа, либо просить звонить в магазин по телефону — как вариант.
0
Надуманная проблема для ниши «4Круб. дорого».
При «нормальном» хостинге, владелец подобного сайта вообще не задумается об аптаймах.
При «нормальном» хостинге, владелец подобного сайта вообще не задумается об аптаймах.
0
НЛО прилетело и опубликовало эту надпись здесь
Мы говорим о ситуации, когда простой сайта обойдется в ~0 рублей (как сказали выше, вероятность упущенной покупки минимальна). Соответственно страховать подобные риски нет смысла.
0
Разве у нормальных хостингов всего 1 ISP/аплинк? И нет резервного?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чтобы сайт не падал: экономный метод