Результаты внедрения AI/ML, безопасной разработки и других трендовых технологий в крупнейшие отрасли рынка. Опыт заказчиков, производителей, разработчиков и интегратора из крупнейших отраслевых компаний.

Модератор: Максим Морарь, CPO, Orion soft

Спикеры:

Иван Эрих, лидер направления развития ИИ, Газпром нефть
Максим Пустовой, генеральный директор, Arenadata
Максим Чернухин, CTO клиентского сервиса, СберСтрахование жизни
Евгений Шишков, управляющий директор, Orion soft
Оксана Воробьева, директор по управлению, МТС Web Services
Армен Амирханян, директор по развитию искусственного интеллекта, Московская Биржа

;

AI/ML-интеграция в инфраструктуру

Максим Морарь (модератор): Друзья, всем привет! Мы продолжим тему трендов, но поговорим о них в более прикладном ключе. Пообщаемся на тему искусственного интеллекта, как это внедряется в крупных компаниях и где это полезно, а главное — как эту пользу померить.

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

Давайте начнем с темы ИИ. Хочется поговорить не в отрыве от реального проектного опыта, а навалить «мяса». Может быть, кто-то поделится примерами реального внедрения технологий ИИ в процессы, в продукты компании, где это стало успехом? А главное, как вы поняли, что это стало успехом? Как померить этот успех от внедрения ИИ?

Иван, я предложу тебе начать, если ты не возражаешь.

Иван Эрих: Да, Максим, спасибо. Коллеги, добрый день. Я попробую навалить «мясо». Мне кажется, что мы сегодня услышим много реальных кейсов применения искусственного интеллекта. Я с позиции промышленной компании на этот вопрос отвечу.

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

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

Приведу несколько примеров. Одному примеру из области добычи 2-3 года. То есть это не что-то новое, что вчера произошло, потому что классическим машинным обучением занимаются еще с 2015-2016 годов. Вещь-то на самом деле не новая. На одном из месторождений, это месторождение Ямала, с помощью разработанных алгоритмов и обработки данных геологии, сейсмики, петрофизики и так далее, удалось найти реальные залежи нефти. И сейчас эти алгоритмы активно у нас тиражируются по месторождениям. Это реальный инструмент, который позволяет геологу определить место для дальнейшей разработки.

Есть классный кейс по логистике. У нас организована логистика по Северному морскому пути. Там за счет моделей, которые были разработаны нашими инженерами, мы смогли оптимизировать маршрут следования судов. То есть мы смотрим ледовую обстановку, насколько загружен трафик, какие-то изменения. За счет оптимального маршрута сократили на 12% затраты на логистику нефтепродуктов. Это миллиарды.

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

Максим Морарь (модератор): Очень круто. То есть вы можете померить эффект реальными деньгами. Это прям здорово. Где-то это профит, где-то это экономия коста.

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

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

Максим Морарь (модератор): Все так, но вопрос все-таки открытый для многих, потому что не все научились для себя мерить внедрение того или иного проекта. Мы видим сегмент проектов, которые бегут куда-то, потому что надо бежать. Это проблема. А как померить результат? Поэтому то, что вы можете это переложить на конкретные деньги, это очень круто.

Армен, поделись, пожалуйста, как вы это делаете в своем секторе?

Армен Амирханян: Всем привет. Во-первых, я бы разделил на две сферы — GenAI и Classic ML.

Если говорить про Classic ML, то здесь эффект более значим в силу того, что это более управляемая история. Его можно применять в довольно значимые и серьезные процессы, а как правило именно значимые и серьезные процессы приносят денежку, профит. Мы его применяем в риск-моделировании. У нас есть прямой экономический эффект — более 500 миллионов в год от внедрения одной модели. Это такая серьезная история именно про классический ML.

Но всех интересует GenAI. Сейчас главная дискуссия идет вокруг этого: GNI вообще себя окупает? У нас есть очень классные кейсы, где он себя окупает. Мы верим в то, что GNI дает эффект в качестве Copilot человека. Не полная автоматизация некого процесса, а именно Copilot. И здесь у нас есть два классных кейса.

Первый кейс. У нас есть обязанность проверять проспекты миссий. Это документы, в которых более 200 страниц. Там очень много эмитентов, несколько сотен. Если все это умножить, то кто-то это должен делать. Сейчас с помощью Copilot для людей, которые валидируют эти проспекты миссий, мы сможем выполнить эту задачу 3 людьми вместо 20. Это довольно серьезный эффект.

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

Максим Морарь (модератор): Я правильно услышал, с 20 разработчиков до 3 вы оптимизируете за счет внедрения Copilot. То есть FTE, да?

Армен Амирханян: Это не разработчики, это бизнес-валидаторы. Это бизнес именно.

Максим Морарь (модератор): Эффект очень заметный. Круто, cпасибо.

Макс, дам тебе возможность дополнить и перейдем к следующему вопросу.

Максим Чернухин: Есть очень интересная мысль про AI. Круто, что он стал так популярен. Люди стали думать о том, что есть задачи, которые мы теперь можем оптимизировать с помощью AI. Скорее всего, большинство задач можно было сделать еще лет 10 назад. Это всякие алгоритмы, поиски оптимальных путей, поиски в глубину, которые всегда были, с графами и так далее. Но так как он стал настолько популярным люди задумались о том, что все могут оптимизировать. И там, где все можно оптимизировать, здорово, что теперь мы об этом думаем, но там не всегда есть AI.

Есть очень интересный кейс один, как раз там, где мы применяли LLM, AI. Казалось бы, страхование жизни, отстает от банковской сферы лет на десять, честно. Два года мы шли, и вот к чему пришли. Раньше рассматривался страховой случай человека, когда, допустим, что-то произошло — насморк, ногу поломал и так далее, в течение десятков дней. Потом сделали, чтобы это было не больше пяти. И в этом году, летом, это стало происходить за пять минут. Не больше пяти минут — и деньги приходят на карту. Это впервые в мире и в Европе. Нигде такого больше нет.

