Мир без розовых единорогов. Тестирование производительности высоконагруженных систем

Высоконагруженная система — это система, цена ошибки производительности которой высока с репутационной и финансовой точек зрения. Поэтому они относятся к классу mission или business critical.

Тестирование производительности высоконагруженных систем должно обеспечивать: высокую интенсивность нагрузки; необходимое количество исторических и тестовых данных.

Мы часто работаем с системами, спроектированными до появления современных паттернов highload-разработки. Архитекторы не закладывали в них возможностей для роста нагрузки, который в итоге произошел. Эти системы работают на пределе своего потенциала и, безусловно, еще больше нуждаются в регулярном нагрузочном тестировании (НТ).

Кому сейчас требуется заказное нагрузочное тестирование? Чаще всего финансовым организациям, ритейлу и операторам сотовой связи. Такие компании могут обеспечить всю необходимую инфраструктуру для проведения тестирования.

Ниже мы поговорим о тестировании на системном и приемочном уровнях. Конечно, выявлять дефекты производительности можно (и даже нужно) раньше, но, чтобы разобраться, как делать это на компонентном и интеграционном уровнях, понадобится отдельный номер журнала.

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

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

Все высоконагруженные приложения должны иметь серьезную систему мониторинга. Не менее, а то и более тщательный мониторинг нужно строить и в тестовой среде. Основное правило: не навреди. Система мониторинга не должна существенно влиять на производительность тестируемого приложения.

Система нагрузочного тестирования (скрипты, инструменты генерации нагрузки, эмуляторы) должна создаваться с учетом паттернов highload-разработки. Если SLA на операцию — 30 секунд, а эмулятор при высокой нагрузке отвечает минуту, то дефект в данном случае находится на его стороне.

Для тестирования нужны данные, в идеале — обезличенные. В больших системах это сотни таблиц со сложными связями, сотни терабайт информации.

Безусловно, все обезличивать не надо, но даже обработка 10% данных займет достаточно много времени. Причем обезличивание путем простой замены информации на рандомный набор символов может изменить логику работы системы, и вы начнете тестировать что-то не то. Все эти нюансы необходимо продумывать вместе с бизнесом и разработчиками.

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

Необходима автоматизация процесса тестирования. Без этого для постоянно растущей системы невозможно обеспечить регулярное и быстрое тестирование.

Важно грамотно подобрать команду. Она не обязательно должна быть большой — стенд у вас все равно только один. Что делать 8 инженерам, когда тесты проводят только двое? Команда должна быть оптимальной — такой, чтобы каждый был при деле, но при этом всегда оставалось время на автоматизацию и оптимизацию процессов.

Нужно регулярно проводить ретроспективу, чтобы понять, где в вашем тестировании узкое место и как его устранить.

Уже налаженный процесс тестирования должен развиваться вместе с системой. НТ требует постоянной корректировки и оптимизации.

Мы живем в реальном мире без розовых единорогов. Дефекты все равно будут, но можно минимизировать их количество и снизить критичность.

Когда нужно проводить тестирование производительности

На самом деле всегда. Но встраивание НТ в жизненный цикл любой системы — это дорого и сложно. Как тогда выбрать подходящий момент? Достаточно оценить стоимость тестирования и размер финансовых потерь от дефекта производительности системы. Например, он может привести к потере данных, длительному простою или увеличению времени отклика приложения. А вдруг система окажется не способна к восстановлению после падения? А если речь идет о финансовых транзакциях?

Когда стоимость НТ значительно меньше возможных потерь, его обязательно стоит проводить. При этом если задача срочная, а у вас не хватает экспертизы или специалистов, логично заказать его на стороне.

Нагрузочное тестирование на аутсорсинге

Аутсорсинг — отличный вариант, если вам не хватает экспертизы. Также он подойдет, если тестирование нужно для выполнения конкретной задачи. Например, заменить серверы, сменить версию СУБД или перейти на другое решение (привет импортозамещению). Такие задачи возникают редко и не всегда решаются стандартным способом — синтетическими тестами. А нанимать в штат людей с нужными компетенциями ради их решения бессмысленно.

Недавно к нам пришел запрос на НТ автоматизированной системы от крупного банка с офисами по России и Европе, входящего в топ-50. Речь шла о системе для работы с претензиями клиентов в отношении транзакций по картам на устройствах самообслуживания. БД на тот момент составляла более 20 ТБ данных. Раньше разработкой занимались подрядчики, а потом банк забрал эту задачу себе. При этом была утрачена экспертиза в части тестирования системы и частично по ее работе.

Требовалось оценить производительность решения перед внедрением в продуктив очередного релиза, восстановить экспертизу и обучить сотрудников заказчика.

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

