Доступность системы (SA,Service Availability) — отношение времени, когда система работала, к общему времени
Availability (%) = (Время работы / Общее время) × 100
🔘Пример: если система работала 364 дня и 6 часов в году:
Availability = (364.25 / 365) × 100 ≈ 99.79%
Метрики доступности
💙 Uptime / Downtime
💙Uptime — сколько времени система работает
💙Downtime — сколько система была недоступна (по любым причинам: сбои, обновления, ошибки конфигурации)
Эти метрики логируются в большинстве APM/мониторинговых систем (например, Datadog, Pingdom, New Relic, Zabbix)
💙 MTBF (Mean Time Between Failures)
MTBF = Общее время работы / Кол-во сбоев
💙показывает, как часто происходят сбои
💙чем выше MTBF 💙, тем надёжнее система
💙полезен для оценки стабильности инфраструктуры
💙MTTR (Mean Time To Recovery)
MTTR = Общее время восстановления / Кол-во инцидентов
Показывает, сколько времени в среднем уходит на устранение сбоя
📌MTBF и MTTR рассчитываются на основе логов событий и инцидентов
🌸Для автоматизации этих расчетов можно использовать Prometheus + Grafana, Zabbix, Datadog
RTO и RPO
🤩RTO (Recovery Time Objective) — за сколько времени должна быть восстановлена система после сбоя
Пример: RTO = 15 мин → система должна заработать не позже чем через 15 мин после сбоя
🤩RPO (Recovery Point Objective) — максимальное допустимое время потери данных
Пример: RPO = 5 мин → допустимая потеря не более 5 мин данных (время с последнего бэкапа или репликации)
❗️Эти параметры обязательно обсуждаются при выборе архитектуры и процедур восстановления
Примеры под разные классы доступности
💙 Класс 99% (базовая надёжность)
💙один сервер, одно приложение, одна БД
💙резервные копии раз в сутки
💙мониторинг вручную или Zabbix/Prometheus без алертов
💙downtime в случае обновлений или перезапуска
💙 Класс 99.9% (высокая доступность)
💙балансировка нагрузки: NGINX / HAProxy
💙минимум два экземпляра приложения
💙репликация БД (например, master-slave PostgreSQL)
💙автоматический мониторинг и алерты (Prometheus + Alertmanager)
💙оркестрация: Docker Compose / простейший Kubernetes кластер
💙 Класс 99.99% (отказоустойчивость)
💙геораспределённость: приложения и БД в разных зонах доступности
💙Active-Passive конфигурация (один сервер работает, второй на подстраховке. При сбое первый отключается, второй включается)
или Active-Active (оба сервера работают одновременно. Нагрузка распределяется. Если один падает — второй продолжает без переключений)
💙автопереключение при сбое: Patroni для PostgreSQL (управляет кластерами PostgreSQL — автоматически назначает нового мастера)
💙CI/CD с canary/blue-green деплоем
💙RTO/RPO оговорены и тестируются
💙Класс 99.999% (непрерывная доступность)
💙многоуровневая геораспределённая архитектура
💙реальное Active-Active с кворумами (например, CockroachDB)
💙самовосстанавливающийся кластер (Kubernetes)
💙контейнерные образы зафиксированы по версии
💙тестирование отказов в проде (chaos engineering)
📎Материалы
1. Классификация критичности информационных систем
2. Типы информационных систем и их уровни защищённости
3. Доступность IT-систем: поругаться или договориться?
4. MTBF — откуда берется «миллион часов MTBF»
5. Разбираемся с метрикой «Среднее временя между сбоями» (MTBF)
6. RTO и RPO: что это и в чём отличия
📚 Site Reliability Engineering. Надежность и безотказность как в Google
#архитектура
➿➿➿➿➿➿➿➿
🧑🎓 Больше полезного в базе знаний по системному анализу