Рейтинг банков по кредитным картам

Рейтинг кредитных карт
Эксклюзивное исследование Банки.ру — ноябрь, 2016

Автоматизация создания тестовых сред для банков – новая тенденция времени

07.08.2012 16:19 15 5 414 просмотров
Как технический директор департамента по работе с финансовыми организациями «Техносерва» в последнее время я все чаще сталкиваюсь с намерениями ряда крупных банков оптимизировать процесс подготовки и создания тестовых сред.

Информационные технологии за последние несколько лет претерпели значительные изменения. Этот факт не мог не отразиться на процессе тестирования. Логично, что руководители ИТ-департаментов таких крупных банков, как Промсвязьбанк, ВТБ 24, Россельхозбанк, УРАЛСИБ или «Хоум Кредит», задумываются о реорганизации этого процесса. CIO банков говорят совершенно логичные вещи: «Прежде чем внедрять систему, мы обязаны ее качественно протестировать на работоспособность. Мы не хотим, чтобы через полгода у нас был глобальный сбой. Сервис для клиентов не должен быть остановлен ни при каких условиях! Это главное требование нашего бизнеса».

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

При внедрении программного обеспечения по выдаче кредитов требовалось убедиться, что на пути развития данного бизнес-приложения нет ни каких технических препятствий. К информационной системе предъявлялись жёсткие требования по обеспечению высокой производительности и надёжности работы внедряемого функционала. Чтобы убедиться в корректной технической реализации, было принято решение провести нагрузочное тестирование. Так как функционал ещё не был внедрён, то для тестирования была использована часть серверов, предназначенных в дальнейшем для эксплуатации внедряемого приложения. Это почти идеальный вариант, когда полученные данные не надо оценивать через какие-то коэффициенты. Архитектура системы для проведения тестирования была такой: один сервер базы данных, один сервер приложения и один сервер балансировки нагрузки. Предполагалось, что в случае увеличения нагрузки выше допустимой, система должна масштабироваться. Будут добавляться только сервера приложения, так как сервер базы данных с поставленной задачей справлялся. Нагрузочное тестирование должно было дать ответ на вопрос, когда потребуется дополнительный сервер приложения. На тот момент все условия эксплуатации были воспроизведены достаточно точно, но именно на этапе создания тестовой среды и была допущена специалистами банка основная ошибка.

Результаты нагрузочного тестирования показали, что решение работоспособно, а дополнительные сервера потребуются только через полгода-год. На основании этого заключения было принято решение о начале внедрения. До определённого момента система функционировала достаточно стабильно. Периодически в эксплуатации наблюдались сбои, но никто не мог дать конкретного объяснения причины их возникновения. Так как эти сбои были очень редки и устранялись оперативно, то до детального анализа причин их возникновения дело не дошло. Ситуация кардинально изменилась после того, как сбои неожиданно стали повторяться ежедневно. Для анализа проблемы и поиска обходного решения были привлечены все ресурсы банка - аналитики, программисты и сотрудники подразделения поддержки.

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

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

Комментарии 15

Семен Семенович Горбунков  (Семен Семенович)
#
В приведенном примере я не увидел логической связи результатов успешного тестирования и выявленных причин возникавших сбоев.
Вы это предвители, но случилось раньше? Или заказчики нарушили ваши рекомендации?
Поясните, какая связь ваего тестирования и последующей эксплуатации.
Что мы из вашего рассказа должны понять?
Что тестирование очень важно?
Александр Горшков  (technoserv)
#
Уважаемый Семен Семенович, в приведенном примере мне пришлось выступать в лице заказчика и исполнителя одновременно (тогда я работал в ИТ-подразделении банка).
Теоретически все делалось правильно, но отсутствие опыта, который есть у интеграторов, привел к сбою. Хорошо, что наших знаний хватило, и мы смогли исправить ситуацию.
Семен Семенович Горбунков  (Семен Семенович)
#
ОК.
Так вы можете сказать, что не было учтено при тестировании? Или это узкопрофессиональная тайна?
Александр Горшков  (technoserv)
#
Семён Семёнович, нет ни какой профессиональной тайны.
Не было протестировано масштабирование решения, а конкретно работа балансировщика нагрузки на сервера приложения. В то время они только не давно стали появляться.
Моя задача заключалась в своевременном обеспечении подготовки тестового стенда.
Это теперь мы все умные и всё знаем, а в то время....
Если Вам потребуется организовать качественное тестирование, то обращайтесь, обязательно поможем.
Iriema  (Iriema)
#
В описанной Вами ситуации с "повторяющимися сбоями" мне кажется понятным, что проблема была не в созданной тестовой среде, а в некорректно разработанной методике тестирования, и как следствие, в некорректно проведенном нагрузочном тестировании:
Цитата
Анализ показал, что программа балансировки осуществляла распределение запросов не по фактической нагрузке на сервер, а по количеству текущих пользовательских сессий.

