Заказчик — крупнейший универсальный банк России и Восточной Европы. По состоянию на конец 2022 года услугами банка пользуются 106,7 млн физических лиц, а также 3 млн корпоративных клиентов.
Цель проекта:
Провести хаос-тесты системы TPS для выявления узких мест и потенциальных точек отказа при нештатных рабочих условиях и выяснить, соответствует ли система требования отказоустойчивости
Время реализации:
5 недель
Предпосылки
Заказчик ввел в эксплуатацию систему маршрутизации карточных операций. Сложность интеграции заключалась во взаимодействии с большим количеством сервисов (что задействовало различные типы трафика, МПС, сервисы очередей и межсервисного взаимодействия, источники трафика с использованием разных протоколов). Запросом было хаос-тестирование TPS с интеграцией или эмуляцией всех подключенных сервисов. Перед инженерами «Перфоманс Лаб» стояла задача провести нагрузочные хаос-тесты и сформировать на основе результатов таблицу соответствия системы требованиям.
Задачи тестирования
01
Совместно с заказчиком сформировать критерии соответствия системы требованиям
02
Сформировать перечень тестов и определить сценарии атак. В качестве последних были выбраны:
01
отказ элементов архитектуры
02
неполадки сети
03
ошибки базы данных
04
неполадки с физическими комплектующими
03
Провести хаос-тесты
04
Выполнить аналитику по результатам проведенных тестов
05
Выявить узкие места
06
Подготовить и предоставить заказчику отчет по тестированию
07
Выработать рекомендации по улучшению производительности
08
Передать материалы тестирования заказчику
Решение
Для тестирования устойчивости системы TPS были использованы методы деструктивного и хаос-тестирования. Такая методология позволяет проверить, как система будет себя вести в условиях сильной нагрузки, сбоев и атак.
Цель деструктивного тестирования —
проверить, как система будет работать при различных условиях, включая экстремальные. Цель хаос-тестирования — создать условия, которые могут привести к сбою системы и проверить ее устойчивость. Эти лимиты и сценарии должны стать основой для укрепления системы и устранения узких мест.
Тестовый кейс в случае деструктивного и хаос-тестирования включает в себя пять этапов:
01
Выдвижение гипотезы: предполагаем, какие ошибки могут быть выявлены при определенном наборе вводных данных
02
Подача нагрузки: включаем в процесс описанный тестовый сценарий
03
Измерение результатов: сравниваем полученные в результате деструктивного тестирования метрики с ожидаемыми и теми же, что получены в обычных условиях
04
Если проблема не найдена: повторяем тест-кейс, изменяя вводные данные (например, увеличивая нагрузку)
05
Если дефект найден: описываем и изучаем найденную уязвимость
Для выполнения поставленных задач было произведено более 40 тестов при взаимодействии с различными командами со стороны заказчика. Тестирование выполнялось на стенде, на 50% повторяющем продуктовую среду.
В качестве инструментов для проведения деструктивного нагрузочного тестирования были выбраны:
01
Стандартные инструменты нагрузочного тестирования
Apache JMeter, LoadRunner, Gatling
02
Инструменты для стресс-тестов
StressStimulus, WebLOAD, LoadForge
03
Инструменты для фаззинга
Peach Fuzzer, Sulley
04
Сканеры уязвимостей
Nessus, OpenVAS, Qualys
Проблемы реализации
Из-за высокой сложности и модульности системы возникали следующие трудности:
01
Каждый деструктивный сценарий мог вывести стенд из строя на значительный период времени (до суток);
02
Необходимость полного рестарта стенда после каждого теста
03
Хаос-воздействия не всегда завершались по графику, приходилось отлавливать зависшие процессы-эмуляторы воздействий
04
Для корректной оценки результатов тестирования необходимо было анализировать большое количество метрик и логов после каждого теста
Итоговая матрица тестов состояла из более чем 40 различных воздействий, каждое из которых в теории могло стать причиной выхода системы из строя.
Результаты проекта и преимущества для заказчика
По результатам проведенных тестов были выявлены критически важные уязвимости.
01
Первая проблема была связана с не вполне корректной настройкой BGP для кластеров. Это приводило к выходу из строя системы при попытке перевести трафик с вышедшего из строя плеча (ДЦ). Похожий дефект был выявлен в алгоритме балансировки, который не отслеживал важные метрики для оценки состояния хоста
02
Часть ошибок наблюдалась в работе с In-memory DB. Отсутствие поддержки со стороны вендора привносило свои сложности. Также эта часть системы администрировалась отдельно, что не всегда давало возможность получить достаточно подробные логи
03
Самым устойчивым компонентом системы оказалась база данных. Выходы из строя частей или перезагрузка физических компонентов не вносила нестабильность в систему
В итоге со стороны заказчика по результатам тестирования и соблюдением рекомендаций было устранено подавляющее большинство критичных недочетов, после чего деструктивные сценарии перестали оказывать влияние на систему.
Результаты тестирования позволили банку значительно повысить уровень безопасности и устойчивости TPS-системы. Благодаря проведенному деструктивному тестированию заказчик смог убедиться в том, что его продукт готов к работе в условиях высокой нагрузки и деструктивных атак. Таким образом, была обеспечена безопасность и надежность услуг для клиентов.
Закажите нагрузочное тестирование у тех, кто занимается им много лет
Увеличьте производительность вашей системы
до максимума и застрахуйте свой бизнес.
