Failover и отказоустойчивость

Два слова, которые не одно и то же

Люди говорят «отказоустойчивый», когда имеют в виду «есть failover», и зазор между ними — там, где ломаются ожидания.

• Failover — это реактивная последовательность: компонент умирает, что-то это замечает, и трафик переносится на здоровую замену. Есть окно — обнаружение плюс переключение — в течение которого запросы отказывают или висят. Failover даёт тебе высокую доступность: система восстанавливается быстро, но не мгновенно. Продвижение БД в active-passive — это failover.
• Отказоустойчивость (fault tolerance) — это маскировка отказа, так что видимого перерыва нет вообще. Работу сбойного компонента впитывают другие с нулевым разрывом, ведь резервирование уже было живым и обслуживало. Active-active за балансировщиком отказоустойчив к потере одного узла — выжившие уже принимали трафик, так что потеря одного невидима пользователям.

Практическое различие: у отказоустойчивой системы нет окна восстановления для отказов, которые она терпит; у высокодоступной системы с failover оно короткое. Настоящая отказоустойчивость дороже (резервную ёмкость гоняешь и оплачиваешь вживую, непрерывно), так что большинство систем высокодоступны через failover для большинства компонентов и отказоустойчивы лишь там, где разрыв недопустим.

Механика: обнаружить → продвинуть → перенаправить → откатиться

Failover — это конвейер из четырёх шагов, и у каждого свой режим отказа:

1. Обнаружить. Что-то должно заметить, что компонент пропал. Два частых механизма: health checks (наблюдатель периодически зондирует «ты в порядке?» и ждёт здорового ответа) и heartbeats (компонент периодически объявляет «я жив», и тишина значит смерть). Обнаружение — это трейдофф: зондируй слишком редко — медленно реагируешь; зондируй слишком агрессивно — мгновенный сбой выглядит как смерть, и ты переключаешься зря.
2. Продвинуть. Резерв возвышают, чтобы взять на себя — реплика становится новым primary, пассивный узел — активным. Для stateful-систем это опасный шаг: ты должен быть уверен, что старый реально пропал.
3. Перенаправить. Трафик направляют на новую цель — обнови DNS, переконфигурируй балансировщик, переключи виртуальный IP. Шаг ограничен тем, как быстро распространится перенаправление (TTL DNS, дренаж соединений).
4. Откатиться (fail back). Когда оригинал восстанавливается, ты решаешь, возвращаться ли к нему (fail back) или оставить продвинутый узел новым primary. Откат сам по себе — управляемый failover и частое место, где вызывают второй сбой, делая его небрежно под нагрузкой.

Все четыре шага вместе означают: каждая деталь инфраструктуры — TTL DNS, интервал health-check, время прогрева резерва — должна быть спроектирована до инцидента, а не придумываться в его ходе. Пропустишь шаг fencing — рискуешь split-brain; пропустишь шаг перенаправления — трафик не найдёт нового primary.

Split-brain: отказ, который вызывает failover

У сбоя из вступления есть имя: split-brain (расщепление мозга). Он случается, когда failover продвигает новый primary, пока старый ещё жив — обычно потому что сетевое разделение лишило их возможности видеть друг друга, и каждая сторона заключила, что другая мертва. Теперь два узла оба верят, что они primary, оба принимают записи, и данные расходятся. Когда разделение залечивается, у тебя две конфликтующие истории и нет автоматического способа их слить. Split-brain уникально мерзок, потому что не теряет доступность — обе половины подняты и обслуживают — он теряет корректность, что часто хуже и труднее обнаружить.

Корень — фундаментальная неоднозначность, которую обнаружение никогда не разрешит полностью: с точки зрения резерва «primary упал» и «я потерял сеть до primary» выглядят одинаково — тишина в любом случае. Все защиты сводятся к тому, чтобы максимум один узел мог победить:

• Кворум / консенсус. Требуй согласия большинства узлов перед продвижением. Разделение, оставившее старый primary в меньшинстве, значит, что он не может продолжать быть primary, и продвигает только сторона большинства. Поэтому системам консенсуса (Raft, ZooKeeper, etcd) нужно нечётное число узлов — большинство должно быть однозначным.
• Fencing (STONITH — «выстрели другому узлу в голову»). Перед продвижением принудительно отрежь старый primary — отзови его аренду хранилища, выключи питание, заблокируй в сети — чтобы, даже будь он жив, он не мог продолжать писать. Ты не просишь его уйти; ты делаешь уход физически принудительным.

Graceful degradation: отказать частично вместо целиком

Отказоустойчивость не всегда всё-или-ничего. Graceful degradation (плавная деградация) — это проектирование системы так, чтобы под отказом сбрасывать неважную функциональность вместо полного потемнения. Если сервис рекомендаций лежит — покажи общий список популярного вместо 500. Если кэш персонализации недостижим — отдай страницу без персонализации. Если записи отказывают — оставайся поднятым в режиме только-чтение. Пользователь получает деградировавший, но работающий опыт, и отказ сдержан в сломавшейся фиче. Это практическое дополнение к резервированию: резервирование держит критический путь поднятым, graceful degradation делает некритические пути отказывающими мягко, так что смерть одной зависимости — это пропавшая фича, а не пустая страница.

Взаимодействие ретраи/таймаут/failover — где failover превращается в сбой

Это ловушка senior-уровня, и поэтому AWS посвящает ей целую статью Builders’ Library. Failover, таймауты и ретраи взаимодействуют, и при неверной настройке усиливают малый отказ в каскадный:

• Таймауты надо ставить осознанно. Слишком длинные — и одна медленная зависимость держит потоки в заложниках, пока весь пул не исчерпан, и ты превратил один медленный бэкенд в полный сбой. Слишком короткие — и ты бросаешь запросы, что прошли бы, производя отказы.
• Ретраи помогают с кратковременными сбоями, но опасны при перегрузке. Когда зависимость борется, наивные ретраи умножают нагрузку на неё ровно тогда, когда она меньше всего может это вынести — петля обратной связи, что AWS зовёт retry storm (шторм ретраев), что гонит просадку в сбой. Защиты: бюджет ретраев (ограничь ретраи как долю трафика, а не на запрос), экспоненциальный backoff (жди дольше между попытками) и jitter (рандомизируй backoff, чтобы все клиенты не ретраили в унисон, создавая синхронные всплески). И ретраи уместны только на идемпотентных операциях — ретрай неидемпотентной записи может дважды списать с клиента.
• Во время failover всё это складывается: в момент смерти primary каждый запрос в полёте таймаутится разом, каждый клиент ретраит разом, и этот синхронный всплеск приземляется на резерв, что ещё разогревается — так что само событие failover может опрокинуть то, что ты только что продвинул. Рецепт AWS (ограниченные таймауты, ограниченные ретраи, экспоненциальный backoff с jitter, circuit breakers) существует именно ради того, чтобы восстановление не стало следующим инцидентом.