Но где там используется AI? Там AI, именно генеративный, используется пока только в одном кусочке. Там есть Computer Vision, он был всегда. Там есть какие-то модельки, которые могли обучать. Они обучались с 2015 года и тоже всегда используются. Но есть одно место, где мы на вход подаем что-то, что было написано от врача, и говорим: «Отдай нам диагноз». И чтобы написать что-то свое, высчитать диагноз, надо было прям очень сильно постараться. А вот с этой задачкой LLM очень здорово справляется, она дает диагноз. Потом это опять уходит в обычную модельку, которая уже обучена, проскорена, риски посчитаны. И потом как раз принимаем быстро решение. Вот так мы с десятков дней сократили до пяти минут.

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

Максим Морарь (модератор): Прикольно. Короткий вопрос — короткий ответ. Если задачу можно решить с применением ИИ и без, ты что выберешь?

Максим Чернухин: Без. Это скорость, понимаешь? LLM долго думает. Это вероятность. А если я могу сказать «вот здесь будет больше 20, делай то решение», это будет миллисекунды. А все, что связано с AI, особенно с LLM, это вопрос секунд. Если у меня есть какая-то обычная модель и так далее, то окей, можно об этом подумать. Но если что-то можно решить без AI, то это будет работать точно лучше, быстрее и надежнее.

Максим Морарь (модератор): Все согласны с тезисом, коллеги? Армен, давай я тебе дам возможность высказаться.

Армен Амирханян: Мы применяем очень простой принцип: «Сначала попробуй с AI. Если не получилось, тогда уже задумывайся». И мы это пропагандируем внутри. Есть много задач, которые решаются one prompt. One prompt solution. Поэтому мы другой принцип пропагандируем и в нем уверены.

Максим Морарь (модератор): Понятно, здорово. У вас опыт немножко из другой области.

Давайте поговорим про вопрос конфиденциальности данных. А именно — все используют LLM, кто-то обучает их под себя, файн-тюнит. А что с вопросом confidential? Это локальные модели, которые вы развертываете у себя. Как обеспечивать безопасность этих моделей, как сделать так, чтобы мой код или персональные данные моих сотрудников, моих клиентов в какой-то момент не оказались где угодно?

Максим, с твоего позволения, предложу тебе ответить на этот вопрос.

Максим Пустовой: В данном случае, напомню, мы, Arenadata, производим продукты по работе с данными, CУБД. Не называя имен, на этой сцене есть в частности наши клиенты. Чтобы вы понимали, где же данные хранятся, которые используются в моделях, которые рассчитывают те или иные бизнес-эффекты.

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

Сразу пошли путем, что не хотим обращаться в публичное облако. Во-первых, в запросах от наших клиентов может быть конфиденциальная информация. То есть в тикетах, которые поступают, очевидно, можно идентифицировать клиента, какую-то проблему, которая у него возникла в продукте Arenadata. Поэтому мы взяли нашу локальную модель. Ну то есть мы взяли Open Source модель, не буду говорить какую. Установили в рамках своей инфраструктуры, обучили. Это локальная LLM-модель, на узком контексте достаточно обученная, но суперэффективная. И действительно вопрос не праздный, потому что, казалось бы, служба техподдержки, приходят тикеты, но если посмотреть, что в них мы от заказчика просим — мы просим номер договора, лицензию, продукт, кто именно в какой ситуации столкнулся. Данные заказчики в тикетах не передают, но достаточно точное описание. Не дай бог эта информация уйдет куда-то наружу. Поэтому, конечно, в таких задачах прикладных это локальные модели, модели Open Source глобальные, но размещенные в локальной инфраструктуре с максимальной защитой доступа к этой модели. В двух словах так отвечу.

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

Максим Пустовой: Подходят. Скорее вопрос конфиденциальности. Более того, есть очень сильные облачные модели. Это же вопрос еще чего? Ресурса. Тебе нужна эластичная загрузка, возможность грузить большой загрузкой в моменте и, соответственно, тарифицироваться таким образом. Тебе нужно иметь свою мощность. Тебе нужно свои «железки» покупать с видеокартами NVIDIA, что мы и делали. Тебе нужно собрать этот комплекс, этот пак. Это еще та муторная задача. А так ты из облака получаешь это в момент по подписке. С финансовой точки зрения, наверное, эффективнее, чем это делать в своей инфраструктуре.

Максим Морарь (модератор): Но вопрос безопасности при этом зачастую перевешивает, и ты соглашаешься с этими трудностями.

Максим Пустовой: Безусловно, да.

Максим Морарь (модератор): Понятно. Очень круто. Давайте про вопрос доверия немножко поговорим. Поделитесь реальным опытом, какую степень возможности принятия решений на базе ИИ вы готовы позволить внутри своей организации, а какие решения точно не должны приниматься автоматизированной системой, обязательно в цепочке должен быть человек.

Макс, может быть, ты начинаешь?

Максим Чернухин: Окей. Тут вопрос же в том, что в принципе автоматизировано, что можно принимать, что нет. Понимаешь?

Максим Морарь (модератор): Что угодно. Скейлинг инфраструктуры, например. Ты можешь автоматизировано управлять инфраструктурой через ИИ? Как будто бы да.

Максим Чернухин: Но я могу автоматизированно управлять инфраструктурой и без ИИ, понимаешь? Как раз таки автомасштабирование, скейлинг и так далее работают, когда у тебя классно настроена инфраструктура, классная архитектура, все знают, что такое 12 факторов разработки и прочее, прочее, прочее. И исходя из того, у тебя есть куча данных, на которых ты можешь принимать грамотные решения.

И тут я бы перешел к другому — а насколько вы доверяете своим данным, на которых будут приняты решения? И сейчас очень часто видно, что компании очень хотят быть AI-native, но при этом не прошли через data-driven. У них данные разрознены, все задублировано, непонятно, где источник, где основная точка, куда ты можешь посмотреть и сказать, что вот эти данные верны, точка единственная, которая принимает решение, что данные меняются, не меняются, актуальны, неактуальны. И они, исходя из этой точки, двигаются в AI-native. Конечно, там ничему не можешь доверять.

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

Человек что делает? Он смотрит на данные и принимает решение. И дальше вопрос, а как много данных человек может собрать? Понятно, что если данные не структурированы, то в AI ты их не запихнешь. А человек может пойти почту почитать, собрать как-то данные. И в этом как раз плюс. Что у тебя есть этот гэп данных, которые мы еще не оцифровали, они где-то находятся, кто-то с кем-то поговорил. И решение, которое принимается человеком, может быть более актуально. Он более свежими данными обладает, в отличие от каких-то наших систем, потому что многие данные, если мы говорим про принятие финансовых решений, не оцифрованы.

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

