Сайт находится в состоянии доработки. Извиняемся за неудобства.

x
© 1995-2020 Компания «Инфосистемы Джет»
№5-6 (297) / 2019
Программное обеспечение

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

Автор
Мария Полубелова начальник отдела тестирования Дирекции по разработке и внедрению программного обеспечения компании «Инфосистемы Джет»

287

0

12

0

3

Когда необходимо проводить тестирование производительности?

 

В чем особенности тестирования высоконагруженных систем?

 

Почему 5 дней обучения по мануалам не сделают из вас тест-инженера?

 

 

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

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

 

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

 

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

 

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

 

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

 

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

На заметку

С точки зрения инфраструктуры тестовый стенд должен включать:

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

 

При этом на всех серверах нужно установить те же настройки и патчи, которые используются в промышленной среде.

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

 

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

 

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

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

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

 

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

 

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

 

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

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

 

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

 

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

 

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

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

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

 

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

 

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

На заметку


Какая экспертиза нужна тестировщику производительности высоконагруженных систем?

 

Нужны навыки:

  • администратора — сетевого, ОС и СУБД;
  • разработчика;
  • аналитика;
  • сотрудника сопровождения;
  • инженера по ручному функциональному тестированию.

 

Также необходимо: разбираться в конкретных областях бизнеса, владеть специфическими знаниями и инструментами нагрузочного тестирования. Важную роль играют и soft skills: усидчивость, умение работать в команде — короче говоря, классический «джентльменский набор».

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

 

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

 

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

 

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

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

 

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

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

 

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

 

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

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

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

 

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

 

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

 

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

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

 

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

 

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

 

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

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

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

 

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

 

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

 

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

 

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

Подводим итоги:

 

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

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

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

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

Кластерные СУБД

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

Как изменится ритейл в 2020 году

Какие тренды характерны для отечественного ритейла, и как мировые гиганты справляются с вызовами рынка

Обзор решений по защите от таргетированных атак

Обзор представляет решения Anti-APT от ведущих производителей: FireEye, Trend Micro Deep Discovery, Check Point SandBlast, Kaspersky Anti Targeted Attack Platform (KATA)

Спасибо!
Ваш материал отправлен.
Мы с вами свяжемся
Предложить
авторский материал
Спасибо!
Вы подписались на обновления наших статей
Подписаться
на рубрику






Спасибо!
Вы подписались на обновления наших статей
Оформить
подписку на журнал







Спасибо!
Вы подписались на обновления наших статей
Оформить
подписку на новости







Спасибо!
Вы подписались на наши новости.
Оформить
подписку на Новости
Спасибо!
Ваша заявка отправлена.
Мы с вами скоро свяжемся.
Задать вопрос
редактору

Оставить заявку

Мы всегда рады ответить на любые Ваши вопросы

* Обязательные поля для заполнения

Спасибо!

Благодарим за обращение. Ваша заявка принята

Наш специалист свяжется с Вами в течение рабочего дня