Нагрузочное тестирование: как проверить, упадет ли сервер Black Friday

Нагрузочное тестирование - это процесс проверки производительности и стабильности системы под ожидаемой или пиковой нагрузкой, который становится критически важным в событиях вроде Black Friday, когда трафик может вырасти в десятки раз. Основная цель - убедиться, что серверы, базы данных и сетевые компоненты выдержат наплыв пользователей без потери функциональности, замедления ответов или полного отказа. Для Black Friday это особенно актуально, так как сбои напрямую ведут к финансовым потерям, ущербу репутации и оттоку клиентов. Тестирование имитирует реальные сценарии: массовые переходы на сайт, добавление товаров в корзину, оформление заказов, работу с платежными системами. Оно выявляет узкие места до запуска, позволяя оптимизировать код, инфраструктуру и настройки. Ключевые этапы включают планирование, разработку сценариев, выбор инструментов, проведение тестов, анализ метрик и внедрение улучшений. Без этого даже мощные серверы могут упасть из-за неучтенных деталей, таких как утечки памяти или блокировки в БД. Успешное нагрузочное тестирование обеспечивает не только техническую надежность, но и бизнес-уверенность в периоды аномального спроса.

Планирование - фундамент успешного нагрузочного тестирования, особенно для события масштаба Black Friday, где ошибки недопустимы. Начните с сбора требований: определите ожидаемое количество одновременных пользователей (например, 500 000), пиковую нагрузку в запросах в секунду (RPS), критические бизнес-процессы (поиск, корзина, оплата) и допустимое время ответа (например, 2 секунды для страниц). Оцените текущую инфраструктуру: мощность серверов, конфигурацию балансировщиков, возможности баз данных, кэширование (Redis, Memcached), CDN. Учтите сезонные особенности: рост мобильного трафика, географическое распределение пользователей, интеграции с внешними сервисами (платежные шлюзы, CRM). Разработайте план тестов: этапы (дымовое тестирование, нагрузка, стресс, стабильность), длительность (например, 4 часа пиковой нагрузки), инструменты, команду. Важно согласовать план с бизнес-подразделениями, чтобы тесты отражали реальные сценарии. Не забывайте про резервное тестирование: что если нагрузка превысит план на 20%? Запланируйте резервные меры: автоскейлинг, отключение неключевых функций. Документируйте все предположения и критерии успеха, чтобы избежать субъективных оценок.

В рамках планирования необходимо также определить цели тестирования: выявление производительности до 1000 RPS, проверка масштабируемости при росте до 5000 RPS, оценка времени восстановления после сбоев. Создайте матрицу рисков: какие компоненты наиболее уязвимы (например, платежный модуль). Учитывайте нормативы: PCI DSS для платежей, GDPR для данных. Планируйте тестовое окружение, максимально приближенное к продакшену: одинаковое железо, софт, сетевые задержки. Избегайте тестирования на dev-среде - результаты будут некорректными. Учтите, что Black Friday часто сопровождается маркетинговыми акциями (флеш-продажи), что создает всплески нагрузки. Имитируйте эти всплески в сценариях. Планируйте ресурсы: нагрузочные генераторы должны быть достаточно мощными, чтобы не стать узким местом. Рассмотрите облачные решения для эластичности. Важно установить базовый уровень - текущие показатели, с которыми будем сравнивать после оптимизаций.

Выбор инструмента зависит от бюджета, экспертизы команды, типа приложения (веб, мобильное, API) и требуемой детализации. Популярные open-source варианты: Apache JMeter - универсален, поддерживает HTTP, JDBC, JMS, имеет GUI и режим CLI, подходит для сложных сценариев, но требует настройки распределенной нагрузки. Gatling - на Scala, высокопроизводительный, код-ориентированный, хорош для CI/CD, дает детальные отчеты. k6 - современный, на Go, скрипты на JavaScript, легкий, интегрируется с облачными сервисами, поддерживает метрики в Prometheus. Для API-тестирования Postman с Newman или SoapUI. Для потоковой нагрузки Tsung (Erlang) масштабируется до миллионов виртуальных пользователей. Коммерческие: LoadRunner (Micro Focus) - мощный, но дорогой, поддерживает множество протоколов, аналитика. NeoLoad - более доступный, простой в освоении, хорош для enterprise. BlazeMeter - облачный, совместим с JMeter, масштабируемый. Для мобильных приложений Appium с нагрузочными плагинами. Критерии выбора: стоимость, поддержка протоколов (HTTP/2, WebSocket, gRPC), простота написания сценариев, интеграция с мониторингом (Grafana, Datadog), облачные возможности, сообщество и документация. Для Black Friday рекомендуется комбинация: JMeter или k6 для генерации нагрузки, плюс специализированные инструменты для БД (например, sysbench). Обязательно протестируйте инструменты на пилотной сессии.

