# Справочник цифр нагрузки

Отвечает на класс вопросов «с каким трафиком/масштабом сталкивался» и «как бы ты справился с масштабом X». Домашняя лаба физически не может воспроизвести продовые нагрузки крупной компании — честный подход, зафиксированный в [../AI_GUIDELINES.md](../AI_GUIDELINES.md), состоит из трёх слоёв цифр, которые никогда не смешиваются между собой:

1. **Публичные пределы технологий** — задокументированные производителем/сообществом ориентиры, не выдаваемые за личный опыт.
2. **Замеры на своей лабе** — реальные цифры, полученные прогоном инструментов на CASE.md-стендах этого репозитория.
3. **Реальные масштабы с работы** — заполняются пользователем лично, только фактами со своего места работы; ИИ эти значения не придумывает и не подставляет.

## 1. Публичные пределы технологий

| Технология | Ориентир | Источник/пояснение |
|---|---|---|
| Nginx | Десятки тысяч RPS на ядро на статике; на проксировании (с TLS termination, upstream) — обычно тысячи RPS на инстанс, сильно зависит от бэкенда | Известный порядок величины из документации/бенчмарков nginx; сильно варьируется от конфигурации, поэтому это ориентир, не гарантия |
| Prometheus (один инстанс) | Ориентировочно ~1–2 млн активных time series на инстанс, десятки-сотни тысяч samples/sec на приём | Официальная документация Prometheus описывает такой порядок как практический предел одного инстанса до необходимости шардирования/federation |
| Mimir / Thanos (горизонтальное масштабирование) | Сотни миллионов активных series суммарно за счёт шардирования ingester/distributor и объектного хранилища | Архитектурная особенность — компонентная модель Mimir специально спроектирована так, чтобы снять ограничение одного Prometheus |
| Elasticsearch (data-нода) | Обычно рекомендуемый размер шарда — десятки ГБ (типовой ориентир ~10–50 ГБ на шард), heap-память — не более ~30–32 ГБ на JVM-инстанс (ограничение compressed oops в JVM) | Общеизвестная эксплуатационная рекомендация Elastic |
| Kafka (один брокер) | Порядок сотен МБ/сек на брокер при последовательной записи на быстром диске, десятки-сотни тысяч сообщений/сек в зависимости от размера сообщения | Публично известный порядок из документации/бенчмарков Kafka; сильно зависит от диска, размера батча, репликации |
| PostgreSQL | От нескольких тысяч до нескольких десятков тысяч TPS на мощном железе с SSD при простых транзакциях; сильно зависит от синхронности commit, индексов, объёма данных | Общий ориентир, публично встречающийся в бенчмарках `pgbench` |
| Kubernetes | Официальный документированный лимит — до 5000 нод и до 110 подов на ноду на кластер | Официальные Kubernetes Considerations for Large Clusters |

**Важно:** это ориентиры порядка величины, а не гарантированные числа под любую нагрузку — правильный ответ на собеседовании называет порядок и объясняет, от чего он зависит, а не выдаёт одно «магическое число».

## 2. Замеры на своей лабе

Инструкция и место для заполнения — прогнать инструмент на соответствующем CASE.md-стенде и вписать реальный результат. Пока не прогнано — стоит `[замерить]`, не выдуманное число.

**Характеристики машины для замеров:** `[указать: CPU, RAM, диск (SSD/HDD), ОС]` — важно фиксировать, чтобы честно объяснять экстраполяцию на других мощностях.

| Стенд | Инструмент | Команда | Результат |
|---|---|---|---|
| [../stack/nginx/CASE.md](../stack/nginx/CASE.md) | `wrk`/`hey` (не входит в текущий CASE.md, добавить: `hey -n 10000 -c 50 http://localhost:8080/`) | RPS, задержка p50/p99 | `[замерить]` |
| [../stack/monitoring/CASE.md](../stack/monitoring/CASE.md) | Prometheus, число активных series | `curl localhost:9090/api/v1/status/tsdb` | `[замерить]` |
| [../stack/databases/CASE.md](../stack/databases/CASE.md) | `pgbench -c 10 -j 2 -T 30 labdb` | TPS | `[замерить]` |
| [../stack/kafka/CASE.md](../stack/kafka/CASE.md) | `kafka-producer-perf-test.sh --num-records 100000` | records/sec, MB/sec | `[замерить]` |
| [../stack/kubernetes/CASE.md](../stack/kubernetes/CASE.md) | число подов/нод в pet-кластере | `kubectl get nodes`, `kubectl get pods -A \| wc -l` | 3 ноды (1 control-plane + 2 worker), `[число подов после деплоя]` |