Максим Морарь (модератор): Как обычно, иначе все было бы очень просто.

Армен, у вас в «Московской Бирже» так же на это смотрят или есть нюанс, как закончил Максим?

Армен Амирханян: У нас смотрят очень строго, потому что мы финансовая инфраструктура финансового рынка России. Финансы — это очень чувствительный домен, где недопустимы искажения.

Я бы привел следующий пример. Как определять, можно ли в процесс вкладывать или нет? Если посмотреть по бенчам, по последним большим языковым моделям, я сейчас про GNI говорю, то где-то мы увидим 70-80% — это качество решения задач на различных доменах, которые делают. В покере, если кто играет вдруг, вероятность выигрыша, когда вам выпало два туза в самом начале, — 72%. Теперь вопрос. Если мы внедряем GNI на атомную станцию, например, готовы ли мы на два туза поставить управление стержнями на этой атомной станции? Наверное, нет. А готовы ли мы, например, рискнуть, когда мы трейдим? На 72%, 2 туза. Многие говорят «да».

То есть вот в критические какие-то процессы точно нет. В скейлинг инфраструктуры я бы тоже не стал. Однажды Cursor у меня удалил базу, например. Но человечество уже изобрело решение. Copilot, Human-in-the-loop. Когда каждое критически важное действие подтверждается человеком. Наверное, вот в этом мы видим подход к работе GenAI и внедрению.

Максим Морарь (модератор): Спасибо большое. Давайте к разработке. Есть тезис. Согласитесь, опровергните или раскройте, дополните, как вы на это смотрите. «Не использовать технологии искусственного интеллекта в разработке того или иного продукта или сервиса в 2025 году — это уже как минимум не модно, а как максимум вообще не должно так быть». Как вы на это смотрите?

Жень, предлагаю тебе начать.

Евгений Шишков: Да, всем привет. С этим вопросом невозможно не согласиться, и этот тренд уже не новый.

Мне кажется, полгода назад, а может и больше, я услышал историю про Google, которые сделали что? Они поставили KPI своим ведущим senior-разработчикам на то, чтобы они серьезный процент кода, около 50%, писали с помощью искусственного интеллекта. И если они этот критерий не выполняли, то считалось, что они не соответствуют своей квалификации.

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

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

Максим Морарь (модератор): Спасибо, Жень. Максим, а как вы в Arenadata смотрите на эту задачу, на этот комплекс в разработке ваших решений?

Максим Пустовой: У нас так сложилось, что большая часть разработчиков — senior, причем с большим перекосом в длительный опыт.

Я читал недавно, есть такая компания, по-моему, называется «METR». Они изучают и оценивают модели на предмет их качества. Врут, не врут, галлюцинируют, насколько на них можно полагаться. И они опубликовали исследование как раз у разработчиков, насколько это влияет на их качество, скорость работы. У junior ускорение было на 10%, у middle — практически нулевой эффект, а senior использование замедляло на 10%. Это исследование «METR». Достаточно авторитетная контора в этом плане. Ей отдают свои модели известные гиганты, кто строит модели, на тестирование.

Возвращаясь к нам. Мы пока достаточно узко используем искусственный интеллект при разработке. Мы используем это в части, связанной с безопасной разработкой, в области поиска уязвимостей. Многие используют пакеты внешние, Open Source, при создании ПО. Я даже не знаю, кто их не использует сейчас. В большей или меньшей степени. Соответственно, было бы неплохо сканировать, выявлять уязвимости, если вы используете это в своих пакетах. Вот это мы сделали одной из первых вещей. Но как Copilot, например, в разработке, мы используем пока это достаточно ограниченно.

Есть мнение, может быть оно спорное, что чем более низкоуровневое программирование, а у нас, если мы говорим о ядре СУБД, это Cи, тем меньше ИИ может помогать, а наоборот может замедлять работу. Может быть, в области создания интерфейсов пользовательских или писать на Java это будет более эффективно. Но тут я не настаиваю, я не настолько разработчик, чтобы утверждать, что дилемма такая.

Максим Морарь (модератор): Но при этом ваш опыт как будто это подтверждает.

Максим Пустовой: Мы еще посмотрим, может мы и ошибаемся.

Максим Морарь (модератор): Время покажет. Здорово.

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

Оксана Воробьева: Я добавлю по поводу фронт-платформы. У нас есть такая. Именно там искусственный интеллект. Через определенные задачи описания лендинга, который тебе нужен, без программирования, по тем брендбукам, которые клиент просит, можно поднять сайт. Но это пока больше стандартное, авторизация или еще что-либо. В принципе, в это мы идем, да.

Максим Морарь (модератор): Спасибо большое. Здорово.

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

Армен, может быть, ты начнешь?

Армен Амирханян: Здесь классические проблемы в области информационной безопасности. Я думаю, все, кто ИИ занимаются, с этим сталкиваются. Это наш главный барьер, который надо перепрыгнуть.

Первое — данные не могут покидать контур. То есть мы не можем использовать облачные модели. Мы должны разворачивать инфраструктуру внутри контура. А это очень специфичная инфраструктура. И на всю Россию можно насчитать человек 20, которые умеют на самом деле работать с GPU и разворачивать GPU-кластеры, объединять GPU в кластеры и так далее. Это очень дефицитный ресурс, в целом на администрирование всего этого. Это первая проблема, что очень специфичное оборудование, очень редкое, очень дефицитное, очень дорогое. И опыт не так много у кого есть.

Вторая история — это разговор про то, что если мы внедряем в систему с уровнем надежности определенным, то есть классическая проблема. Система должна резервироваться. Должны резервироваться источники данных для нее, на тот случай, если она упадет. Но как мы можем резервировать, например, сервер с самыми последними видеокартами, который стоит 100 миллионов рублей? Ничего себе резервирование. То есть рядом будет стоять, просто простаивать 100 миллионов рублей. Вот проблема. Без резервирования уже подключиться к промсистеме невозможно.

И третье — а может ли наш GenAI гарантировать качество, достаточное для подключения к промсистеме? Но это больше бизнесово, наверное.

Максим Морарь (модератор): Про резервирование, конечно, интересно. Ты в какой-то момент начинаешь считать, и там вообще кейс не сходится, видимо, в этот момент с точки зрения резервирования. Прикольно.

