Классы доступности систем

Доступность системы (SA,Service Availability) — отношение времени, когда система работала, к общему времени.
Availability (%) = (Время работы / Общее время) × 100

Пример

Если система работала 364 дня и 6 часов в году:
Availability = (364.25 / 365) × 100 ≈ 99.79%

Классы доступности и допустимый простой

Класс	Доступность	Допустимый простой / год
Basic	99%	~3 дня 15 часов
High	99.9%	~8 часов 45 минут
Fault-Tolerant	99.99%	~52 минуты
Continuous	99.999%	~5 минут

Каждая «девятка» добавляет кратно больше затрат на инфраструктуру, тестирование, процессы поддержки.

Метрики доступности

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 позволяют автоматизировать эти расчёты.

Инструменты мониторинга доступности

Инструмент	Uptime	MTBF	MTTR	SLA-алерты
Prometheus	✓	✓	✓	Через Alertmanager
Grafana	✓	✓	✓	Через дашборды/алерты
Zabbix	✓	✓	✓	Да
Datadog	✓	✓	✓	Да
Pingdom	✓	—	—	Да
New Relic	✓	✓	✓	Да

Примеры под разные классы доступности

Класс 99% (базовая надёжность)

Один сервер, одно приложение, одна БД
Резервные копии раз в сутки
Мониторинг вручную или Zabbix/Prometheus без алертов
Downtime в случае обновлений или перезапуска

Класс 99.9% (высокая доступность)

Балансировка нагрузки: NGINX / HAProxy
Минимум два экземпляра приложения
Репликация БД (например, master-slave PostgreSQL)
Автоматический мониторинг и алерты (Prometheus + Alertmanager)
Оркестрация: Docker Compose / простейший Kubernetes кластер

Класс 99.99% (отказоустойчивость)

Геораспределённость: приложения и БД в разных зонах доступности
Active-Passive конфигурация (один сервер работает, второй на подстраховке. При сбое первый отключается, второй включается)
или Active-Active (оба сервера работают одновременно. Нагрузка распределяется. Если один падает — второй продолжает без переключений)
Автопереключение при сбое: Keepalived (переключает IP на резервный сервер), Patroni для PostgreSQL (управляет кластерами PostgreSQL — автоматически назначает нового мастера), Route53 health checks (при сбое трафик уходит на живой сервер)
CI/CD с canary/blue-green деплоем
RTO/RPO* оговорены и тестируются

Класс 99.999% (непрерывная доступность)

Многоуровневая геораспределённая архитектура (в разных регионах и странах)
Реальное Active-Active с кворумами (например, CockroachDB, Spanner)
Самовосстанавливающийся кластер (Kubernetes)
Контейнерные образы протестированы и зафиксированы по версии
Тестирование отказов в проде (chaos engineering*)

Улучшение доступность приложений

Балансировка нагрузки (load balancing) — оптимальное распределение запросов пользователей
(отправка части запросов пользователей на менее нагруженные серверы)

Масштабируемость (scalability) — автоматическое увеличение количества серверов, когда повышается нагрузка на приложение

Отказоустойчивость (fault tolerance) — способность системы нормально функционировать даже при отказах
Происходит это так: неработающая часть сервиса временно отключается и влечёт недоступность только одной функции приложения (например, отправки сообщений), но сохраняет доступность других (чтение ленты, просмотр сообщества и так далее)

RTO и RPO

RTO (Recovery Time Objective) — за сколько времени должна быть восстановлена система после сбоя
Пример: RTO = 15 минут → система должна заработать не позже чем через 15 минут после сбоя

RPO (Recovery Point Objective) — максимальное допустимое время потери данных
Пример: RPO = 5 минут → допустимая потеря не более 5 минут данных (время с последнего бэкапа или репликации)

Эти параметры обязательно обсуждаются при выборе архитектуры и процедур восстановления

Дополнительно

Хаос-инженерия (Chaos Engineering) — целенаправленное внесение отказов в прод, чтобы проверить устойчивость
(пример: Netflix Chaos Monkey)

Практика позволяет:

проверить устойчивость приложения
выявить слабые места и скрытые проблемы в проектировании и масштабировании
улучшить работу системы в реальных условиях использования

Полезно знать системному аналитику

Формализовать требования доступности
Учитывать их при описании архитектуры
Проверять, что метрики доступны и измеримы
Участвовать в обсуждении RTO/RPO, SLA и сценариев отказа

Что можно обсудить с заказчиком и архитектором

Какие потери допустимы при отказе
Варианты восстановления (ручной / автоматический)
План реагирования и RTO / RPO
Кто и как будет следить за SLA

Материалы

Наши статьи

Видео

Книги

Site Reliability Engineering. Надежность и безотказность как в Google

Пример​

Классы доступности и допустимый простой​

Метрики доступности​

Инструменты мониторинга доступности​

Примеры под разные классы доступности​

Класс 99% (базовая надёжность)​

Класс 99.9% (высокая доступность)​

Класс 99.99% (отказоустойчивость)​

Класс 99.999% (непрерывная доступность)​

Улучшение доступность приложений​

RTO и RPO​

Дополнительно​

Полезно знать системному аналитику​

Что можно обсудить с заказчиком и архитектором​