Чёрная пятница — долгожданный день для охотников за скидками и выгодными предложениями. Это своеобразный экзамен на прочность для разнообразных сервисов, финансовых организаций и банков, который, к сожалению, не все сдают, на «отлично».
Я — Дмитрий Тутов, руководитель направления нагрузочного тестирования в ПСБ. Сегодня поговорим про другую сторону Чёрной пятницы!
Поехали!
Перегруженные серверы, «лежащие» сайты, ошибки при оформлении заказа, переводы без исполнения — лишь верхушка айсберга проблем, с которыми сталкиваются потребители услуг.
Даже самые тщательные прогнозы финтех-компаний о предстоящих нагрузках часто не учитывают реальный пик трафика и транзакций.
Представьте себе узкую улочку, на которую внезапно выезжает трафик целого мегаполиса — коллапс неизбежен.
Типичные проблемы «Чёрной пятницы» или почему ничего не работает:
Медленная загрузка страниц: Самая распространенная проблема. Страницы загружаются настолько медленно, что покупатели не выдерживают и уходят.
«Ошибка 503: Service Unavailable»: Эта ошибка сигнализирует о том, что сервер временно не может обработать запросы. По сути, сайт просто «лежит».
Проблемы с выполнением операции: Пользователь выбрал товар или услугу нажимает «В корзину» или «Выполнить», но ничего не происходит.
Ошибки при оформлении заказа: После долгого процесса выбора, покупатель доходит до этапа оплаты и сталкивается с ошибкой. Часто это связано с перегрузкой платежных шлюзов.
Некорректное отображение цен и скидок: Случается, что акционные цены не применяются, скидки не отображаются, или цены вообще оказываются неверными. Это вызывает гнев и недоверие.
Проблемы с мобильной версией: Многие пользователи совершают покупки с мобильных устройств. Если мобильная версия сайта работает нестабильно, это приводит к потере значительной части трафика.
Примеры громких падений в Чёрную пятницу
J.Crew (Чёрная пятница 2015): Сайт американского ритейлера одежды J.Crew не выдержал наплыва посетителей в Чёрную пятницу 2015 года. Пользователи столкнулись с проблемами при оформлении заказов, которые часто просто не проходили. Компания принесла извинения, но ущерб репутации был нанесен.
Best buy (Чёрная пятница 2019): Крупный онлайн-магазин электроники, ставший печально известным из-за обвала сайта в Чёрную пятницу. Пользователи столкнулись с медленной загрузкой страниц, проблемами с корзиной и ошибками при оплате. Несмотря на обещания подготовиться, сайт не выдержал нагрузки, что вызвало волну критики в социальных сетях. Клиенты теряли время, упуская выгодные предложения, а ритейлер понес репутационные и финансовые потери.
Как избежать проблем?
К счастью, существуют способы подготовки сайта к наплыву покупателей в Чёрную пятницу:
Масштабировать инфраструктуру: Увеличение мощности серверов и пропускной способности сети.
Кешировать контент: Сохранение часто запрашиваемых данных в кеше для снижения нагрузки на сервер.
Использовать CDN (Content Delivery Network): Распределение контента по серверам, расположенным в разных географических точках, для ускорения загрузки страниц.
Оптимизировать код и базы данных: Улучшение производительности сайта за счет оптимизации кода и запросов к базе данных.
Мониторить в режиме реального времени: Непрерывный мониторинг работы сайта во время Чёрной пятницы для оперативного выявления и устранения проблем.
Иметь запасной план: В случае серьезных проблем пригодится план «Б» (а ещё «В» и так до конца алфавита), например, временно упростить сайт или перенаправить трафик на резервный сервер.
Тестировать под нагрузкой: Имитация большого количества пользователей поможет выявить слабые места в системе.
Но как именно найти эти «узкие места», которые способны обрушить даже самую мощную систему?
Узкие места которые создают напряжение
«Есть известные известные — то, что мы знаем, что знаем. Есть известные неизвестные — то, что мы знаем, что не знаем. Но есть и неизвестные неизвестные — то, о чем мы даже не догадываемся, что не знаем.»
Эта фраза удивительно точно описывает то, чем мы сталкиваемся в нагрузочном тестировании. Пока система работает в штатном режиме — кажется, что все под контролем. Но стоит нагрузке вырасти, и начинают проявляться те самые «неизвестные неизвестные» — узкие места, которые раньше не были замечены.
С чего начать: небольшой экспресс-анализ.
Системы в банке бывают разные: одни обслуживают клиентов онлайн и должны отвечать быстро, другие собирают и хранят данные, третьи помогают сотрудникам работать. У каждой – свой характер и свои узкие места. Что бы понять, где именно может «зажать» и создать напряжение, не нужно глубокое знание технологий. Достаточно задать себе несколько простых вопросов. Ниже – короткий чек-лист, который поможет определить тип вашей системы и прикинуть, какие риски для нее самые чувствительные
Маленький чек-лист:
Кто основные пользователи?
- Клиенты банка — скоре е всего, это онлайн-сервис (важна скорость отклика)
- Сотрудники внутри банка — скорее всего, это внутренний сервис (важна стабильность и удобство)Как работает система по времени?
- Реагирует сразу на действие — реал тайм (важна каждая секунда).
- Формирует отчеты к определенному часы — пакетная система (важно уложиться к дедлайну)Что будет, если система замедлится?
- Клиенты заметят и уйдут — риск репутационных потерь.
- Нарушим регламент/требования — ри ск регуляторных последствий.
- Просто дольше подождем — риск снижения эффективности сотрудников.Где может образоваться очередь?
- В интерфейсе (страница крутится и не отвечает).
- В базе данных (долго вытаскиваются данные).
- В обработке задач (ждем, когда закончатся предыдущие задачи).Какой главный показатель для вас важен?
- Время отклика (скорость ответа)
- Количество пользователей одновременно (масштабируемость)
- Объем обрабатываемых данных (производительность хранения)
Разные типы систем и разное «напряжение»
У каждой системы своя зона риска.
Онлайн-сервисы критичны к задержкам — даже пара секунд может стоить лояльности клиента.
Сбой или замедление в системах хранения и обработки данных заставляют страдать сам банк — отчеты не формируются, данные не успевают обновляться, нарушаются требования регуляторов.
Внутренние сервисы не так заметны снаружи, но если они начинают тормозить, страдает эффективность сотрудников, падает скорость обслуживания клиентов.
Даже если технологии похожи, тип узкого места может отличаться: у одних — сеть, у других — база данных, у третьих — логика приложения.
Как появляются узкие места
Иногда дело не в баге, а в простой несбалансированности.
Одни серверы загружены до предела, в это же время другие простаивают.
База данных выполняет тяжелые запросы, блокируя очередь.
Очереди сообщений переполняются, потому что все процессы идут в один канал.
Память или CPU не рассчитаны на пиковую нагрузку.
Система в этот момент похожа на дорогу: если есть узкий участок, то именно там и соберется пробка.
Как локализуют проблемы в НТ
Чтобы найти и устранить такие «пробки», команда нагрузочного тестирования имитирует работу системы в условиях, максимально приближенных к реальным.
Эмулируется нагрузка, соответствующая реальному поведению пользователей.
Система разбирается под микроскопом: CPU, память, сеть, базы данных, логика приложения.
Сравниваются показатели с целевыми нормами — SLA, временем отклика, стабильностью.
Главное не просто поймать ошибку, а показать где именно система не справляется и почему.
Пример из практики
На одной из банковских систем дистанционного обслуживания клиентов в плановых тестах была замечена деградация по сравнению с предыдущими релизами: выросло время отклика, появились ошибки. По чек-листу эта система относится к системам типа «Онлайн-сервис», первые признаки нестабильности системы себя проявили, риски, как вы можете догадываться, серьезные: сильное недовольстве со стороны клиентов банка → репутация банка, отток клиентов → финансовые потери банка.
Анализ, проведенный инженерами нагрузочного тестирования показал, что проблема связана с компонентом, обрабатывающим операции с облачным сертификатом. Логи помогли локализовать участок, разработчики внесли правки, выкатили фикс и повторный тест подтвердил устраненные проблемы.
В итоге система выровнялась по показателям, а риск сбоя на продуктивном контуре был снят еще до релиза. Это значит:
Меньше вероятность технического инцидента,
Меньше жалоб от клиентов,
Меньше риск финансовых и репутационных потерь для банка.
Что это дает бизнесу
Нагрузочное тестирование — это не только «прогон графиков», но и уверенность.
Уверенность, что система выдержит час пик.
Что изменения в коде не ухудшили производительность.
Что рост числа клиентов не станет неожиданным стрессом.
С каждым тестом система становится стабильнее, а «неизвестных неизвестных» — меньше.
Вывод
Узкие места есть у любой системы. Вопрос не в том, появляются ли они, а в том – когда и где.
Нагрузочное тестирование помогает увидеть эти точки заранее, пока она не превратились в инциденты. Чем раньше это понимание приходит в проект, тем меньше напряжение – и в системе, и в бизнесе.