Сравним ключевые инструменты в таблице для наглядности:

Инструмент	Тип	Язык скриптов	Масштаб	Особенности
Apache JMeter	Open-source	XML (GUI), Groovy (CLI)	До 10k+ пользователей (распределенно)	Больше плагинов, поддержка протоколов, но тяжелый
Gatling	Open-source	Scala	До 100k+ пользователей	Высокая производительность, код-ориентированный, CI-friendly
k6	Open-source	JavaScript	До 1M+ (облако)	Легкий, современный, интеграция с Grafana, облачные экосистемы
LoadRunner	Коммерческий	C, Java, .NET, JavaScript	До 1M+	Корпоративный, дорогой, полная аналитика, поддержка legacy-протоколов
BlazeMeter	Облачный (SaaS)	JMeter, k6, Gatling	Безлимитно (облако)	Автоматизация, отчёты, интеграция с CI/CD, платно

Для Black Friday часто выбирают гибрид: локальные генераторы (JMeter) для контроля и облако (BlazeMeter, k6 Cloud) для масштаба. Убедитесь, что инструмент может генерировать достаточное количество запросов без сам становясь узким местом. Проверьте поддержку HTTPS, аутентификации (OAuth, JWT), обработки cookies, параметризации данных. Важна возможность записи сценариев (recording) для веб-приложений. Также учитывайте требования к отчётности: нужны детальные графики времени ответа, ошибок, throughput, а также возможность коррелировать с логами серверов (например, через X-Ray или Jaeger). Для микросервисов полезны инструменты, поддерживающие распределенное трассирование.

Сценарии должны точно отражать поведение реальных пользователей в день Black Friday. Начните с анализа аналитики: какие страницы самые популярные (главная, категории, товары), путь покупки (поиск ? карточка товара ? корзина ? оформление ? оплата), среднее количество просмотров на сессию. Учтите, что в Black Friday пользователи часто быстро листают, добавляют в корзину, но не все оформляют заказ. Разработайте несколько типов сценариев: типичный покупатель (поиск, просмотр, добавление, покупка), браузерщик (много просмотров без покупки), мобильный пользователь (упрощенный путь). Используйте параметризацию: разные товары, акционные купоны, регионы доставки. Включите задержки между действиями (think-time) и интервалы между итерациями (pacing) на основе реальных данных. Не забывайте про асинхронные операции: уведомления, обновление статуса заказа. Для API протестируйте эндпоинты отдельно и в связке. Важно смоделировать распределение нагрузки: не равномерное, а с пиками (например, в момент старта распродажи в 00:00). Используйте постепенный рост и спад нагрузки (ramp-up и ramp-down). Для аутентификации реализуйте логин/логаут, работу с сессиями. Тестируйте с разными данными: корректными, граничными, невалидными (но в стресс-тестах). Сценарии должны быть идемпотентными или управлять состоянием (например, очистка корзины после теста). Записывайте сценарии через прокси (JMeter HTTP(S) Test Script Recorder) или вручную. Проверьте корректность на небольшом масштабе перед полным запуском. Документируйте каждый шаг: ожидаемый результат, входные данные.

Для веб-приложений сценарии включают:

• Загрузка главной страницы (кэширование статики).
• Поиск товаров по ключевым словам (нагрузка на поисковый движок).
• Фильтрация и сортировка (сложные запросы к БД).
• Просмотр карточки товара (динамический контент, рекомендации).
• Добавление в корзину (работа с сессиями, обновление количества).
• Оформление заказа (форма, валидация, расчет доставки).
• Оплата (интеграция с платежным шлюзом - тестировать в песочнице).
• Просмотр истории заказов (чтение из БД).

Для API:

1. Авторизация (получение токена).
2. Получение списка товаров (пагинация).
3. Создание заказа (POST с телом).
4. Обновление статуса заказа.

