Привет, Хабр!
Мы — команда RapidSoft и сегодня хотим рассказать, как мы разработали и внедрили нестандартное решение системы лояльности клиентов SBI банка, как удалось в кратчайшие сроки успеть выполнить работы на абсолютно новом модуле процессинга и разработать полноценный сложный продукт, преодолев все «подводные камни». В этом нам помог опыт работы по автоматизации таких известных программ лояльности как Мультибонус, СберСпасибо и многих других…
На тот момент SBI Банк был довольно небольшим. Исторически он работал в корпоративном сегменте, но к 2017 году стал 100%-й «дочкой» японского холдинга SBI Holdings, после чего акционеры задумались о том, чтобы предложить на российском рынке услуги для розничных клиентов — новое решение для управления семейными финансами и накоплениями «Свой круг».
К нам банк пришёл за программой лояльности для этого решения. Хорошей рекомендацией стал опыт RapidSoft в реализации программы лояльности Мультибонус для банка ВТБ, которую мы автоматизировали в 2013-м году и с тех пор продолжаем поддерживать и развивать. Однако запрос SBI Банка сильно отличался от ВТБ.
Пакет «Свой круг» — это семейные карты, которые подключаются к одному счету и позволяют всей семьёй собирать бонусы. В комплекте есть одна основная карта, две дополнительные карты и даже брелок для ребёнка.
Запуск такой семейной программы лояльности приносит пользу и банку, и его клиентам:
Итак, представьте себе семейную игру. Всем, включая детей, выдаются банковские карточки, подключенные к одному счёту, устанавливаются лимиты на снятие наличных, расходы. Всё готово, игра начинается. Каждый член семьи тратит и зарабатывает общие бонусы. Причем ведётся рейтинг, где можно посмотреть, кто и сколько принес на общую карту.
Хорошая идея программы лояльности для всей семьи? Классная. Но каждая идея требует реализации.
Нашей задачей было разработать и внедрить программу лояльности с многоуровневым кешбэком. Количество баллов зависит от суммы покупок по карте и выбранных категорий повышенного начисления. Начисление должно осуществляться на единый счёт с разных карт. Дополнительное условие — начисление процентов на остаток по счёту (максимально 8,5%).
Особенность решения, которое хотел построить SBI Банк, состояла в том, что бонусы должны были списываться на погашение ранее совершённых транзакций (например, накопив много бонусов, клиент получал возможность оплатить ими вчерашний поход в ресторан). Так делает «Тинькофф Банк» и ещё некоторые банки, а в ВТБ вместо этого используется потолок призов — на бонусы можно заказать определённые товары или услуги (например, дорогую газонокосилку).
Ещё одно отличие — в системе выбора категорий. В программе лояльности SBI Банка заложено три уровня: бронзовый, серебряный и золотой. Первый открыт по умолчанию, а следующие достигаются с определённой суммой трат по карте. И в каждом из уровней есть разные категории, на которые можно получать повышенные начисления.
Скажем, начался месяц, у клиента сразу открыто несколько категорий — нужно зайти и выбрать, в какой категории он будет накапливать бонусы, например, в категории «Детские товары» или «Авто». По достижении определенной суммы общих трат (например, 30 тысяч рублей) открывается следующий уровень — ещё несколько категорий.
Получается «двухходовка»: сначала тратишь, потом открывают категории, выбираешь какую-то из них и в ней накапливаешь больше. Это довольно нестандартная механика для системы лояльности.
Кроме того, банк поставил условие: все начисления бонусов должны происходить оперативно и отображаться онлайн. Человек потратил деньги — в тот же день увидел начисленные бонусы. Такой подход в полной мере тоже редко встречается, поскольку требует внимательного отношения к обработке авторизаций, клиринга, возвратов по операциям от платёжных систем. Наши коллеги из проектной команды со стороны банка предложили нам реализовать этот механизм сразу при запуске программы, и это здорово.
В нашей Системе лояльности за расчёт механик начисления отвечает компонент под названием «Модуль акций». Это, если говорить упрощённо, движок принятия решений, который получает на входе контекст какого-либо события, например, авторизации по карте, и выдаёт на выходе набор действий, которые нужно совершить: начислить бонусы, отправить сообщение клиенту и т.д. За счёт того, что все правила компилируются и выполняются в памяти, этот движок может обрабатывать очень большие объёмы данных онлайн.
Когда мы проектировали интеграцию с банком, придумывали, как реализовать многоуровневую систему начислений, возникло такое творческое решение — дважды вызывать модуль акций. В первый раз настраиваются механики под выбор доступных категорий: счётчики модуля акций считают входящие транзакции и суммы, и в модуле акций решается, какие категории сделать доступными. А когда клиент ставит галочку на какой-то из категорий, этот выбор фиксируется, и клиент включается в целевую аудиторию следующей акции (уже по фактическому расчёту начислений) — то есть возникает триггерная цепочка.
Как раз перед тем, как заняться системой лояльности для SBI Банка, мы завершили миграцию кода процессинга с Oracle на PostgreSQL — проект для SBI Банка стал первым промышленным внедрением нового модуля процессинга, при этом удивительно удачным.
У нас уже было решение, которое работало полностью на Oracle, — огромный компонент с десятками тысяч строк кода и кучей функций: весь процессинг баллов, система учёта, хранящая информацию о клиентах, их счетах, транзакциях, балансах, в общем, всё связанное с транзакционной активностью клиентов.
Раньше Oracle был стандартом де-факто в банковской сфере, и действительно, технически это по-прежнему передовая СУБД. Однако есть недостатки: стоимость лицензий и поддержки, закрытый код, невозможность включения разработок с его использованием в реестр отечественного ПО. Так что последние лет пять все заказчики, и действующие, и потенциальные, задали нам хотя бы по разу вопрос о переходе на Open Source СУБД.
Выбор в пользу PostgreSQL был довольно очевидным — это СУБД №1 в Open Source. Ключевым фактором были поддержка MVCC, без которой нереально говорить об обработке финансовых транзакций, и очень похожий на Oracle PL/SQL язык разработки PL/pgSQL.
Почти год мы потратили, чтобы переписать своё решение на PostgreSQL. Надо сказать, что мы вообще не были уверены, что успеем за год: в модуле процессинга 120 тысяч строк кода, и это самый «ответственный» код в системе. Точного плана и оценки работ никто из нас дать не мог. Мы посомневались и решили — «Начнём, а там посмотрим». Все приключения по миграции достойны отдельного поста: мы начали с использования «автоматических» инструментов миграции от Amazon для чайников и закончили уже будучи участниками PostgreSQL Europe и разбираясь в вопросах по исходникам и по «закопанным» в архивах перепискам на postgresql.org с 2008-го года.
Получилось так, что как только мы завершили перенос всего кода и добились прохождения всех тестов, сразу же началось развёртывание проекта с SBI Банком. Заказчику был нужен PostgreSQL, и мы уже были уверены, что код полностью рабочий. И всё-таки были поражены, когда в течение первых нескольких месяцев не получили ни одного инцидента на проде, связанного с процессингом — пришло всего пара обращений по медленной работе, которые мы довольно быстро локализовали (чуть подробнее об этом ниже).
Трудно было ожидать, что программа, которая разрабатывалась год, и в течение этого года не испытывалась в окружении у «живых» клиентов, просто встанет и заработает. Но так и получилось!
Постфактум мы для себя определили два фактора, почему проблем почти не было: во-первых из 120 тысяч строк кода у нас порядка 100 тысяч — это модульные тесты, покрытие почти полное, и эти тесты мы мигрировали в первую очередь; во-вторых мы сразу же после миграции тестов настроили автоматическую сборку и тестирование в Gitlab с использованием Kubernetes, так что каждый коммит проходит полный цикл тестирования, и merge request не получится принять, если тесты не проходят.
Сейчас мы предлагаем PostgreSQL как основное решение, а Oracle поддерживаем для текущих клиентов и для любителей экзотики.
Одна из интересных проблем совместимости была связана с тем, что в PostgreSQL нет встроенной поддержки автономных транзакций. Классическое их применение — это журналирование в таблицах БД.
Мы записываем в журнал каждый вызов — всё, что пришло, и всё, что вышло, то есть все неуспешные транзакции тоже должны сохраниться в журнале, а не стереться. При ошибке в PostgreSQL вся транзакция откатывается, включая, само собой, и записи журнала. Получается, записи в таблицах журнала не должны записываться в той же транзакции, что и всё остальное.
В Oracle есть готовый механизм, чтобы обойти это ограничение. В PostgreSQL такого механизма «транзакции внутри транзакции» не оказалось. Типовое решение — использовать dblink, подключаясь к той же БД через локальную петлю, тогда в этом подключении можно открыть отдельную транзакцию.
Всё работало отлично в юнит-тестах и на лабораторных тестах производительности, но как только это решение заработало на реальном потоке транзакций — в тысячи транзакций в секунду при обработке реестров — мы увидели, что база не справляется. Оказалось, что dblink нам не подходит: работает нормально, пока количество потоков обработки не превысит количество ядер процессора, а потом быстро и непредсказуемо разваливается — соединения рвутся, «текут», блокируют друг друга. Кроме того нашли, что лабораторные тесты работают в Kubernetes на одном-двух ядрах, что совсем не соответствует реальным серверам.
Мы сделали несколько вещей:
Кроме всего этого, наборы нагрузочных тестов дополнили стресс-тестами на параллельную обработку.
От каждого банковского проекта в памяти остаётся процесс согласований с подразделением информационной безопасности (ИБ): как нам предоставляют доступ к банковским серверам или базам данных, где нужно устанавливать и тестировать наш софт. Бывает, что половина срока проекта внедрения — это получение доступов.
Довольно часто возникает проблема с доступом к Active Directory банка.
Дело в том, что внутри нашей системы есть несколько компонентов, например, модуль акций, база справочников, клиентский профиль и т.д. И каждый подобный компонент располагает своим Web GUI (в нашей терминологии — АРМ). Есть в их числе и АРМ Безопасности, через который можно управлять доступом к другим компонентам системы — заводить учётные записи для менеджеров, операторов колл-центра и всех, кому нужен доступ к системе. Все учётки хранятся в Active Directory. Для хранения данных о полномочиях пользователя у нас обычно используются дополнительные атрибуты AD.
В банках, где безопасность данных приоритетна, очень неохотно согласуют доступ системы к Active Directory, поскольку там хранятся учётные записи пользователей. А техническая учётка АРМ Безопасности должна иметь доступ не только на чтение, но и на изменение дополнительных атрибутов.
В принципе, все банки к этому относятся с большой настороженностью. И скорость принятия таких решений обычно зависит от того, насколько в банке разделены информационная безопасность и IT. В SBI Банке это была более или менее одна структура, и все решения принимались довольно быстро. Там, где безопасность живёт отдельной жизнью, провести решения через неё очень трудно.
В SBI Банке нам предложили альтернативный подход: они решили создавать новых пользователей — менеджеров и операторов — силами своих администраторов безопасности в стандартных инструментах Active Directory, без использования нашего АРМ Безопасности. Это, конечно, неудобно и совсем не упрощает жизнь ни бизнесу, ни безопасникам.
То, что наш клиент отказался от удобного и быстрого инструмента, чтобы избежать изменений в AD, заставило нас задуматься об альтернативных решениях.
Обдумывая вышеописанную проблему, мы нашли ещё один способ предоставления доступа к различным подсистемам через Active Directory, не вызывающий внутренних коллизий.
Одна из причин, по которой банки не хотят интегрировать сторонние решения через свой Active Directory — это появление новых атрибутов для пользователей, которые вводятся правилами таких решений, в том числе и нашего.«Чужие» атрибуты могут конфликтовать с уже имеющимися атрибутами в системе банка.
Чтобы эту проблему решить, RapidSoft подал официальную заявку в IANA, которая занимается раздачей уникальных идентификаторов компаний, в том числе для атрибутов разных директорий. Чтобы наши атрибуты точно не повторяли ничьи другие и не конфликтовали с ними, мы получили собственный уникальный префикс.
Это ещё один способ преодоления подобных проблем на будущее — теперь мы можем предлагать заказчику на выбор, как поступить. Если безопасность не разрешает заводить атрибуты в системе, можно использовать наши собственные атрибуты, полученные нами официально.
В ближайшем обновлении, до конца этого года, мы добавляем возможность вообще не использовать атрибуты AD, а хранить полномочия в отдельной БД в Системе лояльности. При этом аутентификация пользователей по-прежнему выполняется по доменному паролю. Такая комбинация должна полностью снять вопросы у подразделений, отвечающих за эксплуатацию AD.
Проект c SBI Банком получился невероятно быстрым. Мы начали в декабре, и в марте уже запустили систему лояльности. Как так вышло? Банк небольшой, и общались мы в основном с командой из трёх-четырёх человек — формальностей было мало, контакт с группой разработки банка был очень живым и оперативным. У нас был отдельный чат с командой банка во время внедрения, который мы организовали в нашей чат-системе (мы пользуемся MatterMost), чтобы можно было задавать вопросы и получать ответы «на лету».
Прошло почти два года, и за это время существенных переработок нашего проекта для SBI Банка не было вообще. Они время от времени приходят к нам с идеями разных акций, мы объясняем, как это можно сделать — с точки зрения интеграции всё для этого уже настроено. Долгосрочная техническая поддержка — обычное дело для таких проектов, а с доработками складывается по-разному.
Сейчас мы продолжаем консультации, оказываем информационно-аналитическую, технологическую поддержку. Решаем любые вопросы, которые возникают у заказчика.
SBI Банк запустил систему «Свой круг» в мае 2020 года. За год, по данным банка, оборот в повышенных категориях вырос вдвое, а доля клиентов со списаниями увеличилась на 40%. В целом, цифры впечатляющие:
(Кстати, в 2020 году семейный пакет «Свой круг» стал победителем Национальной банковской премии в номинации «Банковский продукт»).
Программа лояльности банка — это сложный продукт, способный на высокую отдачу вложенных ресурсов при грамотном исполнении. Судя по цифрам, у нас всё получилось.
В дополнение к своему рассказу мы попросили поделиться впечатлениями о реализации проекта руководителя программы лояльности SBI Банка Сергея Грачева. Вот какой была история старта и внедрения разработки со стороны банка:
Компания RapidSoſt более 20 лет разрабатывает и внедряет IT-решения для банковской, розничной и интернет-отраслей. Специализируется на комплексной автоматизации программ лояльности, выполняя полный цикл работ. Среди клиентов, использующих решения RapidSoſt, — Сбербанк, ВТБ, Газпромбанк, mail.ru, Почта Банк, Мегафон, М.Видео и многие другие.
Мы — команда RapidSoft и сегодня хотим рассказать, как мы разработали и внедрили нестандартное решение системы лояльности клиентов SBI банка, как удалось в кратчайшие сроки успеть выполнить работы на абсолютно новом модуле процессинга и разработать полноценный сложный продукт, преодолев все «подводные камни». В этом нам помог опыт работы по автоматизации таких известных программ лояльности как Мультибонус, СберСпасибо и многих других…
На тот момент SBI Банк был довольно небольшим. Исторически он работал в корпоративном сегменте, но к 2017 году стал 100%-й «дочкой» японского холдинга SBI Holdings, после чего акционеры задумались о том, чтобы предложить на российском рынке услуги для розничных клиентов — новое решение для управления семейными финансами и накоплениями «Свой круг».
К нам банк пришёл за программой лояльности для этого решения. Хорошей рекомендацией стал опыт RapidSoft в реализации программы лояльности Мультибонус для банка ВТБ, которую мы автоматизировали в 2013-м году и с тех пор продолжаем поддерживать и развивать. Однако запрос SBI Банка сильно отличался от ВТБ.
Условия игры
Пакет «Свой круг» — это семейные карты, которые подключаются к одному счету и позволяют всей семьёй собирать бонусы. В комплекте есть одна основная карта, две дополнительные карты и даже брелок для ребёнка.
Запуск такой семейной программы лояльности приносит пользу и банку, и его клиентам:
- Клиенты получают персональную копилку, учат детей разумным тратам, используя лимиты, все вместе зарабатывают. Придумывают общие цели, на которые в дальнейшем пойдут средства, накопленные с помощью программы лояльности.
- Банк привлекает новых клиентов, сохраняет существующих, поскольку с ним выгодно, и он заботится о семье. Повышает уровень репутации, доверия клиентов.
Итак, представьте себе семейную игру. Всем, включая детей, выдаются банковские карточки, подключенные к одному счёту, устанавливаются лимиты на снятие наличных, расходы. Всё готово, игра начинается. Каждый член семьи тратит и зарабатывает общие бонусы. Причем ведётся рейтинг, где можно посмотреть, кто и сколько принес на общую карту.
Хорошая идея программы лояльности для всей семьи? Классная. Но каждая идея требует реализации.
Особенности механики
Нашей задачей было разработать и внедрить программу лояльности с многоуровневым кешбэком. Количество баллов зависит от суммы покупок по карте и выбранных категорий повышенного начисления. Начисление должно осуществляться на единый счёт с разных карт. Дополнительное условие — начисление процентов на остаток по счёту (максимально 8,5%).
Особенность решения, которое хотел построить SBI Банк, состояла в том, что бонусы должны были списываться на погашение ранее совершённых транзакций (например, накопив много бонусов, клиент получал возможность оплатить ими вчерашний поход в ресторан). Так делает «Тинькофф Банк» и ещё некоторые банки, а в ВТБ вместо этого используется потолок призов — на бонусы можно заказать определённые товары или услуги (например, дорогую газонокосилку).
Ещё одно отличие — в системе выбора категорий. В программе лояльности SBI Банка заложено три уровня: бронзовый, серебряный и золотой. Первый открыт по умолчанию, а следующие достигаются с определённой суммой трат по карте. И в каждом из уровней есть разные категории, на которые можно получать повышенные начисления.
Скажем, начался месяц, у клиента сразу открыто несколько категорий — нужно зайти и выбрать, в какой категории он будет накапливать бонусы, например, в категории «Детские товары» или «Авто». По достижении определенной суммы общих трат (например, 30 тысяч рублей) открывается следующий уровень — ещё несколько категорий.
Получается «двухходовка»: сначала тратишь, потом открывают категории, выбираешь какую-то из них и в ней накапливаешь больше. Это довольно нестандартная механика для системы лояльности.
Кроме того, банк поставил условие: все начисления бонусов должны происходить оперативно и отображаться онлайн. Человек потратил деньги — в тот же день увидел начисленные бонусы. Такой подход в полной мере тоже редко встречается, поскольку требует внимательного отношения к обработке авторизаций, клиринга, возвратов по операциям от платёжных систем. Наши коллеги из проектной команды со стороны банка предложили нам реализовать этот механизм сразу при запуске программы, и это здорово.
В нашей Системе лояльности за расчёт механик начисления отвечает компонент под названием «Модуль акций». Это, если говорить упрощённо, движок принятия решений, который получает на входе контекст какого-либо события, например, авторизации по карте, и выдаёт на выходе набор действий, которые нужно совершить: начислить бонусы, отправить сообщение клиенту и т.д. За счёт того, что все правила компилируются и выполняются в памяти, этот движок может обрабатывать очень большие объёмы данных онлайн.
Когда мы проектировали интеграцию с банком, придумывали, как реализовать многоуровневую систему начислений, возникло такое творческое решение — дважды вызывать модуль акций. В первый раз настраиваются механики под выбор доступных категорий: счётчики модуля акций считают входящие транзакции и суммы, и в модуле акций решается, какие категории сделать доступными. А когда клиент ставит галочку на какой-то из категорий, этот выбор фиксируется, и клиент включается в целевую аудиторию следующей акции (уже по фактическому расчёту начислений) — то есть возникает триггерная цепочка.
«Переезд» с Oracle на PostgreSQL
Как раз перед тем, как заняться системой лояльности для SBI Банка, мы завершили миграцию кода процессинга с Oracle на PostgreSQL — проект для SBI Банка стал первым промышленным внедрением нового модуля процессинга, при этом удивительно удачным.
У нас уже было решение, которое работало полностью на Oracle, — огромный компонент с десятками тысяч строк кода и кучей функций: весь процессинг баллов, система учёта, хранящая информацию о клиентах, их счетах, транзакциях, балансах, в общем, всё связанное с транзакционной активностью клиентов.
Раньше Oracle был стандартом де-факто в банковской сфере, и действительно, технически это по-прежнему передовая СУБД. Однако есть недостатки: стоимость лицензий и поддержки, закрытый код, невозможность включения разработок с его использованием в реестр отечественного ПО. Так что последние лет пять все заказчики, и действующие, и потенциальные, задали нам хотя бы по разу вопрос о переходе на Open Source СУБД.
Выбор в пользу PostgreSQL был довольно очевидным — это СУБД №1 в Open Source. Ключевым фактором были поддержка MVCC, без которой нереально говорить об обработке финансовых транзакций, и очень похожий на Oracle PL/SQL язык разработки PL/pgSQL.
Почти год мы потратили, чтобы переписать своё решение на PostgreSQL. Надо сказать, что мы вообще не были уверены, что успеем за год: в модуле процессинга 120 тысяч строк кода, и это самый «ответственный» код в системе. Точного плана и оценки работ никто из нас дать не мог. Мы посомневались и решили — «Начнём, а там посмотрим». Все приключения по миграции достойны отдельного поста: мы начали с использования «автоматических» инструментов миграции от Amazon для чайников и закончили уже будучи участниками PostgreSQL Europe и разбираясь в вопросах по исходникам и по «закопанным» в архивах перепискам на postgresql.org с 2008-го года.
Получилось так, что как только мы завершили перенос всего кода и добились прохождения всех тестов, сразу же началось развёртывание проекта с SBI Банком. Заказчику был нужен PostgreSQL, и мы уже были уверены, что код полностью рабочий. И всё-таки были поражены, когда в течение первых нескольких месяцев не получили ни одного инцидента на проде, связанного с процессингом — пришло всего пара обращений по медленной работе, которые мы довольно быстро локализовали (чуть подробнее об этом ниже).
Трудно было ожидать, что программа, которая разрабатывалась год, и в течение этого года не испытывалась в окружении у «живых» клиентов, просто встанет и заработает. Но так и получилось!
Постфактум мы для себя определили два фактора, почему проблем почти не было: во-первых из 120 тысяч строк кода у нас порядка 100 тысяч — это модульные тесты, покрытие почти полное, и эти тесты мы мигрировали в первую очередь; во-вторых мы сразу же после миграции тестов настроили автоматическую сборку и тестирование в Gitlab с использованием Kubernetes, так что каждый коммит проходит полный цикл тестирования, и merge request не получится принять, если тесты не проходят.
Сейчас мы предлагаем PostgreSQL как основное решение, а Oracle поддерживаем для текущих клиентов и для любителей экзотики.
В потоке транзакций
Одна из интересных проблем совместимости была связана с тем, что в PostgreSQL нет встроенной поддержки автономных транзакций. Классическое их применение — это журналирование в таблицах БД.
Мы записываем в журнал каждый вызов — всё, что пришло, и всё, что вышло, то есть все неуспешные транзакции тоже должны сохраниться в журнале, а не стереться. При ошибке в PostgreSQL вся транзакция откатывается, включая, само собой, и записи журнала. Получается, записи в таблицах журнала не должны записываться в той же транзакции, что и всё остальное.
В Oracle есть готовый механизм, чтобы обойти это ограничение. В PostgreSQL такого механизма «транзакции внутри транзакции» не оказалось. Типовое решение — использовать dblink, подключаясь к той же БД через локальную петлю, тогда в этом подключении можно открыть отдельную транзакцию.
Всё работало отлично в юнит-тестах и на лабораторных тестах производительности, но как только это решение заработало на реальном потоке транзакций — в тысячи транзакций в секунду при обработке реестров — мы увидели, что база не справляется. Оказалось, что dblink нам не подходит: работает нормально, пока количество потоков обработки не превысит количество ядер процессора, а потом быстро и непредсказуемо разваливается — соединения рвутся, «текут», блокируют друг друга. Кроме того нашли, что лабораторные тесты работают в Kubernetes на одном-двух ядрах, что совсем не соответствует реальным серверам.
Мы сделали несколько вещей:
- Во-первых, вырезали из лога пакетных вызовов большую часть возвращаемых данных, оставили там только заголовки посылок.
- Во-вторых, перевели автономные транзакции на другую технологию — на расширение pg_background, которое показало себя и быстрее и стабильнее, чем вариант с dblink.
- В-третьих, с помощью pg_advisory_lock и sequence сделали самодельный mutex, с помощью которого ограничили количество параллельных потоков записи журнала, чтобы оно не превышало max_worker_processes.
Кроме всего этого, наборы нагрузочных тестов дополнили стресс-тестами на параллельную обработку.
Как получить доступ к Active Directory банка — или обойтись без него
От каждого банковского проекта в памяти остаётся процесс согласований с подразделением информационной безопасности (ИБ): как нам предоставляют доступ к банковским серверам или базам данных, где нужно устанавливать и тестировать наш софт. Бывает, что половина срока проекта внедрения — это получение доступов.
Довольно часто возникает проблема с доступом к Active Directory банка.
Дело в том, что внутри нашей системы есть несколько компонентов, например, модуль акций, база справочников, клиентский профиль и т.д. И каждый подобный компонент располагает своим Web GUI (в нашей терминологии — АРМ). Есть в их числе и АРМ Безопасности, через который можно управлять доступом к другим компонентам системы — заводить учётные записи для менеджеров, операторов колл-центра и всех, кому нужен доступ к системе. Все учётки хранятся в Active Directory. Для хранения данных о полномочиях пользователя у нас обычно используются дополнительные атрибуты AD.
В банках, где безопасность данных приоритетна, очень неохотно согласуют доступ системы к Active Directory, поскольку там хранятся учётные записи пользователей. А техническая учётка АРМ Безопасности должна иметь доступ не только на чтение, но и на изменение дополнительных атрибутов.
В принципе, все банки к этому относятся с большой настороженностью. И скорость принятия таких решений обычно зависит от того, насколько в банке разделены информационная безопасность и IT. В SBI Банке это была более или менее одна структура, и все решения принимались довольно быстро. Там, где безопасность живёт отдельной жизнью, провести решения через неё очень трудно.
В SBI Банке нам предложили альтернативный подход: они решили создавать новых пользователей — менеджеров и операторов — силами своих администраторов безопасности в стандартных инструментах Active Directory, без использования нашего АРМ Безопасности. Это, конечно, неудобно и совсем не упрощает жизнь ни бизнесу, ни безопасникам.
То, что наш клиент отказался от удобного и быстрого инструмента, чтобы избежать изменений в AD, заставило нас задуматься об альтернативных решениях.
Альтернатива: собственные атрибуты
Обдумывая вышеописанную проблему, мы нашли ещё один способ предоставления доступа к различным подсистемам через Active Directory, не вызывающий внутренних коллизий.
Одна из причин, по которой банки не хотят интегрировать сторонние решения через свой Active Directory — это появление новых атрибутов для пользователей, которые вводятся правилами таких решений, в том числе и нашего.«Чужие» атрибуты могут конфликтовать с уже имеющимися атрибутами в системе банка.
Чтобы эту проблему решить, RapidSoft подал официальную заявку в IANA, которая занимается раздачей уникальных идентификаторов компаний, в том числе для атрибутов разных директорий. Чтобы наши атрибуты точно не повторяли ничьи другие и не конфликтовали с ними, мы получили собственный уникальный префикс.
Это ещё один способ преодоления подобных проблем на будущее — теперь мы можем предлагать заказчику на выбор, как поступить. Если безопасность не разрешает заводить атрибуты в системе, можно использовать наши собственные атрибуты, полученные нами официально.
В ближайшем обновлении, до конца этого года, мы добавляем возможность вообще не использовать атрибуты AD, а хранить полномочия в отдельной БД в Системе лояльности. При этом аутентификация пользователей по-прежнему выполняется по доменному паролю. Такая комбинация должна полностью снять вопросы у подразделений, отвечающих за эксплуатацию AD.
Три месяца на всё
Проект c SBI Банком получился невероятно быстрым. Мы начали в декабре, и в марте уже запустили систему лояльности. Как так вышло? Банк небольшой, и общались мы в основном с командой из трёх-четырёх человек — формальностей было мало, контакт с группой разработки банка был очень живым и оперативным. У нас был отдельный чат с командой банка во время внедрения, который мы организовали в нашей чат-системе (мы пользуемся MatterMost), чтобы можно было задавать вопросы и получать ответы «на лету».
Прошло почти два года, и за это время существенных переработок нашего проекта для SBI Банка не было вообще. Они время от времени приходят к нам с идеями разных акций, мы объясняем, как это можно сделать — с точки зрения интеграции всё для этого уже настроено. Долгосрочная техническая поддержка — обычное дело для таких проектов, а с доработками складывается по-разному.
Сейчас мы продолжаем консультации, оказываем информационно-аналитическую, технологическую поддержку. Решаем любые вопросы, которые возникают у заказчика.
SBI Банк запустил систему «Свой круг» в мае 2020 года. За год, по данным банка, оборот в повышенных категориях вырос вдвое, а доля клиентов со списаниями увеличилась на 40%. В целом, цифры впечатляющие:
(Кстати, в 2020 году семейный пакет «Свой круг» стал победителем Национальной банковской премии в номинации «Банковский продукт»).
Программа лояльности банка — это сложный продукт, способный на высокую отдачу вложенных ресурсов при грамотном исполнении. Судя по цифрам, у нас всё получилось.
Глазами заказчика
В дополнение к своему рассказу мы попросили поделиться впечатлениями о реализации проекта руководителя программы лояльности SBI Банка Сергея Грачева. Вот какой была история старта и внедрения разработки со стороны банка:
— В сентябре 2019 года SBI Банк попытался внедрить новую программу лояльности «Свой круг». Через два-три месяца после запуска разработки стало понятно, что выбранный разработчик не сможет вовремя и с должным качеством вывести продукт на рынок. Проблемы появились уже на пилоте. Перед командой банка встала новая задача — в сжатые сроки, максимум три месяца, найти нового поставщика услуг и передать ему задачу по разработке системы управления лояльностью. Выбрали RapidSoſt, как одного из наиболее надёжных разработчиков.
Стоит отметить, что на установку и внедрение процессинга было очень мало времени. После заключения первичных договоров работы стартовали в начале декабря, а 1 марта 2020 году уже необходимо было вывести продукт на рынок.
При этом нужно учитывать, что постановка продукта в банк, такого как процессинг лояльности, связана не только с установкой серверов, но и с дополнительными требованиями безопасности, с контролем доступа. Нельзя просто так прийти в банк и что-то там спокойно проинсталлировать, какую-нибудь программу, которой не хватало.
Мы работали совместно — команда банка и коллеги из RapidSoſt. Они помогали нам советами, делились наработанными методами. К марту новая платформа была поставлена, внедрён тестовый контур, поставлены продуктивные сервера, банк запустил сайт системы лояльности.
Внедрение прошло отлично. Бесшовно, без влияния на клиента, мы перенесли данные со старых платформ на новые. К марту подошли во всеоружии. Были полностью готовы.
Хочется сказать спасибо коллегам за проведённую работу, выполненную в сжатые сроки, успешно реализованный проект. Позвольте пожелать удачи и хороших продаж в будущем.
Компания RapidSoſt более 20 лет разрабатывает и внедряет IT-решения для банковской, розничной и интернет-отраслей. Специализируется на комплексной автоматизации программ лояльности, выполняя полный цикл работ. Среди клиентов, использующих решения RapidSoſt, — Сбербанк, ВТБ, Газпромбанк, mail.ru, Почта Банк, Мегафон, М.Видео и многие другие.