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: актив-актив (важче: дані/консистентність) або актив-пасив (простіше: вище 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-гейтингом і авто-відкатом.
Карта залежностей + квоти/пули/таймаути/СВ по кожному «червоному шляху».
Регламент планових вікон і комунікацій, шаблони інцидент-повідомлень.

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, «дев'ятки» з економікою, деградація замість падіння, дисципліна таймаутів/квот, канарні релізи, регулярні навчання і прозора комунікація. Робіть доступність вимірною і керованою - і вона стане конкурентною перевагою, а не лотереєю.