Особое внимание - на операции записи (POST, PUT, DELETE), так как они влияют на целостность данных. Имитируйте конкурентный доступ к одним и тем же товарам (например, последний экземпляр). Тестируйте обработку ошибок: если платеж не прошел, корректный ли возврат в корзину. Для мобильных приложений учитывайте меньшую пропускную способность, паузы между экранами. Создайте сценарии для нагрузочных тестов (нормальная нагрузка), стресс-тестов (за пределами плана) и тестов на устойчивость (длительная нагрузка). Используйте данные о конверсии: например, 10% от просмотров ведут к добавлению в корзину, 30% от добавленных - к покупке. Это поможет рассчитать пропорции в сценариях.

Метрики делятся на клиентские (от генератора нагрузки) и серверные (с мониторинга). Клиентские: время отклика (response time) - среднее, медиана, 90-й, 95-й, 99-й перцентили; для Black Friday 95-й перцентиль должен быть <2 сек для ключевых страниц. Пропускная способность (RPS,Transactions Per Second) - должна соответствовать планируемой пиковой нагрузке с запасом 20-30%. Ошибки - процент ошибок (HTTP 5xx, таймауты) должен стремиться к 0%; допустимо до 0.1% для неключевых операций. Скорость загрузки страниц (Full Page Load) - с учетом всех ресурсов (CSS, JS, изображения). Серверные: Утилизация CPU - не выше 70-80% на пике, иначе нет запаса. Использование памяти - отсутствие утечек, стабильное потребление. Дисковый ввод-вывод - задержки чтения/записи, особенно для БД. Сетевой ввод-вывод - отсутствие потерь пакетов, задержки. Метрики базы данных: количество активных соединений, время выполнения запросов (медленные запросы), блокировки, коэффициент попаданий в кэш. Сборка мусора (для JVM) - частоты и длительность пауз. Логи ошибок - отсутствие критических ошибок в логах приложений. Пороги задаются на основе SLA и базового уровня. Например, для корзины время ответа <1 сек, для оплаты <3 сек. Установите пороги срабатывания оповещений для мониторинга во время тестов. Важно смотреть на устойчивость: как система ведет себя при длительной нагрузке (утечки памяти, фрагментация). Также оценивайте масштабируемость: при увеличении нагрузки в 2 раза, время отклика растет линейно или экспоненциально? Используйте метрики бизнес-уровня: конверсия в покупку, количество добавлений в корзину в секунду. Для Black Friday целевые показатели должны быть заложены в требования к релизу.

Для удобства анализа собирайте метрики в единую систему (Grafana, Kibana). Сравнивайте результаты тестов с базовым уровнем. Определите узкое место - компонент, ограничивающий производительность (например, БД при сложных запросах). Рассчитайте емкость - максимальную нагрузку, которую система может выдержать с приемлемыми метриками. Например, если при 5000 RPS время ответа 95-го перцентиля становится 5 сек, а ошибки растут, емкость около 4000 RPS. Задайте запас - до емкости (обычно 20-30%). Это нужно для непредвиденных всплесков. Также отслеживайте распределение ошибок: какие запросы падают чаще всего (например, оплата). Используйте корреляцию между метриками: рост CPU приводит к росту времени ответа? Это поможет локализовать проблему. В отчете включайте графики: время отклика по шагам сценария, RPS, ошибки, загрузка ресурсов. Для Black Friday критично протестировать переключение на резервные системы: что происходит при падении одного сервера или БД? Метрики доступности (availability) должны быть >99.9%. Не забывайте про метрики стоимости: сколько ресурсов нужно для поддержания нагрузки, чтобы оценить бюджет инфраструктуры.

После проведения нагрузочных тестов начинается самый важный этап - анализ. Соберите все логи: от генератора нагрузки, приложений, веб-серверов (Nginx, Apache), БД, ОС. Сопоставьте временные метки: когда начали расти ошибки, что происходило с CPU, памятью, сетью. Ищите корреляции: например, скачки времени ответа совпадают с ростом очереди в БД. Используйте инструменты для трассировки: X-Ray (AWS), Jaeger, Zipkin - они покажут, какие вызовы сервисов занимают больше всего времени в распределенной системе. Для БД анализируйте лог медленных запросов, план выполнения запросов (EXPLAIN), блокировки (pg_stat_activity для PostgreSQL, SHOW PROCESSLIST для MySQL). Частые узкие места:

