Тестування стійкості

1) Базові поняття та цілі

Надійність (reliability) - ймовірність працездатності; стійкість (resilience) - поведінка при і після збою.
SLO/помилковий бюджет: критерії «прийнятності» деградації.
Steady-state hypothesis: формальне очікування стабільних метрик (наприклад, p95 <200 мс, error rate <0. 5%). Експеримент вважається успішним, якщо гіпотеза витримана.
Види відмов: мережеві (латентність, втрати/дублі, розриви), обчислювальні (CPU, пам'ять), сторідж (I/O, вичерпання диска), залежностей (5xx, timeouts, rate-limit), логічні (часткові інциденти, «повільна деградація»), операційні (реліз, конфіг), «темні» (split-brain, годинні зміни).

2) Піраміда стійкості

1. Юніт-тести відмов логіки (ретраї, ідемпотентність, таймаути).
2. Компонентні з fault-inject адаптерами (Testcontainers/tc-netem).
3. Інтеграційні/системні з мережею/БД/кешами і real-world профілями.
4. Хаос-експерименти в pre-prod (а потім обмежено в проді) по runbook'ам.
5. Гейм-дей - сценарні навчання команди (люди + інструменти).

3) Спостережуваність як основа

SLI: латентність p50/p95/p99, error rate, saturation (CPU/heap/FD/IOPS), drop/timeout, queue depth.
Трасування: для пошуку «вузьких місць» під відмовою.
Семантичні метрики стійкості: частка успішних graceful-degrade, частка shed-запитів, швидкість самовідновлення (MTTR).
Маркування експериментів: `chaos. experiment_id','phase = inject/recover'в подіях/логах.

4) Каталог ін'єкцій відмов (faults)

Мережа: затримка/джиттер, втрата/дублікати/реордеринг, обмеження пропускної здатності, пакетні «шторми», TLS-обриви.
Хост: обмеження CPU, витоки/ліміти пам'яті, паузи GC, вичерпання дескрипторів, «clock skew».
Сховище: зростання латентності, EROFS, ENOSPC, деградація репліки, втрата лідера.
Залежності: 5xx/429, уповільнення, флапінг DNS, застарілі сертифікати, rate-limit, «часткові відповіді».
Дані: пошкодження запису, «дірки» в потоках, дублі подій, конфлікти версій.
Операції: невдалий реліз, фіча-прапор, конфіг-дрейф, ручна помилка (в рамках симуляції).

5) Патерни стійкості (що перевіряти)

Ретраї з джиттером і таймаути на кожному RPC.
Circuit Breaker (відкриття/напіввідкриття, експоненціальне відновлення).
Bulkheads (ізоляція пулів/черг на критичні домени).
Load Shedding (скидаємо низькопріоритетні запити при насиченні).
Backpressure (сигнали вгору по ланцюжку, ліміти паралелізму).
Idempotency (ключі ідемпотентності на «побічних ефектах»).
Кешування і стаби на випадок деградації витоку.
Graceful Degradation (полегшені відповіді, stale-дані, відключення фіч).
Timeout-budget (загальний бюджет часу по ланцюжку викликів).
Атомарність/компенсації (Saga/Outbox/Transactional Inbox).
Кворуми і реплікація (R/W кворуми, деградація консистентності заради доступності).
Anti-entropy/реплей (відновлення при «дірах» подій).

6) Рецепти ін'єкцій та очікувань (псевдокод)

Ретрай з джиттером і брейкером

for attempt in 1..N:
if breaker. open(): return fallback()
res = call(dep, timeout = base 0. 8)
if res. ok: return res sleep(exp_backoff(attempt) jitter(0. 5..1. 5))
if attempt == N: breaker. trip()
return fallback()

Шейдинг і бекпрешер

if queue. depth() > HIGH          cpu. load() > 0. 85:
if request. priority < HIGH: return 503_SHED limiter. acquire () # constrain concurrency

Ідемпотентність

key = hash("payout:"+external_id)
if store. exists(key): return store. get(key)
result = do_side_effect()
store. put(key, result, ttl=30d)
return result

7) Експерименти: сценарії та гіпотези

7. 1 «Повільна залежність»

Ін'єкція: + 400 мс p95 до зовнішнього API.
Очікування: зростання таймаутів ≤ X%, відкриття брейкера, fallback-відповіді, збереження p99 сервісу <SLA, відсутність каскаду при ретраях.

7. 2 «Часткова втрата кешу»

Ін'єкція: відмова 50% вузлів Redis/Кеш-шарда.
Очікування: збільшений miss, але без лавини до витоку (request coalescing/іммутабельні TTL), авто-прогрів і відновлення.

7. 3 «Split-brain в БД»

Ін'єкція: втрата лідера, перемикання на репліку.
Очікування: короткочасний deny записів, читаємо з кворуму, відсутність втрати даних, Outbox не втрачає повідомлення.

7. 4 «ENOSPC/диск заповнений»

Ін'єкція: диск на 95-100%.
Очікування: аварійні ротації логів, відмова неблокуючих фіч, збереження критичних журналів (WAL), алерти і автоліквід.

7. 5 «Бурст трафіку»

Ін'єкція: × 3 RPS до гарячого ендпоінту 10 хв.
Очікування: шейдинг низького пріоритету, стабільний p95 у «ядерних» шляхів, зростання черг в межах лімітів, відсутність DLQ-штормів.

7. 6 «Clock Skew»

Ін'єкція: зміщення часу ноди на +/−2 хв.
Очікування: коректні TTL/підписи (leeway), монотонічні таймери в ретраях, валідні токени при допустимому дрейфі.

8) Середовища і безпека експериментів

Починайте з pre-prod, синтетичні дані, максимально близькі до проду конфіги/топологія.
У проді - тільки контрольовані вікна, фіча-прапори, покрокова амплітуда, авто-відкат, «червона кнопка».
Guardrails: ліміти RPS/помилок, SLO-охоронці, блокування релізів під час критичних інцидентів.
Обов'язковий runbook: як відкотити, кого покликати, де дивитися.

9) Автоматизація та CI/CD

Каталог експериментів як код (YAML/DSL): цілі, ін'єкції, метрики, пороги, «кнопки» відкату.
Smoke-chaos в кожному релізі: короткі ін'єкції (наприклад, 2 хв + 200 мс до залежності) в стейджі.
Нічні прогони матриці: сервіси × види відмов.
Гейт на реліз: заборона деплоя, якщо стійкість нижче порога (наприклад,'fallback coverage <95%'під «повільною залежністю»).

10) Дані та консистентність

Перевіряйте компенсації (Saga): частково виконані операції повинні доводитися до узгодженого стану.
Тестуйте повтори/дублі подій, out-of-order доставку, «дірки» і реплей.
Верифікуйте інваріанти домену після збоїв: баланс не негативний, транзакції не «застрягають», ліміти не порушені.

11) Анти-патерни

Тестувати тільки happy-path і навантаження без відмов.
Ретраї без джиттера → шторм під деградацією.
Відсутність глобального таймаут-бюджету → каскадні таймаути.
Єдиний пул для всіх завдань → відсутність ізоляції (bulkheads).
«Нескінченні» черги → зростання латентності/ООМ.
Нульова телеметрія експериментів → «сліпі» хаос-практики.
Хаос в проді без відкату/лімітів/відповідального власника.

12) Чек-лист архітектора

1. Визначена steady-state гіпотеза і SLO?
2. На кожному RPC є таймаути, ретраї з джиттером, брейкери?
3. Реалізовані bulkheads, лімітери, backpressure, load-shedding?
4. Кеш стійкий: coalescing, захист від кеш-штормів, прогрів?
5. Outbox/Saga для побічних ефектів, ідемпотентні ключі?
6. Кворуми/реплікація/фейловер протестовані?
7. Є каталог експериментів, nightly хаос і гейти в CI/CD?
8. Метрики/трасування позначають експерименти, є дашборди?
9. Runbook'і і «червона кнопка» готові, відповідальність призначена?
10. Регулярні гейм-дей за участю Dev/SRE/Support?

13) Міні-інструменти та приклади сценаріїв (YAML-скетчі)

Мережа (tc/netem)

yaml experiment: add-latency target: svc:payments inject:
netem:
delay_ms: 300 jitter_ms: 50 loss: 2%
duration: 10m guardrails:
error_rate: "< 1%"
p95_latency: "< 400ms"

CPU/Heap

yaml inject:
cpu_burn: { cores: 2, duration: 5m }
heap_fill: { mb: 512 }

Залежність

yaml inject:
dependency:
name: currency-api mode: slow p95_add_ms: 500 fallback_expectation: "serve stale rates ≤ 15m old"

Висновок

Тестування стійкості - не «трюк з хаосом», а дисципліна, яка робить систему передбачуваною під збоями. Чіткі гіпотези, телеметрія, каталог керованих експериментів і вбудовані в архітектуру патерни (таймаути, брейкери, ізоляція, ідемпотентність) перетворюють потенційні інциденти в контрольовані сценарії. Команда отримує впевненість у релізах, а користувачі - стабільний сервіс навіть в умовах відмов.