Данные и отказоустойчивость
Тема дорожной карты · DevOps Engineer
Надёжность данных — то, что делает сервис заслуживающим доверия: долговечность (данные не теряются), доступность (данные достижимы, когда нужны) и согласованность (чтения возвращают корректные значения при конкурентных записях и сбоях). Компромиссы описываются теоремами CAP и PACELC, а практические ответы — стратегией репликации, кворумами записи, периодичностью бэкапов и учениями по аварийному восстановлению. Надёжность — свойство всей системы, а не отдельного компонента.
Как это работает
Данные и отказоустойчивость — инженерная практика поддержания данных доступными, сохранными и восстанавливаемыми при сбоях. Инструментарий: реляционные БД (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) и прогнозирование роста по реальному трафику.
Когда применять
Инвестируйте в Данные и отказоустойчивость с момента появления платящих пользователей или бизнес-критичных данных. Порядок: ночные бэкапы, проверенные ежеквартальными 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 — ежеквартально.