• Неоптимальные запросы - отсутствие индексов, N+1 проблема, большие JOIN.
• Недостаток соединений к БД - маленький пул, долгие запросы занимают соединения.
• Утечки памяти в приложении (например, кэши без очистки).
• Паузы сборки мусора в JVM - частые полные GC.
• Сетевые задержки между сервисами, особенно в микросервисной архитектуре.
• Блокировки на уровне приложения (synchronized, блокировки на ресурсы).
• Недостаток пула потоков в веб-сервере (Tomcat, Undertow).
• Устаревшее оборудование или недостаток дискового I/O (используйте SSD/NVMe).
• Некорректная настройка кэшей (маленький TTL, отсутствие инвалидации).
• Проблемы с DNS или балансировщиками (неравномерная нагрузка).

Для каждого узкого места предложите гипотезу и способ проверки: например, если подозреваете БД, запустите нагрузку только на этот эндпоинт и мониторьте метрики БД. Проведите изолированные тесты: тестируйте отдельные компоненты (например, только поиск) для точной локализации. Используйте профилировщики (Async Profiler, YourKit, VisualVM) для Java-приложений, чтобы увидеть горячие методы. Для .NET - dotTrace, для Python - cProfile, py-spy. Анализируйте логи приложений на наличие исключений, предупреждений. Часто узкие места проявляются только при высокой нагрузке из-за race conditions или deadlocks - ищите их в логах. После выявления проблем приоритизируйте: какие влияют на критичные бизнес-процессы (оплата), а какие на второстепенные (личный кабинет). Составьте план исправлений с оценкой усилий и эффекта.

Пример анализа: при нагрузке 3000 RPS на эндпоинт оформления заказа время ответа 95-го перцентиля выросло с 1.2 сек до 8 сек, ошибки 5xx появились при 3500 RPS. Мониторинг показал: CPU приложения на пике 90%, память стабильна, но БД CPU 100%, очередь запросов выросла до 200. Лог медленных запросов выявил запрос на расчет доставки без индекса по почтовому индексу. Гипотеза: запрос выполняется долго, занимает соединения, другие запросы ждут. Проверка: выполнение EXPLAIN показало полное сканирование таблицы доставки. Решение: добавить индекс, пересмотреть логику (кешировать расчеты). После исправления повторный тест показал снижение времени до 2 сек при той же нагрузке. Такой детальный анализ обязателен. Также оценивайте влияние на другие компоненты: улучшение одного запроса может ухудшить другой из-за конкуренции за ресурсы. Все изменения тестируйте изолированно и в интеграции. Документируйте каждый найденный узкий момент, его причину, решение и результат после исправления. Это создаст базу знаний для будущих релизов.

Оптимизация - итеративный процесс, основанный на данных тестов. Начните с низко висящих плодов: настройка конфигураций, кэширование, индексы БД. Кэширование: внедрите Redis или Memcached для часто запрашиваемых данных (каталог товаров, сессии, результаты поиска). Настройте TTL и стратегию инвалидации (например, при изменении товара). Для статики используйте CDN. База данных: добавьте недостающие индексы, оптимизируйте запросы (избегайте SELECT *, используйте JOIN вместо подзапросов, разбейте большие транзакции). Рассмотрите шардирование или репликацию для чтения. Настройте пул соединений (HikariCP для Java) под нагрузку. Приложение: оптимизируйте алгоритмы (сложность O(n^2) ? O(n log n)), используйте пулы объектов (например, для HTTP-клиентов), уменьшите количество вызовов внешних сервисов (пакетные запросы). Уберите синхронизации, где возможно, используйте lock-free структуры. Настройки JVM: подберите размер heap, G1GC или ZGC для снижения пауз GC. Веб-сервер: увеличьте количество worker-процессов/потоков (Nginx worker_processes, Tomcat maxThreads). Настройте keep-alive. Сеть: увеличьте лимиты файловых дескрипторов (ulimit), оптимизируйте TCP-параметры (tcp_tw_reuse, tcp_fin_timeout). Код: избегайте N+1 запросов (используйте JOIN FETCH, batch size), кэшируйте результаты тяжелых вычислений. Асинхронность: для I/O-bound операций используйте асинхронные вызовы (CompletableFuture, reactive programming), чтобы не блокировать потоки. После каждой оптимизации проводите повторный тест и сравнивайте метрики. Не оптимизируйте вслепую - всегда измеряйте эффект. Иногда проще масштабировать горизонтально (добавить инстансы) чем оптимизировать вертикально. Но для Black Friday часто нужно и то, и другое: оптимизация кода позволяет сэкономить на инфраструктуре. Учитывайте компромиссы: кэширование ускоряет чтение, но усложняет инвалидацию и может давать устаревшие данные. Выбирайте стратегии в зависимости от бизнес-требований (например, для цен - строгая консистентность, для каталога - eventual consistency).

