Своя платежная система бизнес план

Своя платежная система бизнес план thumbnail

Привет, Хабр! Мы в RBKmoney новый платежный процессинг написали. С нуля. Ну не мечта ли?

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

Мы расскажем, как написали весь процессинг RBKmoney Payments, так мы его назвали. Как делали его устойчивым к нагрузкам и сбоям оборудования, как придумали возможность его практически линейного горизонтального масштабирования.

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

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

Disclaimer

Со дня последней публикации в нашем блоге прошло ни много ни мало 5 лет. За это время наша команда разработки заметно обновилась, у руля компании теперь новые люди.

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

Суровая реальность такова, что за платежным процессингом находятся платежные организации, вовсе не с распростертыми объятиями принимающие такой трафик, а иногда даже просящие “присылать нам не более 3 запросов в секунду”. А на интерфейсы смотрят люди, которые, может быть, впервые в интернете решились что-то оплатить. И любой косяк UX, непонятность и задержка — это повод запаниковать.

Корзина, в которую можно положить покупки даже во время торнадо

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

Подход звучит знакомо, не так ли?

Да, мы вдохновлялись концепцией, описанной в Amazon Dynamo Paper. Парни из Амазона тоже строили все так, что пользователь должен иметь возможность положить книжку в корзину, какая бы жуть ни творилась по ту сторону его монитора.

Конечно, мы не нарушаем законы физики и не придумали как опровергнуть CAP-теорему. Не факт, что платеж тут же и проведется — ведь могут быть неполадки и на стороне банков, но запрос сервис создаст, и пользователь увидит, что все сработало. Да и нам до идеала еще десяток листингов беклога с техническим долгом, чего греха таить, можем и 504 ответить изредка.

Заглянем в бункер, раз торнадо за окном

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

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

Сами приложения у нас крутятся в Docker-контейнерах, логи из которых мы надежно сливаем в центральное Elasticsearch-хранилище; друг друга они находят через Service Discovery, а данные передают по IPv6 внутри Макросервиса.

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

За порядком приглядывает SaltStack, в котором описано все состояние Макросервиса.

Мы еще вернемся с подробным описанием всего этого хозяйства.

С приложениями легче.

А вот если хранить где-то состояние, то обязательно в такой базе, в которой минимальна цена выхода из строя части нод. Еще чтобы в ней не было мастер-нод с данными. Чтобы могла с предсказуемым временем ожидания на запросы отвечать. Это тут мечтают? Тогда еще чтобы ее обслуживать особо не надо было, и чтобы разработчикам-эрлангистам нравилась.

Читайте также:  Бизнес план по проведению конференций

Да, разве мы еще не сказали, что вся онлайн-часть нашего процессинга на Эрланге написана?

Как многие уже, наверное, догадались выбора у нас как такового и не было.

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

Где деньги, Лебовски?

Если взять бесконечное количество денег, возможно, удастся построить бесконечно надежный процессинг. Но это не точно. Да и денег нам особо не выделили. В аккурат на сервера уровня “качественный, но Китай”.

К счастью, это привело к положительным эффектам. Когда понимаешь, что тебе как разработчику, будет несколько затруднительно получить 40 физических ядер, адресующих 512GB оперативки, приходится выкручиваться и писать маленькие приложения. Зато их можно развернуть сколько угодно много — сервера все-таки недорогие.

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

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

Но с серверами легче.

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

Но с дисковыми массивами так не поступить! Выход из строя даже небольшого дискового хранилища — это отказ части платежного сервиса, чего мы себе позволить не можем. Дублировать СХД? Слишком нецелесообразно.

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

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

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

Таким образом у нас получилась удобная, отказоустойчивая и универсальная система — стойка, набитая простыми дешевыми серверами, несколько свитчей. Следующая стойка. И так далее.

Просто, удобно и в целом — очень надежно.

Прослушайте правила поведения на борту

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

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

Мы решили ничего не запрещать, а наоборот, поощрять все новое. Так у нас в продакшене построился Макросервис из огромной кучи приложений в докер-контейнерах, управляемый через SaltStack, кластеры Riak’а, Consul в качестве Service Discovery, оригинальная реализация трассировки запросов в распределенной системе и множество других замечательных технологий.

И все это безопасно настолько, что можно без стыда публиковать программу Bugbounty на hackerone.com.

Разумеется, первые же шаги по этой дороге оказались усеяны каким-то уж совсем неприличным количеством граблей. Как мы по ним пробежались, мы обязательно расскажем, также расскажем, например, почему у нас нет тестовой среды, а весь процессинг можно развернуть на ноутбуке разработчика простым make up.
Как и еще кучу интересных вещей.

Читайте также:  Примеры бизнес планов мини гостиницы

Спасибо, что выбрали нашу авиакомпанию!

P.S.: Original content! Все фотографии в посте — сцены из жизни нашего офиса.

Источник

Давайте знакомиться. Мы финтех-компания АО «НСПК» и наша задача — обрабатывать все внутрироссийские операции по картам всех платежных систем. Ежедневно через нас проходят десятки миллионов транзакций, каждая из которых должна быть обработана быстрее чем за 10 миллисекунд. Наша компания должна была за полгода перевести весь этот массив операций на российские рельсы — казалось, это невыполнимо. Параллельно с этим мы создавали платежную систему «Мир». Как выжили? Помогли прорывные технологии, Agile и заряженная команда, работающая на принципах взаимопомощи и доверия. Но обо всем по порядку.

Российская платежная система: трудности на старте

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