Смысл этих цифр не в том, чтобы впечатлить масштабом (лаба заведомо на несколько порядков меньше прод-инсталляций), а в том, чтобы иметь реальную точку отсчёта: «на своей лабе на таком-то железе получил такой-то результат» — это честный, проверяемый факт, в отличие от абстрактного «я знаю, что Prometheus быстрый».

## 3. Реальные масштабы с работы

**Заполняется только пользователем, фактами со своего реального места работы. ИИ не подставляет сюда числа — ни выдуманные, ни «типичные для профиля компании».** Это прямо запрещено правилом честности кейсов в [../AI_GUIDELINES.md](../AI_GUIDELINES.md).

| Показатель | Значение |
|---|---|
| Число серверов в обслуживаемом парке | `[заполнить]` |
| Число targets/эндпоинтов в Prometheus | `[заполнить]` |
| Число дашбордов в Grafana (в резюме: 50) | 50 (уже зафиксировано в [../RESUME.md](../RESUME.md)) |
| Объём логов в сутки (если известно) | `[заполнить]` |
| Число внутренних пользователей систем мониторинга | `[заполнить]` |
| Другие известные показатели нагрузки | `[заполнить]` |

**Про черновые числа в [STORY.md](STORY.md):** там для нарратива (состав отдела, число VM и сервисов) стоят ориентировочные заготовки, явно помеченные как черновик для подтверждения — это не то же самое, что факты этого раздела. Раздел 3 CAPACITY.md остаётся пустым до тех пор, пока сюда не будут вписаны подтверждённые самим кандидатом цифры; правило ИИ не подставлять их сюда самостоятельно действует независимо от черновиков в STORY.md.

## Как отвечать на вопрос про масштаб/трафик

Формула ответа, которая не скатывается ни в выдумывание, ни в беспомощное «не знаю»:

1. **Реальный масштаб, если он есть и подтверждён** — если вопрос про то, с чем реально сталкивался на работе, называть цифры из раздела 3 выше (после того как пользователь их заполнит).
2. **Что замерял на своей лабе и что получил** — честно обозначить, что это домашний стенд, и назвать реальную цифру из раздела 2. Это лучше, чем неопределённое «наверное, справится».
3. **Знание публичных пределов технологии** — показать, что понимаешь порядок величины, на которую рассчитана технология в принципе (раздел 1), и от чего он зависит.
4. **Как масштабировал бы дальше** — если вопрос про гипотетический больший масштаб (как в Bi.Zone про 300 000 серверов), проговорить архитектурный путь: шардирование, горизонтальное масштабирование компонентов, что именно упрётся в лимит первым.

### Разбор конкретного вопроса (Реалист банк): «сколько Гб логов в ELK, если в Prometheus уже 15 Гб метрик»

Правильный ответ не содержит единственного числа — это вопрос на понимание природы данных, а не на память конкретной цифры. Метрики компактны и хорошо сжимаются (числовые ряды с повторяющимися паттернами), логи — произвольный текст без такой плотности. При сопоставимом количестве событий логи обычно занимают на порядок (иногда на два) больше места, чем метрики того же периода — то есть если метрики занимают 15 Гб, разумный ответ — «логи, скорее всего, будут занимать существенно больше, на порядок или больше, в зависимости от verbosity логирования» — с объяснением почему, а не с попыткой угадать точное число. Разбор этого же вопроса в контексте ELK — [../stack/elk/QUESTIONS.md](../stack/elk/QUESTIONS.md).

## Правило непротиворечивости

При добавлении новых цифр:
1. Всегда явно указывать, к какому из трёх слоёв (публичный предел / лабный замер / реальный факт с работы) относится число — никогда не смешивать формулировки так, чтобы лабная цифра выглядела как продовая, или публичный ориентир — как личный опыт.
2. Лабные замеры — обновлять по мере реального прогона инструментов, не оставлять `[замерить]` дольше, чем до следующего прогона соответствующего кейса.
3. Раздел 3 — трогать только по прямому запросу пользователя с реальными данными, никогда не заполнять предположениями.