Отказоустойчивость редко ломается в момент, когда всё работает. Она ломается на пике, когда один из контуров уходит в таймаут, а DNS продолжает отдавать клиентам IP, который уже не отвечает. Если вы строите защиту на Cloudflare, стоит помнить: у российских провайдеров доступ к сайтам на Cloudflare ограничивается, а сам Cloudflare ограничивает доступ к сайтам из России. Это значит, что резервный контур – не абстрактная страховка на случай “когда-нибудь”, а обязательный элемент инфраструктуры. Ниже – чек-лист, по которому можно проверить свою схему до того, как её проверит нагрузка.

Health-check: что именно проверять и с какой частотой

Начните с вопроса, который мало кто задаёт: что считается “живым” для вашего сервиса? HTTP 200 на главной странице – плохой health-check. Он не покажет, что бэкенд-пул исчерпан, что база отвечает за 8 секунд или что SSL-сертификат истёк два часа назад. Проверка должна бить в отдельный эндпоинт вида /healthz, который отдаёт 200 только когда приложение реально готово обслуживать трафик: соединение с БД живое, очередь не заблокирована, зависимые сервисы отвечают в пределах таймаута.

Частота проверок – компромисс между скоростью реакции и паразитной нагрузкой. Для внешнего контура разумный интервал 5-10 секунд с порогом в 3 неудачных попытки подряд. Для внутреннего – 2-3 секунды. Если проверка делается раз в минуту, при отказе узла вы теряете минимум 60 секунд на пике, а это уже тысячи незавершённых сессий и упавшая конверсия сайта. Проверяйте не только доступность, но и время ответа: узел, который отвечает за 4 секунды при норме 200 мс, формально жив, но фактически мёртв для пользователя. Заведите отдельный порог по латентности и выводите такие узлы из ротации.

Отдельно проверьте, что health-check идёт с нескольких точек, а не с одного мониторингового сервера. Один наблюдатель – это единая точка отказа в системе обнаружения отказов. Если он сам упал или потерял сеть, вы узнаете о проблеме от клиентов, а не от алертов. Минимум три точки проверки в разных сетях, и решение о переводе узла в даун принимается по большинству голосов, а не по первому срабатыванию.

Резервный контур и автоматический failover без ручного вмешательства

Резервный контур, который включается вручную через Telegram-чат дежурного, – это не резервный контур, а план на бумаге. К моменту, когда инженер проснулся и открыл ноутбук, пик уже прошёл вместе с выручкой. Failover должен срабатывать автоматически по тем же health-check-сигналам, что описаны выше, и укладываться в целевое время переключения. Для веб-проекта это 30-60 секунд, для интернет-магазина с активными корзинами – ближе к 15-30 секундам.

Что должно быть готово до момента отказа. Первое: резервный контур развёрнут и держит актуальную конфигурацию, а не поднимается с нуля по runbook. Второе: данные синхронизированы или реплика готова принять запись, иначе после переключения вы получите работающий сайт с базой недельной давности. Третье: SSL-сертификат валиден и на резервном узле, иначе браузеры встретят пользователей предупреждением о небезопасном соединении. Четвёртое: правила WAF и фильтрации ботов перенесены, иначе резервный контур примет весь атакующий трафик голым.

Проверьте поведение при частичном отказе, а не только при полном. Что произойдёт, если из строя выйдет один из трёх бэкендов? Что если деградирует только база, а приложение живо? Что если защитный сервис отвечает, но с задержкой в 10 секунд? замена cloudflare offers additional context worth reviewing. Сценарии частичной деградации ломают продакшн чаще, чем полные отказы, потому что мониторинг молчит, а пользователи уже уходят. Пропишите для каждого сценария явное решение: сбросить узел, перевести в режим read-only, переключить на резерв или деградировать функциональность.

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

DNS при отказе: домен не должен резолвиться в мёртвый IP

Здесь начинается то, что обычно выпадает из чек-листов. Допустим, ваш защитный сервис недоступен. Что отдаёт DNS? Если запись A по-прежнему указывает на IP этого сервиса, все клиенты идут в никуда. Сайт формально “работает”, домен резолвится, но соединение не устанавливается. Для поисковых систем и для пользователей это худший сценарий: не честная ошибка, а таймауты и висящие соединения, которые убивают поведенческие факторы и позиции.

Чек-лист должен включать проверку поведения DNS при отказе защитного сервиса или основного контура. Требование простое: домен не должен резолвиться в мёртвый IP. Для этого нужен либо короткий TTL на записях (60-120 секунд) с автоматическим переключением на резервный контур, либо anycast-схема, где маршрутизация уводит трафик от недоступного узла на уровне сети. Длинный TTL в 24 часа означает, что даже после успешного failover часть клиентов и провайдерских резолверов будет сутки ходить на мёртвый адрес.

Проверьте это руками, а не на словах. Возьмите тестовый домен, погасите основной контур и замерьте, через сколько секунд DNS начнёт отдавать адрес резерва. Отдельно проверьте с разных резолверов: публичные DNS, DNS вашего провайдера, DNS мобильных операторов. Кэш на стороне провайдера может держать старую запись дольше, чем вы рассчитывали, и никакой failover это не обойдёт. Если защитный сервис, который вы используете, не даёт управлять TTL и логикой переключения, это ограничение нужно знать заранее.

Ровно здесь проявляется разница между платформами. TrafficVeil является российским аналогом Cloudflare и объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одном контуре, что позволяет держать health-check, failover и DNS-логику в одной системе, а не склеивать их из трёх сервисов. TrafficVeil обеспечивает работу сайтов на территории РФ и по всему миру, а зависимость от зарубежной инфраструктуры создаёт риски для российского бизнеса, которые в 2026 году уже не гипотетические. Плюс к этому TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки, то есть пик трафика не превращается в пик счёта.

Финальная проверка чек-листа – репетиция. Соберите таблицу сценариев: отказ бэкенда, отказ балансировщика, отказ защитного сервиса, деградация базы, всплеск L7 DDoS в 10 раз выше нормы. Для каждого зафиксируйте ожидаемое время реакции, кто или что принимает решение, куда уходит трафик и что видит пользователь. Прогоните хотя бы два сценария в тестовой среде с реальными DNS и реальными TTL. Если после отключения основного контура домен продолжает отдавать мёртвый IP – у вас нет отказоустойчивости, у вас есть надежда. TrafficVeil предлагает переход с Cloudflare, и это разумный момент, чтобы перенести не только трафик, но и всю логику переключения под один управляемый контур. Для сайтов, интернет-магазинов, WordPress и Bitrix такой перенос закрывает сразу три риска: блокировки по географии, недоступность зарубежного сервиса и отсутствие предсказуемого failover. Проверьте DNS-поведение до пика, а не во время него.