company_banner

Как мы Raiffeisen Online создавали…


    Интернет-банк уже давно превратился из роскоши в must have для любого уважающего себя банка. Излишне говорить, что приложение должно не просто быть, а должно быть надёжным, удобным и приятным в использовании. В одной статье не получится рассказать обо всех аспектах нашего интернет-банка Raiffeisen Online, но зато я расскажу о нашем опыте создания новой версии, его архитектуре и трудностях, с которыми столкнулась команда. Возможно, кому-то наш опыт поможет сэкономить время и усилия.

    Об авторе


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

    Краткое содержание предыдущих серий: R-Connect v1, v2


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

    Здесь я не буду касаться первой версии. Это был просто интернет-банк, который несколько раз становился лучшим интернет-банком для частных лиц. Java, Struts, аминь.

    Вторая версия появилась как эволюционное развитие R-Connect v1 в результате разработки мобильного приложения.

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

    Лучший интернет-банк 2009


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

    Опыт развития и поддержки интернет-банка версии 2.0 показал, что мы не можем реализовывать в адекватные сроки простейшие запросы от бизнеса. Например, изменить срок действия или условия открытия банковского вклада. Боль возникала в разных местах: сильная связанность кода серверной части с Javascript-логикой, захардкоженные описания банковских продуктов, прописанная в клиентской части логика форм, завязанная на конкретные продукты, проблемы в интеграциях с мастер-системами. Реализация более сложных задач вызывала ужас не только на лицах разработчиков, но и в умах бизнеса, который начинал осознавать, какой же монстр у нас вырос. Но, как говорится, осознание проблемы — это половина пути по ее решению.

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

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

    Ключевыми идеями нового интернет-банка, вокруг которых формировался проект, были:

    • Виджетная система с возможностью пилотирования и пользовательскими настройками;
    • Адаптивный дизайн;
    • Таргетирование контента;
    • Единая платформа для интернет и мобильного банка;
    • Легкость изменения контента.

    С этими требованиями мы запустили R&D.

    R’n’D


    Под R&D была выделена часть команды, которую освободили от production-задач. Перед ней была поставлена задача поиска стека технологий, на котором будет базироваться новый интернет-банк.

    Мы рассматривали разные варианты:

    • Коробочное решение.
    • Платформа.
    • Собственная разработка.

    Банк — это организация, которая любит считать деньги. Как чужие, так и свои. Поэтому первым делом команда отправилась на поиски готового коробочного решения, которое можно было сегодня начать эксплуатировать, а уже завтра получить с этого прибыль. Но рассмотренные нами предложения не устраивали по разным причинам, связанным с возможностью доработок под нас и приватностью этих доработок, стоимостью развития и поддержки, и так далее.

    «Если готовый продукт купить нельзя, то давайте поищем полуфабрикаты» — решила команда. И отправилась на поиски некой мифической платформы, на базе которой можно разработать уникальный для рынка продукт. Анализ рынка и внедрений показал, что наиболее подходящим решением для нас является портальная технология и так называемые веб-порталы. Хотя на рынке были примеры разработки интернет-банка и на Adobe CQ5, большой корпоративной CMS.

    «Собственная разработка — это так дорого и несовременно! Зачем нам изобретать велосипед заново, если прогрессивное сообщество уже сделало это за нас?» — подумала команда и приступила к созданию прототипа на портале.

    Прототип 1: платформа Liferay


    Эй! Кто-нибудь! Здесь хоть кто-то умеет работать с Liferay?

    Не могу вспомнить, почему в качестве пилотного решения мы выбрали именно Liferay, а не какой-либо другой портал. Но, тем не менее, мы его выбрали и начали рассматривать со всех сторон.

    Так как Java-разработчику, который разбирался с Liferay, не хватало знаний в клиентских технологиях, то ему в помощь дали единственного на тот момент во всей команде frontend разработчика. И в итоге наш первый прототип был написан на дикой смеси из кастомных JSF-компонентов. Попытка приблизить внешний вид получающегося интерфейса к концепции, которую ожидал наш бизнес, удалась, однако, опрос участников R&D-команды показал, что мнения о процессе и результате расходятся.

    Разработчик клиентской части признал, что это был его первый опыт работы с тяжелым и неудобным миром Java-enterprise и JSF в частности, и, в дальнейшем получившийся результат будет непросто развивать и поддерживать с учетом требований, которые выдвинул бизнес. А разработчик серверной части, напротив, был доволен результатом. Потому что он очень любит использовать готовые решения и раньше работал с JSF.

    Пока они разрабатывали наш первый прототип, матерясь и чертыхаясь, в команде интернет-банкинга возникло оппозиционное движение — за собственную разработку. Было много встреч, обсуждений, привлечение внимания руководства к выбору технологии. Основными тезисами против порталов и Liferay, в частности, были:

    • Отсутствие на рынке высоконагруженных решений на данной платформе → не выдержит нашу нагрузку;
    • Отсутствие на рынке специалистов, готовых уже завтра начать разработку → потери на поиск и обучение;
    • Разработка под несколько каналов (интернет и мобильный сегмент) будет нетривиальной и сложной → скорее всего, рядом будет написано свое отдельное решение, которое будет обходить ограничения платформы.

    И по мере разработки прототипа эти тезисы подтверждались.

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

    Так как было принято решение не отвлекать существующую команду от развития R-Connect v2, то мы стали набирать новую команду под новый проект. Поиск специалистов с опытом разработки на Liferay в Москве показал, что это не самая популярная платформа, и таких специалистов нам не найти в нужном количестве ближайшие «никогда» лет.

    С большим трудом мы нашли разработчика, который, о чудо, обладал опытом разработки под Liferay. Его опыт оказался нам полезен для доказательства последнего тезиса — в предыдущей компании они действительно написали свое кастомное решение, обходящее ограничения Liferay и стандарта JSR-186.

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

    Прототип 2: Собственная разработка


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



    В итоге у нас осталось:

    • Виджетная система.
    • Интеграция с существующей банковской CMS.
    • Современный адаптивный дизайн.

    Разработку второго прототипа начали со стеком, который был знаком команде:

    • ExtJs.
    • Spring и Java.

    Справедливости ради стоит отметить, что в качестве разработчика клиентской части выступал тот же frontend-разработчик, который участвовал в разработке первого прототипа, а в качестве разработчика серверной части выступил тот самый Java-разработчик, который пришел к нам с опытом разработки на Liferay.

    Получившийся прототип развеял опасения команды по поводу собственной разработки и мы, в очередной раз взвесив все «за» и «против», приняли итоговое решение идти по пути самостоятельной разработки.





    Безусловно, портальная технология и Liferay в частности уже «из коробки» обладают огромной функциональностью: CMS, виджеты, ролевая модель и многое другое.

    Однако без серьезных доработок всё это богатство нельзя использовать для создания публичных сервисов с претензией на уникальность. Все преимущества подобных многофункциональных технологий хитрым образом сотканы из ограничений, на которые наступали поколения программистов в попытке создать абстрактный «комбайн», и воспользоваться ими можно только в приватных корпоративных решениях со стандартными схемами по построению UI/UX. Увы, но это не наш путь.

    Стек технологий


    — У вас технологии свежие? Отсыпьте мне килограммчик

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

    Мы сделали ставку на свежие технологии, но которые уже были опробованы в корпоративном сегменте. Ниже не будет строк про реактивное программирование, микросервисы и прочее — в тот момент мы не были готовы принимать столь кардинальные изменения. Здесь речь пойдет про технологии, достаточно свежие по сравнению со Struts, на котором был возведен R-Connect v2.

    В клиентской части мы хотели видеть HTML5, CSS3 и крутой JS-фреймворк. В качестве последнего был выбран Angular в первом поколении. React был еще в глубокой бете и не подходил на роль основного фреймворка в production-использовании для серьезного продукта. ExtJS не рассматривался как кандидат вовсе, так как опыт его использования командой в рамках пилота и других проектов показал, что это библиотека с сильной корпоративной составляющей, и переделать её под нас будет сложнее и дороже, чем накрутить необходимое на современный MVC-фреймворк. Еще одним кандидатом оказался EmberJS. Его не взяли из-за чуть меньшей популярности, чем у Angular. О сложностях применения Angular в серьезных проектах написано немало статей, поэтому именно здесь «вкусности» будут пропущены. Но при наличии должного интереса у аудитории к нашим «хождениям по Angular-мукам» мы попробуем оформить это в виде отдельной статьи.

    В погоне за скоростью загрузки страницы у нас прописались обфускаторы и минимизаторы кода и, соответственно, система сборки Javascript’a Gulp. Для их работы в серверсайдном стане банка развернули Javascript-анклав — NodeJs. Такого себе еще никто в банке не позволял. Мы ожидали, что сейчас перед дверьми нашего офиса выстроятся толпы жаждущих инноваций senior’ных инженеров. Однако жизнь показала, что толпы желающих устроиться на работу в банк не возникло, даже несмотря на модные технологии.

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

    Обновки для серверной части выбирали чуть менее трепетно, так как всё было давно уже известно и соответствовало проторенным дорожкам Java-мира: свежая версия Java 8 и Spring 4. Собирать всё это богатство стали с помощью Gradle, забросив использовавшийся ранее Maven подальше.

    С набором разработчиков здесь тоже возникли проблемы, несмотря на популярность на рынке выбранных технологий. Проблема та же самая — недостаток квалификации.

    Развитие архитектуры


    Внимательный читатель, наверное, помнит, что в начале статьи я писал о том, что версия R-Connect v2 появилась путем выделения новых архитектурных слоев на EJB. Куда же мы дели эти самые EJB и почему о них больше не было ни строчки?

    Если быть кратким, то архитектура R-Connect v2 представляет собой следующую картину:

    1. Клиентские запросы принимает на себя фронтовый балансировщик. Он распределяет запросы между нодами с канальной логикой.
    2. На ноде с канальной логикой живет банальное Java веб-приложение, запущенное на Tomcat.
    3. Ноды с канальной логикой обращаются через отдельный балансировщик к нодам с бизнес-логикой, на те самые пресловутые EJB-приложения. Серверами приложений для бизнес-логики у нас выступают IBM Websphere. В слое бизнес-логики уже спрятана вся интеграционная составляющая с нашей базой данных и банковскими мастер-системами.


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

    Когда весь этот многослойный пирог разрабатывался и внедрялся, команда вдохновлялась примерами академической архитектуры по модели Java Enterprise. Какие результаты мы получили в итоге от этого решения? Не самые позитивные. Это сложность отладки кода на нескольких серверах одновременно (Tomcat + Websphere), сложность развёртывания приложений в продуктивную среду без прерывания обслуживания. Одним из преимуществ подобного многослойного пирога должно было стать удобство обновления слоев отдельно друг от друга. Но пока приложение жило и развивалось, API бизнес-логики тоже развивалось и изменялось с каждым релизом. А это значит, что для того, чтобы клиентскому коду на Java взаимодействовать с EJB, который реализовывает бизнес-логику и располагается на другом сервере, разработчику необходимо сгенерировать специальные stub-классы, заглушки для IIOP/RMI. Что в случае корпоративных решений вроде Websphere или Weblogic может быть достаточно нетривиальной задачей. Java-разработчики, имеющие дело с подобными серверами-комбайнами, меня поймут. После перегенерирования stub’ов на каждое изменение в API бизнес-слоя необходимо было пересобрать и протестировать все приложения, которые завязаны на работу с этим API, потому что изменения обратно не совместимы на уровне протокола взаимодействия с EJB. Таких приложений у нас было четыре вида, и не в каждом релизе в них появлялась какая-то новая функциональность. Но при этом каждый релиз вызывал боль у всей команды: от разработчиков, которым приходилось вносить изменения во все приложения, и тестировщиков, которые тестировали «лишние» приложения, до AppSupport, которому эти приложения приходилось устанавливать на кучу серверов.

    Когда мы начали писать новую версию нашего интернет-банка, то пересмотрели подход к архитектуре и развёртыванию с целью оставить всё самое лучшее и убрать всё самое плохое. В итоге мы отказались от Websphere и выделенных серверов с бизнес-логикой. Её мы завернули в обычную библиотеку и поместили вместе с остальными библиотеками в канальное веб-приложение.



    Само веб-приложение тоже претерпело изменение. Мы отвернулись от Struts и похожих подходов к построению интерфейса «от серверной части» и повернулись ликом к REST-подходу. Это шаг к единым сервисам для интернет и мобильного банкинга, а также задел на модную сейчас тему с OpenAPI.

    Трудности и неопределённости


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

    Разработка очень долго велась безо всяких финальных прототипов и макетов, что тоже не облегчало нам жизнь. Прототипы постоянно менялись, мы искали то, что нам полностью подойдёт: проводили исследования, пилотировали на сотрудниках, обсуждали внутри команды. И даже когда такие прототипы были созданы, это решило лишь половину проблемы — у нас всё ещё не было готовых дизайнов. Финальный дизайн появился буквально за месяц до запуска. Мы сидели ночами, переписывали, вылавливали все мелкие баги.

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

    Заключение


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

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

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

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

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

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

    Важно понимать, что ни одна система не может быть зафиксирована во времени. Если система не развивается — она умирает. Наш интернет банк продолжает жить и развиваться, поэтому у нас появляются новые технические компромиссы между скоростью внедрения функциональности и удобством дальнейшего сопровождения, мы постепенно набираем темп и обращаем внимание на передовые технологии разработки. В одной из следующих статей мы расскажем, что и как у нас поменялось в плане технологий и подходов по мере развития нашего интернет-банка.
    Райффайзенбанк 195,03
    Развеиваем мифы об IT в банках
    Поделиться публикацией
    Похожие публикации
    Комментарии 84
    • +5
      Угу, вот только у вас там выделить ничего нельзя, чтобы скопировать в буфер обмена цифры. А в банке для юр-лиц ещё хуже, вообще ничерта не скопируешь, а там часто нужно.
      Сделайте, чтобы всё можно было мышкой выделять и копировать!
      • +3
        * { user-select: all !important; -moz-user-select: all !important }
        • 0
          Скорее всего вы говорите про содержимое шапки виджетов. Там действительно нельзя ничего выделить и скопировать. Но спасибо за полезный фидбек
          • 0
            Ну, из самого очевидного (но это из банка для юрлиц) — попробуйте скопировать всю информацию (путь по полям по отдельности) о транзакции. В некоторых случаях просто не выделяется, в некоторых, при попытке выделить, сворачивается/разворачиватеся раздел и т.п. Даже сумму скопировать проблема. Это очень критично.
            В обычном интернет-банке для физлиц, я точно сейчас не скажу где такое наблюдается, т.к. редко пользуюсь, но тоже где-то было.
            • 0
              И ещё пожелание для онлайни клиента дла бизнеса — проверьте совместимость экспорта во всякие онлайн-бухгалтерии (Эльба, Моё Дело и т.п) через файл. Вы сейчас круто проигрываете Альфе в том, что у них есть интеграция с этими сервисами (при примерно прочих равных условиях для малого бизнеса) и это очень большой плюс.
              Интеграцию прикрутить, понятно, что дело не простое. Но если бы был хотя бы экспорт операций из банка через файл, то это уже было бы хорошо. И сделать это по-моему, совсем не сложно.
              Возможно, что я что-то не так делал, но с ходу ничего не получилось. У вас экспортирует во что-то очень странное, что потом мало куда загрузить можно.
          • 0
            А мобильное приложение — это ваше или это другие делают?
            • +1
              Мобильное приложение делаем тоже мы. Мы работаем и над интернет-версией, и над мобильной версией для физиков. Юриками занимается другая команда и также делает и декстоп версию и мобильную
              • НЛО прилетело и опубликовало эту надпись здесь
                • +1
                  Мобильные приложения в современном мире становятся основным каналом для большинства пользователей. Нативное приложение намного более удобно, чем адаптированный под устройства сайт. Это подтверждают как исследования рынка, так и мой собственный опыт как пользователя интернет-ресурсов.
                  Наличие еще одного канала не доставляет особых проблем, к тому же получить доступ к мобильному приложению чуть более сложнее, чем попытаться поэксплуатировать какую-нибудь XSS уязвимость на доверчивом пользователе.
                  Больше всего вопросов по безопасности возникает тогда, когда пытаешься сделать пользователю удобнее. Каждый шаг в сторону удобства и комфорта (в привычном понимании) это шаг в противоположную сторону от безопасности. Достаточно почитать комментарии к этой же статье про ДБО для юриков.
                  • 0
                    Таки да, сразу уходящий пин — немного непривычно, но иногда удобно. А r-online на хроме под андроидом отлично работает, вполне можно обойтись без мобильного приложения, только если оно не мегаудобное.
                    • 0
                      Напишите, пожалуйста, на чем пишите мобильные приложения, что используете, как часто переписываете под новые платформы/библиотеки.
                  • +1
                    Вы пробовали войти в физическое мобильное приложение по отпечатку?
                    Судя по реакции приложения — нет :)
                    Ибо на каждый такой вход мобильное приложение радостно сообщает:
                    К сожалению произошла ошибка. Пожалуйста, повторите операцию еще раз.
                    Но входит и работает.
                    • 0
                      Не имею отношения к сотрудникам Райфа, скажу за себя – у меня такая ошибка возникает с завидной регулярностью, но всё же чаще вход происходит безо всяких ошибок.
                      • 0
                        У меня в 100% случаев, причем сразу после первой установки приложения. Возможно, стоит заново подключиться, но, есть подозрение, что оно сразу должно нормально работать. Вроде никаких экстратехнологий нет.
                        • 0
                          Был момент, и после обновления ОС приложение вообще всё время выдавало ошибку («отсутствует интернет-соединение»), когда я пытался войти (причём там совсем не пускало). Мне посоветовали полностью удалить и вычистить приложение и поставить его заново. После этого проблема исчезла. Может быть, и вам поможет. А вообще Райф всё намекает на то, что вскоре будет совершенно новое приложение – жду-не дождусь, потому что нынешнее не устраивает.
                • 0
                  Помню, как много лет назад шаманил с Java-апплетом в линуксе, для подписи разных документов. С тех пор стало заметно проще :)
                  • +1

                    Так и не понял на чём в итоге написали фронт. На первом Ангуляре?

                    • 0
                      В клиентской части мы хотели видеть HTML5, CSS3 и крутой JS-фреймворк. В качестве последнего был выбран Angular в первом поколении.
                      • 0

                        Так и будете жить на устаревшей версии или планируете перейти на 4?

                      • +2
                        Да, на AngularJS. На тот момент это было лучшее решение из всех, и мы о нём не пожалели. Сейчас он уже, конечно, подустарел, поэтому мы активно переходим на Angular.
                      • 0
                        Вопрос — зачем у карт в настройках стоит изменение расчетной даты, но загрузить эту настройку интерфейс не может?
                        • +1
                          Эта функциональность пилотируется на небольшой группе пользователей и скоро станет доступен всем нашим клиентам
                          • 0
                            А что, можно будет менять длительность платежного периода, не фиксированно 21 день как сейчас? Или просто сдвигать его влево-вправо?
                            • +1
                              Сдвигать влево-вправо
                              • 0
                                Да, сегодня уже в общих условиях засветили. Запуск, судя по документу, 10 ноября. Может быть полезно тем, кому з/п после 7-го числа приходит.
                                P.S. Забавно после выходных система заблокированные суммы в списанные переводит — сначала увеличит долг, а потом только через несколько часов убирает из заблокированных (тормозит наверно). Забавно наверно пользователи на двойной долг реагируют)
                        • –1
                          В общем то ничего нового нет. Обычная жизнь java разработчиков.
                          Когда-то тоже страдал этой х… нёй, но слава богу вырвался.
                          Одно огорчило в online — запросы на yandex, google.
                          В connect этого нет.
                          И в elbrus тоже пытается на bssys, но работает вроде.
                          • +2
                            А банк для юр лиц (эльбрус) когда-нибудь станет мультиплатформенным? держать на ноуте виртуалку только для банка — напрасная трата дискового пространства. И понятно что не к вам, но вдруг знаете — когда скорость обработки платежек повысится? А то отправишь в банк и жди по полчаса…
                            • 0

                              Я кстати не знаю, как можно получать всякие ачивки 'лучший банк', когда у тебя один из самых тормозных банков многие годы подряд. Скорость проведения платежей — традиционно слабое место райфа.

                              • +1
                                Не знаю на счёт «лучшего банка», но отвечу как варящийся в этой кухне: скорость проведения платежей зависит от многих факторов. Если упрощённо, то от:
                                — скорости обработки внутренней системой банка. Не забываем про обязательные тайм-ауты на ключевых этапах.
                                — скорость обработки процессинговым центром, если речь идёт про платежи на другой банк.

                                Базово, для «простых смертных», используется «упрощённая» или «быстрая» система обработки, когда тебе говорят «эй, чувак, всё отлично, твой платёж прошёл!» и ты спокоен, а на самом деле твои средства просто блокируются и ждут перечисления на требуемые счета.

                                Для юр. лиц, на сколько я помню, обязательным условием того, что «платёж успешен» является его полная обработка внутри банка с возвращением статуса операции, т.е. по факту перечисления средств. Если речь идёт о платеже на другой банк — возврат ответа от процессинга, мол, «реквизиты верные» и отправка платежа в другой банк.

                                Так что, безусловно, скорость проведения платежей есть, где улучшать, но зачастую это упирается в смену архитектуры всей системы в целом.
                              • +1
                                А банк для юр лиц (эльбрус) когда-нибудь станет мультиплатформенным? держать на ноуте виртуалку только для банка — напрасная трата дискового пространства.


                                Прошу обратиться в отделение банка и заказать «электронную подпись через SMS». Работает в Firefox и Chrome под Linux.
                                • 0
                                  Не знал про такой вариант. А еще есть какие-то альтернативные способы? С учетом нахождения за границей и использования Mac OS?
                                  • +1
                                    Можно поступить намного проще, если вы индивидуальный предприниматель, так как не так давно в Raiffeisen Online стали доступны операции по счетам ИП.
                                    А про скорость обработки платежей в Банке мне к комментарию Alexxhn добавить нечего. На упрощенном уровне это примерно так и выглядит. Если интересно чуть более подробно посмотреть на стандартные банковские проблемы, рекомендую статью моего коллеги aBozhiev(https://habrahabr.ru/company/raiffeisenbank/blog/334242/)
                                • +4
                                  Ох, жесть жестяковая. Помню я этот лайфрей, плевались все разработчики кровью от него, такой тормознутый и жирный контейнер, но начальство продолжало настаивать.
                                  Было предложено решение на Jetty, которое было быстрее в почти три раза, но было поздно, сижу провалил всё что можно было, всех разрабатывающих под этот лайфрей разогнали. Выбрали в итоге фулстек на джаваскрипте :)
                                  Такой вот интернет банк.
                                  • +1
                                    Я надеюсь вы также обновите мобильное приложение. Текущим пользоваться просто невозможно. Каждый запуск приносит новые неприятные сюрпризы.
                                    • +1
                                      Обновим) Мы задумались об этом еще на старте Raiffeisen Online
                                    • +1
                                      А как картина про запорожцев с их непокорной, свободной жизнью и ответом на ультиматум султана связана со статьей?
                                      • 0
                                        Сугубо визуальным рядом
                                      • +1
                                        Отличный интернет-банк получился по сравнению и с коннектом, и другими банками, с которыми приходится иметь дело. Да хотя бы за то, что курсор автоматически позиционируется в поле для ввода кода из СМС — низкий вам поклон.

                                        Но вот когда вы выбросите на помойку требование о периодической смене пароля? У меня (как, надеюсь, у большинства из здесь присутствующих) он уникален для каждого ресурса, хранится в менеджере паролей и имеет длину и характеристики, некомфортные при вводе на мобильнике. Выбешивает
                                        • +1
                                          Спасибо за отзыв!
                                          Про смену пароля: мы работаем над этим
                                        • 0
                                          А liferay — да, хорошо, что не купились. У нас бухгалтерии приходится пользоваться каким-то госпорталом, который, судя по ошибкам — внутри liferay. Это ужасный ужас
                                          • +1

                                            А когда смски на русском приходить будут наконец? Транслит в 2к17 — это как-то не слишком современно.

                                            • +1
                                              Спасибо за статью, подскажите пожалуйста, как вы обеспечиваете консистентность данных между нодами логики на всех уровнях?
                                              • +1
                                                Вопрос, на самом деле, в том, что использовать в качестве хранилища данных, с которым должны работать ноды логики. Можно использовать ту же самую БД, что и для хранения операционных данных. Однако, здесь встает вопрос о скорости исполнения операций чтения/записи. Поэтому сообщество обычно рассматривает более быстродействующие варианты: in-memory data grid или distrubuted cache. То есть что-то, что позволяет обрабатывать запросы на получение данных гораздо быстрее, чем стандартная корпоративная СУБД.
                                                Мы используем Memcache для session replication стандартных веб-сессий. Остальные данные записываются в БД.
                                                • +1
                                                  Все верно, вопрос в «хранилище». И тут как правило разделяют сессионный кэш и кэш данных, которые обычно поднимаются в канал из бэков. Про сессионный понял, а вот к вопросу про остальные данные — какого рода эта БД? Если обычная реляционка, то нет ли проблем со скоростью обработки запросов и локах, если в одну таблицу собираются данные из нескольких систем-источников?
                                                  • +1
                                                    У нас реляционная БД. Проблемы с производительностью конечно же есть, поэтому мы используем локальное кеширование запросов на каждой из нод. В ближайшем будущем планируем этот кеш перенести на Memcache.
                                              • 0
                                                А у вас все-еще нельзя привязать в rbo йоту на смс вместо эцп?
                                                • +1
                                                  Попробую неофициально ответить за коллег.
                                                  ЭЦП априори более безопасный способ подтверждения операций, но из-за этого менее удобный, особенно, в российских реалиях. Чтобы хоть как-то приблизить подтверждение операций с помощью SMS у нас происходит проверка IMSI. И Yota был одним из тех операторов, по которым мы не могли получить этот идентификатор. Я бы рекомендовал времени от времени проверять возможность переключения с ЭЦП на SMS с yota'вским номером, скорее всего это либо уже доступно, либо станет доступно в ближайшем будущем.
                                                • 0
                                                  • 0
                                                    Потому что на текущий момент часть sms, как и эквивалентные им уведомления в приложении, являются частью одной и той же платной услуги.
                                                  • +1
                                                    Правильно ли я понял, что мобильное приложение ходит на тот же frontend, что и Интернет-банк?
                                                    • +1
                                                      Текущее мобильное приложение пока еще пользуется старой инфраструктурой и ходит на SOAP-сервисы, отдельные как от R-Connect, так и от Raifeisen Online. Новое приложение, по архитектурной задумке, будет использовать те же REST-сервисы, что и Raiffeisen Online.
                                                    • +1
                                                      1. Так и не понял, почему вы не взяли решение из коробки? Ведь действительно дешевле и если дока хорошая, то без проблем кастомизировать можно и самим.
                                                      2. Подскажите, сколько человек было в команде и какие позиции закрывали?
                                                      3. Мобильное приложение нативное? Или тоже на библиотеках Angular?
                                                      • +1
                                                        1. Изменять логику настройкой и изменять логику программированием — разные вещи. Опыт коллег показывает, что даже если ставишь коробку и пытаешься что-то там кастомизировать самостоятельно, то рядом с коробкой вырастает собственное решение. Это если не рассматривать вопрос лицензий и исходного кода, который не всегда доступен.
                                                          Кастомизация силами вендора долго, дорого и непрозрачно. Также нет гарантии, что твою уникальную идею/функциональность не растиражируют на остальной рынок. Все это, безусловно, можно решать договорным путем, но это, опять-таки, не добавляет удобства.
                                                        2. Суммарно команда выросла с 30-ти до 50-ти человек. Это вся команда, включая бизнес-владельцев и AppSupport. Закрывали преимущественно IT-позиции: аналитиков, разработчиков, тестировщиков. Уровень позиций был разный: от junior до senior. Позиции выше на рынке найти практически нереально, поэтому все ведущие позиции у нас занимают ребята, которые выросли внутри команды.
                                                        3. Мобильное приложение нативное. Кросс-платформенные технологии вроде Cordova или Titanium, конечно, заслуживают уважения и интереса, но пока еще не дотягивают по достоинствам до нативного приложения. Особенно, если мы можем себе позволить разработчиков под популярные платформы.

                                                      • 0
                                                        Мелочь, а неприятно — виджет имеет фиксированный размер, не всё инфо влезает, приходится переходить в нужный раздел, т.е. смысл некоторых виджетов пропадает
                                                        • +1
                                                          На старте проекта мы планировали иметь адаптивную верстку, но, по мере реализации, от этого отказались, так как у нас есть мобильные приложения под популярные платформы.
                                                          Сейчас у нас есть минимальное разрешение, которое мы поддерживаем и от которого проектируем наш UI.
                                                          Скорее всего, устройство, с которого вы используете Raiffeisen Online, обладает меньшим разрешением экрана, но возможно и другое. Если вы напишете разрешение монитора, которое у вас выставлено, либо название устройства, то станет более понятно в чем может быть проблема
                                                          • 0
                                                            В данном случае разрешение (которое 1920х1200) ни причём. Речь не о том, что виджеты не помещаются, а то, что виджет не может отобразить всё инфо по своей «рубрики», только 5 шт. Кнопочка «Следующие 5...» — издевательство, потому как выполнена логика замещения в этом же окошке текущих записей на следующие вместо добавления (=увеличения верт. размера виджета). Поэтому в вашем банке виджеты для меня — красивые, но почти бесполезные рюшечки; сразу переключаюсь на нужный раздел.
                                                            • 0
                                                              Мы уперлись в технологическое ограничение адресации на сетке, на которой располагаются виджеты
                                                        • 0
                                                          Полгода назад писал в поддержку про отсутствие в выписке по счету остатков на начало и конец периода. До сих пор не сделали. Элементарная вроде функция, в R-connect была, почему тут не можете сделать?
                                                          • +1
                                                            Подобная функциональность была в R-Connect, но мы ее оттуда удалили.
                                                            По этой задаче даже были архитектурные споры о том, кто должен это считать: интернет-банкинг или бэк-офис.
                                                            Могу лишь сказать, что в одном из будущих релизов мы реализуем эту возможность.
                                                          • +1
                                                            Я где-то на полгода отказался от использования новой версии, потому что были детские проблемы, а поддержка просила всё подробно описывать, чуть ли не видео снимать. Простые описания проблем не принимались. Например, в выписке нет переводов на телефон или сумма расходов в шапке не совпадает с итогом по выписке из-за разницы в датах транзакций/списаний. Сейчас почти всё устраивает, и вместе с новыми функциями, стало лучше.
                                                            Пожелания:
                                                            1. Отказаться от требования смены пароля (уже просили выше, присоединяюсь).
                                                            2. Подтвержденные sms-кодом 1 раз шаблоны операций (тот же перевод на сотовый) исполнять уже без подтверждений (как мошенник может украсть мои деньги, переводя их на мой телефон по подтвержденному шаблону?).
                                                            3. Перестать делать баннеры на входе, которые нельзя отключить раз и навсегда (реклама о возможности переводить по № телефона и e-mail'у, реклама переводов между картами).
                                                            4. Сделать по-возможности облегченную версию, т.к. при медленном интернете в браузере на планшете старая версия работала, а вот новая — вряд ли.
                                                            Претензии:
                                                            1. Почему в стандартной выписке видны неподтвержденные транзакции по карте, а в периодической нет?
                                                            2. Почему Raiffesen Connect на андроид требует столько разрешений (особенно доступ к камере и контактам)? Почему постоянно работают службы определения местоположения и перезапускаются после остановки?
                                                            3. Raiffesen Connect на андроид очень часто ругается на отсутствие соединения (когда любые другие приложения работают) и очень плохо работают push-подтверждения операций, а sms-подтверждения невозможны.
                                                            • +1
                                                              Спасибо за отзыв!
                                                              По пожеланиям:
                                                              2. Подтвержденные шаблоны подтверждаются одноразовым паролем один раз. После этого для оплаты подтверждения паролем не требуется. Мы лишь сделали небольшую защиту пользователей от самих же себя с помощью подтверждения операции еще одной кнопкой, чтобы пользователь не совершал платежей по ошибке, например, если промахнулся мимо нужного шаблона. Платежи у клиентов настроены на разные суммы: у одного это может быть пополнение на 50 рублей, а у другого — на 50 000 рублей. Мы сами попадались в ловушку сверхбыстрых платежей на этапе пилотирования функционала внутри команды.
                                                              3. Соглашусь, что реклама всегда преимущественно раздражает, чем радует. Но у бизнеса тоже есть свои потребности, которые требуется удовлетворять. Мы подумаем, как сделать эту рекламу более полезной и менее назойливой.
                                                              4. Мы работаем над оптимизацией скорости работы.
                                                              По претензиям:
                                                              1. Это известный нам дефект, мы работаем над его устранением
                                                              2. Мобильное приложение обладает возможностями, в которых задействованы как камера (оплата платежек ряда организаций по штрих/QR-коду), так и контакты (подстановка номера телефона из списка контактов для пополнения баланса через оплату услуг). Службы определения местоположения используются для геофенсинга — функциональности по предложениям от партнеров банка по скидкам в зависимости от близости точки, в которой эту скидку можно получить.
                                                              3. Мы знаем об этой проблеме и работаем над ее устранением.

                                                              • +1
                                                                Спасибо за ответ!
                                                                Пожелание 2. Честно говоря не видел, что появилась такая возможность. Я имел ввиду, что у вас при оплате по шаблону всё равно требуется каждый раз подтверждать sms-кодом. А оказывается уже есть «Подтвержденные шаблоны» — то что мне нужно.
                                                                Претензия 2. Вы вроде всё по делу ответили, кто-то из клиентов этим всем, возможно, пользуется, а я нет. Разве что определение местоположения для меня понятно для банковской программы — поиск банкоматов поблизости, но почему она работает не только при запущенном приложении? Мой внутренний параноик в ужасе от всего этого «шпионского функционала». К сожалению, у других банк-клиентов похожие наборы разрешений.
                                                              • 0
                                                                Совсем забыл добавить: если вы имеете отношение к личному кабинету «Райффайзен-Всё сразу», то, пожалуйста, уберите Google-капчу с логина, задалбывает по три раза машины помечать.
                                                              • +1
                                                                Вот и разработчики. Может вы ответите на вопрос, с какого перепугу множества символов пароля ограничено, в частности, символ "_" (нижнее подчёркивание) является «недопустимым»? Какое ваше дело, что я ввожу в поле «пароль»?
                                                                На андроиде вообще кривое приложение, которое мало того, что глючит постоянно (отсутствует соединение), так ещё и дезинформирует пользователя (из банка прислали письмо, в котором говорится, что мобильное приложение работает некорректно и не отражает нужной информации по кредитке с грейсом, «пользуйтесь браузерной версией»).
                                                                В общем, много детских болячек, которые при наличии адекватной обратной связи давно могли бы быть излечены, подозреваю, что до разработчика эти баги просто не доходят.
                                                                • +1
                                                                  Требования к символам пароля связаны с проблемой поддержания консистентности данных между старой и новой платформой. Как только у нас останется в эксплуатации только новая платформа, так нам сразу станет гораздо проще поддерживать решение, а пользователям им пользоваться.
                                                                  • 0
                                                                    А про корректность отображаемой информации? Это когда планируете поправить?
                                                                    • 0
                                                                      Ошибки мобильного приложения исправляются, сейчас, возможно, не с той скоростью, с которой бы нам хотелось. В том числе и поэтому поддержка новых продукты банка идет с некоторой задержкой
                                                                      • 0
                                                                        Может подрядчику отдать мобильную разработку?
                                                                • 0
                                                                  Удалось ли вам в итоге сделать легкое «обновление приложений без прерывания в обслуживании»?
                                                                  • 0
                                                                    Мы и на старой архитектуре выкатывались без перерывов, сейчас же обновление стало заметно проще, так как убрали лишний балансер и слой серверов
                                                                  • 0
                                                                    Ну зря вы так про Liferay. Система сложная — но при правильном подходе может многое. Просто как и с любой сложной системой ее надо «уметь готовить» (порог входа по моим ощущениям минимум 6 месяцев). Жаль когда изучали идею про Liferay до нас не дошли — мы внедряем Liferay уже 8 лет — и есть примеры и высоконагруженных систем (с аптаймом 100%) и примеры в финсекторе (банки, страховые) — разные примеры бы показали.

                                                                    Почему у вас возникла мысль про Liferay? Возможно потому что он активно используется в Райфе в Восточной Европе (с ходу о ком знаю и кого можно нарыть в публичном доступе — Венгрия, Чехия, Хорватия) — видимо оттуда ветром и принесло идею.
                                                                    • 0
                                                                      Основные причины почему не выбрали Liferay и портальные технологии я описал в статье.
                                                                      Я не говорю, что это «ужасная поделка» и бежать от нее надо не оглядываясь)
                                                                      Нам показалось, что в нашем случае она мало подходит и добавит больше проблем, чем преимуществ. Почему смотрели именно Liferay, а не JBoss'овский портал я сейчас уже не вспомню.
                                                                      А вот высоконагруженные системы с претензией на современный дизайн, выполненные на Liferay, я бы посмотрел.
                                                                      • 0
                                                                        У нас был как раз опыт, когда компании делали сначала B2C сами, но потом переходили на портал. Можно самим разработать удобные инструменты работы с продуктами (и такие инструменты никакой портал из коробки не даст — тут в любом случае придется делать) — но потом приходит маркетинг и говорит «А вот тут я хочу разместить банер, а еще — добавьте здесь новую страницу с промо-контентом». Понятно что при правильных инструментах разработки и прямых руках это разрабатывается/добавляется в проект за пару часов — но это все равно разработка — соответственно появляется куча шагов (проработка тз, постановка задачи, сама разработка, деплой и тестирование на несколько сред и пр.) — а портал со встроенными средствами управления контента дает возможность делать это средствами «администрирования» — не привлекая разработку.
                                                                        Ну и, учитывая что можно делать разработку и внедрение каждого «инструмента» отдельно — по сути дела реализуется паттерн «микросервисов» — но с точки зрения UI — когда, например, обновление инструмента работы с депозитами можно проводить не затрагивая все другие инструменты.
                                                                        Про пример «претензии» на дизайн и высокой нагрузки — из того что доступно в паблике — www.yota.ru

                                                                        • 0

                                                                          Но на самом деле что я про лайфрей и лайфрей. Как давний клиент Райфа могу сказать что новый кабинет это огромный прыжок вперед! Приятно видеть что к его разработке подходили с умом!

                                                                  • 0
                                                                    Вопрос касательно безопасности. В онлайн-банке зеленого банка, при всей его кривизне, в принципе невозможно залогиниться без двухфакторной смс-аутентификации, в то время как Райффазен-Онлайн радостно пускает кого угодно по сохраненному в браузере паролю. Понятно дело, что для операций смс-подтверждение будет необходимо, но информация о состоянии счетов все-таки доступна и без этого. Не могу сказать, стоит ли это считать прямо «брешью в безопасности», но как-то некомфортно.
                                                                    • 0
                                                                      В Raiffeisen Online уже давно существует возможность входа по смс. Эта функция по умолчанию выключена, так как не всем пользователям нравится совершать дополнительные действия. Однако, ее можно включить через настройки.
                                                                      • 0
                                                                        Действительно опция есть, только немного неоднозначно называется, поэтому сразу не обратил на нее внимания. Спасибо.
                                                                    • 0
                                                                      Несколько дней назад в ИБ перестало срабатывать пополнение (стягивание) с других карт. Сегодня гениальный ответ ТП:
                                                                      "По имеющимся у нас данным перевод с карты стороннего банка произведен успешно".
                                                                      И прикол в том, что в МБ отображаются какие угодно шаблоны, кроме шаблона на стягивание! Теперь каждый раз, чтобы пополнить карту, сижу с телефончиком перед компом и перебиваю с экрана много циферок. Спасибо за приложение по тренировке пальцев!
                                                                      • 0
                                                                        vadimpl, шаблоны на пополнение с внешних карт очень скоро появятся в МБ. А пока мы его делаем, Вы можете воспользоваться ИБ — там шаблоны отлично работают. Приносим извинения за неудобства.
                                                                        • 0
                                                                          По поводу неработоспособности стягивания в ИБ — сам дурак стороннее приложение виновато. Обновился AdGuard, он расценивает всплывающее окно ввода пароля из СМС как рекламное и схлопывает его. В ТП AdGuard уже отписался.
                                                                      • 0
                                                                        Уже столкнулся с новой версией, правда дальше авторизации дело не проходит. Пришло письмо: «Просим зайти в новую систему до 11 ноября… бла-бла-бла». Не вопрос, логин и пароль от старой версии внезапно не работают, жмём сбросить, проходим все шаги, вводим пароль из смс — неправильно, пробуем несколько раз с тем же результатом и получаем «ждите 30 минут для следующей попытки...» ну это дело в Райфайзен исправимое, чистим куки и все опять можно. Звонок в поддержку, описываю ситуацию и внезапно: «У вас введённое вами имя пользователя, они по умолчанию в новую систему не переносятся, нам надо до 72 часов на исправление ситуации с вашим аккаунтом». Это вообще как??? Сложно ещё одно поле скопировать? Или пришлите мне его смс на номер телефона после подтверждения вместе с паролем или сообщите по телефону или хоть что-то сделайте раз ваш косяк, но нет. Сидите и ждите пока поправим без доступа к банку
                                                                        • 0
                                                                          Товарищи! С «чёрной» пятницы ИБ и приложение крайне нестабильны, соединение и сервер ошибки возвращают через раз, причем похоже, очень у многих, читайте форум известно где. Почините уже что ли, пятница-то закончилась.
                                                                          • 0
                                                                            Всю неделю ползал, теперь вообще лёг.

                                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                            Самое читаемое