Максим, может быть, у тебя есть что дополнить в эту область?

Максим Чернухин: Очень похоже, да, резервирование. Вопрос в том, что когда начинаешь пользоваться GenNI, тебе нужно много видеопамяти. C GenAI пока это сложно.

Ты поднял на 300 Гигабайт, допустим, какое-то решение, где крутится сколько-то LLM, и вроде бы хорошо, а потом ты понимаешь — у тебя есть production, и вот ты уже 300 туда закинул, у тебя есть pre-prod, потом dev, test и так далее. Pre-prod, там, скорее всего, у тебя тоже персональные данные лежат, их надо тоже изолировать, значит, туда 300 гигабайт. Потом у тебя есть dev/test-стенд, там тоже хорошо бы какое-то решение поднять, и там тоже 300.

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

Понятно, что есть всякие сервисы, которые помогают LLM поднимать. Open Source и не только. И с этим уже, я думаю, все поработали. А вот о том, что ты понимаешь, что тебе надо сильно больше ресурсов, и это ресурсы, которые скорее приходят коробкой, что надо точно 300, потому что какая-то большая моделька развернута, или 400, две модельки развернуты, чтобы они быстро работали. И надо это продублировать, продублировать это на pre-prod, на тестовые стенды, потому что просто физически не поднимется.

В случае обычной разработки ты понимаешь, что немножко поменьше накидал. Они между собой подоговаривались. У кого-то было больше, он работал быстрее, у кого-то меньше, он помедленнее работает, и окей. А вот с историями, связанными с GenAI, пока так не работает. Я думаю, что эту задачу решить, так чтобы можно было как-то ресурсы «шарить» между собой, это будет хороший кейс.

Максим Морарь (модератор): Очень хороший кейс. А тезис про безопасность ты в итоге подтверждаешь или опровергаешь, что это действительно трудно сейчас?

Максим Чернухин: Когда ты поднимаешь все у себя, то автоматически этот тезис про безопасность пропадает. Тут вопрос лишь в том, что у тебя же не только LLM принимает решение. Это утопия, я не знаю, где это. Мы говорим, конечно, об этом, что как же будет AI принимать решение. Ну, нет. Там есть куча алгоритмов. AI — это кусочек, который приносит решение. А дальше все это сравнивается. Другие модельки обученные все это используют.

Мы используем все это именно on-prem, поднимая модели, как-то там RAGами обкладывая и так далее. Это помогает думать о безопасности уже в рамках нашего контура. Это совершенно другие вопросы. Это не так, что ты что-то закидываешь в облако. Но опять же, если закидываешь в облако, то надо тоже понимать, в принципе, ты можешь там другую AI натравить, чтобы она, если увидит персональные данные, об этом подумала, токены поставила, потом токены поменяла обратно. Это тоже решается. Дольше уже надо об этом думать, дольше вкладывать ресурсы, а поднять где-то у себя сильно проще. Сильно проще для того, например, чтобы документы какие-то люди закидывали, чат-бот у вас есть, кто-то хочет не весь документ читать, закинул на самморизацию. Хорошо бы такое сделать все-таки на внутренних решениях, а не так, чтобы в облако улетел ваш договор с подрядчиком или с кем-то еще.

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

;

Безопасная разработка

Максим Морарь (модератор): На этом тезисе про безопасность давайте плавно переходить к безопасности и раскрывать этот вопрос чуть глубже. Открываю блок по безопасной разработке. Я глубоко убежден, что все здесь присутствующие в том или ином виде в компании занимаются безопасной разработкой.

Иван, можно я начну с вопроса к тебе, как к представителю стороны клиента? Когда вы берете к себе на борт какое-то решение, какие требования вы предъявляете с точки зрения безопасной разработки к поставщику и как убедиться, что поставщик действительно этим требованиям соответствует с точки зрения безопасной разработки внутри продуктов? Что важно?

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

С точки зрения требований, у нас есть ряд принципиальных задач и требований, которые мы предъявляем к любому решению. Коллеги упомянули о развертывании любых решений on-premise. Мы действуем аналогично, то есть не используем никакие облачные решения, все должно быть в нашем защищенном контуре.

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

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

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

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

Максим Морарь (модератор): Слушай, очень интересно. А я правильно понимаю, что вот эта база промптов, по сути, может быть бесконечной? И для вашей безопасности это постоянный процесс наполнения, наполнения, наполнения этой базой теми промптами, которые потом можно будет отрабатывать с точки зрения защиты?

Иван Эрих: Абсолютно верно. Я периодически смотрю, мне самому интересно, какие промты там появляются. Каждую неделю это какие-то новые запросы, которые коллеги анализируют, добавляют. Она постепенно разрастается, разрастается, но при этом валидация тестирования становится более всеобъемлющей и комплексной. Постоянная работа.

Максим Морарь (модератор): Очень интересно. Мы начали про безопасную разработку, но вернулись к ИИ и здесь. Что бы это могло значить?

Жень, а давай с другой стороны на это посмотрим. Со стороны вендора. Что, на твой взгляд, важно с точки зрения выстраивания процесса безопасной разработки внутри вендора для того, чтобы предоставлять качественные продукты и сервисы компаниям уровня «Газпром нефти», например?

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

По поводу того, что мы как вендор делаем, очень показательна наша первая пленарная сессия. Мы там так или иначе коснулись всех аспектов. Первое — это Security by Design. Когда ты начинаешь разрабатывать продукт, ты уже должен хорошенько подумать о том, какие механизмы обеспечения информационной безопасности у тебя заложены, достаточны ли они, масштабируемы и прочее.

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

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

Максим Морарь (модератор): Спасибо большое.

Оксан, а давай сделаем шаг назад и поговорим про трансформацию и подход к внедрению DevSecOps. Она уже идет у вас в МТС Web Services или вы только на этапе запуска? Если идет, то какой первый шаг был правда полезен, где вы поняли, что идете в нужное направление, выбранный вектор правильный?

