Кейсы

Анализ

Свернул кластерную инсталляцию в локальный docker-compose, сохранив то, что влияет на поведение памяти: лимиты контейнеров и переменные окружения аллокатора. Критерий воспроизведения задал измеримо и заранее — превышение лимита за считанные минуты под нагрузкой, а не «вроде растёт». Нагрузку подал профилем с крупными телами запросов, на них утечка и проявлялась. Дальше профили кучи через pprof, снятые в динамике и сопоставленные между собой: так отделяется «компонент много аллоцирует» от «компонент не отдаёт».

Проверка

Ретест на том же стенде тем же профилем, сравнение до и после по тому же критерию. Цикл проверки гипотез сократился с часов на кластере до минут на ноутбуке, а репро-стенд остался активом: регрессию по этому месту можно проверить в любой момент.

Анализ

Причина не в объёме данных, а в том, где собираются тела: сборка шла внутри итерации, а в k6 каждый VU — отдельный JS-рантайм со своей кучей, поэтому расход множился на число VU.

Проверка

Потребление памяти генератора перестало расти по ходу теста — вместо неограниченного роста плоская полка, профиль держит целевой RPS в штатных ресурсах стенда. На его основе собран набор сценариев под разные размеры тел и доли атакующего трафика.

Анализ

Перебрать типы инстансов руками нельзя: ручная сборка одного стенда съедает день. Автоматизировал сборку целиком — окружение, тестируемая конфигурация, backend-заглушки и генератор нагрузки одной командой. Зафиксировал один профиль нагрузки на все конфигурации, иначе сравнение бессмысленно, и прогнал матрицу «тип инстанса × профиль», снимая CPU, память, сеть и метрики отказа в каждой точке.

Проверка

На некоторых типах трафика ARM-инстансы дали двукратный выигрыш по CPU при той же нагрузке — разница, которую по традиции не замечали. Сама процедура осталась воспроизводимой: повторный прогон матрицы — запуск пайплайна, поэтому пересчитать можно на новой версии продукта или на новом семействе инстансов.

Анализ

Собрал датасет из накопленных прогонов: суммарный и атакующий RPS, входящая и исходящая полоса, число ядер, объём памяти, наблюдаемая утилизация CPU — среднее и перцентили. Признаки нормировал на ядро: без нормировки модель учит «большая машина — меньше процентов» и не переносится между конфигурациями.

Проверка

Если запрос попадал в точку, которая уже есть в истории прогонов, предсказание совпадало с замером; вне датасета это приближение, и я говорю о нём именно так. Поэтому любой собранный профиль можно было тут же прогнать и получить фактические данные за полчаса — прогноз всегда есть чем проверить, а каждый такой прогон уточняет модель.

Анализ

Сложное здесь не веб-интерфейс. Первое — честный пересчёт между полосой и RPS через фактические размеры тел и заголовков: заказчик думает в гигабитах, инструмент в запросах в секунду, и перевод должен быть точным, иначе тест мерит не тот профиль. Второе — доказательство, что сгенерированный сценарий действительно даёт заданную нагрузку, а не только синтаксически корректен.

Проверка

Сервис работает в проде как внутренний инструмент команды. Сценарии версионируются, переиспользуются и не протухают незаметно, а результаты прогонов стали структурированными данными — именно они легли в основу модели из кейса 04.

Анализ

Удалял поды сервисов и воркеров во время прогона и смотрел ошибки и latency в окне перезапуска. Один из сервисов продолжал отдавать 5xx уже после того, как кластер считал под готовым: readiness probe проверяла только открытый порт, а не готовность зависимостей и прогрев кеша, и трафик приходил раньше времени. Рядом нашлась вторая дыра: drain без PodDisruptionBudget снимал реплики одновременно, поэтому в момент обновления сервис мог остаться вообще без живых экземпляров.

Проверка

Повторный прогон с теми же воздействиями: окно с 5xx после перезапуска закрылось, drain больше не оставлял сервис без живых реплик. Оба сценария остались в релизном прогоне: перезапуск и обновление кластера проверяются под нагрузкой, а не при обновлении у заказчика.

Анализ

Стенд с кластером PostgreSQL и потоковой репликацией. Под нагрузкой убивал мастер и считал не только время переключения кластера, но и то, сколько операций за это время потерял клиент. Главное нашлось в разрыве между двумя числами: кластер уже выбрал нового мастера, а приложение ещё держало старые соединения и отвечало ошибками — фактическое окно недоступности оказалось заметно шире кластерного.

Проверка

Повторный failover под той же нагрузкой — с замером по тому же критерию, чтобы видеть эффект правок. Сценарий остался в методике испытаний: RTO базы теперь не декларация, а замер, повторяемый на любой инсталляции.

Анализ

Воспроизвёл проблему на стенде с профилем и объёмами данных заказчика. Упиралось в тяжёлые запросы к базе, которые не лечились индексами: дело было не в плане отдельного запроса, а в том, как данные хранились. Пришлось проводить полный аудит данных и схемы, а не тюнинг отдельных запросов.

Проверка

Прогон на профиле заказчика после переделки хранения — по тем же критериям, что были согласованы до теста. Протокол испытаний закрыл требование к акту. Регулярный прогон здесь был не формальностью: этот функционал переезжал с ORM на ручные запросы постепенно, и каждый шаг переезда надо было сверять с предыдущим замером — иначе одна переписанная выборка могла тихо вернуть тормоза на следующем релизе.