Не очень понимаю, что изменилось бы, если бы сервера под тестирование выделяла внешняя организация. Или разворачивала бы на них базы данных. Или под созданием тестовой среды подразумевается в том числе и организация тестирования (в том числе с разработкой методики тестирования и тест-кейсов?) Из Вашей статьи это неочевидно.
Александр Горшков  (technoserv)
#
Очень сложно выяснить причину плавающих ошибок. Они повторяются нерегулярно.
Поймать ускользающую нить причинно-следственной связи, размотать клубок и найти первопричину - это ещё тот ребус. Сервера под тестирвание практически ни одна внешняя компания не выделяет.
Разве только в том случае, если банк потом намерен их выкупить.
Это очень ресурсоёкое решение. Во-первых, сервера должны быть сопоставимы с теми, что будут в реальной эксплуатации. Слабее, мощнее, но сопоставимы. Во-вторых, для создания тестового стенда их требуется много. В третьих, никто не будет возить оборудование из банка в банк, выделять под него место, энерго и холодо ресурсы.
Так же и банк не передаст данные о своих клиентах ни в какую внешнюю организацию. Речь идёт только о привлечении внешней компании к проработке программы тестирования. А уже исходя из неё должен быть подготовлен стенд.
В рассматриваемом примере задача ставилась - определить, когда потребуется увеличение аппаратных ресурсов для этой системы.
В том случае, если персональные данные будут тестовыми или обезличенными, то можно привлекать сотрудников сторонних организаций для проведения самого тестирования. Но повторю ещё раз - ни кто не будет предоставлять оборудование или передавать данные для тестирования.
Iriema  (Iriema)
#
Цитата
Так же и банк не передаст данные о своих клиентах ни в какую внешнюю организацию

Конечно, нет. Для этого используют обезличенные базы.
Цитата
В рассматриваемом примере задача ставилась - определить, когда потребуется увеличение аппаратных ресурсов для этой системы.

Не очень понимаю все-таки роль внешней компании в решении этой задачи. Что собственно сделал бы Техносерв на данной задаче? Разработал бы методику тестирования? Провел бы это тестирование? Провел бы экспертный анализ предоставленной банком "программа тестирования"?
Извините, никак не могу постичь причинно-следственную связь между некорректным тестированием и необходимостью привлекать на работы по созданию тестовой среды внешнего контрагента.
Александр Горшков  (technoserv)
#
Да, сотрудники "Техносерва" могут выполнить все перечисленные Вами работы.
Необходимость привлечения компетентного внешнего подрядчика заключается в том, что у специалистов, которые выполняют работы во многих организациях (и не только в финансовой сфере) больше опыта, который позволит не повторять уже пройденные ошибки.
Если у специалистов банка имеется такая компетенция, то никого привлекать не надо.
Есть же в некоторых банках свои программисты, которые пишут программное обеспечение для Банк-Клиента, АВС, перевода денежных средств без открытия счёта и т.д.
Iriema  (Iriema)
#
Извините, вопрос не по существу:
Цитата
Блог начальника управления банковских технологий интегратора «Техносерв»

Цитата
Как технический директор департамента по работе с финансовыми организациями «Техносерва»

