Пример методики расчета доступности¶

Представим некий облачный сервис, в котором клиент может купить свою инфру в виде виртуальных машин. Клиент говорит: "Мне нужна доступность 99,95% для моих виртуальных машин". Что это значит на практике? Давайте разберем на конкретных числах и рублях (очень-очень-очень упрощенно).

Бизнес-контекст¶

Сервис: облачный провайдер виртуальных машин Целевая аудитория: средний бизнес, стартапы, разработчики Тариф: 500 ₽/месяц за VM среднего класса (2 vCPU, 4 ГБ RAM) Количество VM: 10000 виртуальных машин у клиентов Годовой оборот: 10000 × 500 × 12 = 60000000 ₽/год

Перевод "девяток" в рубли¶

Бизнес требует 99,95% доступности.

Что это значит: - Год = 8760 часов - Допустимый простой = 100% - 99,95% = 0,05% - 0,05% от 8760 часов = 4,38 часов в год

А теперь в рублях: - Средний доход в час: 60000000 ₽ / 8760 ≈ 6850 ₽/час - Стоимость 1 часа простоя: 6850 ₽ - Бюджет ошибок на год: 4,38 × 6850 ≈ 30000 ₽

Клиент "покупает" право на 4,5 часа простоя в год. Если мы превысим этот лимит, то заплатим компенсации.

Декомпозиция системы ВМ¶

Видимая для клиента "виртуальная машина" состоит из множества компонентов:

Виртуальная машина клиента:
├── Гипервизор
├── Вычислительные ресурсы (CPU)
├── Память (RAM)
├── Виртуальный диск (Storage)
│   ├── Система хранения
│   └── Сеть хранения данных (SAN)
├── Сеть
│   ├── Виртуальный коммутатор
│   ├── Физический сетевой интерфейс
│   └️── Балансировщик трафика
├── Система управления (Control Plane)
└── Внешние зависимости
    ├── Электроснабжение ЦОД
    ├── Охлаждение
    └── Интернет-каналы

Расчет доступности компонентов (в рублях)¶

Компонент 1: физический сервер¶

Стоимость сервера: 500000 ₽
MTTF (среднее время наработки на отказ): 50000 часов
MTTR (время замены): 4 часа

Доступность одного сервера:

A = MTTF / (MTTF + MTTR) = 50000 / (50000 + 4) = 0,99992 = 99,992%

Но у нас кластер из 100 серверов! - Вероятность отказа одного сервера: 0,008% - Вероятность отказа кластера (N+1 резервирование): Нужно чтобы отказали 2 сервера одновременно P_отказа_кластера = P_отказа_кластера = (Вероятность отказа одного сервера)² × Количество уникальных пар серверов = (0,00008)² × C(100, 2) ≈ 0,00000064 × 4950 ≈ 0,0032%

Note

(0,00008)² - вероятность отказа конкретной пары серверов. 0,00008 (или 0,008%) - это предполагаемая вероятность отказа одного конкретного сервера в рассматриваемый промежуток времени. Предполагается, что отказы серверов независимы (отказ одного не влияет на отказ другого). По правилу вероятности для независимых событий, вероятность того, что одновременно откажут сервер А И сервер Б, равна произведению их вероятностей: P(А отказал И Б отказал) = P(А отказал) * P(Б отказал) = 0,00008 * 0,00008 = (0,00008)² = 0,0000000064. Это очень маленькое число (6.4e-9), потому что одновременный отказ двух конкретных машин — событие крайне маловероятное.
C(100, 2) - количество уникальных пар серверов, которые могут отказать. Нам неважно, какие именно два сервера откажут. Отказ любой пары приводит к отказу кластера. C(100, 2) - это число сочетаний из 100 по 2. Оно показывает, сколькими способами можно выбрать 2 сервера из 100, когда порядок не важен (отказ пары "сервер 1 и сервер 53" - то же самое, что "сервер 53 и сервер 1"). Формула для числа сочетаний: C(n, k) = n! / (k! * (n-k)!) C(100, 2) = 100! / (2! * 98!) = (100 * 99) / (2 * 1) = 9900 / 2 = 4950.

Несмотря на то, что отказ конкретной пары невероятно редок, таких возможных "слабых мест" (пар) в кластере из 100 серверов очень много — 4950.

Итоговый расчет: 0,0000000064 × 4950 ≈ 0,00003168. Мы умножаем вероятность катастрофического события для одной конкретной пары на количество всех возможных пар, которые могут привести к катастрофе. 0,0000000064 * 4950 = 0,00003168 (что равно ~0.0032%).

