← [Раздел](README.md) · [Главная](../README.md)

# Нагрузочное тестирование и chaos-lite

## Цель

Научиться планировать **нагрузочные тесты** (цели, сценарии, метрики успеха) и проводить **облегчённый chaos** на staging — отключение зависимостей, задержки — без production-экспериментов уровня Netflix.

## Предварительно

- [Метрики и SLO](../08-observability/metriki-i-slo.md)
- [Тестирование архитектуры](testirovanie-arhitektury.md)

## Время

~90 минут (теория + один сценарий k6 на бумаге)

---

## Зачем load testing

Ответить до Black Friday:

- при каком **RPS** p95 превышает SLO;
- что упадёт первым: CPU, pool БД, downstream;
- хватает ли **HPA** и лимитов pod.

Без нагрузки вы масштабируете «на глаз».

---

## Типы нагрузочных тестов

| Тип | Цель |
|-----|------|
| **Smoke load** | 1–5 мин, мало VU — «не сломано» после деплоя |
| **Load** | Ожидаемый трафик 30–60 мин |
| **Stress** | Выше пика до отказа — найти предел |
| **Soak / endurance** | Средняя нагрузка часами — утечки памяти |
| **Spike** | Резкий всплеск — авт scaling |

---

## Инструменты

| Инструмент | Особенности |
|------------|-------------|
| **k6** | JS-сценарии, Grafana интеграция |
| **Locust** | Python, распределённый режим |
| **vegeta** | Простой HTTP hammer |
| **JMeter** | GUI, enterprise |

Для курса достаточно **k6** или Locust. Сценарии — в Git рядом с кодом.

---

## Пример сценария k6 (учебный)

```javascript
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 50 },   // разгон до 50 VU
    { duration: '5m', target: 50 },   // плато
    { duration: '2m', target: 0 },  // спад
  ],
  thresholds: {
    http_req_duration: ['p(95)<300'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.get('https://staging.example.com/api/products');
  check(res, { 'status 200': (r) => r.status === 200 });
  sleep(1);
}
```

**VU** (virtual users) — не равно RPS; смотрите метрики генератора и сервера.

---

## Критерии успеха

Привяжите к SLO:

| Метрика | Порог |
|---------|-------|
| p95 latency | < 300 ms |
| Error rate | < 0.1% |
| CPU pod | < 80% sustained |
| DB connections | < 80% pool |

Фиксируйте **окружение**: версия образа, размер кластера, наполненность БД — иначе сравнение бессмысленно.

---

## Подготовка среды

- Только **staging**, изолированный от prod.
- Данные: репрезентативный объём (1M строк vs 1K — разная БД).
- Отключите сторонние rate limits или согласуйте IP.
- Мониторинг включён: дашборды RED + БД.

---

## Chaos-lite

Полный chaos engineering (Chaos Monkey в prod) — для зрелых команд. **Chaos-lite** на staging:

| Эксперимент | Ожидание |
|-------------|----------|
| `kubectl delete pod` API | HPA/recovery, нет 500 пользователю |
| Network delay к Redis 500ms | Деградация, не outage |
| Отключить mock платежки | Circuit breaker, понятная ошибка |
| Заполнить диск pod | Алерт, не тихая порча |

Документируйте **гипотезу** до эксперимента: «При падении 1 pod из 3 error rate < 1%».

---

## Безопасность chaos

- Окно согласовано с командой.
- Kill switch — откат за минуты.
- Не трогать prod без game day и executive approval.
- Не chaos'ить без observability — вы не поймёте результат.

---

## Интерпретация результатов

| Наблюдение | Действие |
|------------|----------|
| p95 растёт линейно с RPS | Нужно scale out или оптимизация |
| Ошибки только на write | Узкое место БД / lock |
| Плато CPU при низком RPS | Блокировка I/O, внешний API |
| Memory растёт на soak | Утечка, пересмотр кэша |

---

## CI интеграция

- **Smoke load** 2 мин после deploy на staging.
- **Полный load** — nightly или перед крупным релизом.
- Артефакты: HTML отчёт k6, ссылка на Grafana snapshot.

---

## Самопроверка

1. Чем stress test отличается от soak?
2. Что такое VU в k6?
3. Зачем thresholds в сценарии?
4. Назовите три безопасных chaos-lite эксперимента на staging.

---

## Дальше

→ [Раздел 10 — Deploy](../10-deploy/README.md)  
← [Тестирование архитектуры](testirovanie-arhitektury.md)
