О карте МегаФона — технические подробности, часть 2

в 12:11, , рубрики: agile, scrum, Анализ и проектирование систем, биллинговые системы, Блог компании «МегаФон», интеграция, карта мегафона, Мегафон, Проектирование и рефакторинг, тестирование, Тестирование IT-систем

Продолжаем рассказывать про технические особенности реализации проекта по выпуску и обслуживанию банковских карт «МегаФона». В предыдущих постах мы говорили о карте как о финансовом продукте, о ее возможностях и об устройстве программного обеспечения, которое обеспечивает работу системы. В этом посте мы затронем вопросы, связанные с интеграцией  IT-систем «банка Раунд» — партнера «МегаФона» по проекту — с IT-системами оператора. Технологическим партнером по созданию интеграционного решения, объединяющего IT-системы банка и «МегаФона», стала компания «Неофлекс» — системный интегратор с более чем двенадцатилетним опытом работы на IT-рынке.

О карте МегаФона — технические подробности, часть 2 - 1

Проект проходил в несколько этапов:

  • Команда «Неофлекс» изучила бизнес-процессы, спроектированные на стороне МегаФона.
  • Совместно с ИТ-архитекторами банка мы предложили решение, которое позволило положить эти процессы в основу SOA-архитектуры, с учетом обеспечения стабильности и устойчивости системы.
  • Затем были сформулированы требования к будущему интеграционному решению, которое также было разработано «Неофлекс».
  • Следующий этап — разработка и тестирование, его делали итерационно, разбивая функциональность на логические блоки.

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

Одним из самых сложных аспектов проекта еще на этапе планирования работ являлось наличие большого количества поставщиков и подрядчиков. Выполнение такого проекта классическим водопадом привело бы нас к увеличению сроков, что было недопустимо. Из-за того, что работы выполнялись в динамическом режиме, фиксировать scope на начальном этапе было практически нереально. Работать классическим scrum мы тоже не могли, так как многие контрольные точки зависели от поставщиков других систем. Мы применили спиральный подход: совместно с банком мы проанализировали приоритеты других поставщиков, общие задачи проекта и выделили блоки функциональности. Эта модель и определила для нас состав итераций по разработке проекта. Как результат, когда прошла половина срока на выполнение всего проекта, мы начинали аналитику по сервисам для IVR и личного кабинета клиента, при этом на тестовом окружении уже стояло интеграционное решение, обеспечивающее процесс выпуска карт. Это позволяло на ранней стадии определить, какие изменения и улучшения внести в процесс, а команды АБС и фронта по выпуску карт могли проводить сквозное тестирование новой функциональности.

Коротко о главном

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

В качестве основной платформы для обеспечения интеграции выбрали решение Oracle Service Bus. Это промышленная интеграционного платформа от одного из мировых лидеров IT-отрасли, которая предназначена для построения инфраструктуры доступа к бизнес-сервисам и их виртуализации. Как и ряд других промышленных платформ, OSB обладает развитым средством разработки и отладки решений, большим объемом документации, также можно отметить возможности для быстрого и удобного создания сложных трансформаций данных, поддержку из коробки большого числа различных транспортных протоколов, эффективное управление большим количеством запросов, удобное управление изменениями. Компания «Неофлекс» уже имела успешный опыт выполненных программ проектов на платформе OSB, поэтому мы были уверены в решении и понимали, как его оптимально использовать для решения задач проекта Банковская карта Мегафона, как минимизировать затраты на написание кода, фактически концентрируясь только на бизнес функционале.

Опытным путем

На стороне «МегаФона» проект затронул шлюз электронной коммерции для списания и пополнения лицевого счета, систему для управления услугами, подключенными к телефонам клиентов, IVR, а также личный кабинет абонента. Также на стороне оператора активно используется «Система продаж и обслуживания»,  через которую отправляются запросы на оформление и выдачу карт. На стороне банка решение интегрируется с процессинговой системой, АБС, системой валидации клиентов. Со всеми системами, кроме биллинга, мы интегрировались напрямую, используя стандартные для индустрии технологии — SOAP и REST. Взаимодействие с биллинговой системой было настроено с использованием шлюза от компании InPlat, который обеспечивает единую точку входа для всех партнеров «МегаФон» и предоставляет доступ к услугам электронной коммерции.

Часть функциональности проекта включала не только необходимость создания транспортных потоков, но и сложную бизнес-логику с поддержкой асинхронных транзакционных вычислений. Для реализации таких задач в рамках проработки архитектуры мы решили вынести эту функциональность в отдельное масштабируемое решение на java компонентах, в основу которого были положены как принципы java enterprise, так и MSA (micro service architecture). Выбранный подход позволяет добиться легкого и недорогого масштабирования решения по нагрузке с возможностью оперативно вносить необходимые изменений в функциональность.

Исходя из нашего опыта, мы понимали, что критически важной частью такого решения является система мониторинга состояния инфраструктуры и компонентов решения и система аудита обрабатываемых сообщений. В качестве средства сбора и обработки данных о состоянии инфраструктуры банк использует Zabbix, и мы решили интегрироваться в него, имея опыт его использования в сложных проектах. При проектировании и создании системы мы закладывали точки мониторинга, всего их было создано несколько десятков, они позволяют контролировать количество используемых ресурсов (потоки обработки, соединения с базой данных, соединений с внешними системами) и анализировать показатели по обработке сообщений, например, количество неуспешных запросов за последнее время, количество обработанных запросов и прочее. Разработанная система аудита обработанных сообщений позволяет через удобный пользовательский интерфейс просматривать полную информацию обо всех запросах с использованием фильтров и поиска. При этом различные сообщения в рамках одного бизнес процесса объединяются в одну цепочку. Естественно информация о запросах, доступная в мониторинге, проходит предварительную обработку, чтобы удовлетворять политикам безопасности банка и требованиям PCI DSS, но указанного средства банку достаточно, чтобы разобрать максимально быстро любую спорную ситуацию. Для интеграции это очень важно, т.к. в процесс вовлечено много систем и даже несколько организаций.

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

Автор: MegaFon

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js