~0,0032% это и есть искомая вероятность того, что в кластере из 100 серверов одновременно откажут ровно два сервера в заданный промежуток времени. Эта вероятность значительно выше (в 4950 раз!), чем вероятность отказа конкретной, заранее выбранной пары (0,00000064%). На практике это означает: хоть отказ любых двух конкретных машин почти невозможен, из-за большого количества компонентов в системе общий риск отказа всей системы (кластера) становится хоть и небольшим, но уже поддающимся оценке.

Доступность кластера: 99,9968%

Стоимость обеспечения: - Дополнительные серверы для N+1: 5 серверов × 500000 ₽ = 2500000 ₽ - Амортизация: 2500000 ₽ / 5 лет = 500000 ₽/год

Компонент 2: система хранения (Ceph, например)¶

Конфигурация: 3 реплики, 3 сервера хранения

Расчет: - Доступность одного сервера хранения: 99,9% - Система работает при 2 из 3 рабочих серверов - Формула: 1 - (вероятность отказа 2+ серверов)

P_отказа = C(3, 2)×(0,001)²×(0,999) + C(3, 3)×(0,001)³
         = 3×0,000001×0,999 + 0,000000001
         = 0,000002997 + 0,000000001 = 0,000002998

Доступность: 99,9997%

Стоимость: - 3 сервера хранения: 3 × 750000 ₽ = 2250000 ₽ - Амортизация: 450000 ₽/год

Компонент 3: сеть¶

Коммутаторы: активный-пассивный
Доступность: 99,99%
Стоимость: 2 × 300000 ₽ = 600000 ₽ (амортизация 120000 ₽/год)

Компонент 4: электроснабжение ЦОД¶

Основной источник + ИБП + дизель-генератор
Доступность: 99,999%
Стоимость инфраструктуры: 10000000 ₽
Амортизация: 2000000 ₽/год

Общий расчет доступности¶

Последовательная модель (все должно работать):¶

A_системы = A_серверы × A_хранилище × A_сеть × A_электричество
          = 0,999968 × 0,999997 × 0,9999 × 0,99999
          = 0,999855 = 99,9855%

Проблема: 99,9855% < 99,95%? Нет, это больше! Но: Это теоретический максимум. На практике добавляются: - ошибки ПО (гипервизора, управления) - человеческий фактор (ошибочные операции) - плановые работы

С учетом практических факторов:¶

A_практическая = A_теоретическая × (1 - P_человек) × (1 - P_ПО)
               = 0,999855 × 0,999 × 0,9995
               = 0,99835 = 99,835%

Понятно, что без дополнительных мер мы не достигнем 99,95%

Улучшения для достижения 99,95%¶

Инвестиция 1: zero-downtime миграция¶

Проблема: Плановые работы (апдейты безопасности) требуют перезагрузки серверов.

Решение: Live migration между хостами - Стоимость разработки: 5000000 ₽ - Экономия простоя: 2 часа/месяц × 12 = 24 часа/год - Стоимость простоя: 24 × 6850 ₽ = 164400 ₽/год - ROI: 5000000 ₽ / 164400 ₽ ≈ 30 лет (не окупается!)

Но: Это также снижает риски внеплановых простоев.

Инвестиция 2: улучшение мониторинга и автовосстановление¶

Разработка системы auto-healing: 2000000 ₽
Снижение MTTR с 4 часов до 30 минут
Экономия: 3,5 часа на инцидент × 10 инцидентов/год × 6850 ₽ = 239750 ₽/год
ROI: 8,3 года

Инвестиция 3: геораспределение (2 ЦОД)¶

Наиболее эффективно, но дорого:

Стоимость: - Второй ЦОД: 50000000 ₽ - МежЦОДовая связь: 1000000 ₽/год - Операционные расходы: +15000000 ₽/год

Расчет доступности: - ЦОД1: 99,835% - ЦОД2: 99,835% - Система работает если хотя бы 1 ЦОД жив

P_отказа = P(ЦОД1_упал) × P(ЦОД2_упал) = 0,00165 × 0,00165 = 0,0000027225
A = 99,99973%

Понятно, что геораспределение дает "пять девяток", но стоит 66000000 ₽ капитальных + 16000000 ₽ операционных в год.

Экономический компромисс¶

Вариант 1: Один ЦОД с улучшениями - Капитальные затраты: 7000000 ₽ - Операционные: +2000000 ₽/год - Доступность: 99,92% - Риск: полный выход ЦОД = 100% простой

