Как технический директор департамента по работе с финансовыми организациями «Техносерва» в последнее время я все чаще сталкиваюсь с намерениями ряда крупных банков оптимизировать процесс подготовки и создания тестовых сред.
Информационные технологии за последние несколько лет претерпели значительные изменения. Этот факт не мог не отразиться на процессе тестирования. Логично, что руководители ИТ-департаментов таких крупных банков, как Промсвязьбанк, ВТБ 24, Россельхозбанк, УРАЛСИБ или «Хоум Кредит», задумываются о реорганизации этого процесса. CIO банков говорят совершенно логичные вещи: «Прежде чем внедрять систему, мы обязаны ее качественно протестировать на работоспособность. Мы не хотим, чтобы через полгода у нас был глобальный сбой. Сервис для клиентов не должен быть остановлен ни при каких условиях! Это главное требование нашего бизнеса».
Понимая эту потребность, «Техносерв» подготовил специальное предложение по созданию и управлению тестовыми средами. Под этой услугой мы понимаем организацию тестового стенда высокой степени готовности, на котором можно качественно и оперативно «прогнать» практически любое решение, используемое в банке. Почему проработка технического решения создания тестовых сред должна быть поручена внешней организации, а не выполняться силами собственных сотрудников? Ответ не очевидный, но вполне понятный. Накопленный опыт реализации в предыдущих проектах тестирования и создания тестовых сред позволяет избежать многих ошибок. Приведу пример одной такой ошибки из практики, когда я работал в ИТ-департаменте одного крупного банка.
При внедрении программного обеспечения по выдаче кредитов требовалось убедиться, что на пути развития данного бизнес-приложения нет ни каких технических препятствий. К информационной системе предъявлялись жёсткие требования по обеспечению высокой производительности и надёжности работы внедряемого функционала. Чтобы убедиться в корректной технической реализации, было принято решение провести нагрузочное тестирование. Так как функционал ещё не был внедрён, то для тестирования была использована часть серверов, предназначенных в дальнейшем для эксплуатации внедряемого приложения. Это почти идеальный вариант, когда полученные данные не надо оценивать через какие-то коэффициенты. Архитектура системы для проведения тестирования была такой: один сервер базы данных, один сервер приложения и один сервер балансировки нагрузки. Предполагалось, что в случае увеличения нагрузки выше допустимой, система должна масштабироваться. Будут добавляться только сервера приложения, так как сервер базы данных с поставленной задачей справлялся. Нагрузочное тестирование должно было дать ответ на вопрос, когда потребуется дополнительный сервер приложения. На тот момент все условия эксплуатации были воспроизведены достаточно точно, но именно на этапе создания тестовой среды и была допущена специалистами банка основная ошибка.
Результаты нагрузочного тестирования показали, что решение работоспособно, а дополнительные сервера потребуются только через полгода-год. На основании этого заключения было принято решение о начале внедрения. До определённого момента система функционировала достаточно стабильно. Периодически в эксплуатации наблюдались сбои, но никто не мог дать конкретного объяснения причины их возникновения. Так как эти сбои были очень редки и устранялись оперативно, то до детального анализа причин их возникновения дело не дошло. Ситуация кардинально изменилась после того, как сбои неожиданно стали повторяться ежедневно. Для анализа проблемы и поиска обходного решения были привлечены все ресурсы банка - аналитики, программисты и сотрудники подразделения поддержки.
Анализ показал, что программа балансировки осуществляла распределение запросов не по фактической нагрузке на сервер, а по количеству текущих пользовательских сессий. В определённый момент нагрузка на одном из серверов превышала допустимую, в результате чего сервер переставал отвечать на запросы. Балансировщик нагрузки, не получая ответа от сервера приложения, распределял все новые и повторные запросы пользователей на другой сервер, который был по его логике менее нагруженным. В результате - нагрузка на нём также превышала допустимую, и в считанные мгновения весь комплекс прекращал функционировать. Увеличение числа серверов приложений могло исправить ситуацию, но ненадолго. Превышение нагрузки на одном из серверов моментально приводило к падению всего комплекса в целом. В таких условиях нормальная эксплуатация системы стала невозможна. На время поиска обходного решения пришлось ввести административные ограничения на количество одновременно работающих пользователей. Развитие бизнеса замедлилось.
Вывод из этой истории очевиден: наличие правильно организованной тестовой среды, настроенной специально под существующую архитектуру ИТ-комплекса банка, - вещь крайне необходимая. Для сокращения непродуктивного использования времени, которое тратится на проведение всего комплекса тестирования, необходимо сократить время подготовки тестовых сред максимум до одного дня. Сейчас в некоторых банках для выполнения полного цикла работ, необходимых для подготовки тестовых сред, в некоторых случаях затрачивается значительно больше времени. Есть уверенность, что в ближайшее время во многих банках будут проведены мероприятия для оптимизации затрат на создание тестовых сред.
Комментарии 15
Вы это предвители, но случилось раньше? Или заказчики нарушили ваши рекомендации?
Поясните, какая связь ваего тестирования и последующей эксплуатации.
Что мы из вашего рассказа должны понять?
Что тестирование очень важно?
Теоретически все делалось правильно, но отсутствие опыта, который есть у интеграторов, привел к сбою. Хорошо, что наших знаний хватило, и мы смогли исправить ситуацию.
Так вы можете сказать, что не было учтено при тестировании? Или это узкопрофессиональная тайна?
Не было протестировано масштабирование решения, а конкретно работа балансировщика нагрузки на сервера приложения. В то время они только не давно стали появляться.
Моя задача заключалась в своевременном обеспечении подготовки тестового стенда.
Это теперь мы все умные и всё знаем, а в то время....
Если Вам потребуется организовать качественное тестирование, то обращайтесь, обязательно поможем.
Не очень понимаю, что изменилось бы, если бы сервера под тестирование выделяла внешняя организация. Или разворачивала бы на них базы данных. Или под созданием тестовой среды подразумевается в том числе и организация тестирования (в том числе с разработкой методики тестирования и тест-кейсов?) Из Вашей статьи это неочевидно.
Поймать ускользающую нить причинно-следственной связи, размотать клубок и найти первопричину - это ещё тот ребус. Сервера под тестирвание практически ни одна внешняя компания не выделяет.
Разве только в том случае, если банк потом намерен их выкупить.
Это очень ресурсоёкое решение. Во-первых, сервера должны быть сопоставимы с теми, что будут в реальной эксплуатации. Слабее, мощнее, но сопоставимы. Во-вторых, для создания тестового стенда их требуется много. В третьих, никто не будет возить оборудование из банка в банк, выделять под него место, энерго и холодо ресурсы.
Так же и банк не передаст данные о своих клиентах ни в какую внешнюю организацию. Речь идёт только о привлечении внешней компании к проработке программы тестирования. А уже исходя из неё должен быть подготовлен стенд.
В рассматриваемом примере задача ставилась - определить, когда потребуется увеличение аппаратных ресурсов для этой системы.
В том случае, если персональные данные будут тестовыми или обезличенными, то можно привлекать сотрудников сторонних организаций для проведения самого тестирования. Но повторю ещё раз - ни кто не будет предоставлять оборудование или передавать данные для тестирования.
Конечно, нет. Для этого используют обезличенные базы.
Не очень понимаю все-таки роль внешней компании в решении этой задачи. Что собственно сделал бы Техносерв на данной задаче? Разработал бы методику тестирования? Провел бы это тестирование? Провел бы экспертный анализ предоставленной банком "программа тестирования"?
Извините, никак не могу постичь причинно-следственную связь между некорректным тестированием и необходимостью привлекать на работы по созданию тестовой среды внешнего контрагента.
Необходимость привлечения компетентного внешнего подрядчика заключается в том, что у специалистов, которые выполняют работы во многих организациях (и не только в финансовой сфере) больше опыта, который позволит не повторять уже пройденные ошибки.
Если у специалистов банка имеется такая компетенция, то никого привлекать не надо.
Есть же в некоторых банках свои программисты, которые пишут программное обеспечение для Банк-Клиента, АВС, перевода денежных средств без открытия счёта и т.д.
Вы совмещаете две эти должности в компании? (Я не пытаюсь Вас троллить, просто любопытно).
Однажды в Сыктывкаре сотрудник ДПС мне выписал штраф, так в протоколе он указал номер региона не по месту регистрации моей машины, а своего.
В данном случае я могу развеять Ваши сомнения:
Должность моя - начальник управления банковских технологий, но визитки новые ещё не отпечатаны, а на старых у меня указано - технический директор департамента по работе с финансовыми организациями. Спасибо за замечание.
НО! Как человека, имеющего непосредственное отношение к этому процессу, интересует ряд моментов
1. Логично, что подготовка тестового стенда оправдана только для обособленной группы систем - не получится протестировать новый релиз CRM, без интеграций с другими системами (в идеале, можно построить копию инфраструктуры Банка, конечно и стоить будет это дорого). Я прав?
2. Поддержка актуального состояния тестового стенда. Это ответственность Банка или подрядчика (естественно, имеется в виду своевременная передача патчей и хот-фиксов)?
3. Местонахождение тестового стенда и доступ. Понятно, что тестовые стенды служат для тестирования функционала. Внутреннее тестирование силами подрядчика - это понятно. А каким образом Банк (IT и бизнес-пользователи) будут получать доступ к тестируемому функционалу? В обратном случае (когда тестовый стенд размещается в сети Банка), появляется куча других проблем (к примеру - доступы сотрудников подрядчика, физическое размещение стенда, и т.п.).
4. В какой-то степени зависит от предыдущего пункта (особенно если тестовый стенд - на территории подрядчика) - подготовка тестовых данных. Честно говоря, совсем не представляю, каким образом это будет происходить, если скажем, будут нужны данные по всем системам на t-1, да еще и обезличенные...
Мы предлагаем решения для учета и управления тестовыми средами. В чьей зоне отвественности будет этот вопрос - это должен определить банк. Для реализации тестовых стендов можно использовать и удаленные площадки. В некоторых банках они размещены не только в разных городах, но и странах.
Также и процесс тестирования, в некоторых случаях выполняется собственными силами, а в других - передается подрядчику. Во втором случае для соблюдения требований 152ФЗ и PCI DSS требуется обезличить данные.
Внедрение процедур тестирования требует реорганизации процессов разработки, внедрения и поддержки. Должна быть полная документация по программному продукту и описанию бизнес процессов. Жду письма на почту и до встречи.