Вы совмещаете две эти должности в компании? (Я не пытаюсь Вас троллить, просто любопытно).
Александр Горшков  (technoserv)
#
Когда начинается новый календарный год, то сложно привыкнуть, что в дате надо указывать новое число. smile:)
Однажды в Сыктывкаре сотрудник ДПС мне выписал штраф, так в протоколе он указал номер региона не по месту регистрации моей машины, а своего. smile:)
В данном случае я могу развеять Ваши сомнения:
Должность моя - начальник управления банковских технологий, но визитки новые ещё не отпечатаны, а на старых у меня указано - технический директор департамента по работе с финансовыми организациями. Спасибо за замечание.
Михаил Павличенко  (Mixerr)
#
Тестовая среда может смоделировать ВСЕ!!!! вероятные глюки?
Александр Горшков  (technoserv)
#
Михаил, тестовая среда должна повторять реальные условия эксплуатации, а воспроизводить "вероятные глюки" и реальные ошибки - это мастерство.smile:)
Георгий Дорохов  (Netmould)
#
Честно говоря - я бы купил работающее решение, прямо сразу. Потому из-за них ну очень много головной боли - как у заказчиков, так и у заказчиков (а сколько времени может тратиться на их подготовку...).
НО! Как человека, имеющего непосредственное отношение к этому процессу, интересует ряд моментов smile:).
1. Логично, что подготовка тестового стенда оправдана только для обособленной группы систем - не получится протестировать новый релиз CRM, без интеграций с другими системами (в идеале, можно построить копию инфраструктуры Банка, конечно и стоить будет это дорого). Я прав?
2. Поддержка актуального состояния тестового стенда. Это ответственность Банка или подрядчика (естественно, имеется в виду своевременная передача патчей и хот-фиксов)?
3. Местонахождение тестового стенда и доступ. Понятно, что тестовые стенды служат для тестирования функционала. Внутреннее тестирование силами подрядчика - это понятно. А каким образом Банк (IT и бизнес-пользователи) будут получать доступ к тестируемому функционалу? В обратном случае (когда тестовый стенд размещается в сети Банка), появляется куча других проблем (к примеру - доступы сотрудников подрядчика, физическое размещение стенда, и т.п.).
4. В какой-то степени зависит от предыдущего пункта (особенно если тестовый стенд - на территории подрядчика) - подготовка тестовых данных. Честно говоря, совсем не представляю, каким образом это будет происходить, если скажем, будут нужны данные по всем системам на t-1, да еще и обезличенные...
Александр Горшков  (technoserv)
#
Георгий, напишите письмо AGorshkov@technoserv.com (вернусь из отпуска в понедельник), договоримся о встрече. Буду рад обсудить с Вами интересующие вас темы. Что касается ваших вопросов, то полностью согласен. Для полноценного тестирования требуется интеграция. Решение получается не очень дешёвым, но все надо обсуждать. Дублировать оборудование основных систем не требуется.
Мы предлагаем решения для учета и управления тестовыми средами. В чьей зоне отвественности будет этот вопрос - это должен определить банк. Для реализации тестовых стендов можно использовать и удаленные площадки. В некоторых банках они размещены не только в разных городах, но и странах.
Также и процесс тестирования, в некоторых случаях выполняется собственными силами, а в других - передается подрядчику. Во втором случае для соблюдения требований 152ФЗ и PCI DSS требуется обезличить данные.
Внедрение процедур тестирования требует реорганизации процессов разработки, внедрения и поддержки. Должна быть полная документация по программному продукту и описанию бизнес процессов. Жду письма на почту и до встречи.
Комментарии и отзывы могут оставлять только зарегистрированные пользователи.
Авторизуйтесь или зарегистрируйтесь.

Популярные сообщения

FINAL CALL 11/16
15 ноября вышли данные по исполнению федерального бюджета за очередной месяц — октябрь. 1. В апреле — августе 2016 года из Резервного фонда изъяли
0
Как вернуть «тетрадочный» вклад?
Короткий ответ: показать документы о вкладе в банке-агенте. Длинный ответ. Наверное, уже практически все вкладчики знают, что во многих банках с
6
Рынок нефти 6 декабря
Ситуация на нефтяном рынке локально не изменилась. Brent консолидируется в районе $54/bbl на нейтральном новостном фоне. Оптимизм после заключения сделки
0
Венера в Козероге
Венера вошла в Знак Зодиака Козерог и пробудет здесь до 09 декабря. Вместо иллюзий и идеализма приходят сдержанность в проявлении чувств, строгость оценок
0
Моспромстрой
Моспромстрой еще и в Глобэксе кредитуется 7) Об одобрении сделки – Дополнительного соглашения № 1 к Договору об открытии кредитной линии № 1-79-НКЛ/15
0

Новые сообщения

  • Рынок нефти 6 декабря
    Ситуация на нефтяном рынке локально не изменилась. Brent консолидируется в районе $54/bbl на нейтральном новостном фоне. Оптимизм после заключения сделки
  • Рынок нефти 5 декабря
    Нефть торгуется в небольшом минусе, отступая от 16 месячных максимумов. Пауза в дальнейшем оптимизме на рынке сейчас выглядит вполне логично. Во-первых,
  • Как связаться с Агентством по страхованию вкладов?
    В разговорах, связанных с отзывом лицензий банков, часто возникает вопрос: как сообщить что-то АСВ, задать вопрос, пожаловаться и т.п. Ниже - справочник
  • Рынок нефти 1 декабря
    ОПЕК после почти годичных переговоров и восьми лет перерыва приняла решение о сокращении добычи нефти. Отдельным успехом для рынка в целом и картеля в
  • FINAL CALL 11/16
    15 ноября вышли данные по исполнению федерального бюджета за очередной месяц — октябрь. 1. В апреле — августе 2016 года из Резервного фонда изъяли