High availability & replication
Тема дорожной карты · DevOps Engineer
Высокая доступность (HA) — это способность сервиса продолжать обслуживать трафик при отказе отдельных компонентов: за счёт репликации состояния между узлами, регионами или провайдерами и автоматического failover. Базовые механизмы — выбор лидера, синхронная и асинхронная репликация, кворумные записи, балансировщики с проверкой здоровья. Реальная HA измеряется в nines (99,9% = 8,7 часа простоя в год, 99,99% = 52 минуты), и каждый дополнительный девятка стоит примерно в 10 раз дороже по инфраструктуре и эксплуатационной сложности.
Как это работает
High availability & replication — инженерная практика поддержания данных доступными, сохранными и восстанавливаемыми при сбоях. Инструментарий: реляционные БД (PostgreSQL, MySQL) с primary/replica-репликацией, point-in-time recovery через WAL archiving; кэш-слои (Redis, Memcached) для горячих чтений; backup-стратегии (pg_dump, pgBackRest, WAL-G, Velero для Kubernetes PV); high-availability паттерны (Patroni для Postgres, Sentinel для Redis); runbooks disaster recovery с RPO/RTO-целями. Capacity planning — это нагрузочное тестирование (k6, Locust) и прогнозирование роста по реальному трафику.
Когда применять
Инвестируйте в High availability & replication с момента появления платящих пользователей или бизнес-критичных данных. Порядок: ночные бэкапы, проверенные ежеквартальными restore-drill'ами → репликация (sync или async) → automated failover → multi-region replication для серьёзных RPO. Не пропускайте restore-drill — бэкап, который никто не восстанавливал, — это отсутствие бэкапа. Для SaaS ₽249/мес как devroadmap.ru минимальная планка — один Postgres + ежедневный pg_dump в object storage с 7-дневным retention; HA-схемы преждевременны до контрактных SLO по uptime.
Типичные ошибки
Ловушки reliability: непроверенные бэкапы (классика — backup-скрипт "успешен", но дамп corrupted); replication lag, который никто не мониторит, пока replica не отстанет на 4 часа; manual failover, который никто не репетировал; Redis как "база" вместо кэша (по дефолту эфемерный); нет задокументированных RPO/RTO (узнаете на собственной шкуре после инцидента); cap-сюрпризы (БД упирается в 100% CPU на Чёрной пятнице, потому что никто не нагрузил). Game days — ежеквартально.