Кроме того, тестируемое решение предполагало интеграцию с БД четырех автоматизированных систем (АС), откуда в офлайн-режиме должны были загружаться данные. Нам нужно было эмулировать БД этих АС. Для эмуляции создавались таблицы, которые нужно было наполнять данными (более 100 млн записей). При этом для успешного проведения каждой операции важно было соблюдать и правила наполнения таблиц внутри одной АС, и правила связи данных между АС. Поскольку экспертиза по системе у заказчика была частично утеряна, вместо необходимых инструкций у нас был единственный документ из ста с лишним страниц. Для решения задачи мы привлекли Oracle DBA, который смог быстро разработать скрипты создания и наполнения таблиц с учетом всех изложенных в документе правил. Мы подобрали оптимальное количество потоков для наполнения БД и разработали инструкции по использованию скриптов для заказчика.

В ходе тестирования мы столкнулись с неожиданной проблемой. Каждый раз после перезапуска стенда (а значит, после каждого теста) в коде системы изменялись ID компонентов пользовательского интерфейса. Всему виной технология JSF, где ID могут быть фиксированными, а могут назначаться заново. По умолчанию использовался второй вариант. Из-за этого приходилось каждый раз выполнять отладку всего набора UI-скриптов. Для устранения этой проблемы мы вместе с разработчиками приняли решение зафиксировать ID в коде системы.

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

В итоге все тесты были выполнены вовремя, а трудозатраты не превышены. Мы исправили все дефекты производительности, и релиз был внедрен в промышленную среду.

Фишки аутстаффинга

В последние годы на рынке заказного тестирования набирает популярность новая парадигма — иметь хорошую внутреннюю экспертизу, а при увеличении объема работ дополнительно привлекать подрядчиков. Другими словами — использовать аутстаффинг. Вот несколько фишек, с помощью которых мы как генеральный подрядчик делаем эту модель действительно эффективной для заказчика.

Сами проводим первичное интервью с кандидатом. Только если он нас полностью устраивает, мы включаем его в работу с заказчиком. Кандидат попадает к нам в штат: мы учим его, вместе выходим из конфликтных ситуаций, решаем вопросы, касающиеся развития, ищем для него следующий проект у другого заказчика.

Ходим на собеседования к заказчику вместе с кандидатами. Поскольку у нас за плечами большой опыт и в нагрузочном тестировании, и в подборе персонала, мы умеем задавать правильные вопросы заказчику и выявлять ключевые компетенции из всего перечисленного в описании вакансии. Это помогает понять, каких именно людей надо искать для заказчика.

Не просто выполняем задачи заказчика, а находим узкие места в процессах и предлагаем варианты их оптимизации. Безусловно, у заказчика всегда есть свой ответственный эксперт, но взгляд на уже устоявшийся процесс со стороны всегда полезен. Успешная автоматизация процессов и применение современных технологий позволяют сократить время на подготовку и проведение тестирования до 90%.

Проводим стажировки под конкретные проекты. Обсуждаем и корректируем программу обучения в зависимости от особенностей заказчика, его пожеланий в отношении знаний и умений стажеров. Это не два дня обучения MF LoadRunner. Понятно, что можно обучиться работе с любым инструментом по мануалам за неделю совершенно бесплатно, но это не сделает из вас инженера по нагрузочному тестированию. Мы обучаем теории тестирования производительности, основам объектно-ориентированного программирования, DML- и DDL-командам в SQL. Рассказываем о мониторинге, брокерах сообщений. Результаты выполнения итогового задания обсуждаем с заказчиком и решаем, на какой проект можно привлечь конкретного стажера.

Обеспечиваем стабильный состав команды. Люди реже уходят оттуда, где о них заботятся.

За хорошего инженера нужно платить. Конечно, всегда есть озвученный выше вариант «5 дней обучения по мануалам — и инженер готов». Дешево и сердито. Только даст ли это ожидаемый заказчиком результат?

Чем хорош интегратор?

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

Мы умеем решать не только задачи нагрузочного тестирования. Обезличивание данных, развертывание и поддержка тестовых сред, использование практик DevOps, автоматизация процессов, поставка оборудования, закупка лицензий — мы реализуем все это и многое другое.

Комплексные задачи под ключ раскрывают все наши преимущества. Мы можем не просто решить кейс, а улучшить бизнес компании. По секрету: мы часто знаем о заказчике то, чего он сам о себе не знает (здесь надо подмигнуть).

Стабильно работающие системы и вовремя выявленные дефекты производительности — это гарантированная прибыль. Чтобы отношения между заказчиком и интегратором были win-win, имеет смысл платить разумные деньги за качественные услуги и экспертизу. Иначе непременно получится как в известной сказке Пушкина: «А Балда приговаривал с укоризной: “Не гонялся бы ты, поп, за дешевизной”». Классик знал, о чем пишет.