Оксана Воробьева: Начали мы года полтора назад, когда мы приняли это решение. Предпосылок было несколько. И самая главная предпосылка, которую мы видели, была связана с тем, что у нас достаточно высокие требования информационной безопасности, потому что мы делаем большие нагрузочные платформы, которые должны соблюдать тайну связи, банковскую тайну и так далее. Все это понятно. Плюс, давайте не забывать, с каждым годом растет требование по персональным данным. И предпосылка была такая, что мы понимаем, что нужно заранее автоматизировать весь процесс, обучить команды, заранее закладывать в архитектуру, в подходы, все те ГОСТы, которые нужны, все уже наработанные практики. Это первое. Для этого нужна была команда, и мы наняли экспертов, которые смогли этот процесс поставить.

А вторая история была с тем, что мы постоянно наталкивались на историю управления доступами, производственными доступами, корпоративными доступами, когда особенно единая история с клиентом, что общую инфраструктуру предоставляешь вместе с облаком и так далее. И здесь огромные риски. И мы специально для этого создали определенную платформу по управлению данными Security Factory, где менеджерятся правильно доступы, правильно автоматизировано они распределяются, закрываются. Потому что много было инцидентов, понятно, с какого этапа они начались по времени. Это была вторая главная задача для них.

Чем мы довольны? Довольны тем, что эксперты сопровождают с самого начала. Мы не переделываем заново какие-то архитектурные решения. Они уже правильно сразу идут. Встраиваем Open Source, покупные решения в производственную фабрику, которая на определенных этапах не пропускает дальше автоматизированную историю, прогоняя код на проверки и так далее, останавливает, мы переделываем что-то, включая нагрузочные, предкоммерческие выпуски.

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

Максим Морарь (модератор): Спасибо большое, Оксан.

Максим, с точки зрения Arenadata тот же вопрос. Где вы находитесь сейчас на долгом эволюционном пути внедрения DevSecOps? И какой первый шаг ты правда понял, что был полезен?

Максим Пустовой: Видимо, мы скитаемся по той пустыне. Мы идем каким-то путем. Но шутки шутками. Во-первых, напоминаю, что все, кто занимается Software-бизнесом и работает в B2B-сегменте, должны соответствовать требованиям регулятора, которые выражаются в требовании сертификации ФСТЭК по разному уровню доверия, но четвертый уровень доверия считается минимально необходимым для критической инфраструктуры. И если посмотреть на требования ФСТЭК и что они проверяют, как они проверяют — там есть испытательная лаборатория, вы обязаны работать с ней, если вы хотите сертифицировать продукт. Они достаточно высокие требования предъявляют. Они используют разные сканеры по выявлению уязвимости.

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

Возвращаясь к ФСТЭК, даже если посмотреть на требования ФСТЭК для сертификации и какие процессы безопасной разработки вы должны внедрить — вы уже выполните 80% того, что нужно сделать, чтобы построить более-менее зрелый процесс безопасной разработки. 20% нет. На 20% приходится свой взгляд безопасников каждого крупного корпоративного клиента на то, что такое уязвимость, как ее выявлять, как ее закрывать и так далее.

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

Максим Морарь (модератор): Спасибо. Ты хочешь дополнить? Давай.

Максим Чернухин: Я не буду повторяться про Security by Design и так далее. Что классно и помогло тоже «апнуть» как раз-таки безопасную разработку у нас. С точки зрения безопасной разработки, мне кажется, в «Альфе» получилось прям очень классно построить. В какой-то момент нам надо было переезжать в Public Cloud. Мы пришли к безопасности и сказали, что кажется, нам в любом случае работать с вами вместе, давайте работать как команда. И к чему это привело? В итоге мы начали это продвигать и среди разработчиков в том числе, и через какое-то время у нас выросли security-чемпионы. Это люди в разработке, которые присматривают за тем, как его команда, какие-то соседние команды разрабатывают.

Через какое-то время нам проводили пентест безопасники. И в итоге они провели пентест, максимально постарались это сделать жестко и сказали: «Ребята, у вас лучший проект, который мы проводили и пентестили за всю историю в компании». Это привело к тому, что мы стали безопасность продвигать через разработчиков в том числе. И это закладывалось не просто Security by Design. А люди, которые разрабатывают, проектируют и так далее, тоже думали об этом. И они это тоже закладывали на уровне кода. И это помогло очень сильно «апнуть» безопасную разработку.

Максим Морарь (модератор): Ты затронул вопрос команд, а давай чуть раскроем. Как выглядит сейчас у тебя взаимодействие Dev-, Sec- и Operation-команд? И как сделать так, чтобы имплементация security-части не повлияла на скорость конвейера, бизнесовые метрики типа time-to-market и так далее? Как безопасностью не заблочить выход важного функционала в нужный срок? Есть ли вообще такая проблема, Макс?

Максим Чернухин: Эта проблема есть, и при внедрении она точно будет. Ты просто должен принять это и какое-то время с этим пожить, что тебя будет что-то «лочить». Но когда ты настраиваешь эту историю, какая же идея? Идея в том, чтобы выяснять, что у тебя есть код какой-то небезопасный, максимально близко к тому, как человек пишет код. Это, как мы знаем, чем раньше мы находим проблему, тем меньше она стоит в решении. Если в продакшне что-то нашли, то пока проанализируешь, код напишешь, протестируешь, это очень дорого.

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

Совершенно точно этот процесс построить больно. Но когда ты его строишь, это становится частью производственного процесса. Все уже понимают, что надо это делать. Он сильно сокращается по времени. И в этом случае ты получаешь value. Но в любом случае, чтобы туда прийти, надо пострадать. Где-то сроки, скорее всего, посрываются. Но кажется, что сейчас это неизбежно, потому что системы становится все сложнее. А так как сложные системы, то у тебя больше связей. А чем больше связей, тем сложнее за ними следить. И кажется, что надо максимально сдвигать на разработку отслеживание связей, которые могут потенциально как-то зловредно быть использованы.

Максим Морарь (модератор): Спасибо большое, Макс.

Жень, расскажи про Orion soft, про взаимодействие ребят в командах разных ролей и к чему Orion soft идет с точки зрения той же сертификации, которую Максим уже упоминал?

Евгений Шишков: Сейчас обязательно к твоему вопросу вернусь. Но тема DevSecOps, тема ИТ и ИБ, для меня немножко личная, потому что два года назад я попал в пленарку, где вокруг меня сидели коллеги из информационной безопасности банков, заказчиков из ритейла и прочее. Так складывался разговор, что они очень быстро между собой подружились против ИТ. И в какой-то момент они начали как-то очень сильно разделять ИБ и ИТ. «ИБ все правильно делает. ИТ ни о чем не думает, бегут куда-то там себе вперед, дыры нам в безопасности множат».

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

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

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

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

