Что такое отказоустойчивость (fault tolerance)

Отказоустойчивость — способность системы продолжать работать корректно при появлении сбоев в её компонентах. Иначе: система «терпит» отказы (hardware, софт, сеть, человеческие ошибки) без критической потери функциональности и гарантирует приемлемое поведение для пользователей.

Ключевые идеи

• Выделение и маскирование отказов. Система должна обнаруживать сбой и либо автоматически переключаться на резерв, либо деградировать контролируемо.

• Сохранение инвариантов. Даже при частичных отказах важные свойства (целостность данных, корректность обработки) должны соблюдаться.

• Прогнозируемое поведение. Переход системы в degraded-mode и время восстановления (MTTR) — предсказуемы и управляемы.

Типы отказов и модели

• Crash/fail-stop — узел внезапно перестаёт отвечать.

• Byzantine (произвольные) — узел даёт некорректные/вредоносные ответы.

• Network partition — разделение сети; узлы изолированы.

• Transient/soft faults — временные ошибки (пакеты теряются, таймауты).
  Для разных моделей требуются разные алгоритмы: для простых fail-stop часто достаточно репликации; для Byzantine нужны более тяжёлые схемы (например, 3f+1 реплик чтобы терпеть f произвольных ошибок).

Количество реплик и кворумы (коротко)

• Для того чтобы просто сохранить хотя бы одну живую копию при f отказах — нужно f+1 реплик.

• Для систем, использующих кворум-голосование (majority), чтобы после f отказов остался кворум, обычно проектируют 2f+1 нод.

• Для устойчивости к Byzantine-faults теоретический минимум — 3f+1 нод.

Техники обеспечения отказоустойчивости

• Избыточность (redundancy): ноды, диски (RAID), кластеры, реплики БД.

• Репликация: синхронная (сильная согласованность, медленнее) и асинхронная (быстрее, возможна потеря недозаписанных транзакций).

• Failover / leader election: автоматическое переключение на резервный узел.

• Разделение доменов отказа: размещение в разных rack/AZ/region.

• Изоляция (bulkheads): ограничение распространения ошибок между компонентами (контейнеры, очереди).

• Circuit breakers и rate limiting: предотвращение лавинообразного ухудшения при проблемах зависимостей.

• Idempotency & retries с backoff: безопасные повторы и контролируемая нагрузка.

• Checkpointing и журналирование (WAL): возможность откатиться или восстановить состояние до консистентной точки.

• Разнообразие (diversity): разные реализации/поставщики, чтобы ошибка в одной реализации не затронула все копии.

• Health checks и heartbeats: быстрое детектирование недоступных компонентов.

Проектирование stateful vs stateless

Stateless-сервисы проще: масштабируются и заменяются. Stateful-компоненты (БД, очереди) требуют репликации, согласованности и механизма восстановления состояния (snapshot + WAL, журнал транзакций, реплика-промоут).

Метрики и SLA-связь

• MTTF / MTBF (среднее время до отказа), MTTR (среднее время восстановления).

• RPO / RTO — влияют на выбор стратегий репликации и резервирования.
  Отказоустойчивость про то, чтобы минимизировать влияние отказа (низкий RTO/RPO) и удерживать SLO.

Тестирование и валидация

• Chaos engineering (fault injection) — симуляция отказов в проде для проверки устойчивости.

• Failover drills, интеграционные тесты, регулярные проверки резервных сценариев, мониторинг метрик «здоровья».

Ограничения и компромиссы

Отказоустойчивость увеличивает сложность, стоимость (дублирование, сеть, оперирование) и может требовать компромиссов по согласованности (CAP). Нужно балансировать требования бизнеса (насколько критична потеря данных/простой) и стоимость реализации.