Что такое high availability (HA)

High Availability (HA) — это свойство системы оставаться работоспособной и доступной для пользователей при нормальных и форс-мажорных условиях. Цель HA — минимизировать время простоя и максимально сократить влияние отказов на бизнес-функции.

Как измеряют

Основная метрика — доступность (availability) в процентах за период. Примеры допустимого простоя:

• 99% → ~3 дня/год;

• 99.9% → ~8.76 часа/год;

• 99.99% → ~52.6 минуты/год;

• 99.999% → ~5.26 минуты/год.
  Связанные показатели: RTO (сколько времени разрешено на восстановление) и RPO (сколько данных можно потерять).

Ключевые принципы

• Избыточность — дублирование компонентов (N+1, active-active, active-passive).

• Отсутствие single point of failure — никакой элемент не должен полностью выводить систему из строя.

• Автоматический failover — мгновенная или быстрая замена упавшего узла/сервиса.

• Зоны отказа (fault domains) — разделение инфраструктуры по зонам/локализациям (rack/AZ/region) для изоляции сбоев.

• Мониторинг и детекция — раннее обнаружение деградации и автоматическая реакция.

• Graceful degradation — при проблемах часть функционала может быть ограничена, но критичные операции сохраняются.

• Оркестрация обновлений — rolling updates, canary, blue/green для минимизации простоя при релизах.

Архитектурные паттерны

• Active-Active — несколько узлов одновременно обрабатывают нагрузку; преимущества: масштабирование и мгновенная замена; сложность: согласованность состояния.

• Active-Passive — резервный узел готов, но не обрабатывает трафик; при отказе происходит переключение. Проще реализовать согласованность, но переключение может занимать время.

• Replication & clustering — БД/сервисы с репликацией (синхронная/асинхронная) и кластерными алгоритмами (Raft, Paxos).

• Load balancing — распределение трафика по здоровым узлам; health checks для выявления плохих инстансов.

• Geo-redundancy (multi-region) — копии в разных регионах для защиты от региональных катастроф.

Statefulness vs Stateless

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

CAP и компромиссы

При распределённых системах приходится выбирать между согласованностью, доступностью и устойчивостью к разделению сети. HA часто требует компромиссов: ради доступности можно ослабить строгую согласованность (eventual consistency).

Операция и тестирование

• Регулярные испытания: failover drills, chaos engineering (симуляция отказов).

• On-call и runbooks: готовые шаги для быстрого восстановления.

• Автоматизация recovery: скрипты, orchestration, IaC.

• Мониторинг SLI/SLO и error budget: предупреждение о сжигании бюджета до SLA-нарушения.

Ограничения и стоимость

Повышенная доступность увеличивает сложность и затраты (дублирование, сеть, согласованность, операционные расходы). Балансирует бизнес-требования: критичные системы требуют больших вложений, менее важные — разумный компромисс.

Практические проверки при проектировании HA

• какие компоненты являются single point of failure;

• как работает failover и сколько он занимает;

• где хранятся состояния и как их синхронизировать;

• как тестировать recovery и проверять RTO/RPO;

• какие уровни доступности задать в SLO/SLA и как отслеживать.