Комментарии 43
Что хуже – сайты могут выпасть из выдачи поисковых систем, поскольку поисковые роботы видят вместо сайта какую-нибудь 503-ю или 404-ю ошибки или не видят вообще ничего.
Уточните, пожалуйста, о каких системах идёт речь, а то за гуглом я что-то не замечал такого. Через гугл можно даже удалённые статьи с хабра читать, не говоря уж о лежащих сайтах.
Читать из сайт кеша безусловно можно, но мнению сеошников понижается позиция сайта в выдаче (как есть на самом деле знают только поисковики).
Если страница выдает 404 или другой ошибочный код несколько раз — она точно будет исключена из выдачи.
А может даже с первого, это на усмотрение поисковой машины.
А может даже с первого, это на усмотрение поисковой машины.
Потому что это написано в документации того же Яндекса)
ну 404 по каждому чиху отдавать — это ССЗБ.
А вообще все что описано в статье делается через 302, его поисковики нормально обрабатывают, и не нужны танцы с dns.
А вообще все что описано в статье делается через 302, его поисковики нормально обрабатывают, и не нужны танцы с dns.
Простите — а если сервер у хостера упал — кто вам будет 302 выдавать?
а 404 кто отдает?
а если без ерничаний — если упал фронт, то никто. Если бэк или база — то собственно фронт и должен это отдавать.
а если без ерничаний — если упал фронт, то никто. Если бэк или база — то собственно фронт и должен это отдавать.
1. А 404 тут причем?
Хостинг упал, сайт лежит — наружу может отдаваться 404 (хостер не прочитал конфиг, аккаунт хостинга выключен за неоплату или нарушение), 500 (ошибка на сервере хостинга или в сайте), 200 (сайт работает или ошибка внутри сайта), может отдаваться еще какой-то код. Речь идет о том, что если не отдается нормальный контент — сайт может выпасть или понизиться в выдаче.
2. Настраивать свои 302-е редиректы при ошибках можно если у вас свой сервер/VDS и есть способ определять что бэкенд лежит чтобы отдать 302-й редирект. Врядли у владельцу сайта получится договориться о такой настройке с провайдером виртуального хостинга (которого кстати достаточно для большинства интернет-магазинов).
Смена A-записи решает эти задачи и работает в том числе с дешевым виртуальным хостингом, от которого тоже практически ничего не требуется — главное чтобы небыло требования работать только со своими dns-серверами. Но такого обычно нет.
Хостинг упал, сайт лежит — наружу может отдаваться 404 (хостер не прочитал конфиг, аккаунт хостинга выключен за неоплату или нарушение), 500 (ошибка на сервере хостинга или в сайте), 200 (сайт работает или ошибка внутри сайта), может отдаваться еще какой-то код. Речь идет о том, что если не отдается нормальный контент — сайт может выпасть или понизиться в выдаче.
2. Настраивать свои 302-е редиректы при ошибках можно если у вас свой сервер/VDS и есть способ определять что бэкенд лежит чтобы отдать 302-й редирект. Врядли у владельцу сайта получится договориться о такой настройке с провайдером виртуального хостинга (которого кстати достаточно для большинства интернет-магазинов).
Смена A-записи решает эти задачи и работает в том числе с дешевым виртуальным хостингом, от которого тоже практически ничего не требуется — главное чтобы небыло требования работать только со своими dns-серверами. Но такого обычно нет.
только со своими dns-серверами
— в смысле только с dns-серверами хостера.
>с провайдером виртуального хостинга
давайте завершим разговор — vps стоит от 400 рублей в месяц.
давайте завершим разговор — vps стоит от 400 рублей в месяц.
К VPS должен прилагаться администратор, который умеет с VPS работать, а он стоит уже заметно больше 400 рублей в месяц.
кроме того VPS тоже может упасть как сам по себе так и вместе с физическим сервером хостера, тогда 302-ю снова отдавать никто не может.
кроме того VPS тоже может упасть как сам по себе так и вместе с физическим сервером хостера, тогда 302-ю снова отдавать никто не может.
если vps падает сам по себе, то я за два часа поменяю вместе с dns записями еще и хостера. А по поводу навыков — большой разницы между администрированием vps и виртуального хостинга я не вижу. По мне так vps попроще будет. Или виртуальный хостинг сам работает, без админа?
Это раз. Если падает vps(на и виртуальный хостинг тоже) то проблемой занимаетесь не вы лично или ваш эникейщик, а техподдержка хостера, которая, если хостер нормальный — 24/7/365. У меня лично за три года работы — два инцидента, один на пол дня, но там не хостер а магистраль, второй — чисто хостера косяк, поправили за полтора часа.
Это раз. Если падает vps(на и виртуальный хостинг тоже) то проблемой занимаетесь не вы лично или ваш эникейщик, а техподдержка хостера, которая, если хостер нормальный — 24/7/365. У меня лично за три года работы — два инцидента, один на пол дня, но там не хостер а магистраль, второй — чисто хостера косяк, поправили за полтора часа.
Разница между VPS (даже с панелью) и виртуальным хостингом огромна в момент когда внутри VPS что-то наворачивается (например тупо место закончилось из-за того что кеш движка не чистился и всё встало). С VPS клиент предоставлен сам себе и сам должен понять что внутри его сервера случилось и как это чинить, для этого нужен человек который знает как работать с сервером. Если такого человека нет — его надо искать, а это небыстро.
А виртуальный хостинг — да, спокойно работает без админа (со стороны владельца сайта) по многу лет, т.к. ломаться там особо нечему + если всё же сломалось всегда можно просто восстановиться из резервной копии по кнопке из личного кабинета.
А виртуальный хостинг — да, спокойно работает без админа (со стороны владельца сайта) по многу лет, т.к. ломаться там особо нечему + если всё же сломалось всегда можно просто восстановиться из резервной копии по кнопке из личного кабинета.
Знаете, есть еще более дешевое решение — стоит оно аж целых 0 рублей, называется cloudflare(есть и альтернативные CDN) с включенной функцией Always online
А если к нему прикрутить runbook.io (стоит в целых 10 раз дороже, правда), то можно полноценный фейловер сделать.
Да, про cloudflare знаю.
Кроме стоимости 0 рублей есть и другие отличия:
Я не говорю о том что cloudflare плохой — просто этот инструмент подходит не для всех задач.
Кроме стоимости 0 рублей есть и другие отличия:
- Cloudflare определяет падение сайта по http-коду 500 или невозможности подключения к серверу, т.е. если навернется база данных и на сайте будет каша — cloudflare может посчитать это нормой и если не повезет — даже закешировать её для always online.
- Нельзя задать какие именно страницы будут попадать в кеш — это cloudflare определяет сам, это могут оказаться не те страницы которые важны с точки зрения бизнеса, а просто самые посещаемые (например страница справки, а не того товара который начал рекламироваться вчера).
- Нельзя сделать свою заглушку на несуществующие страницы — будет показываться ошибка cloudflare, которая говорит что сайт упал. При этом методе — будет показываться условно главная страницы и телефон оператора (заглушку можно сделать и отличающуюся от сайта — это уже по желанию).
- При использовании использовании CDN все запросы проксируются через него, у Cloudflare нет серверов в России — скорость открытия страниц вырастает на скакание трафика до заграницы и обратно дважды если хостинг в России (от клиента до CDN и от CDN до хостинга).
Я не говорю о том что cloudflare плохой — просто этот инструмент подходит не для всех задач.
Да, по поводу алгоритма определения кешированных страниц и принципу кеширования есть ряд вопросов к cloudflare, однако такая «реализация», если ее так можно назвать существенно проще вашей (и да, если вы рекламируете определенную посадочную страничку, на которую много переходов — с большой долей вероятности cloudflare все же ее закеширует).
По поводу TTB для России через cloudflare — я бы не сказал, что существенно возрастает пинг (у меня к примеру, direct — 45-46 / cloudflare — 74-76), наоборот, если ваш сайт посещают НЕ ТОЛЬКО жители России а и жители из других регионов то это им даст существенное преимущество(да, я понимаю что это редко оправдано для интернет-коммерции).
По поводу TTB для России через cloudflare — я бы не сказал, что существенно возрастает пинг (у меня к примеру, direct — 45-46 / cloudflare — 74-76), наоборот, если ваш сайт посещают НЕ ТОЛЬКО жители России а и жители из других регионов то это им даст существенное преимущество(да, я понимаю что это редко оправдано для интернет-коммерции).
Это, наверное, какой-то очень хороший движок у сайта, который при ошибке базы данных всё равно отдаёт 200 OK и ту кашу, которая в результате получилась. Вот только в таком хорошем движке и код яндекс-метрики и гуглоаналитики тоже будет на месте, ибо в таких хороших движках они обычно захардкожены в шаблонах.
Специально проверил только что — например так делает 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-тег/комментарий.
Может, там все-таки какой-то отладочный режим включен? Джумла — ладно, с ней все ясно, но битрикс за большие деньги продают, так совсем нельзя.
Нет, никаких спец. режимов — просто установил свежий битрикс на пустой сайт в пустую базу и поставил в настройках неправильный пароль подключения.
В отладочном режиме битрикс выдает более подробную информацию.
В отладочном режиме битрикс выдает более подробную информацию.
Мда, в гугле по запросу «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-ю. Но это жесть.
Может я чего-то не понимаю, но я всегда считал, что смена записей в DNS туда и обратно может для конечного посетителя занять больше времени, чем ремонт сайта.
Это зависит от TTL. Обычно у А-записей он 1 час (иногда больше) — тогда да, чинить бывает быстрее. В данном случае TTL устанавливается на 90 секунд, т.е. уже быстрее переключать.
А ещё есть кеширующие DNS, которым стандарт не писан. Они могут сутками отдавать старые записи. И их количество статистически весьма заметное.
Да, есть и такие, но по опыту переносов я бы не сказал что их сильно много — через сутки на старом IP я замечал только роботов, скачивающих картинки, в основном Bing. Подавляющая часть запросов переезжают примерно за TTL.
Для того чтобы сохранить остальных есть кластер, где при переезде между ДЦ IP-адреса сохраняются, а маршруты меняются через BGP, о нём я писал в предыдущем посте.
Этот вариант для тех у кого нет кластера или кому размещаться в кластере по каким-то причинам не хочется/не можется.
Для того чтобы сохранить остальных есть кластер, где при переезде между ДЦ IP-адреса сохраняются, а маршруты меняются через BGP, о нём я писал в предыдущем посте.
Этот вариант для тех у кого нет кластера или кому размещаться в кластере по каким-то причинам не хочется/не можется.
По закону подлости падения случаются на выходных или когда ты где-нибудь в отпуске далеко от интернета. Т.е. кроме времени ремонта, надо учитывать и время от возникноваения проблемы до начала ремонта.
Если у резервного сервера хватает возможностей на «занимается мониторингом основного и при сбое меняет IP-адрес на адрес резервного сервера» — то почему-бы там не держать полную версию сайта? В табличке заказов автоинкремент побольше поставить чтобы заказы не пересекались и готово.
Развернуто могу отвечать долго, ограничусь двумя пунктами
Потому что это:
1. Заметно сложнее в настройке, а репликация например в MySQL еще и работает плохо — её надо периодически чинить.
2. Нужен полный резерв мощностей на запасной площадке чтобы при сбое принять на себя всю нагрузку.
Ну и перечитайте еще раз раздел поста: «Преимущества перед кластером».
Потому что это:
1. Заметно сложнее в настройке, а репликация например в MySQL еще и работает плохо — её надо периодически чинить.
2. Нужен полный резерв мощностей на запасной площадке чтобы при сбое принять на себя всю нагрузку.
Ну и перечитайте еще раз раздел поста: «Преимущества перед кластером».
Вы пишете:
Не требует никакой поддержки со стороны основного сайта, работает с любыми движками и технологиями.
Хотя до этого писали:
Для поддержания актуальности (цены, изменения в дизайне и т. п.) такой сайт-заглушка автоматически обновляется раз в неделю.
Лукавите, всё же нужно допиливать периодическую автогенерацию html. А так недалеко и до полноценной html-копии сайта дойти.
Не требует никакой поддержки со стороны основного сайта, работает с любыми движками и технологиями.
Хотя до этого писали:
Для поддержания актуальности (цены, изменения в дизайне и т. п.) такой сайт-заглушка автоматически обновляется раз в неделю.
Лукавите, всё же нужно допиливать периодическую автогенерацию html. А так недалеко и до полноценной html-копии сайта дойти.
А где тут лукавство?
Я же и пишу что
Конечно для поддержания актуальности на резервный сервер должен эту актуальность поддерживать, но это не предъявляет никаких требований к основному сайту — он может быть написан как угодно, на чем угодно и ничего про запасной вариант не знать, он не занимается специальным генерированием кода заглушки.
Заглушка генерируется резервным сервером путем запроса страниц с основного сайта, в самом простом виде это может быть например wget …
Я же и пишу что
Не требует никакой поддержки со стороны основного сайта, работает с любыми движками и технологиями.
Конечно для поддержания актуальности на резервный сервер должен эту актуальность поддерживать, но это не предъявляет никаких требований к основному сайту — он может быть написан как угодно, на чем угодно и ничего про запасной вариант не знать, он не занимается специальным генерированием кода заглушки.
Заглушка генерируется резервным сервером путем запроса страниц с основного сайта, в самом простом виде это может быть например wget …
> Клиенты не могут достучаться до сайта и вы теряете заказы
Если магазину заплатить 3-4 тысячи дорого, то и клиентов у него единицы, и шанс, что во время падения такой редкий клиент зайдет — не сильно большой. Если же поток такой, что прям час простоя — это очень «дорого» для магазина, то на постраховку денежка как-то, да найдется.
Да, у Cloudflare есть такая фича, что, если ваш сервер не отвечает, Cloudflare отдает его страницы из своего кеша с припиской «это кешированная версия». По идее, можно как-то внутри кода страницы такие моменты отловить, и либо прятать форму заказа, либо просить звонить в магазин по телефону — как вариант.
Если магазину заплатить 3-4 тысячи дорого, то и клиентов у него единицы, и шанс, что во время падения такой редкий клиент зайдет — не сильно большой. Если же поток такой, что прям час простоя — это очень «дорого» для магазина, то на постраховку денежка как-то, да найдется.
Да, у Cloudflare есть такая фича, что, если ваш сервер не отвечает, Cloudflare отдает его страницы из своего кеша с припиской «это кешированная версия». По идее, можно как-то внутри кода страницы такие моменты отловить, и либо прятать форму заказа, либо просить звонить в магазин по телефону — как вариант.
Надуманная проблема для ниши «4Круб. дорого».
При «нормальном» хостинге, владелец подобного сайта вообще не задумается об аптаймах.
При «нормальном» хостинге, владелец подобного сайта вообще не задумается об аптаймах.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чтобы сайт не падал: экономный метод