Алексей Перминов: «Модная технология не спасет плохую архитектуру»
При обработке данных в реальном времени цена ошибки быстро становится вполне материальной. Пока архитектор экономит на проектировании, пилот незаметно превращается в промышленное решение, нагрузка растет, а технический долг начинает диктовать свои правила. Параллельно ИИ ускоряет разработку, но создает новые риски — от плохо понятого кода до более быстрых атак. О том, где real-time действительно нужен, почему не стоит гнаться за модными технологиями и как меняется работа инженера с приходом ИИ, IT Manager поговорил с Алексеем Перминовым, техническим лидером, который более 11 лет работает с данными и сегодня отвечает за архитектуру и развитие платформы потоковой обработки в крупной финтех-компании.
Алексей, расскажите немного о себе. Как складывался ваш профессиональный путь и в какой момент вы сосредоточились на потоковой обработке данных?
Начинал я в 2014 году Oracle-разработчиком в ИТ-консалтинге, на проектах крупного европейского банка. Потом был телеком — в одной из ведущих телеком-компаний России за три года вырос от инженера до ведущего эксперта и занимался хранилищами данных и ETL.
В 2021 году перешел в финтех уже senior data engineer и постепенно сосредоточился на потоковой обработке — Kafka, Flink и self-service-инструментах для других команд. Из этой работы выросла платформа потоковой обработки данных, а в 2024 году я стал техлидом — эту должность занимаю и сейчас.
Основное направление моей работы — построение систем для бизнес-команд. Мы стремимся уменьшить time-to-market решений и снизить нагрузку, связанную с технической составляющей работы команд. Если говорить в общих чертах, наша цель — чтобы заказчики меньше думали о том, с какими технологиями они работают, а больше — о решении бизнес-задач и могли приносить пользу бизнесу как можно скорее.
Сейчас я отвечаю за архитектуру и развитие платформы в масштабе компании. У нас команда из восьми человек, и в мою зону ответственности входят архитектурные решения, внедрение новых технологий, улучшение процессов разработки, исследование и апробация новых подходов, а также ревью результатов работы команды.
При этом для нас важны и время обработки данных, и время доставки приложений в промышленную среду, поэтому мы стараемся добиться минимальных задержек в обоих случаях.
Скорость обработки данных сегодня критична для бизнеса. А в каких задачах решение действительно нужно принимать в момент события?
На самом деле скорость обработки данных была критична всегда. Просто рынок очень динамично развивается, новые технологии позволяют совершать действия намного быстрее, чем, например, 10 лет назад.
Каждому пользователю хочется, чтобы транзакция, которую он совершает, проходила максимально быстро. Бизнесу хочется того же самого, потому что бизнес хочет получить деньги, клиент хочет их потратить, и это прекрасно для всех.
Маркетинг — тоже довольно важная часть всего этого. Вы заходите на какой-нибудь маркетплейс, выбираете товар, и вам нужно показывать в рекомендациях то, что человек хочет именно сейчас. При этом далеко не все регистрируются: люди могут просто зайти, что-то посмотреть, и по разным признакам нужно определить, что им сейчас интересно.
То же самое с транзакциями. Человеку, который что-то покупает, нужно, чтобы транзакция прошла быстро, и он получил свой товар. Но если у него украли карту, ему, наоборот, важно, чтобы транзакция не прошла. И решение о том, проводить ее или нет, приходится принимать в очень маленьком временном окне — за миллисекунды, сотни миллисекунд. Сейчас понятие скорости дошло до миллисекунд, а не минут или дней.
На практике мне удавалось заметно сокращать время обработки данных. Например, обогащение торговых данных удалось ускорить с десяти минут до нескольких секунд, примерно на два порядка, а начисление клиентских бонусов — с суток до нескольких минут.
Какие решения при построении систем обработки данных требуют наибольшего инженерного опыта? Где особенно легко ошибиться при переходе от пилота к промышленной эксплуатации?
Любой проект проходит несколько стадий — от proof of concept до промышленного решения. Но нужно понимать, что ИТ и крупные компании не лишены обычной человеческой проблемы. Есть такая поговорка: нет ничего более постоянного, чем временное.
Proof of concept, который решает задачу здесь и сейчас, вполне может дойти до промышленной среды и работать до тех пор, пока не появляется серьезная нагрузка или новые требования. И вот тогда встает очень остро вопрос проектирования.
Архитектор может рассуждать так: здесь срежем угол, здесь где-нибудь сэкономим, здесь пойдем от ситуации, здесь сложим все в одно монолитное приложение. В итоге система становится неустойчивой, ее поддержка — дорогой, она перестает выполнять свою изначальную задачу, и все приходится переписывать заново.
Я с таким сталкивался буквально. Проект, над которым я сейчас работаю — это полная переделка проекта, который создавался в очень сжатые сроки. При этом сам проект очень важный. Но во время проектирования был стартап-подход: сейчас сделаем максимально быстро, time-to-market очень важен, нужно скорее выкатить, а проблемы, которые возникнут потом, когда-нибудь решим.
Это такая «проблема будущих нас». А когда это будущее наступает, оказывается, что весь накопившийся объем проблем уже нельзя просто взять и решить.
Из того, с чем я сталкиваюсь, основная проблема — масштабирование. Это колоссальная беда и для больших данных, и вообще для систем обработки данных.
Если говорить о ваших собственных проектах, какой из них вы считаете наиболее значимым?
Наверное, наиболее значимый для меня проект сейчас — self-service-платформа потоковой обработки данных на базе Apache Flink и Kafka Connect. Ее задача — дать командам возможность самостоятельно строить, запускать и мониторить потоковые пайплайны без глубокой экспертизы в стриминге и без очереди к платформенной команде.
Я занимался архитектурой платформы и ее выводом в промышленную эксплуатацию. Сегодня к ней подключены десятки команд компании, в продакшене работают сотни задач Apache Flink и более тысячи коннекторов Kafka Connect. На пиковых нагрузках платформа обрабатывает сотни тысяч записей в секунду и на чтение, и на запись.
Главное здесь в том, что потоковая обработка перестает быть узкой экспертизой платформенной команды и становится рабочим self-service-инструментом для других разработчиков.
Давайте поговорим про инструменты потоковой обработки. Насколько важен сам выбор технологии, а насколько — умение правильно спроектировать весь контур вокруг нее?
На самом деле это касается вообще любой технологии. Есть люди, которым нравятся определенные бренды, и они придерживаются какой-то стратегии при покупке вещей. С технологиями происходит примерно то же самое. Есть люди, которые любят определенные технологии. Кто-то читает научные или просто популярные журналы по разработке, кто-то съездил на конференцию, увидел, что с помощью новой технологии решается целый спектр сложных задач, и начинает ее внедрять, не очень анализируя, зачем она вообще нужна. Это довольно распространенная история.
Хорошо спроектированное решение на обычных технологиях, к которым все привыкли, гораздо лучше, чем плохо спроектированное решение на модных технологиях. Я слишком много таких проектов видел за время своей работы и могу сказать, что старая добрая отвертка поможет лучше, чем какие-то модные электронные приборы, если говорить метафорически.
При этом мы сами используем довольно новый спектр технологий. Но здесь есть специфика именно потоковой обработки данных. Вы наверняка в своей работе сталкивались с так называемым хайпом. Были NoSQL, Big Data, были технологии, которые должны были похоронить старые решения. Hadoop, например, должен был похоронить реляционные базы данных. Этого не случилось.
Каждая технология в итоге находит свою нишу и решает свою задачу. Поэтому самое главное для архитектора — не пытаться выбрать самую модную технологию, а найти инструмент, который подходит для решения конкретной задачи.
А какие ошибки в архитектуре потоковых систем вы встречаете чаще всего?
Раньше я придерживался довольно абсолютистской позиции. Мне казалось, что все эти бизнес-данные, вся эта специфика не так важны. В конце концов, это всего лишь нули и единицы, а главное — написать эффективный алгоритм, который хорошо решает формально поставленную задачу.
На самом деле каждый инженер, который работает с определенными данными, должен понимать их семантику, специфику и модель.
Простейший пример — оператор связи. Очевидно, что в Москве абонентов будет гораздо больше просто потому, что там выше концентрация людей. И нельзя применять одни и те же правила работы с данными для всей страны, исходя из того, что они распределены равномерно.
При построении распределенной системы, которая, например, обогащает данные об абонентах информацией по регионам, на одну ноду может прийти огромное количество абонентов, а остальные будут простаивать.
Когда инженер исходит из того, что все данные имеют примерно одинаковую семантику, равномерно распределяются и при этом не разбирается в бизнес-части процесса, возникает огромное количество проблем.
Технологии увлекают, и это нормально. Но если инженер не погружается в бизнес-процесс и не разбирается, как все устроено, система получается хрупкой.
Отдельная история — разработчики, которые любят писать собственные DSL, понятные только им самим. Иногда считается, что это такой вариант job security: человек написал код, который понимает только он.
Но, по моему опыту, чаще дело не в расчете, а в увлеченности технической стороной задачи. При этом код должен быть понятен всей команде: решение, которое может поддерживать только один человек, это риск для бизнеса.
Насколько сегодня инженеру вообще важно знать Kafka, Flink и другие инструменты потоковой обработки?
Все зависит от того, в какой среде он находится. Если говорить о российской специфике, наша компания использует open-source-технологии. Мы вендор-агностичны.
После определенных событий этот подход стал близок многим российским компаниям, потому что vendor lock-in — огромная проблема.
Kafka, Flink, Kafka Connect — это open source. Никто не запретит вам использовать Kafka. А какой-нибудь облачный сервис Google или решение Cloudera вам использовать могут запретить. Поэтому я в том числе выступаю за распространение open source: он позволяет компаниям меньше зависеть от изменений в политике конкретного вендора.
Но если владельцы open-source-проекта перестают принимать изменения, не возникает другая форма зависимости?
Смотрите, владелец не отключает open-source-проект. Он может поставить на паузу изменения, которые в него вносятся. Но open source тем и примечателен, что никто не заставляет вас использовать именно ту версию, которая сейчас находится в публичном репозитории.
Например, мы в команде активно используем собственные версии open-source-проектов. Допиливаем их под нужды конкретно нашей компании и нашего бизнеса. Насколько я знаю, в России это довольно распространенная практика: компании забирают такие системы к себе и силами своих инженеров начинают их поддерживать.
У этого есть и минус. Если ваши изменения сильно расходятся с основным open-source-проектом, вы начинаете нести дополнительные издержки. Сам проект развивается усилиями огромного количества людей, среди которых много очень сильных инженеров. Они вносят изменения, на которые у вашей команды может просто не хватить времени. А для вас этот результат, по сути, бесплатный.
Поэтому, делая собственный форк open-source-проекта, вы рискуете начать отставать от его развития. Зато можете гарантировать, что именно ваши потребности этот проект закрывает.
Мы много говорили о самих системах, архитектуре и инструментах. А какую роль в вашей работе сегодня играет искусственный интеллект?
Искусственный интеллект, естественно, стал огромной частью всего, что касается и данных, и ИТ в целом. И сейчас уже есть отдельный кластер проблем, связанных с его использованием. Например, я много работаю с кодом: пишу его, проверяю. Искусственный интеллект позволяет делать это гораздо эффективнее и быстрее. Но есть проблема, о которой многие обычные пользователи не задумываются: за весь код, который пишет искусственный интеллект, кто-то должен отвечать.
Если ИИ что-то написал, тот, кто за это отвечает, должен разобраться, что именно там происходит. А сейчас есть огромная проблема с тем, что люди генерируют какой-то код, иногда даже целый продукт, и в итоге сами не понимают, как он устроен. Все это накапливается как снежный ком, и в какой-то момент мы получаем машину Руба Голдберга, которая бог знает как работает внутри. Поддерживать ее практически невозможно, проверять тоже становится все сложнее.
При этом каждое изменение необходимо проверять. Представьте, например, что у меня в команде восемь инженеров. Каждый из них решает свои задачи с помощью нейросетей, и работа действительно идет гораздо быстрее. Но весь этот код потом нужно проверять. В результате нагрузка на тех, кто занимается ревью, существенно возрастает.
Это негативная сторона. Но я не буду отрицать, что искусственный интеллект дает и огромное количество новых возможностей. Мне, например, очень интересно, куда в будущем может прийти потоковая обработка данных. И одна из важных частей этого развития — LLM и изменение самих способов взаимодействия с данными.
Представим старый процесс. Происходит какое-то событие, система должна на него отреагировать, и нужно принять решение. В классической парадигме каждое такое решение приходится описывать отдельно.
Допустим, в чате поддержки начинают жаловаться пользователи. Вы по определенным правилам отбираете эти сообщения, пытаетесь понять, на что именно жалуются люди, и у вас есть ограниченный набор действий, которые приложение может выполнить в ответ.
Искусственный интеллект позволяет выстроить это иначе. Например, есть приложение, которое читает такие сообщения. Модель, развернутая на наших серверах, анализирует чаты и через MCP получает доступ к набору инструментов, которыми может воспользоваться для решения проблемы. Она может обратиться к базе данных, создать заявку, вызвать другой сервис — в зависимости от того, какие инструменты ей доступны.
Если в MCP-сервисе появляется новая возможность, ее просто добавляют туда. Модель, которая работает в приложении, узнает о существовании нового инструмента и уже может решить, использовать его или нет.
Понятно, что здесь есть свои нюансы. Поведение модели недетерминировано: мы не можем точно знать, что именно она выберет. Ответ модели вероятностный, поэтому один и тот же запрос может привести к разным ответам. Они не обязательно будут противоречить друг другу, но такая вероятность есть.
Меня впечатлил пример с австралийцем, который попросил ИИ-агента записать его в фитнес-клуб. Агент увидел, что свободных мест нет, нашел уязвимость в системе, отменил чужую запись и записал своего хозяина. Ему ведь не ставили задачу что-то взламывать — его просто попросили записать человека в клуб. Получилось буквально «вижу цель — не вижу препятствий». В этом и есть одна из опасностей ИИ — у него нет привычных человеку рамок и эмпатии?
Да, этот пример хорошо иллюстрирует проблему. Впрочем, ошибиться в моменте может и человек, на любой должности. Вещи, которые должны быть формализованы, например отказ в регистрации или отказ в проведении транзакции, — это сугубо формальные решения. Они должны приниматься по определенному набору признаков.
Недетерминированное поведение нейросети может привести к тому, что она начнет по каким-то своим критериям производить отбор. Такое поведение в итоге приносит компании репутационные издержки. То же самое может произойти, если кто-то, не разобравшись, поручит нейросети заниматься какими-то важными вещами. Это может приводить к убыткам и, скорее всего, в долгосрочной перспективе будет к ним приводить.
Потому что нейросеть не оперирует вашими целями по достижению успеха компании. Она оперирует задачей, которую ей поставили, и то далеко не всегда решает ее так, как вы хотите.
Иногда можно сказать, что это такой исполнитель желаний, который исполняет желание так, как ему захотелось.
Насколько вообще искусственный интеллект полезен при анализе потоковых данных? Где он действительно усиливает систему, а где надежнее классические правила и инженерная логика?
Есть разные сферы применения. Одна из них для тех фреймворков, которые я использую, в частности Flink, — service reliability, то есть обеспечение стабильности и анализ состояния разных систем компании. В случае аварии хочется по возможности автоматизировать принятие решений, чтобы система продолжала работать, даже если что-то вышло из строя.
Как мы уже говорили, нейросети плохо подходят для формальных задач. Но есть ситуации, где заранее описать все возможные действия сложно. Предположим, что произошел сбой и перестали обрабатываться платежи клиентов. Дальше нужно понять, что именно случилось. Самый простой вариант — срабатывает алерт, команда, которая отвечает за надежность сервиса, начинает разбираться. Время идет, платежи не проходят, компания теряет деньги.
Другой вариант — заранее написать набор правил, по которым система понимает, какие действия нужно предпринять, и одновременно оповещает команду. Но и здесь возникает проблема: эти правила нужно постоянно поддерживать. Компания может поменять базу данных, какой-то сервис может измениться — и всю эту логику тоже придется менять.
Ранее я уже говорил про MCP и агентский подход. Если сервисы поддерживают MCP, а агентский сценарий умеет находить доступные MCP-сервисы, то его задачей становится принять решение на основании поступивших данных и тех инструментов, которые доступны в данный момент.
Такой агентский сервис позволяет максимально автоматизировать рутину людей, которые занимаются восстановлением упавших сервисов. У Flink, например, есть проект Flink Agents, который позволяет автоматизировать часть этой работы. Произошла проблема — сервис обращается к модели, она анализирует ситуацию и может выполнить определенные действия с помощью инструментов, которые разработчик ей предоставил.
Например, при авариях и сбоях приходится действовать по обстоятельствам. Люди и сами в таких ситуациях часто используют LLM. И если часть этой работы можно автоматизировать, почему бы этого не сделать?
Но там, где речь идет о формальных решениях, например о сделках или других критичных действиях, применять LLM уже гораздо опаснее. Есть немало случаев, когда, например, адвокаты с помощью нейросетей получали выдуманные факты и ссылки на несуществующие судебные решения. Вот для таких задач отдавать принятие решения нейросети точно не стоит.
Где в задачах безопасности real-time действительно критичен? В каких случаях задержка даже в несколько минут уже меняет результат?
Основной спектр задач в любом финтехе — это антифрод. В нашем случае это касается еще и регистрации. Условно говоря, человек приходит и хочет зарегистрироваться в приложении, и компании нужно успеть предотвратить регистрацию нежелательного клиента еще в тот момент, пока он ждет SMS с кодом. Потому что проще отказать в регистрации, чем потом подсчитывать убытки от фрод-действий этого клиента, когда он уже попал в систему.
То же самое касается внутренней безопасности. Мошенники разными способами могут проникнуть в инфраструктуру компании, потому что у разных систем есть свои уязвимости.
Нам нужно постоянно собирать информацию. Каждое приложение при взаимодействии с другими сервисами и пользователями по-хорошему должно отправлять данные в логи. А система, которая занимается обеспечением безопасности, должна быстро отлавливать действия, которые считает подозрительными.
Если мы анализируем такие действия постфактум или, условно говоря, раз в час запускаем какую-нибудь джобу, которая просматривает логи и ищет подозрительную активность, за этот час мошенник может успеть сделать очень многое. В таком случае онлайн-реакция становится критичной для бизнеса.
Если все это просуммировать, то ответ на вопрос, когда real-time действительно нужен, довольно простой: что будет, если у нас возникнет задержка на пять минут, десять минут или час?
Если ответ — да ничего особенного не будет, просто потом немного поменяем свое поведение — никакой необходимости в real-time нет. А если за это время компания может понести миллионные убытки, тогда real-time нужен.
ИИ используется не только для защиты, но и в атаках. Можно ли вообще понять, что злоумышленник применял нейросеть, и как это меняет требования к системам?
Атаки с использованием нейросетей сейчас, очевидно, очень распространены. Но я не могу ни подтвердить, ни опровергнуть, что в конкретном случае человек пользовался LLM. Очень часто это просто невозможно достоверно определить.
С помощью нейросетей, в принципе, каждый второй может попробовать себя в роли хакера. Но если обычному человеку это вряд ли даст серьезный результат, то профессиональному хакеру нейросети сильно ускоряют работу. Даже если он раньше никогда не сталкивался с системой, которую собирается взламывать, в теории он может воспользоваться какой-нибудь open-source LLM, у которой сняты ограничения на помощь хакерам, и получить необходимую информацию: какие есть уязвимости и как можно попробовать внедрить вредоносный код. Соответственно, здесь борьба уже начинается в онлайн-режиме.
При этом мы видим, например, большое количество подделок документов при проверках KYC. Это позволяет мошенникам обходить различные барьеры, которыми защищают себя финансовые организации. Соответственно, и механизм борьбы с такими людьми становится глубже и сложнее.
Сейчас активно используются графовые базы данных для обнаружения связей между разными признаками конкретного клиента. Каждый человек оставляет большой цифровой след — устройство, браузер, регион и многое другое. Есть антифрод-команды, которые непосредственно этим занимаются, мы со своей стороны работаем с данными.
Злоумышленник оставляет не только те данные, которые сам о себе предоставляет, но и цифровой след, по которому мы можем собирать дополнительную информацию. Нейросети помогают обходить проверку документов, верификацию лица или голоса. Но это только один рубеж. Есть еще цифровой след, и мы как раз работаем с ним, проверяем связи каждого клиента, который пытается зарегистрироваться или пройти проверку.
Основная проблема в том, что таких связей может быть огромное количество, а система должна очень быстро найти нужные и выдать результат — можно пропускать клиента дальше или нет.
Мы говорили о внешних атаках, но ведь риски возникают и внутри компании. Например, разработчик использует ИИ, подключает какие-то библиотеки, не всегда понимая, что именно попадает в проект. Насколько это серьезная проблема?
Сейчас довольно много атак происходит на публичные репозитории NPM, Maven и другие, где находятся библиотеки общего пользования, в том числе open-source.
Представьте ситуацию: модель пишет вам код и скачивает какую-нибудь библиотеку. Библиотека оказывается зараженной и устанавливает фоновый процесс. А потом вы обнаруживаете, что за день у вас закончились все лимиты по токенам в ИИ-ассистенте. На деле ваши токены украли и продали на черном рынке за копейки.
Черный рынок токенов — вообще удивительная вещь. Люди не всегда проверяют, что именно устанавливают, и в итоге заражают свои компьютеры. Поэтому сейчас многие компании регулярно проверяют свои проекты на наличие зараженных библиотек, и это правильная практика.
А что сегодня самое сложное лично для вас в работе? Появились ли вызовы, с которыми раньше не приходилось сталкиваться?
У нас есть бизнес-требование — мы должны как можно быстрее принимать решения, и наша команда предоставляет для этого платформу. Но многие команды привыкли к своим инструментам и не хотят переходить на новые. Поэтому одна из сложных задач, которая, наверное, есть во многих компаниях — внедрение новых инженерных практик и подходов.
Есть и обратная сторона. Нейросети очень сильно меняют сферу разработки. Как техлид я отвечаю за продукты, которые мы предоставляем, поэтому должен разбираться во всех изменениях и понимать, насколько проблемным может оказаться каждое из них.
Получается немного противоречивая ситуация: я сам страдаю от количества изменений, но при этом хочу, чтобы другие активнее их принимали. Наверное, вся наша жизнь состоит из противоречий.
Давайте немного займемся астрологией. На десять лет вперед прогнозировать в ИТ бессмысленно, но как вы представляете развитие real-time-систем в ближайшие два-три года?
Я думаю, что все займет свою нишу точно так же, как произошло с Big Data и NoSQL. Более эффективные решения останутся, менее эффективные постепенно уйдут в небытие.
Другое дело, что вся экосистема меняется. Мне нравится, как это происходит, нравится участвовать в этих изменениях. Те же агентные сценарии — очень новая вещь, пока они применяются не слишком широко, но мне кажется, что будут распространяться все больше.
Много говорят и о переходе от старых подходов к хранению данных. Были Data Warehouse, Data Lake, сейчас появляется Stream House. И все это в том числе направлено на сокращение финансовых издержек.
Огромное количество сервисов сейчас живет в облаках, вычислительные мощности очень дорогие, оперативная память из-за нейросетей тоже дорожает, оборудование в целом становится все дороже. Сначала майнинг взвинтил цены на видеокарты, теперь нейросети - на память и оборудование в целом. Все становится дорого, поэтому компании пытаются сокращать издержки. И вопрос уже не только в том, насколько быстро работает система, но и во сколько эта скорость обходится бизнесу.
Опубликовано 30.09.2026