Вариант 2: Два ЦОД (активный-пассивный) - Капитальные: 60000000 ₽ - Операционные: +16000000 ₽/год
- Доступность: 99,99% - Риск: минимальный

Вариант 3: Два ЦОД (активный-активный) - Капитальные: 80000000 ₽ - Операционные: +20000000 ₽/год - Доступность: 99,999% - Риск: практически нулевой

Расчет SLA и компенсаций¶

Допустим, выбираем Вариант 1 (99,92%):

SLA с клиентом: - Гарантированная доступность: 99,95% - Компенсация при нарушении: 10% от месячной стоимости за каждый час превышения

Пример расчета компенсации: - Клиент платит: 500 ₽/месяц - Фактическая доступность за месяц: 99,8% - Обещано: 99,95% - Разница: 0,15% = 1,08 часа - Компенсация: 1,08 × (500 ₽ × 10%) = 54 ₽

Для 10000 клиентов: 540000 ₽

Резерв на компенсации: - Ожидаемые нарушения: 2 раза в год - Общая сумма: 540000 × 2 = 1080000 ₽/год

Практическая реализация мониторинга¶

Метрики для Prometheus:

# Доступность ВМ (по ping)
(
  1 - (
    sum_over_time(up{job="vm-healthcheck", instance=~"vm-.*"}[30d])
    /
    count_over_time(up{job="vm-healthcheck", instance=~"vm-.*"}[30d])
  )
) * 100

# Доступность по зонам доступности
sum(up{job="vm-healthcheck"}) by (availability_zone)
/ count(up{job="vm-healthcheck"}) by (availability_zone) * 100

Дашборд доступности:

Общая доступность: 99,92% [Цель: 99,95%]
Бюджет ошибок: использовано 68%

По компонентам:
- Гипервизор: 99,99%
- Хранилище: 99,997%  
- Сеть: 99,98%
- Управление: 99,9%

Предстоящие риски:
1. Плановые работы 28.01: -0,05% доступности
2. Обновление ПО в ЦОД: -0,1% доступности

План действий при нарушении SLA¶

Действие 1: Автоматическое уведомление - При использовании 80% бюджета ошибок → предупреждение команде - При 90% → эскалация руководству - При 100% → остановка плановых работ, работаем над стабильностью

Действие 2: Приоритизация инцидентов

Класс A (критично): Влияет на >1000 ВМ → реакция <5 минут
Класс B (высокий): 100-1000 ВМ → <15 минут  
Класс C (средний): <100 ВМ → <1 часа
Класс D (низкий): Деградация производительности → <4 часов

Действие 3: Компенсационный процесс - Автоматический расчет компенсаций - Одобрение финансовым отделом - Начисление на счет клиента - Уведомление с извинениями

Коммуникация с клиентами¶

Прозрачный общедоступный статус-пейдж:

Статус сервиса [99,92% за месяц]

Зона доступности ru-central1-a: ✅ Работает
Зона доступности ru-central1-b: ✅ Работает  
Зона доступности ru-central1-c: ⚠️ Деградация (95% ВМ доступны)

Последние инциденты:
1. 12.01 14:30 - Сбой хранилища (1ч 15мин) - компенсации начислены
2. 05.01 03:00 - Плановые работы (45мин) - уведомление отправлено

Бюджет доступности: 4,38 часов/год
Использовано: 3,2 часа (73%)
Осталось: 1,18 часа

Реалистичный подход к доступности ВМ¶

99,95% это 4,5 часа простоя в год, что стоит примерно 30000 ₽ для бизнеса нашего размера
Основные затраты:
Физическая инфраструктура: 500000-2000000 ₽/год
Резервирование: +50-100% к стоимости
Автоматизация восстановления: 2-5 млн ₽ разработки
Критические решения:
Не гнаться за "пятью девятками" (99,999%) - это в 10 раз дороже
Сфокусироваться на быстром восстановлении (MTTR)
Принять что плановые работы съедят 1-2% доступности
Заложить 1-2 млн ₽/год на компенсации клиентам
Итого: Прибыль = (Доход - (Инфраструктура + Компенсации)) = 60M - (10M + 1M) = 49M ₽/год

Доступность это не абстрактные проценты, а конкретный экономический расчет. Каждая "девятка" имеет свою цену в рублях, и задача SRE найти оптимальный баланс между надежностью и стоимостью, понятный и приемлемый для бизнеса.