В марте 2014 года обстоятельства сложились так, что создание национальной платежной системы стало, как бы громко это ни звучало, вопросом государственной безопасности. Времени на долгую разработку не было.

Головной офис НСПК в Москве

Дальше события развивались с космической скоростью. Было решено, что вся обработка операций по банковским картам внутри страны: проведение расчетов, полный клиринговый цикл — будет проходить на территории России, а международные платежные системы (МПС) будут получать отчетность по транзакциям. Для обеспечения всех этих процессов ЦБ предложил создать компанию «Национальная система платежных карт».

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

Офис IT-департамента НСПК

Команда, готовая к трудностям

Руководителем А О «НСПК» стал Владимир Комлев, до этого возглавлявший процессинговую компанию UCS, дочку американской Global Payments Inc.

Технологический блок компании составили:

Игорь Голдовский, который прежде руководил компанией «Мобильные решения». Он стал создателем процессингового центра STB и гендиректором компании «СТБ Кард».

Сергей Бочкарев, который до этого организовал IT «Лето Банк» (теперь известный как «Почта Банк»).

Владимир Трояновский, ранее построивший службу IT-эксплуатации в «Лето Банк».

Хотелось нового большого проекта, новой реальной работы. И я принял этот вызов. Просто нужно не лениться и расшатывать мир.

Сотрудники департамента IT на рабочих местах

Прежде всего предстояло в короткие сроки полностью воспроизвести работу процессинговых центров МПС, соблюдая при этом все стандарты безопасности по форматам и протоколам передачи данных, а также работу сопутствующего ПО: системы защищенного электронного документооборота, удостоверяющего центра.

Технологическая база: сильное и независимое железо

Требования к инфраструктуре родились из понимания возможной нагрузки и сильно ограниченного времени на инсталляцию:

  • Только стандартные решения, чтобы не зависеть от вендора в будущем;
  • Максимальная независимость от возможных санкций;
  • Катастрофоустойчивость системы.

Мы решили использовать технологию in-memory data grid. Система grid-архитектуры представляет собой сеть из равноправных узлов. Хранилище данных при этом распределено по всем узлам, одновременно каждый узел является узлом обработки трафика, поддерживающим динамическую маршрутизацию. В случае выхода из строя одного элемента нагрузка перераспределяется на другие. Устойчивая система, не имеющая узкого места.

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

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

Во-вторых, нужен был производитель, у которого есть весь набор необходимого оборудования: серверы, дисковые массивы, коммутаторы, маршрутизаторы. И чтобы не из США и Западной Европы. Остановились на Huawei.

Тут помог ЦБ. Он выделил НСПК под ЦОДы два помещения в своих технологических центрах.

В ЦОДах отсутствовал интернет. Тянуть прямой канал до банков-участников — не вариант. Подключились через точки Traffic Exchanger M9 и M10, к которым банки подсоединились по оптоволокну, предоставленному телеком-операторами. Причем каждый банк держал соединение с обеими точками для обеспечения резервирования канала. Такая система позволила относительно легко подключить банки по всей стране.

Хочешь сделать хорошо — сделай сам

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

Читайте также:  Инвестиционный проект и бизнес план что шире

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

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

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

Тестирование: и снова нет времени ждать

В январе 2015 года к национальной платежной системе подключились первые семь банков-участников, заработала обработка тестовых внутрироссийских операций по картам одной из МПС. Первая «боевая» транзакция прошла 30 января 2015 года — это была покупка в настоящем магазине на Пятницкой улице. С начала работ над проектом до первой транзакции по карте МПС через НСПК прошло всего 4,5 месяца.

К 1 апреля 2015 года национальная система платежных карт уже работала на полную мощность по картам международных систем. И когда в декабре МПС отключили три российских банка, работающих в Крыму, для держателей карт это осталось незамеченным. Мы успели. Игра стоила свеч.

Что сейчас: Мир, LеSS, стабильность

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

Сейчас в НСПК трудятся около тысячи сотрудников, и примерно половина из них работает в департаменте IT (ДИТ). Центр программных решений, входящий в ДИТ, нарезан по продуктовым командам, каждая из которых живет в своем жизненном цикле создания ПО.

Стиль разработки сильно зависит от продукта. Команде, которая занимается разработкой продуктов для МПС, удобнее Waterfall, так как законодателями мод в этой сфере являются сами международные платежные системы: есть четкие мандатные изменения, которые российская платформа обязана поддержать как третий процессор на территории России. Они понятны, прозрачны, и о них известно заранее.

А вот у команды, которая развивает карту «Мир», ситуация другая. Так как это наша собственная платежная система, мы можем делать любые изменения и добавлять новые функции, улучшающие жизнь держателя карты, точно по принципам Agile.

Команда, которая работает над Системой быстрых платежей, пошла еще дальше и живет по принципам Large Scale Scrum — LeSS. Масштаб задач и размер команды позволили запустить его в полном объеме. И да, мы одни из немногих в России, кто его уже внедрил.

Кстати, о карьере. НСПК особое внимание уделяет онбордингу новых сотрудников, есть «курс молодого бойца» и видеокурсы по продуктам. Делаем все, чтобы новички адаптировались на новом месте как можно скорее.

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

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

Мы в НСПК стараемся поддерживать work-life balance, правильную пропорцию между работой и личной жизнью. А для тех, кто любит засиживаться в офисе, у нас есть, например, собственный тренажерный зал, в котором можно размяться в любое время суток и день недели.

Сейчас в офисе НСПК уже целый зал с тренажерами

И просторный зал для групповых занятий

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

Теги:

  • платежные системы
  • карьера в IT-индустрии
  • +18

Источник