Пример пошаговой оптимизации на основе тестов:

1. Тест показал высокое время ответа для страницы категории (3 сек). Анализ: 80% времени занимает запрос к БД с JOIN по таблицам товаров, категорий, характеристик. Решение: добавить покрывающий индекс по category_id и status, денормализовать часть данных (например, цена в таблице категорий). Результат: время упало до 1.2 сек.
2. При нагрузке >2000 RPS появились таймауты на оплате. Мониторинг: пул соединений к платежному шлюзу исчерпан. Решение: увеличить maxConnections, добавить retry с экспоненциальной задержкой, кэшировать статичные данные шлюза. Результат: таймауты исчезли.
3. CPU приложения на пике 95%. Профилирование: метод валидации купона вызывался синхронно для каждого товара в корзине. Решение: валидировать купон один раз на уровне заказа, кэшировать результат на 5 минут. Результат: CPU снизился до 70%.
4. Утечка памяти в сервисе уведомлений: после каждого заказа создавался новый поток. Решение: использовать пул потоков, закрывать ресурсы. Результат: память стабильна.

Важно документировать каждое изменение: что делали, почему, какие метрики улучшились. Это поможет в будущем. Также тестируйте оптимизации в условиях, близких к Black Friday: с реальными данными, пиковой нагрузкой. Иногда оптимизация одного сервиса выявляет узкое место в другом - будьте готовы к итерациям. Не забывайте про откат - если оптимизация ухудшила метрики, быстро вернитесь к предыдущей версии. Автоматизируйте деплой и тестирование через CI/CD, чтобы быстро пробовать изменения. Для Black Friday оптимизации должны быть завершены за месяц до события, чтобы осталось время на регресс-тестирование.

Даже после успешных нагрузочных тестов Black Friday требует постоянного мониторинга в реальном времени. Настройте дашборды в Grafana или аналогичных системах, объединяющие метрики со всех слоев:

• Инфраструктура: CPU, memory, disk I/O, network, процессы (top, htop).
• Веб-серверы: запросы в секунду, время ответа, ошибки (4xx, 5xx), активные соединения.
• Приложения: JVM GC, heap, threads, бизнес-метрики (заказов в минуту, добавлений в корзину).
• Базы данных: активные соединения, медленные запросы, hit ratio, репликационная задержка.
• Кэши: hit/miss ratio, память, количество ключей.
• Внешние сервисы: статус платежных шлюзов, SMS-сервисов, доступность.
• Бизнес-метрики: конверсия, средний чек, отказы на этапах воронки.

Установите алерты (alerts) на ключевые пороги: CPU >85% дольше 5 минут, ошибки >1%, время ответа 95-го перцентиля >3 сек, падение конверсии >10% от базового уровня. Алерты должны приходить в чаты (Slack, Telegram) и на сотовые ответственных. Назначьте дежурных, которые будут следить за дашбордами в течение всего события. Используйте распределенное трассирование (Jaeger) для быстрой локализации проблем в микросервисах. Если что-то падает, смотрите логи в реальное время (ELK stack: Elasticsearch, Logstash, Kibana) с фильтрацией по ошибкам. Имейте инструкцию по действиям - инструкцию по действиям при частых инцидентах: как перезапустить сервис, увеличить пул, отключить неключевую функциональность. Для Black Friday часто включают прерыватель цепи паты для внешних сервисов, чтобы не каскадировать сбои. Мониторите также пользовательский опыт через мониторинг реальных пользователей (RUM) - например, Google Analytics или специализированные инструменты (New Relic, Datadog RUM). Это покажет, как быстро загружаются страницы у реальных пользователей в разных регионах. Не забывайте про логи аудита - для отслеживания подозрительной активности (ботами). В день события избегайте любых изменений в продакшене - только мониторинг и, в крайнем случае, откат. После события проанализируйте весь массив данных: сравните с прогнозами, найдите отклонения, внесите в план следующий год.

