Александр фон Розен: Когда очень важна скорость

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

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

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

Расскажите подробнее, почему все-таки понадобилась отдельная платежная система?

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

Во-вторых, мы имеем дело с уникальным сектором бизнеса, который требует специальных процедур обработки данных клиентов, особой аналитики и процессов поддержки.

В-третьих, крайне высоки требования к качеству обслуживания: для индустрии обычны такие профили нагрузки, когда пик превышает плато почти в десять раз и появляется в течение считанных минут. Обеспечивать в таких условиях высочайшую доступность сложно, но мы справляемся — например, SLA доступности наших сервисов по итогам 2022 года превысил 99,99%.

Вы единственный оператор в России, который этим занимается?

До 2021 года существовало два ЦУПИС, поскольку законодательство были иным. Затем государство пересмотрело подход к регулированию отрасли, и теперь наш официальный статус закреплен распоряжением президента. Отмечу, что при этом мы остаемся успешной коммерческой организацией.

Чем занимается ЕДИНЫЙ ЦУПИС? Какие задачи решает?

Мы, прежде всего, современная финтех-компания: наполовину кредитная организация, наполовину — современное ИТ-производство. Мы одновременно и поставщики, и эксплуатанты наших решений.

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

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

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

У нас есть объединенная структура NOC и SOC. Ориентируясь на высокий профессионализм сотрудников и передовые технико-технологические подходы, мы выстроили под эгидой объединенных NOC и SOC комбинированную эшелонированную систему защиты от кибератак. И эта система за последние годы не единожды доказывала свою эффективность, успешно отбивая самые интенсивные и изощренные атаки.

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

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

Но не последнюю роль играет и организация работы: мы избегаем бюрократии, сочетаем современные agile-практики с высокой степенью автоматизации процессов.

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

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

У ИТ и ИБ цели схожие, но иногда конфликтующие – как мы помним, самой безопасной системой является система неработающая, а «безопасно» зачастую означает «неудобно».

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

Какие вызовы и препятствия вы встречаете при управлении и масштабировании платежной платформы такого масштаба и как вы их преодолеваете?

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

Как вы оцениваете влияние регуляторной среды и законодательства на деятельность ЕДИНОГО ЦУПИС?

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

Какие меры принимаются в ЕДИНОМ ЦУПИС для обеспечения импортонезависимости и минимизации рисков?

Соответствующие риски для нас не актуальны. Мы исторически ориентируемся на open-source решения и не пользуемся «тяжелыми» проприетарными системами в нуждах production-платформы. Кроме того, мы успешно взаимодействуем с несколькими отечественными технологическими организациями, сделавшими имя именно в сегменте открытого программного кода, — например, инженерной командой Axiom JDK, поставщиком российской платформы Java.

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

Правда ли, что вы перевели ключевые информационные сервисы на российскую платформу Java?

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

Мы действительно провели импортозамещение серверной Java-инфраструктуры и мигрировали критические информационные сервисы с Open JDK на Axiom JDK Pro. Процесс перехода был органичным и бесшовным, российская сборка полностью соответствует стандарту Java SE. Первая очередь миграции продлилась около 6 месяцев, были переведены основные процессинговые сервисы и платежные гейты. В рамках второй очереди мы планируем выполнить переход оставшихся сервисов — в том числе и тех, что ответственны за обработку персональных данных. Примечательно, что за этот проект мы получили премию CNews в номинации «Импортозамещение года в финтехе».

Главный эффект для нас — возможность не ломать голову над экзотическими проблемами JVM (Java Virtual Machine) в одиночку, теперь всегда рядом квалифицированная команда единомышленников, отлично разбирающихся в предметной области.

Что такое конвейерный подход?

Парадигма не нова, лично мне нравится ее объяснять в парадигме «барабан, веревка, буфер». Барабан — это ритмичность. Веревка — непрерывность. А буфер — средства, позволяющие безболезненно сопрягать участки с разной скоростью. Наш конвейерный подход заключается в использовании собственного kanban-фреймворка.

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

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

Мне кажется, что деление на open source и проприетарное программное обеспечение становится все менее актуальным. Программное обеспечение — это концепция, воплощенная в коде. А концепция не может долго оставаться секретом. Что-то по-настоящему уникальное, длительное время существующее исключительно в проприетарных решениях и не попавшее в open-source, — большая редкость. Главное — это люди, программное обеспечение само себя не внедрит и бесперебойность процессов не обеспечит.

Есть на нашем рынке компании, которые могут обеспечить для open-source решений сервис, скажем, уровня Red Hat?

Настолько масштабных назвать не могу. Индустрия пока не настолько зрелая, но и развивается она не так долго. Часто ли на постсоветском пространстве вы встречаете, например, программистов с опытом работы по специальности более 30 лет? Есть ли перспективы? Конечно, есть. И, я уверен, в будущем у нас все замечательно — если не станем лениться, разумеется.

Безусловно, опасно внедрять незрелые open-source продукты, которые целиком и полностью зависят от одного-двух человек, а не сложившегося коммьюнити. С другой стороны, вы всегда можете постараться взять этих талантливых ребят к себе в штат и построить надежное промышленное решение. Озвученные риски, к слову, касаются не только open-source — коммерческие проекты, завязанные на одного-двух человек, с тем же успехом могут кануть в Лету, что и поделка талантливого студента, и таких проектов больше, чем может показаться. Вернусь к иллюстративному примеру команды Axiom JDK — технологии Java уже 28 лет, и почти столько же российские инженеры работают над ее развитием и кодовой базой JVM.

После того, как оператором единого центра учета переводов ставок стала НКО «Мобильная карта», некоторым компаниям, ранее с ней не сотрудничавшим пришлось переносить базы клиентов. Как кредитные организации состыковали уровень идентификации клиентов? Были ли накладки?

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

Как вы видите развитие ЕДИНОГО ЦУПИС в будущем, особенно с учетом быстрого развития технологий и изменений в отрасли платежных систем?

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

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