Обзор подготовлен

версия для печати
Пример решения: Управление производительностью банковских информационных систем - почему не стоит рисковать в игре «Что? Где? Когда?»

Пример решения: Управление производительностью банковских информационных систем - почему не стоит рисковать в игре «Что? Где? Когда?»

Дмитрий Тищенко

Дмитрий Тищенко,
руководитель отдела автоматизации тестирования и управления производительностью

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

По данным Центробанка, прибыль, полученная российскими кредитными организациями в первом полугодии 2011 года, превысила прошлогодний показатель более чем на 35%. Количество данных и транзакций, которые необходимо обрабатывать, постоянно увеличивается, что ведет к значительному повышеннию нагрузок на ИТ-системы. Однако, в какой физической форме находятся банки и насколько готова их инфраструктура поддерживать непрерывность бизнеса?

«Многие банки и финансовые институты на сегодняшний день сталкиваются с проблемой «уставших» ИТ-систем, которые могут дать сбой при увеличении нагрузки, – комментирует Дмитрий Тищенко, руководитель направления по управлению производительностью компании A1QA. – Ввиду того, что речь идет о критичных для бизнеса системах и операциях, стоимость ошибки слишком высока, чтобы закрывать на это глаза в ожидании что, где и когда выйдет из строя».

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

«Аспекту производительности и отказоустойчивости должно уделяться пристальное внимание на каждом этапе жизненного цикла системы: при выработке требований, при разработке и вводе в эксплуатацию, на стадии эксплуатации, при планировании развития системы, – отмечает Дмитрий Тищенко – Наши эксперты готовы подключиться на любом этапе, а также оказать полный цикл услуг, используя комплексный подход к управлению производительностью».


Комплексный подход к управлению производительностью

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

Система управления взаимоотношениями с клиентами банка на момент старта проекта выдерживала оперативную нагрузку, но темпы увеличения объёмов данных и количества персонала, работающего с ней, вызывали обоснованные опасения в отношении её надежности в ближайшей перспективе. Итак, задача проекта – понять возможности системы по производительности, а также выработать возможные сценарии модернизации системы (увеличение вычислительных мощностей или рефакторинг).

Процесс тестирования производительности проходит в четыре этапа :

  • Первичный анализ
  • Подготовка
  • Тестирование
  • Обработка результатов и выработка стратегии

Этап начального анализа крайне важен: его результатом является понимание потребностей банка при управлении производительностью, а значит и целей тестирования; понимание системы с технологической и функциональной точек зрения; понимание рисков и возможностей по проведению тестирования. Как правило, результатом этого этапа является также уточнённая стоимость работ.

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

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

  • Третья часть этапа – анализ возможностей и ограничений по проведению тестирования. В данном случае были уточнены вопросы по организации стендов для запуска и разработки тестов, определены высокоуровневые требования по профилю нагрузки, параметрам мониторинга и объемам тестовых данных, необходимых для проведения тестов. Специалисты A1QA исследовали интеграционные механизмы тестируемой системы с другими системами Банка, такими как АБС, системой управления потребительским кредитованием, контроля качества данных и другими.


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

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

  • На основании методики проводится разработка тестов производительности. Разработанные тесты в обязательном порядке документируются, в том числе с целью минимизации затрат при их повторном использовании.

  • В случае если стенд, на котором планируется проведение тестирования, недоступен на подготовительном этапе, разработка тестов выполняется на временном стенде. На текущем проекте временный стенд для разработки тестов был развернут на стороне A1QA.


Этап проведения тестирования начинается с подготовки инфраструктуры — развертывание стенда для запуска тестов, настройка генераторов нагрузки. Банк или Подрядчик выполняют работы по развертыванию физических мощностей, установке и настройке системы.

Безусловно, стенд для запуска тестов должен совпадать либо быть максимально приближен к продуктивному окружению. Это требование касается как вычислительных мощностей, так и объёма данных в системе. Наполнение системы данными, как правило, выполняет подрядчик. Оптимизировать трудозатраты по наполнению системы данными может помочь начальный «синтетический» набор (в случае если банк может его предоставить), однако можно обойтись и без него. Зачастую запуск тестов проводится на мощностях, которыми планируется заменить текущее продуктивное окружение.

  • Запуск тестов начинается по готовности системы к тестированию. Как правило, осуществляется предварительный запуск тестов с незначительной нагрузкой (около 10% от профиля нагрузки) с целью проверить работоспособность тестов и системы в целом на новом стенде. При необходимости производится дополнительная настройка системы.

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

  • По понятным причинам, в подавляющем числе случаев тестирование проходит на территории Банка.


Обработка результатов и выработка стратегии осуществляется на основании собранной информации на этапе запуска.

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

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

  • После работ по оптимизации системы проводится повторное тестирование производительности в целях проверки факта исправления дефектов.

Подводные камни

Стоит обратить внимание на некоторые потенциальные трудности, которые могут возникнуть при реализации подобных проектов.

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

  • Во-вторых, изменения в системе, как правило, влекут за собой изменения тестов производительности. Функциональные дефекты в покрываемой тестами функциональности могут блокировать разработку или запуск тестов. К сожалению, нередки задержки в поставках оборудования для тестового стенда (будущей системы). Эти риски негативно сказываются на объёмах и сроках работ.


Советы эксперта

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

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

  • Уровень рекомендаций по улучшению производительности лучше  оговаривать на начальном этапе, чтобы синхронизировать ожидания сторон. Подрядчик может считать достаточным дать только верхнеуровневую информацию о работе компонентов системы. В этом случае банку придётся идентифицировать конкретные проблемы и пути решения самостоятельно или привлекать дополнительных консультантов, увеличивая таким образом бюджет проекта. Нивелировать эти риски в большинстве случаев помогает стратегический выбор надежного подрядчика и построение с ним открытых, партнерских,  долговременных отношений, основанных на компетентности и доверии.


О компании: A1QA (ЗАО «Технологии качества») является одной из крупнейших компаний в Центральной и Восточной Европе, специализирующихся исключельно на услугах обеспечения качества ПО. Специалисты A1QA оказывают полный спектр услуг по тестированию бизнес-приложений и ИТ-решений, работая для ведущих компаний в области банковского дела, страхования, телекоммуникаций и высоких технологий.

Техноблог | Форумы | ТВ | Архив
Toolbar | КПК-версия | Подписка на новости  | RSS