High Availability и SLA

High Availability и SLA

1) Термины и связь с бизнесом

SLI (Service Level Indicator) — измеряемый показатель сервиса (напр. доля успешных запросов 2xx/3xx ≤ T мс).
SLO (Service Level Objective) — целевое значение SLI (напр. «99.95% запросов ≤ 300 мс»).
SLA (Service Level Agreement) — контрактное обязательство перед клиентом (штрафы/кредиты при нарушении).
HA (High Availability) — архитектурные и операционные меры, позволяющие выполнить SLO/SLA.

Принцип: SLA опирается на SLO, а SLO — на наблюдаемые SLI. Нельзя обещать в SLA то, что не измеряете.

2) «Девятки» и математика доступности

Композиция доступности

Последовательная цепочка (зависимости по «красному пути»): `A_total = Π A_i` (каждый компонент уменьшает итог).
Параллельные актив-актив узлы: `A_total = 1 − Π (1 − A_i)` (резерв повышает итог).

3) Что именно измерять (правильный SLI)

Пользовательский взгляд: успешные завершения ключевых операций (login, депозит, чек-аут) и их латентность p99.
Часовой коридор: агрегируйте по скользящим окнам (5/30/60 мин) и по регионам.
Исключения: «запланированные окна» учитываются в SLO, а в SLA — только если так сказано в контракте.

• Доступность: доля успешных ответов ≤ T.
• Качество: p95/p99 latency.
• Составные: «доля успешных депозитов ≤ 5 с».

4) Error Budget и скорость сгорания

Error Budget = `1 − SLO`. Для 99.95% ежемесячное окно дает 0.05% ошибок/простоя.
Burn-rate: скорость расхода бюджета (напр. 4× значит, что за 6 часов вы съедаете дневной лимит).
Политика: при быстром сгорании — стоп релизов, фокус на стабилизации, feature-freeze.

5) Архитектура HA: от узла до региона

5.1 Узел/сервис

N+1: минимум одна избыточная реплика (Deployment ≥ 2, PDB, anti-affinity).
Изоляция ресурсов: лимиты CPU/RAM/IO, приоритеты (PriorityClass).
Graceful shutdown/drain: отсутствие обрыва запросов при рестарте.

5.2 Зона/регион

Multi-AZ: реплики в разных зонах, кросс-зонная балансировка, независимое питание/сеть.
Multi-region: актив-актив (труднее: данные/консистентность) или актив-пасcив (проще: выше RPO).
Данные: CP для денег/заказов (кворум/RAFT), EC/AP для кэшей/витрин.

5.3 Сетевой слой и периметр

L7-LB с health-checks, retry/timeout/circuit-breaking.
GSLB/DNS/Anycast для глобального трафика, короткие TTL.
Egress-контроль и отказоустойчивые каналы до внешних PSP/провайдеров.

6) Деградация вместо падения

Feature kill-switch (фича-флаги): выключить не-критичное, сохранить «красный путь».
Переключение на упрощенные пути: синхрон → асинхрон/очередь, «принято в обработку».
Rate-limit/квоты: лучше ограничить трафик, чем уронить всех.
Stale-режимы: отдавать кэш/статические данные при недоступности origin.

7) Управление зависимостями

Карта зависимостей (service map): прямые/транзитивные, критичность, SLO каждого.
Уязвимые звенья: внешний провайдер без SLA — оборачивается кэшем/очередью/дубликатом.
Bulkhead-изоляция: разные пулы соединений/квоты для медленных маршрутов.
Timeouts > Retries: короткие таймауты, максимум 1 ретрай для идемпотентных операций.

8) Операции и изменения

Change management: релизы через канареек/blue-green, SLO-гейты, автоматический откат.
Запланированные окна: стандартизируйте — длина, периодичность, коммуникации.
Инциденты: роли (IC/Comms/Tech/DB), runbook’и, постмортемы с корректирующими действиями.
Секьюрити-ивенты: при компрометации — «паника-режим» (read-only/токены/ротация/блокировка).

9) Наблюдаемость и алертинг

RED-модель (Rate, Errors, Duration) на каждый маршрут.
SLI-дашборды: доступность/латентность по региону и по клиентскому сегменту.
Burn-rate алерты: быстрые (1h, 14.4×), медленные (6h, 2×) — сигнал до срыва SLO.
Экземпляры (Exemplars): переход из метрик в трассы по trace_id.
Синтетика: пробы из внешних точек (периметр, платежные флоу).

10) Тесты отказоустойчивости

Game-days: сценарии отключения AZ/регионов, деградации БД/кэшей, отказ внешних провайдеров.
Chaos-инструменты: фолты сети (latency/loss), kill-pods, перегруз CPU/IO.
DR-drills: отработка RTO/RPO для Tier-0 систем (см. «Бэкапы и DR»).