Нагрузочное тестирование часто сталкивается с ошибками, которые сводят его пользу к нулю. Ошибка 1: Тестирование на непроизводственной среде. Если окружение отличается (меньше серверов, другие версии ПО, нет кэшей), результаты нерелевантны. Решение: использовать staging, максимально идентичный продакшену, или продакшен-like окружение в облаке с тем же масштабом. Ошибка 2: Нереалистичные сценарии. Если сценарии не отражают реальное поведение пользователей (например, все пользователи сразу добавляют один товар), вы не увидите реальных проблем. Решение: анализировать логи продакшена за прошлые годы, использовать статистику по сессиям, параметризировать данные. Ошибка 3: Отсутствие мониторинга на стороне сервера. Только метрики от генератора нагрузки недостаточно - нужно видеть, что происходит внутри системы. Решение: установить агенты мониторинга (Prometheus Node Exporter, JMX Exporter, Datadog Agent) до тестов. Ошибка 4: Тестирование только в рабочее время. Black Friday часто начинается ночью, а команда тестирует днем. Но нагрузка может зависеть от времени суток (например, из-за фоновых задач). Решение: проводить тесты в схожие временные окна, учитывать фоновые процессы (бэкапы, репликация). Ошибка 5: Игнорирование данных. Использование небольших или однотипных данных (все пользователи из одного региона, товары с одинаковой ценой) не выявит проблем с шардированием или кэшированием. Решение: использовать production-like датасеты (анонимизированные), разнообразить параметры. Ошибка 6: Недостаточная длительность. Короткие тесты (5 минут) не покажут утечки памяти или накопление логов. Решение: для стресс-тестов делать минимум 1-2 часа, для устойчивости - 8-24 часа. Ошибка 7: Запуск тестов без участия разработчиков. Анализ результатов требует экспертизы кода. Решение: вовлекать dev-команду в планирование и анализ. Ошибка 8: Отсутствие тестов на отказоустойчивость. Проверяют только производительность, но не поведение при падении сервиса. Решение: включать chaos engineering (например, с помощью Chaos Monkey) - отключать инстансы, искусственно задерживать запросы. Ошибка 9: Неправильная интерпретация перцентилей. Смотрят только на среднее, которое маскирует долгие хвосты. Решение: всегда анализировать 95-й, 99-й перцентили. Ошибка 10: Откладывание тестов до последнего момента. Если находим проблемы за неделю, на исправление нет времени. Решение: начинать нагрузочное тестирование на ранних этапах разработки, делать его частью CI/CD (например, nightly performance tests). Ошибка 11: Неучет внешних зависимостей. Тестируем только своё приложение, но внешние API (платежи, геолокация) могут стать узким местом. Решение: использовать моки для внешних сервисов, но также проводить интеграционные тесты в изолированной среде. Ошибка 12: Отсутствие документации по результатам. Находки забываются, оптимизации не повторяются. Решение: вести репозиторий с отчётами, выводами, базовыми метриками. Избегая этих ошибок, вы повышаете вероятность успешного прохождения Black Friday.

Нагрузочное тестирование для Black Friday - это не разовое мероприятие, а непрерывный процесс, интегрированный в цикл разработки. Ключевые выводы:

1. Раннее планирование: начинать за 2-3 месяца, согласовать цели с бизнесом, оценить инфраструктуру.
2. Реалистичные сценарии: основаны на реальной аналитике, включают пиковые всплески, мобильный трафик.
3. Подходящие инструменты: комбинация open-source (k6, JMeter) и облачных сервисов для масштаба.
4. Полный мониторинг: клиентские и серверные метрики, трассировка, бизнес-показатели.
5. Итеративная оптимизация: каждый найденный узкий момент исправляется и проверяется повторно.
6. Реальное окружение: тестировать на staging, максимально близком к продакшену.
7. Длительные тесты: проверка на утечки, устойчивость, восстановление.
8. Вовлечение всех: dev, ops, QA, бизнес-аналитики.
9. Документирование: базовый уровень, отчёты, инструкция по действиям для инцидентов.
10. План B: иметь резервные возможности (автоскейлинг, отключение функций).

Для команды: назначьте ответственного за нагрузочное тестирование, создайте чек-лист подготовки к Black Friday, проводите репетиции (fire drills) с имитацией сбоев. После акции проведите retrospective: что пошло не так, какие метрики были неточными, как улучшить процесс в следующем году. Инвестиции в нагрузочное тестирование окупаются: предотвращение одного крупного сбоя может сохранить миллионы в выручке и репутацию. Помните, что Black Friday - это экстремальная нагрузка, но методы применимы и для обычных пиков (например, распродаж). Внедрите культуру производительности: код ревью с учетом производительности, автоматические тесты в CI, регулярный мониторинг. Тогда сервер не упадет, даже когда на него обрушится огромная волна трафика.