Интернет-банк уже давно превратился из роскоши в 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 представляет собой следующую картину:
- Клиентские запросы принимает на себя фронтовый балансировщик. Он распределяет запросы между нодами с канальной логикой.
- На ноде с канальной логикой живет банальное Java веб-приложение, запущенное на Tomcat.
- Ноды с канальной логикой обращаются через отдельный балансировщик к нодам с бизнес-логикой, на те самые пресловутые 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 и справочники в базе данных. Существенно увеличилась скорость разработки более сложных задач за счет более подходящей архитектуры и меньших технологических проблем.
Но это и так понятно. Проекты, которые подразумевают серьезный рефакторинг, обычно реализуются с прицелом на увеличение скорости поставки функциональности до конечного клиента и снижения ее себестоимости. Какие же еще можно сделать выводы из сказанного?
Вывод первый — не бойтесь экспериментировать и тратить время на исследования. Не всегда то, что на первый взгляд кажется идеально подходящим под ваши задачи, таковым является.
Вывод второй — прислушивайтесь к мнению коллег. Здравая мысль может прийти от любого члена команды. Менеджеру очень легко оставить незамеченным то, что вынуждает его откатиться на несколько шагов назад от намеченной цели. Очень сложно признать, что проделанная работа была сделана не в том направлении, а время и деньги потрачены зря. Важно помнить, что не у всех в команде может оказаться достаточно сил, чтобы отстоять свою точку зрения и не отступиться перед давлением менеджмента и более опытных коллег.
Вывод третий — популярность технологии не гарантирует наличие на рынке необходимого количества специалистов хорошего уровня. Как я уже упоминал, трудно было найти подходящих специалистов, поэтому не получалось сразу нарастить команду, которая могла быстро и качественно реализовать проект с нужным темпом. На рынке вообще оказалось очень мало специалистов нужного уровня, потому что хорошие специалисты обычно не ищут работу. А нанимать недостаточно квалифицированных людей накладно, потому что приходится отвлекать для помощи им других членов команды, что может вообще снизить скорость работ.
Вывод четвертый — академический подход к архитектуре не всегда полезен. Избыточное количество звеньев в архитектурной цепочке только добавляет проблем в разработке и поддержке решения.
Важно понимать, что ни одна система не может быть зафиксирована во времени. Если система не развивается — она умирает. Наш интернет банк продолжает жить и развиваться, поэтому у нас появляются новые технические компромиссы между скоростью внедрения функциональности и удобством дальнейшего сопровождения, мы постепенно набираем темп и обращаем внимание на передовые технологии разработки. В одной из следующих статей мы расскажем, что и как у нас поменялось в плане технологий и подходов по мере развития нашего интернет-банка.
Комментарии (63)
o4karek
24.10.2017 16:45А мобильное приложение — это ваше или это другие делают?
donskov-s Автор
25.10.2017 11:07Мобильное приложение делаем тоже мы. Мы работаем и над интернет-версией, и над мобильной версией для физиков. Юриками занимается другая команда и также делает и декстоп версию и мобильную
Dmitry_7
25.10.2017 12:28Зачем вообще нужно мобильное приложение? Лишний вектор уязвимости
donskov-s Автор
25.10.2017 12:46Мобильные приложения в современном мире становятся основным каналом для большинства пользователей. Нативное приложение намного более удобно, чем адаптированный под устройства сайт. Это подтверждают как исследования рынка, так и мой собственный опыт как пользователя интернет-ресурсов.
Наличие еще одного канала не доставляет особых проблем, к тому же получить доступ к мобильному приложению чуть более сложнее, чем попытаться поэксплуатировать какую-нибудь XSS уязвимость на доверчивом пользователе.
Больше всего вопросов по безопасности возникает тогда, когда пытаешься сделать пользователю удобнее. Каждый шаг в сторону удобства и комфорта (в привычном понимании) это шаг в противоположную сторону от безопасности. Достаточно почитать комментарии к этой же статье про ДБО для юриков.Jecky
25.10.2017 13:38Таки да, сразу уходящий пин — немного непривычно, но иногда удобно. А r-online на хроме под андроидом отлично работает, вполне можно обойтись без мобильного приложения, только если оно не мегаудобное.
Jecky
25.10.2017 13:40Напишите, пожалуйста, на чем пишите мобильные приложения, что используете, как часто переписываете под новые платформы/библиотеки.
o4karek
25.10.2017 12:46Вы пробовали войти в физическое мобильное приложение по отпечатку?
Судя по реакции приложения — нет :)
Ибо на каждый такой вход мобильное приложение радостно сообщает:
К сожалению произошла ошибка. Пожалуйста, повторите операцию еще раз.
Но входит и работает.
dmitryrf
24.10.2017 17:03+1Помню, как много лет назад шаманил с Java-апплетом в линуксе, для подписи разных документов. С тех пор стало заметно проще :)
x893
24.10.2017 19:39В общем то ничего нового нет. Обычная жизнь java разработчиков.
Когда-то тоже страдал этой х… нёй, но слава богу вырвался.
Одно огорчило в online — запросы на yandex, google.
В connect этого нет.
И в elbrus тоже пытается на bssys, но работает вроде.
MAXXL
24.10.2017 19:58А банк для юр лиц (эльбрус) когда-нибудь станет мультиплатформенным? держать на ноуте виртуалку только для банка — напрасная трата дискового пространства. И понятно что не к вам, но вдруг знаете — когда скорость обработки платежек повысится? А то отправишь в банк и жди по полчаса…
questor
25.10.2017 10:11Я кстати не знаю, как можно получать всякие ачивки 'лучший банк', когда у тебя один из самых тормозных банков многие годы подряд. Скорость проведения платежей — традиционно слабое место райфа.
Alexxhn
25.10.2017 11:27Не знаю на счёт «лучшего банка», но отвечу как варящийся в этой кухне: скорость проведения платежей зависит от многих факторов. Если упрощённо, то от:
— скорости обработки внутренней системой банка. Не забываем про обязательные тайм-ауты на ключевых этапах.
— скорость обработки процессинговым центром, если речь идёт про платежи на другой банк.
Базово, для «простых смертных», используется «упрощённая» или «быстрая» система обработки, когда тебе говорят «эй, чувак, всё отлично, твой платёж прошёл!» и ты спокоен, а на самом деле твои средства просто блокируются и ждут перечисления на требуемые счета.
Для юр. лиц, на сколько я помню, обязательным условием того, что «платёж успешен» является его полная обработка внутри банка с возвращением статуса операции, т.е. по факту перечисления средств. Если речь идёт о платеже на другой банк — возврат ответа от процессинга, мол, «реквизиты верные» и отправка платежа в другой банк.
Так что, безусловно, скорость проведения платежей есть, где улучшать, но зачастую это упирается в смену архитектуры всей системы в целом.
AEP
25.10.2017 15:30А банк для юр лиц (эльбрус) когда-нибудь станет мультиплатформенным? держать на ноуте виртуалку только для банка — напрасная трата дискового пространства.
Прошу обратиться в отделение банка и заказать «электронную подпись через SMS». Работает в Firefox и Chrome под Linux.MAXXL
25.10.2017 15:44Не знал про такой вариант. А еще есть какие-то альтернативные способы? С учетом нахождения за границей и использования Mac OS?
donskov-s Автор
25.10.2017 15:53Можно поступить намного проще, если вы индивидуальный предприниматель, так как не так давно в Raiffeisen Online стали доступны операции по счетам ИП.
А про скорость обработки платежей в Банке мне к комментарию Alexxhn добавить нечего. На упрощенном уровне это примерно так и выглядит. Если интересно чуть более подробно посмотреть на стандартные банковские проблемы, рекомендую статью моего коллеги aBozhiev(https://habrahabr.ru/company/raiffeisenbank/blog/334242/)
jbubsk
24.10.2017 20:05Ох, жесть жестяковая. Помню я этот лайфрей, плевались все разработчики кровью от него, такой тормознутый и жирный контейнер, но начальство продолжало настаивать.
Было предложено решение на Jetty, которое было быстрее в почти три раза, но было поздно, сижу провалил всё что можно было, всех разрабатывающих под этот лайфрей разогнали. Выбрали в итоге фулстек на джаваскрипте :)
Такой вот интернет банк.
pred8or
25.10.2017 12:18Отличный интернет-банк получился по сравнению и с коннектом, и другими банками, с которыми приходится иметь дело. Да хотя бы за то, что курсор автоматически позиционируется в поле для ввода кода из СМС — низкий вам поклон.
Но вот когда вы выбросите на помойку требование о периодической смене пароля? У меня (как, надеюсь, у большинства из здесь присутствующих) он уникален для каждого ресурса, хранится в менеджере паролей и имеет длину и характеристики, некомфортные при вводе на мобильнике. Выбешивает
pred8or
25.10.2017 12:21А liferay — да, хорошо, что не купились. У нас бухгалтерии приходится пользоваться каким-то госпорталом, который, судя по ошибкам — внутри liferay. Это ужасный ужас
Mehdzor
25.10.2017 12:52А когда смски на русском приходить будут наконец? Транслит в 2к17 — это как-то не слишком современно.
vialz
25.10.2017 14:25Спасибо за статью, подскажите пожалуйста, как вы обеспечиваете консистентность данных между нодами логики на всех уровнях?
donskov-s Автор
25.10.2017 14:40Вопрос, на самом деле, в том, что использовать в качестве хранилища данных, с которым должны работать ноды логики. Можно использовать ту же самую БД, что и для хранения операционных данных. Однако, здесь встает вопрос о скорости исполнения операций чтения/записи. Поэтому сообщество обычно рассматривает более быстродействующие варианты: in-memory data grid или distrubuted cache. То есть что-то, что позволяет обрабатывать запросы на получение данных гораздо быстрее, чем стандартная корпоративная СУБД.
Мы используем Memcache для session replication стандартных веб-сессий. Остальные данные записываются в БД.vialz
25.10.2017 16:31Все верно, вопрос в «хранилище». И тут как правило разделяют сессионный кэш и кэш данных, которые обычно поднимаются в канал из бэков. Про сессионный понял, а вот к вопросу про остальные данные — какого рода эта БД? Если обычная реляционка, то нет ли проблем со скоростью обработки запросов и локах, если в одну таблицу собираются данные из нескольких систем-источников?
donskov-s Автор
26.10.2017 13:49У нас реляционная БД. Проблемы с производительностью конечно же есть, поэтому мы используем локальное кеширование запросов на каждой из нод. В ближайшем будущем планируем этот кеш перенести на Memcache.
fufar
25.10.2017 15:54А у вас все-еще нельзя привязать в rbo йоту на смс вместо эцп?
donskov-s Автор
25.10.2017 16:04Попробую неофициально ответить за коллег.
ЭЦП априори более безопасный способ подтверждения операций, но из-за этого менее удобный, особенно, в российских реалиях. Чтобы хоть как-то приблизить подтверждение операций с помощью SMS у нас происходит проверка IMSI. И Yota был одним из тех операторов, по которым мы не могли получить этот идентификатор. Я бы рекомендовал времени от времени проверять возможность переключения с ЭЦП на SMS с yota'вским номером, скорее всего это либо уже доступно, либо станет доступно в ближайшем будущем.
sergey-b
25.10.2017 22:04Правильно ли я понял, что мобильное приложение ходит на тот же frontend, что и Интернет-банк?
donskov-s Автор
26.10.2017 11:34Текущее мобильное приложение пока еще пользуется старой инфраструктурой и ходит на SOAP-сервисы, отдельные как от R-Connect, так и от Raifeisen Online. Новое приложение, по архитектурной задумке, будет использовать те же REST-сервисы, что и Raiffeisen Online.
adrear
26.10.2017 11:471. Так и не понял, почему вы не взяли решение из коробки? Ведь действительно дешевле и если дока хорошая, то без проблем кастомизировать можно и самим.
2. Подскажите, сколько человек было в команде и какие позиции закрывали?
3. Мобильное приложение нативное? Или тоже на библиотеках Angular?donskov-s Автор
26.10.2017 12:57- Изменять логику настройкой и изменять логику программированием — разные вещи. Опыт коллег показывает, что даже если ставишь коробку и пытаешься что-то там кастомизировать самостоятельно, то рядом с коробкой вырастает собственное решение. Это если не рассматривать вопрос лицензий и исходного кода, который не всегда доступен.
Кастомизация силами вендора долго, дорого и непрозрачно. Также нет гарантии, что твою уникальную идею/функциональность не растиражируют на остальной рынок. Все это, безусловно, можно решать договорным путем, но это, опять-таки, не добавляет удобства. - Суммарно команда выросла с 30-ти до 50-ти человек. Это вся команда, включая бизнес-владельцев и AppSupport. Закрывали преимущественно IT-позиции: аналитиков, разработчиков, тестировщиков. Уровень позиций был разный: от junior до senior. Позиции выше на рынке найти практически нереально, поэтому все ведущие позиции у нас занимают ребята, которые выросли внутри команды.
- Мобильное приложение нативное. Кросс-платформенные технологии вроде Cordova или Titanium, конечно, заслуживают уважения и интереса, но пока еще не дотягивают по достоинствам до нативного приложения. Особенно, если мы можем себе позволить разработчиков под популярные платформы.
- Изменять логику настройкой и изменять логику программированием — разные вещи. Опыт коллег показывает, что даже если ставишь коробку и пытаешься что-то там кастомизировать самостоятельно, то рядом с коробкой вырастает собственное решение. Это если не рассматривать вопрос лицензий и исходного кода, который не всегда доступен.
vadimpl
26.10.2017 13:08Мелочь, а неприятно — виджет имеет фиксированный размер, не всё инфо влезает, приходится переходить в нужный раздел, т.е. смысл некоторых виджетов пропадает
donskov-s Автор
26.10.2017 13:15На старте проекта мы планировали иметь адаптивную верстку, но, по мере реализации, от этого отказались, так как у нас есть мобильные приложения под популярные платформы.
Сейчас у нас есть минимальное разрешение, которое мы поддерживаем и от которого проектируем наш UI.
Скорее всего, устройство, с которого вы используете Raiffeisen Online, обладает меньшим разрешением экрана, но возможно и другое. Если вы напишете разрешение монитора, которое у вас выставлено, либо название устройства, то станет более понятно в чем может быть проблемаvadimpl
26.10.2017 14:00В данном случае разрешение (которое 1920х1200) ни причём. Речь не о том, что виджеты не помещаются, а то, что виджет не может отобразить всё инфо по своей «рубрики», только 5 шт. Кнопочка «Следующие 5...» — издевательство, потому как выполнена логика замещения в этом же окошке текущих записей на следующие вместо добавления (=увеличения верт. размера виджета). Поэтому в вашем банке виджеты для меня — красивые, но почти бесполезные рюшечки; сразу переключаюсь на нужный раздел.
yuribuslaev
26.10.2017 14:37Полгода назад писал в поддержку про отсутствие в выписке по счету остатков на начало и конец периода. До сих пор не сделали. Элементарная вроде функция, в R-connect была, почему тут не можете сделать?
donskov-s Автор
26.10.2017 14:44Подобная функциональность была в R-Connect, но мы ее оттуда удалили.
По этой задаче даже были архитектурные споры о том, кто должен это считать: интернет-банкинг или бэк-офис.
Могу лишь сказать, что в одном из будущих релизов мы реализуем эту возможность.
Batiskaf_stv
26.10.2017 14:52Я где-то на полгода отказался от использования новой версии, потому что были детские проблемы, а поддержка просила всё подробно описывать, чуть ли не видео снимать. Простые описания проблем не принимались. Например, в выписке нет переводов на телефон или сумма расходов в шапке не совпадает с итогом по выписке из-за разницы в датах транзакций/списаний. Сейчас почти всё устраивает, и вместе с новыми функциями, стало лучше.
Пожелания:
1. Отказаться от требования смены пароля (уже просили выше, присоединяюсь).
2. Подтвержденные sms-кодом 1 раз шаблоны операций (тот же перевод на сотовый) исполнять уже без подтверждений (как мошенник может украсть мои деньги, переводя их на мой телефон по подтвержденному шаблону?).
3. Перестать делать баннеры на входе, которые нельзя отключить раз и навсегда (реклама о возможности переводить по № телефона и e-mail'у, реклама переводов между картами).
4. Сделать по-возможности облегченную версию, т.к. при медленном интернете в браузере на планшете старая версия работала, а вот новая — вряд ли.
Претензии:
1. Почему в стандартной выписке видны неподтвержденные транзакции по карте, а в периодической нет?
2. Почему Raiffesen Connect на андроид требует столько разрешений (особенно доступ к камере и контактам)? Почему постоянно работают службы определения местоположения и перезапускаются после остановки?
3. Raiffesen Connect на андроид очень часто ругается на отсутствие соединения (когда любые другие приложения работают) и очень плохо работают push-подтверждения операций, а sms-подтверждения невозможны.donskov-s Автор
26.10.2017 16:36Спасибо за отзыв!
По пожеланиям:
2. Подтвержденные шаблоны подтверждаются одноразовым паролем один раз. После этого для оплаты подтверждения паролем не требуется. Мы лишь сделали небольшую защиту пользователей от самих же себя с помощью подтверждения операции еще одной кнопкой, чтобы пользователь не совершал платежей по ошибке, например, если промахнулся мимо нужного шаблона. Платежи у клиентов настроены на разные суммы: у одного это может быть пополнение на 50 рублей, а у другого — на 50 000 рублей. Мы сами попадались в ловушку сверхбыстрых платежей на этапе пилотирования функционала внутри команды.
3. Соглашусь, что реклама всегда преимущественно раздражает, чем радует. Но у бизнеса тоже есть свои потребности, которые требуется удовлетворять. Мы подумаем, как сделать эту рекламу более полезной и менее назойливой.
4. Мы работаем над оптимизацией скорости работы.
По претензиям:
- Это известный нам дефект, мы работаем над его устранением
- Мобильное приложение обладает возможностями, в которых задействованы как камера (оплата платежек ряда организаций по штрих/QR-коду), так и контакты (подстановка номера телефона из списка контактов для пополнения баланса через оплату услуг). Службы определения местоположения используются для геофенсинга — функциональности по предложениям от партнеров банка по скидкам в зависимости от близости точки, в которой эту скидку можно получить.
- Мы знаем об этой проблеме и работаем над ее устранением.
Batiskaf_stv
26.10.2017 17:02Спасибо за ответ!
Пожелание 2. Честно говоря не видел, что появилась такая возможность. Я имел ввиду, что у вас при оплате по шаблону всё равно требуется каждый раз подтверждать sms-кодом. А оказывается уже есть «Подтвержденные шаблоны» — то что мне нужно.
Претензия 2. Вы вроде всё по делу ответили, кто-то из клиентов этим всем, возможно, пользуется, а я нет. Разве что определение местоположения для меня понятно для банковской программы — поиск банкоматов поблизости, но почему она работает не только при запущенном приложении? Мой внутренний параноик в ужасе от всего этого «шпионского функционала». К сожалению, у других банк-клиентов похожие наборы разрешений.
Batiskaf_stv
27.10.2017 14:43Совсем забыл добавить: если вы имеете отношение к личному кабинету «Райффайзен-Всё сразу», то, пожалуйста, уберите Google-капчу с логина, задалбывает по три раза машины помечать.
uncle_dima
26.10.2017 16:41Вот и разработчики. Может вы ответите на вопрос, с какого перепугу множества символов пароля ограничено, в частности, символ "_" (нижнее подчёркивание) является «недопустимым»? Какое ваше дело, что я ввожу в поле «пароль»?
На андроиде вообще кривое приложение, которое мало того, что глючит постоянно (отсутствует соединение), так ещё и дезинформирует пользователя (из банка прислали письмо, в котором говорится, что мобильное приложение работает некорректно и не отражает нужной информации по кредитке с грейсом, «пользуйтесь браузерной версией»).
В общем, много детских болячек, которые при наличии адекватной обратной связи давно могли бы быть излечены, подозреваю, что до разработчика эти баги просто не доходят.donskov-s Автор
26.10.2017 16:47Требования к символам пароля связаны с проблемой поддержания консистентности данных между старой и новой платформой. Как только у нас останется в эксплуатации только новая платформа, так нам сразу станет гораздо проще поддерживать решение, а пользователям им пользоваться.
uncle_dima
27.10.2017 16:15А про корректность отображаемой информации? Это когда планируете поправить?
Sap_ru
Угу, вот только у вас там выделить ничего нельзя, чтобы скопировать в буфер обмена цифры. А в банке для юр-лиц ещё хуже, вообще ничерта не скопируешь, а там часто нужно.
Сделайте, чтобы всё можно было мышкой выделять и копировать!
a553
donskov-s Автор
Скорее всего вы говорите про содержимое шапки виджетов. Там действительно нельзя ничего выделить и скопировать. Но спасибо за полезный фидбек
Sap_ru
Ну, из самого очевидного (но это из банка для юрлиц) — попробуйте скопировать всю информацию (путь по полям по отдельности) о транзакции. В некоторых случаях просто не выделяется, в некоторых, при попытке выделить, сворачивается/разворачиватеся раздел и т.п. Даже сумму скопировать проблема. Это очень критично.
В обычном интернет-банке для физлиц, я точно сейчас не скажу где такое наблюдается, т.к. редко пользуюсь, но тоже где-то было.
Sap_ru
И ещё пожелание для онлайни клиента дла бизнеса — проверьте совместимость экспорта во всякие онлайн-бухгалтерии (Эльба, Моё Дело и т.п) через файл. Вы сейчас круто проигрываете Альфе в том, что у них есть интеграция с этими сервисами (при примерно прочих равных условиях для малого бизнеса) и это очень большой плюс.
Интеграцию прикрутить, понятно, что дело не простое. Но если бы был хотя бы экспорт операций из банка через файл, то это уже было бы хорошо. И сделать это по-моему, совсем не сложно.
Возможно, что я что-то не так делал, но с ходу ничего не получилось. У вас экспортирует во что-то очень странное, что потом мало куда загрузить можно.