11) Проектирование SLA

Определение «доступности»: что считается инцидентом (5xx, время > T, ошибки домена).
Окно расчета: месяц/квартал; включение/исключение плановых работ.
Кредиты/штрафы: шкала (напр., 99.9–99.99% — X%, ниже — Y%).
Обязанности клиента: интеграция, ретраи в разумных пределах, лимиты.
Нотификации и процедура климов: сроки, формат, доказательная база (логи/метрики).
Форс-мажор: юридическая формулировка и границы.

• «Доступность API по SLI “успешные ≤ 500 мс” не ниже 99.95% в календарный месяц. Плановые окна (до 60 мин/мес, объявленные за 48 ч) исключены. При 99.90–99.95% — кредит 5%; 99.80–99.90% — 10%; <99.80% — 25%.»

12) Экономика девяток

• Tier-0 (деньги/заказы): 99.95–99.99%, мульти-AZ, DR готов.
• Tier-1 (основные фичи): 99.9–99.95%, мульти-AZ.
• Tier-2 (не-критичное): 99.5–99.9%, допускается деградация/стоп при инцидентах.

13) Паттерны HA по слоям

Периметр: CDN/edge, multi-CDN или GSLB, WAF, rate-limit.
Балансировка: L7 с outlier-ejection, таймауты/ретраи, sticky/consistent-hash.
Приложения: горизонтальный скейл, readiness/liveness, PDB, topology spread.
Данные: leader+replicas, quorum для CP, кэш L2, idempotency, PITR.
Очереди: зеркалирование/мультикластер, дедуп, DLQ.
Секреты/конфиги: GitOps, атомарные снапшоты, rollback.

14) Анти-паттерны

SLA без инструментов измерения и внешней синтетики.
Единая зона/кластер как SPOF.
Бесконтрольные ретраи → «само-DDoS».
Длинные транзакции/мутексы на горячем пути.
«Тяжелые» миграции/релизы без канареек и плана отката.
Отсутствие runbook и общения со стейкхолдерами при инциденте.

15) Чек-лист внедрения (0–60 дней)

0–15 дней

Определить критичные пользовательские SLI, задать SLO по уровням Tier-0/1/2.
Включить burn-rate алерты, SLO-дашборды, синтетические проверки периметра.
Убрать SPOF: ≥2 реплики, PDB, multi-AZ для фронтов и критичных БД.

16–40 дней

Ввести канареечные релизы с SLO-гейтингом и авто-откатом.
Карта зависимостей + квоты/пулы/таймауты/CB по каждому «красному пути».
Регламент плановых окон и коммуникаций, шаблоны инцидент-сообщений.

41–60 дней

Game-day: отключение AZ, провал внешнего провайдера, «бурст» трафика.
Пересчет SLA и кредитов по факту, публикация отчетов клиентам.
Пересмотр «стоимость ↔ девятки» и перекладка по тиру.

16) Метрики зрелости

≥ 95% критичных маршрутов имеют SLI/SLO и burn-rate алерты.
Ошибки SLO сопровождаются авто-заморозкой релизов (policy).
Multi-AZ покрытие Tier-0 = 100%, успешные DR-drills ≥ 1/квартал.
Время «детектирования → митигация» p50 < 5 мин, p95 < 15 мин.
Корреляция «релиз ↔ инциденты» — ведется и сокращается (rollback rate↓).
Публичный отчет об инцидентах/кредитах — в течение N рабочих дней.

17) Примеры и сниппеты

• Быстрый: «SLO 99.95%, окно 1 ч, burn ≥ 14.4× → page on-call».
• Медленный: «окно 6 ч, burn ≥ 2× → ticket & мониторинг».

yaml circuit_breakers:
thresholds:
- max_connections: 200 max_pending_requests: 100 max_requests: 1000 max_retries: 1 outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

yaml analysis:
templates:
- name: slo-burn metrics:
- name: error-rate successCondition: result < 0. 005 provider: prometheus

SLI: fraction_of_good_requests = good(HTTP 2xx/3xx ≤ 500ms) / all(requests)
SLO: ≥ 99. 95% per calendar month, per region

18) Заключение

High Availability — это не только кластеры и реплики, а согласованный набор архитектуры, процессов и метрик: четкие SLI/SLO, реалистичный SLA, «девятки» с экономикой, деградация вместо падения, дисциплина таймаутов/квот, канареечные релизы, регулярные учения и прозрачная коммуникация. Делайте доступность измеримой и управляемой — и она станет конкурентным преимуществом, а не лотереей.