Cамое главное в итоге — смотреть в едином направлении, стараться подстроиться, понимать друг друга.

Максим Морарь (модератор): Спасибо, Жень.

Оксана Воробьева: Про security-чемпионов еще хотела добавить. Когда появилась наша группа, я каждый месяц получаю отчеты по уже выявленным в проде или на тестах. Такой обмен опытом. Очень разрозненная разработка и очень много направлений от телекома до банка и так далее. И они смотрят на друг друга. У каждого есть какие-нибудь кошельки, у каждого есть биллинги, у каждого есть еще что-то. Очень интересно, что они, даже обмениваясь опытом между своими кластерами, понимают, что если на это не обращать внимания, в следующий раз ты это тоже так же встретишь. А оказывается, в рекламе была такая-то проблема с кошельком и оплатой или еще что-либо. То есть отчеты у нас идут, они открыты, за это никто не наказывает. Реально обмен опытом идет.

Максим Морарь (модератор): Спасибо, Оксана.

Максим Чернухин: Можно я немножко добавлю? Залог успеха — договориться с безопасностью. В моем личном примере было, что они тебя, скорее всего, не слушают. Прям серьезно. Все новое — по умолчанию небезопасно. Когда ты в этом разбираешься, начинаешь говорить на их языке, то они начинают прислушиваться.

И на самом деле как раз вот эта командность тоже создалась. И есть вот Infrastructure as Code. Кажется, что это уже популярно, и все знают. А мы с ними начали в итоге приходить к Security as Code. Мы запрашивали доступы сетевые тоже через pull request. Я думаю, что это была победа. И когда мы проводили потом в «Альфе» какой-то митап про Cloud Day, я от безопасника столько раз слово «команда» никогда вообще не слышал. За одно выступление раз 20 произнес слово «команда» вместе с ИТ. Это было потрясающе. Но для того, чтобы туда прийти, надо самому в это тоже вложиться, в этом разобраться. Лично мой опыт. Возможно, сейчас уже что-то поменялось для того, чтобы как-то с ними построить коммуникацию.

Максим Морарь (модератор): Это очень позитивный тренд, мне кажется. Очень хорошее изменение. Но точно надо вкладываться. Тезис про то, что все новое априори небезопасно — интересно. Такой Zero Trust на уровне идеи вообще. Круто.

;

Замещение импортозамещения

Максим Морарь (модератор): Давайте на этой ноте плавно переходить к следующей теме. Опишу ситуацию, как мы ее видим. И сформируем из этого некий тренд. Попробуем пообсуждать.

2022 год. У всех на волне масштабное импортозамещение, надо бежать быстро, надо что-то внедрять. Были выбраны какие-то решения. Заказчики из разных классов, неважно, виртуализация, база данных, почтовые сервисы, сервисы коммуникации и так далее. Были сделаны ставки. Сейчас 2025 год, ситуация где-то накалилась, где-то наоборот подутихла. И стало понятно, что те решения, которые были выбраны в 2022, развиваются не так, как хотелось бы, не соответствуют уже актуальным требованиям. То есть ставка была сделана неверно.

Мы эту историю отчетливо начали замечать в 2024. А в 2025 заметили, что она стала очень повторяющейся. И мы назвали это «замещением импортозамещения». Внутри себя мы это так называем. То есть когда российские решения приходят на смену другим российским решениям, на которые была сделана ставка неправильно чуть ранее.

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

Иван Эрих: В «Газпром нефти» только успешные кейсы импортозамещения, поэтому можно следующий вопрос.

Максим Морарь (модератор): Я поэтому сказал «если можешь».

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

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

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

Мы не стали выбирать, мы просто с несколькими производителями, разработчиками пошли в этот путь. Понятно, что нет ресурсов, чтобы 5-6 продуктов параллельно тестировать и так далее. Очень много затрат на это нужно. Но мы старались всегда выбирать 2-3 потенциальных решения и заходили в цикл тестирования. Дальше, если тестирования прошли, начинали постепенно заниматься внедрением с менее критичных контуров. И по ходу появляются кейсы, продукты, которые отваливаются, потому что они не выдерживают целевых требований.

У нас был такой живой кейс как раз по виртуализации, когда мы заходили с одним продуктом, я не буду его называть, не хочется никому антирекламу делать. Вроде мы успешно прошли все предварительные тестирования, но когда вышли в живую нагрузку, то есть когда развернули на этом кластере 500-600 виртуальных машин тяжелых, у нас этот кластер просто развалился. Хорошо, что это была зона тестирования, не самые критичные процессы мы специально выбирали, но тем не менее это произошло. Сказать то, что мы не прогнозировали такую ситуацию, я не могу. Было понятно, что как себя поведет эта инфраструктура под нагрузкой, пока не проверим, не узнаем. Но при этом были рядом альтернативные решения, на которые мы смогли потом это перенести.

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

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

Максим Морарь (модератор): Очень круто. Слушай, вот стратегия шорт-листа и диверсификации, а дальше победит реально сильнейший, мне лично очень отзывается, я бы точно так же действовал в этой ситуации. А при формировании этого шорт-листа вы самостоятельно тратите огромное количество времени на анализ 100500 решений по той же виртуализации, например? Или вы здесь интегратора подключаете? Доверяете ли вы интегратору выбор этого шорт-листа, помощь в выборе?

Иван Эрих: Мы прислушиваемся к мнению интеграторов, к мнению отраслевых партнеров. Все параллельно что-то тестируют, выбирают. Было бы глупо не пользоваться этими наработками, как-то их учитывать. Это не отменяет того, что мы не просто верим в эту фактуру, проводим какие-то тестирования. Мы, безусловно, все это проводим у себя.

