resume/legend/CAPACITY.md

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

Отвечает на класс вопросов «с каким трафиком/масштабом сталкивался» и «как бы ты справился с масштабом X». Домашняя лаба физически не может воспроизвести продовые нагрузки крупной компании — честный подход, зафиксированный в ../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	wrk/hey (не входит в текущий CASE.md, добавить: hey -n 10000 -c 50 http://localhost:8080/)	RPS, задержка p50/p99	[замерить]
../stack/monitoring/CASE.md	Prometheus, число активных series	curl localhost:9090/api/v1/status/tsdb	[замерить]
../stack/databases/CASE.md	pgbench -c 10 -j 2 -T 30 labdb	TPS	[замерить]
../stack/kafka/CASE.md	kafka-producer-perf-test.sh --num-records 100000	records/sec, MB/sec	[замерить]
../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.

Показатель	Значение
Число серверов в обслуживаемом парке	[заполнить]
Число targets/эндпоинтов в Prometheus	[заполнить]
Число дашбордов в Grafana (в резюме: 50)	50 (уже зафиксировано в ../RESUME.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.

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

При добавлении новых цифр:

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