Failover это не про серверы, а про процедуры

Дешёвая часть

Поднять второй сервер в другом ДЦ — это полдня и десять долларов в месяц. Настроить репликацию базы — ещё день. На этом инженеры обычно думают что failover готов. Это неправда. Готова только инфраструктурная часть.

Что значит «упал»

Самая частая ошибка failover-системы — слишком чувствительный детектор. Один таймаут не означает падения, особенно если монитор и primary в разных гео. Минимум — три подряд провала из трёх разных точек, с разными ASN. Иначе флипы на каждом TCP-jitter.

Health-check должен бить в осмысленную ручку: не /, а /healthz, которая внутри проверяет DB и кэш. Иначе вы поймаете ситуацию: nginx жив, отдаёт страницу-заглушку, а приложение лежит.

for host in [primary, backup]:
    for src in [point_a, point_b, point_c]:
        r = check(src, host, '/healthz', timeout=5)
    counters[host].push(all_ok)

if primary.failed_in_a_row >= 3 \
   and backup.ok_in_a_row >= 2:
    flip_dns(backup)

Anti-flap

После переключения нельзя сразу переключаться обратно. Минимум 15 минут lockout и подтверждение от человека для возврата. Причина падения часто сама нестабильна (DDoS, проблема у магистрального оператора), и автоматическое возвращение на primary часто означает второе падение через 5 минут.

Runbook возврата

После того как primary стабилизировался, возврат — это процедура с чек-листом. Проверить что primary действительно ок (несколько проверок подряд). Проверить что лаг репликации = 0. Сделать flip DNS обратно. Дождаться истечения TTL у клиентов. Только потом считать инцидент закрытым.

Что НЕ переключается автоматически

База данных. Платёжный шлюз. Любой stateful endpoint, у которого репликация асинхронная. Для них ручной runbook: остановить writes, дождаться lag=0, promote replica, обновить connection string. Автоматизация здесь стоит дороже, чем риск разбежавшихся данных.