Елена Батяева, «Открытие», о внедрении платформы для обмена данными

Благодаря внедрению решения на базе Tarantool банк «Открытие» повысил доступность фронтальных каналов обслуживания клиентов. Почему в этом проекте особое внимание пришлось уделить качеству данных, как проходила реализация и что еще предстоит сделать, рассказала Елена Батяева, руководитель направления в управлении автоматизации розничных процессов банка «Открытие».

Как воз­ник­ла идея про­ек­та, ко­то­рый Вы пред­став­ля­ете в кон­кур­се «Про­ект го­да»?

В 2019 году перед банком «Открытие» вынужденно встала проблема повышения эффективности работы фронтальных систем, поскольку в ходе объединения большого количества банков образовался достаточно сложный IT-ландшафт. Его необходимо было выравнивать. Также очевидным образом встали вопросы скорости обработки информации и отказоустойчивости на случай возникновения тех или иных аварийных ситуаций, которые при нашем ландшафте необходимо было решать. С одной стороны, мы запустили инициативы по разработке микросервисных платформ, которые позволили нам выпрямить разработку. С другой стороны, начали проект по организации enterprise data cache, т.е. прогретого кэша данных. Это позволило бы нам организовать real time потоки из всех ключевых банковских систем и от компаний-партнеров, чтобы можно было консолидировать их в быстром хранилище, в современном распараллеливании с высокой доступностью, на котором мы могли бы нивелировать те или иные проблемы производительности и скорости обработки данных в классический банковский бэк.

Мы достаточно долго прорабатывали схему работы новой системы и то как она впишется в наш IT-ландшафт. И в итоге после длительных испытаний в прошлом году остановились на том, что мы готовы делать эту систему совместно с коллегами из mail.ru (теперь группа ВКонтакте), на основе их решения Tarantool.

Какие задачи решает проект?

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

Вторая задача, которую мы хотели решить, – повышение скорости ответа систем. Здесь все достаточно очевидно, естественно, in-memory - это гораздо быстрее, чем получение данных из бэка, который, в общем-то, не всегда хорошо приспособлен для современных нагрузок в каналах.

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

Дальнейший спектр использования этой технологии, на самом деле, крайне широкий. Надеемся, этот проект вырастет и будет еще интересней в будущем.

Как проходило внедрение решения? Что было самым сложным?

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

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

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

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

На какие показатели работы компании больше всего повлиял проект?

Пока рано говорить о том, какое влияние произошло, потому что мы сделали большой объем работы, но далеко не все, что хотим. Но мы уже точно можем сказать, что по затронутым направлениям получили 90-процентную экономию нагрузки на внутренние системы и существенное снижение времени отклика. При этом мы понимаем, что задержка данных у нас составляет буквально несколько секунд, и это действительно позволяет обслуживать высоконагруженные места, связанные с обработкой клиентских продуктов, и информировать об их текущем состоянии. Мы ожидаем, что максимального эффекта достигнем примерно через 12-18 месяцев после того, как развернем решение в полном объеме, в том числе на другие банковские направления. После этого мы получим мощнейший синергетический эффект в виде того, что наши затраты на IT-инфраструктуру радикально уменьшатся вместе с повышением доступности инфраструктуры до требуемого уровня. Оценить на текущий момент эффективность кейсов, связанных с data science, достаточно сложно. Но, в любом случае, это представляет серьезную тему для разговора.

Какие рекомендации вы можете дать коллегам, которые сейчас работают над аналогичной задачей или проблемой?

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

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

За какими ИТ-трендами на рынке следите внимательнее всего, в том числе в рамках «Проекта Года»?

Data – это «новая нефть». Поэтому нам, безусловно, интересны все проекты, связанные с обработкой больших данных и получением какой-либо пользы от них. Это интересно, потому что мы прекрасно понимаем силу данных и то, что если мы сможем работать с данными оперативно и качественно, то получим очень большой и интересный эффект. У нас, например, есть кейс: мы сейчас всю систему контроля качества разработки, по сути, строим вокруг внутренней big data для разработчиков. Это начиналось как небольшой проект, но выросло в весьма серьезную инициативу, которая позволяет нам гибко управлять эффективностью и производительностью команд, их размером и масштабом. Просто работая даже с данными на уровне прототипа excel, мы смогли «разогнать» команды примерно в полтора раза. Поэтому очевидно, что на внешнем рынке с огромным объемом клиентских данных, которые на самом деле есть у банков, мы сможем получить даже гораздо более интересный эффект.