Ценность интегратора заключается в том, что когда вы уже выбираете какой-то конкретный продукт и заходите в процесс внедрения, там без него сейчас, к сожалению, не обойтись. Те времена, когда у нас были крупные экосистемные вендора, которые могли позволить себе в том числе обеспечить весь процесс работы с инцидентами в процессе внедрения, интеграции и так далее. Условно, Microsoft, да? Это время ушло. Сейчас ни у производителя, ни у заказчика в таких крупных масштабных проектах ресурса на то, чтобы обеспечить сопровождение внедрения, нет. Мне кажется, сейчас роль и ценность интегратора обрела совершенно новый смысл. Даже сейчас по крупным проектам, где мы ведем активность, у нас всегда треугольник. У нас есть заказчик — наша экспертиза, у нас есть вендор, у нас есть интегратор. В этой связке и есть конечный успех.

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

Максим Морарь (модератор): 100%. Максим, а вот на рынке данных, видишь ли ты этот тренд «замещения импортозамещения»? Есть ли у вас кейсы, когда вы меняете российское на российское? Какой вывод из этого можно сделать? Это рынок меняется или что-то другое?

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

Вообще-то говоря, вещь достаточно тяжелая — СУБД менять. Фактически это хранилище новое создавать нужно. И тут действительно можно поэкспериментировать, потестировать разные решения, но тут проблема курицы и яйца. Пока не «грузанешь» конкретно аналитическое хранилище, ты не поймешь, это решение работает или нет. А чтобы его «грузануть», нужно такие контуры развернуть еще под несколько альтернативных решений. Мало кто себе это может позволить чисто экономически и по временным характеристикам. Поэтому я не знаю, как в других классах решений. Может быть, можно развернуть несколько почтовых агентов, серверов и посмотреть, как они работают. Но с СУБД, мне кажется, полноценный тест с созданием какого-то тестового хранилища, с интеграцией достаточно сложно сделать. Придется все-таки прыгать в этот омут, может быть, с надежным интегратором, который имеет опыт внедрения похожих крупных решений хранилищ, с вендором, которого ты протестировал и доверяешь.

Максим Морарь (модератор): 100%. Здесь специфика решения очень сильно накладывается. С СУБД как с женой. Выбираешь один раз на всю жизнь. В идеале, конечно. А там как пойдет.

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

Евгений Шишков: Да, давай. На самом деле ты даже не первый проспойлерил. Максим Березин в своем выступлении в начале даже процент рассказал, что 26% — это миграция с отечественных решений, которые были выбраны ранее, на наши решения.

И настолько этот тренд стал заметен, что мигратор, который у нас есть, мы его считали одним из основных инструментов на начальных этапах, потому что мы же понимаем, что само решение, сам продукт в отрыве от процессов, которые происходят в заказчике, он веса такого не имеет. Если мы говорим про смену виртуализации, значит, тебе надо мигрировать то, что у тебя есть. У нас был фокус на написание мигратора с VMware на zVirt, потом с Hyper-V на zVirt, а теперь мы добавляем миграцию с других систем виртуализации отечественных на себя. Потому что запрос такой сформировался. Это точно можно назвать трендом.

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

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

Максим Морарь (модератор): Время покажет. Спасибо, Жень.

;

Поливендорная инфраструктура в гибридной среде

Максим Морарь (модератор): Давайте поговорим про решения и про инфраструктуру, но в более высокоуровневом формате. Я плавно перехожу к четвертому блоку. Он у нас посвящен следующей теме:

Ни один продукт в ИТ-ландшафте компании не живет в вакууме. Ему нужно интегрироваться в огромное количество тех сервисов, которые уже в компании внедрены. И это не всегда российские сервисы. Где-то они российские, где-то это зарубежные системы, где-то это Open Source. И особенно явно здесь была проблематика в 2022-2023 годах, когда происходило массовое импортозамещение. И, условно, внедряя виртуализацию, был вопрос, а что с бэкапом? А что с AD? А как это все вместе будет работать? И это подталкивало рынок на создание технологических альянсов, партнерств.

Как сейчас с этим обстоит. Иван, расскажи, пожалуйста, есть ли сейчас проблемы с внедрением любого российского софта в ваш ИТ-ландшафт, проблемы совместимости с общим стеком? Где они, как вы их решаете?

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

Причем мы даже себе такую стратегию поставили. У нас есть общий ландшафт, все это поделено на сегменты, там и общесистемное программное обеспечение, прикладное и так далее. Мы хотели бы иметь 2-3 альтернативы в каждом сегменте. Понятно, это применимо далеко не везде. В случае с операционной системой такая странная и сложная задача — иметь две операционки, когда даже под одну выполнить весь объем работ по адаптации приложения для работы — огромный объем работы. Поэтому, безусловно, это правило применяется не для всего ландшафта, но именно там, где мы можем эту диверсификацию произвести. И дальше мы работаем с каждым из этих продуктов.

Если говорить в целом, есть ли такой тренд на экосистемность, скажем так. Мне кажется, что он в любом случае есть, потому что если даже открыть текущий каталог российского программного обеспечения, операционные системы, там будет 40-50 строчек. Но при этом мы же понимаем, что по сути весь рынок поделен между 4-5 игроков, 99%. И этот тренд на глобализацию происходит. Постепенно укрупняются решения. Какие-то мелкие, незрелые решения либо исчезают, либо их поглощают. И даже если сейчас взять одного из этой пятерки производителей операционных систем, он уже в своем продуктовом портфеле имеет множество разных сервисов. И по управлению инфраструктурой, управлению доменами и так далее. Это уже все равно какой-то набор продуктов. Очевидно, когда ты используешь решение, входящее в этот портфель, тебе гораздо проще это все интегрировать и так далее. Поэтому в любом случае такие экосистемные моменты будут проявляться, будут возникать. И, наверное, в этом ничего плохого нет.

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

Максим Морарь (модератор): Слушай, а стратегически есть у вас какой-то фокус на больше поливендорные сценарии и разделение задач по разным решениям от разных производителей? Или если есть экосистема, которая глубоко интегрирована, поставляется, экономит вам время на внедрении, устраняет проблемы на стыке продуктов, то для вас это отличная возможность, оптимизировать и кост при внедрении и прочее, и прочее?

Иван Эрих: Наверное, в общей массе мы за поливендерный подход. Объясню почему. Потому что у нас большое количество сервисов уже в компании реализовано. То есть, когда к нам приходят производители и говорят коллеги: «Вот у нас платформа, которая включает в себя все». Возникает вопрос, а что делать с уже существующими сервисами, которыми мы занимались и так далее.

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

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

Максим Морарь (модератор): То есть вы здесь достаточно гибки и с точки зрения принятия решений, и с точки зрения того, чтобы принять в будущем другое решение и отказаться от того, что было принято два года назад.

Иван Эрих: Мы стараемся, да. Единственное, что мы эти решения можем очень долго принимать, но стараемся.

Максим Морарь (модератор): Это круто. Давайте я выскажу тезис, а вы, пожалуйста, поддержите или наоборот попробуйте поспорить. Будущее на самом деле за экосистемами, но экосистемами гибридного типа. С точки зрения того, что важно при создании экосистемы не замыкать клиента на вендорлок. Например, ты делаешь виртуализацию или кубера, которые не работают ни с чем другим, кроме твоего фундамента, твоего ландшафта.

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

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

Максим Чернухин: Я думаю, что тезис классный. Мы, допустим, держимся как Vendor-Agnostic. Если мы понимаем, что есть какое-то решение, потенциально это решение может поменяться как-то. Получается мы должны так его заинтегрировать, чтобы в любой момент мы бы максимально дешево произвели change.

И как раз основная история, которая там есть, — это Vendor-Agnostic. Получается, что пишутся интерфейсы, которые максимально изолируют бизнес-логику, и дальше ты там уже что-то используешь. И если вдруг мы понимаем, что у какого-то вендора есть что-то очень классное, что «бустит» нас по скорости, то мы это используем. Но у себя держим в голове: «Так, хорошо, а если вдруг мы от него уйдем, то что нам нужно будет сделать? Где-то еще найти похожее или самим это написать?» Это в любом случае приходится держать в голове.

И исходя из этого, как раз то, о чем ты говоришь, — экосистемы или не экосистемы. Тут вопрос, какие экосистемы? В идеале экосистема — это то, что тебе дает добавочную стоимость. Потому что, честно, таких экосистем я особо не видел. Все говорят: «У нас экосистема», а потом ты заходишь в один из модулей этой самой экосистемы, и он говорит: «А напомни твою фамилию, введи имейл» Где экосистема? И я сейчас не говорю про что-то более низкоуровневое. Это про разные экосистемы, и желтые, и зеленые, и так далее. И тут вопрос, что как минимум надо бы научиться экосистемы крутые создавать. Это первое. Так чтобы у тебя и правда была возможность давать компаниям жить в этом Vendor-Agnostic. Если ему будет необходимо, он сможет и другую экосистему использовать. Это первое.

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

Эта история должна создаваться непосредственно в тесном контакте с заказчиками, которые эти экосистемы используют. Потому что тебе надо понимать, а как они со своей стороны будут это использовать. Кажется, что у нас есть экосистема, есть какие-то скрипты, которые мигрируют одно туда, этот скрипт проходит 3 дня, а если упадет, надо опять запускать. Такое себе, кажется. Возможность мигрировать в одну и в другую сторону.

Я о том, что если мы что-то создаем, то классно, чтобы это был бы win-win. Это win на стороне вендора, win на стороне заказчика. И других вендоров в том числе, и других заказчиков в том числе. Эти решения, где выигрывает каждый, будут жить дольше. В этом есть стратегия, куда хорошо бы идти.

Максим Морарь (модератор): Супер, спасибо.

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

Вопрос. А готовы ли вы это принять? Или вы уже приняли, может быть? Максим, предлагаю тебе начать.

Максим Пустовой: Нет, не готовы. Во-первых, мы тут заперты на этом рынке размером 1% от мирового. И чем дальше, тем больше конкуренция будет усиливаться. Прямо скажем, никаких стимулов кооперироваться, допустим, для совместного завоевания сейчас иностранных рынков у наших российских вендоров нет. Но это мое сугубое убеждение. На собственном опыте я не раз проходил. Рынок маленький достаточно, игроков много, конкуренция усиливается, поэтому, я откровенно говорю, навряд ли мы будем стараться как-то так писать свои СУБД для того, чтобы их легко было подменить нашему уважаемому заказчику. Нет.

Где-то кооперироваться нужно, безусловно, но это слоями ниже и выше. Допустим, операционные системы. Мы запартнерились, адаптировали, друг на друга смотрим с производителями российских операционок. Прикладные решения, те же CRM-системы, может быть, ABS-системы. Да, безусловно, мы с ними кооперируемся. 1С. Это важно и для нас, и для них.

Но делать софт, который легко заменяем, ради какого-то, честно говоря, достаточно иллюзорного интереса, экосистемных мотивов, непонятно. И, честно говоря, я вообще не верю, что это работает. Потому что даже возьмем СУБД, допустим. Есть протокол работы с хранилищем в формате S3. S3 — универсальный формат. IP один и тот же. Ты можешь использовать хранилище через интерфейс S3. Но этих S3 несколько. Они под разный вид нагрузки. Они под разный формат использования данных. Когда ты доходишь до этого понимания, ты понимаешь, что это скорее мечты на предмет каких-то универсальных API, какой-то микросервисной инфраструктуры. Звучит хорошо, а на практике это ломается. И через конкуренцию, и через техническую несовместимость.

Про операционки. Это адище вообще, я вам скажу. Это просто издевательство. При том, что их там несколько. Но это там Astra, несколько версий, сертифицированные и не сертифицированные, более старые. Заказчики некоторые застряли на старых. У тебя все это должно работать. Red OS, та же фигня. Пойдем дальше. SberOS, МосОС, кто-то на CentOS сидит, кто-то еще на Ubuntu.

То есть для российского вендора CУБД сейчас жизнь отвратительна, если мы говорим про совместимость с операционными системами. Рынок вообще ни разу еще не консолидировался. Он пока еще в отвратительном состоянии. Я не знаю, как вам живется с виртуализацией, но полагаю, что у вас та же фигня.

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

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

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

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

Максим Морарь (модератор): Спасибо, Женя.

Оксана, финализируй, пожалуйста.

Оксана Воробьева: Я верю в конкурентное партнерство. Явно, что история экосистемы, когда все-таки открытые API, и когда у тебя нет какого-то решения, но оно есть у партнера, и можно, в принципе, легко интегрироваться и предложить это вместе. Почему нет?

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

Максим Морарь (модератор): Спасибо, Оксана. Очень здорово, что у нас мнения разделились. Это всегда полезно и интересно. А каждый наш слушатель может сделать для себя уже свои собственные выводы.

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

Спасибо, друзья!

;

zVirt