2025-11-09 Нighload: ИИ становится частью ИТ-ландшафта

Короткая ссылка: Highload-2025

Ссылки сюда (3) →

О других конференциях

Дополнение 13.12.2025: #Встреча с Максутом Шадаевым - я посмотрел запись

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

Кстати, эта тема была продолжена на ArchDays, на которой я был после Highload. Про доклады на ArchDays — ждите отчет, но я сразу скажу, что там Газпром Нефть поделился архитектурными схемами, используемыми для построения такого ландшафта, а Greensight рассказал про создание приложений, нацеленных на решение частных задач не хуже больших LLM, и при этом работающих в проде всего на паре видеокарт, обеспечивая приличный поток запросов.

Если делать выводы по теме ИИ в целом, то я бы отметил следующее.

1. ИИ начинает хорошо работать, если вы решаете понятную задачу с конечным эффектом. Например, оптимизируете работу техподдержки, или управление промышленным оборудованием. При этом очень важно, чтобы цикл разработки включал в себя весь цикл внедрения и апробации с реальными пользователями, а не ограничивался просто созданием некоторой системы. Тут ИИ не отличается от другого софта. При этом, как и в случае другого софта, государственные и корпоративные заказчики часто заказывают продукт с формальными требованиями и неясным сценарием внедрения, и силы разработчиков уходят на решение ложных задач, а поможет ли система, например, врачу и насколько — остается неясным.
2. ИИ надо не только первый раз научить и настроить, его надо доучивать постоянно. И надо проектировать цикл обновления, как часть продукта. При этом уже понятно, что для многих групп пользователей будет важна возможность добавить собственный контекст, учесть специфику предприятия. В той же медицине — многие клиники разрабатывает свои методы решения, и если делаешь медицинский ИИ, то надо подумать, как этот контент будут добавлять. Или нефтянка — там тоже свои особенности у каждой компании. Сейчас это в большинстве случаев за рамками проектов, хотя в обычных ИТ-проектах возможность развития закладывают.
3. Ограниченная предсказуемость и воспроизводимость результатов, получаемая при использовании приложений с ИИ, не мешают включению их в ИТ-ландшафт. Да, есть особенности, но не более того. Да, для разбора инцидентов нужны подробные логи, и о них надо позаботиться, но так устроено и во многих других приложениях. Цикл ML-ops — некоторый гибрид DevOps и DataFlow, тут тоже нет проблемы.
4. Достигать решений с использованием ИИ можно двумя способами: грубой силой, беря мощные платформы и вычислительные мощности, или тонкой настройкой, учитывающей содержательную специфику решаемой задачи. Тут полная аналогия с базой данных: мощная железка позволяет не строить индексы и хранить данные абы как, а если вы погрузились в содержание и построили конкретное решение, то можно получить выигрыш на порядки. При этом разработчики часто предпочитают грубую силу, а не погружение в содержание. А приходится.

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

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

Бунин и команда. Новые продукты Онтико

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

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

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

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

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

• Tech kitchen. Группа свободного поиска в мире Полудня Стругацких. Чистый серфинг, лента или шоу погружения в новые технологии. Цель — уменьшить время с появления технологии до распространения в больших масштабах. ИТ-сообщество 1.6 млн, а сообщество Онтико — 5к докладчиков и 15к участников. Поэтому надо запустить это как СМИ, чтобы было широкое распространение. Взяли площадки, начали делать контент. Апробация показала, что доклады заходят, если спрашивать и комментировать — получаются эксклюзивные шоу. Можно присоединиться и поучаствовать. Если люди все равно тупят в ленте, то то почему бы не тупить в прикольных профи-рилсах? И они подумают вытащить туда обсуждения трендов на внутренних встречах ПК, которые происходят при подготовке конференций. Как участвовавший в ПК Knowledge Conf могу подтвердить, что на таких встречах действительно много интересного.
• OnticoGPT. Инженеры тратят долгое время на задачу поиска и выбора решения. А тут можно задать вопрос, получить ответ на основе 6к докладов, со ссылками на видео. Скоро появятся тайминги. Проект делают совместно с сибирскими нейросетями. Под капотом — два пайплайна, первый по сбору и индексации, там мультимодальный контент сегментируется по переключениям слайдов, получается примерно 200к семантических векторов для поиска. И пайплайн поиска: тип вопроса, источник для поиска, вопрос переписывается так, чтобы было понятно для поискового движка — с учетом контента разговора, дальше идет в один из 6 поисковых движков, а потом LLM формирует ответ, и он трассируемый на конкретное место контента. Изначально было 400Gb контента, они профильтровали, выбрали лучшее — 2Gb, там одна A100. Ответы лучше, чем спросить LLM без базы знаний, но насколько лучше — зависит от методик оценки, тут не понятно. Сейчас это доступно для всех.
• DevNavigator. Карьерный GPS в ИТ. Базовые навыки — общие навыки — узкие специализации. И дальше ваш выбор: углубляться или иди в смежные области. Доступно в личном кабинете. Roadmap по архитектуре: собрали, показали. Можно нарисовать свой маршрут, можно обсудить.
• Запустили клуб профессионалов — это специальный раздел в личном кабинете. Есть профиль, туда накапливаются все достижения. И это не только профиль, но и нетворк. Витрина экспертов, чтобы найти того, кто может решить проблему.
• All CFP. Организация митапов или мини-конференций — долгая, с множеством технических деталей. Они делают поддержку: можно регистрировать мероприятия, собирать заявки, а потом — готовить. Чтобы организатор мероприятия легче прошел этот путь, чтобы сделать мероприятие было легко. Забирают рутину на себя. Для докладчика тоже весь roadmap тоже был виден с самого начала. Задача — подстегнуть создание контента. Чтобы митапы продуцировали контент, который мы бы могли брать и вбрасывать в GPT.

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

Для чего это делается? Есть разница США — Россия — список компаний по капитализации. У Штатов в лидерах ИТ, а у нас — нефтянка, эта ситуация не меняется. Но при этом в мире всего несколько стран, у которых собственный поисковик, антивирус, соцсетка, ОС и так далее, Россия в их числе. Но на деньгах это не отображается.

Выступление — передача такт опыта. Они пробуют за счет этих продуктов стократ увеличить скорость и объем передачи информации. И, возможно, это даст офигенный прорыв. А в перспективе — может и заменят ВУЗы, потому что сейчас на 4 курсе 95 % работают, а выполняют программу ВУЗа, чтобы родителей успокоить.

Андрей Носов из Raft. RAG → GraphRAG → LightRAG: как мы трижды переписывали медицинский AI и кратно снизили издержки

Это был рассказ о создании медицинской рекомендательной системы по госзаказу. Для начала загрузили для поиска MedTech. Там pdf, обычно в две колонки, и множество картинок внутри. И с распознаванием такого контента есть отдельные сложности, они делали кастомные парсеры, потому что стандартные теряли связи между заголовками и строкаи на такой верстке.

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

Для обработки взяли семантический RAG — разбитие на предложения, скользящее окно, разрывы чанков по расстоянию между предложениями и подбор порога. И векторная база — Qdrant для гибридного поиска. Возникают проблемы, например, чанк выделил сущность, а противопоказания ушли в соседний чанк, и будет проблема. Используют GraphRAG, чтобы восстановить семантические связи, характеристики улучшаются, но недостаточно, используют NER и Relation extraction, но теперь ломается на аббревиатурах: между аббревиатурой и расшифровкой оказалась большое расстояние. И так далее, в докладе достаточно много деталей по использованным расширениям: Community enhanced RAG, Pathfinding RAG, Hierarchical summarization RAG, Graph Native Chunking, Query Focuced Subgraph RAG.

Результат достигнут, они прошли испытания. Но он оказался очень дорогим, индексация одного документа требует 50к$. И был следующий этап — снижение стоимости, делали LightRAG? используя библиотеку Graph RAG для двойного прохода по графам, из которого строится компактный json, связывающий сущности и включающий низкоуровневые и высокоуровневые сущности. И в результате запрос в LLM получается не 1000+ токенов, а всего 100. А добавлениях новых публикаций оказывается, что не надо пересобирать все, достаточно менять локально структуру графа.

Обработка получается по такому алгоритму: запрос — нормализация — векторный поиск в Qdrant (50 фрагментов) — графовый поиск на основе этих фрагментов — LLM — ответ. А если граф ничего не нашел, то идем в векторный поиск на альтернативный вариант формирования контекста. .Для индексации NER на MedGemma, а поверх — поиск связей на GPT 4o для обогащения. Генерация ответа — 1.5 с. По отношению к максимальной версии 90 % качества и 10 % стоимости.

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

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

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

Николай Пономаренко из Яндекса. GPT в службе поддержки: автоматизация, оптимизация и инновации

Поддержка в Яндексе это 700к тикетов и 1.4 м сообщений в день. Классический способ работы — запрос клиента проходит классификацию, на основе которой оператору показывают варианты шаблонов ответов, он выбирает нужный или может написать свой.

К идее, чтобы LLM сама вела диалог, заказчики относились с недоверием: есть галлюцинации, мало ли, что она ответит и статистика их не убеждала. Поэтому на первом этапе человека не исключали, LLM лишь предлагала ответ оператору, и он мог сам его исправить. И уже на этом этапе скорость возросла на 15 % при том же качестве, которое операторы оценивали. И получив уверенность они перешли на работу LLM без участия человека.

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

По сути, операторы отвечают макросами. Можно посмотреть документы и сказать, какие являются позитивами. А дальше дообучить модели, сделать реранкер. У них получилось три разных модели и реранкер, который объединяет ответы. Генератор сделан на легкой YaGPT Lite, ставить полноценный — дорого. Для него делали датасет: ответы лучших операторов, отфильтрованные на основе LLM, чтобы отобрать хорошие ответы. И получилась эффективная модель.

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

Дополнительно есть пре-фильтр на основе BERT 0.5B, чтобы отсекать вопросы, по которым не хватает информации и провокации. На входе LLM, которая отсекает вопросы. И пост-фильтр на отдельной YaGPT-Lite, который отсекает галлюцинации в ответах.

Дальше возник вопрос — а можно ли сделать еще лучше? В ситуации вопрос-ответ RAG работает хорошо. Но часть базы знаний представляет собой сложные алгоритмы действий, сценарии со ссылками между ними: если попал в такую ситуацию, то иди туда. Там много вложенности, последовательность инструкций. И такую базу знаний надо представлять в виде графа. И пройти по графу при обращении. GTO — Graph Traversing Operator.

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

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

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

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

Для генератора — идет дополнительный анализ для выбора промпта, используемого для генерации ответа, а в зависимости от промпта — разная обработка ответа. Ответ надо не просто выдать клиенту, его надо обработать: если LLM дала промокод или компенсацию, то это должно быть отражено в системе.

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

Начали с письменной поддержкой — она проще. Теперь идут в голос, идея — докрутить то же решение.

Вячеслав Кудряшов из Сбера. Как сохранить высокую надежность при GenAI-трансформации

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

1. Нужна единая среда исполнения агентов. Идентификация агентов, идентификаторы операций, по которым в логах можно восстановить происходящее для разбора инцидентов.
2. Агенты-лодыри неработоспособные. Надо проверять, что агент работает, health check — маленькое тестовое обращение при запуске.
3. Недетерминированная логика работы LLM делает невозможным восстановление при сбоях, поэтому необходимо хорошее логирование, нужно сохранять версию агента, кто запустил, при каких условиях. Без трассировки разобраться нельзя, потому что нет воспроизводства.
4. Агенты могут провоцировать инциденты при выходе за нормативные границы, например, уходя в бесконечные циклы, вызывая ресурсные коллапсы. Сервис не предоставлен, а токены израсходованы. Решение — из обычного ИТ, предотвращение зацикливания, например, как в сетевых пакетах.
5. Агенты могут стучаться в закрытую дверь, к неработоспособному сервису — поставьте ограничения по retry.
6. Подумайте, как избежать паралича бизнес-процессов при отказах агентов. Если сделали агента, который заменяет сотрудников, чтобы те занимались другими задачами, а агент перестал работать, клиент должен получить обслуживание. Нужен business community plan. А на переходном этапе надо уметь отключать агентов, возвращаясь в обслуживание людьми. Правда, тут проблема с теми процессами, которые с ходу строят на основе агентов.
7. LLM не должна превратиться в единую точку отказа, чтобы не было коллапса высоконагруженных бизнес-процессов из-за нехватки производительности. Нужно управлять доступом, ограничивая доступ в критических ситуациях. StopEvent для агентов разной критичности, и закладывать это в сценарии работы.
8. Бывает массовый сбой агентов из-за скрытых несовместимостей с новыми версиями. У них GigaChat постоянно обновляется, люди, которые выпустили говорят «стало лучше, сейчас всех обгоним», метрики растут. Но агенты могут начать вести по-другому, неожиданно. Нужно два контура с разными версиями, постепенное переключение трафика и оценка работы новой версии.

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

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

Денис Цветцих. 50 оттенков Transactional Outbox

Есть задача: надо изменять базу и передавать сообщения, обеспечивая консистентность. Если сообщения передавать сразу, то при откате транзакции изменения базы пропадут, а сообщения — уйдут. А если их накапливать и передавать после коммит, то сервис может упасть после коммит, не передав сообщения. Поэтому мы записываем очередь сообщений в базу, вместе с другими изменениями, а потом отдельный сервис обеспечивает их передачу — это и есть паттерн Transactional Outbox.

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

Сергей Олейников из РТЛабс. Прощай, Oracle! Здравствуй, Scylla! — (совсем не) квантовый переход ленты уведомлений на Госуслугах

Госуслуги — это 150 млн записей, 15 млн активных пользователей, 2 млн услуг в сутки и 160 тыс. rps пиковая нагрузка. Лента уведомлений — статусы заявлений, штрафы, просроченные документы и так далее — коммуникация всего 12 млрд в год, 12 млн в сутки.

В 2021 Oracle начал тормозить, хотя стоял на очень хорошая железка. Как правило, потому что разделял ресурсы с другими сервисами, на нем работали не только уведомления, а еще нагружали джойны и массовые вставки. Так что они начали думать про переход раньше, чем Oracle ушел. А когда он в 2022 ушел и последовал приказ Президента про импортозамещение — вариантов не осталось.

Требовалась бесшовная миграция при высокой нагрузке. А чтобы был задел на будущее — повышенные требования : 4000 вставок в секунду, 300 млн в сутки, возможность A/B тестирования, работа без downtime.

Рассматривали варианты PostgreSQL, Cassandra, которую использовали одноклассники и ScylaDB — на ней работает discord. Начали на Кассандре, но Сцилла оказалась быстрее, больше компактизация, и еще ряд преимуществ, в презентации был слайд. И в ней есть CQL, который похож на SQL.

Архитектура системы: 2 датацентра active-active, общая Кафка и Oracle (мастер+2 standby), и 10+ микросервисов. Госуслуги нельзя поставить на паузу. Поэтому микросервисы на переходном этапе работали с Oracle и Сциллой параллельно. Сначала мастер — oracle, потом переключали. При этом Сцилла развернута в каждом датацентре отдельная. Мигратор написали самостоятельно — балансировка нагрузки, чтобы не убить, и хранить состояние — если что-то не так, чтобы работало. Сохраняли первичные ключи Oracle сохраняли, чтобы работали ссылки из старых писем. И мониторинг миграции через метрики.

Сделали асинхронной — user migration topic. В Oracle хранили состояние каждого пользователя, ставили старт, и отправляли в user migration topic, сообщения — record migration topic. Вставляли в Scylla пачками, потом ставили признак, что мигрировано. С момента запуска сцилла-реплик все новые уведомления писали в сциллу одновременно. Отслеживали тайминги и latency.

Как проверить данные? Исторические наслоения накопилось с 2011 года, все варианты проверить нельзя. Поэтому проводили тестирование на бою: запрос идет с Oracle, дубль — со сциллы, результат сравниваем. Но пользователю результат Oracle выдаем сразу, не ждем Сциллу. И второй механизм — сравниваем ответы oracle и scylla по логу запросов.

Переключение пользователей на Сциллу — поэтапное. Сделали через куку, если она есть — то идем в сциллу. А если нет — то проверяем статус миграции, и ставим куку, если мигрирован, и делаем internal redirect.

Проблемы и их решения.

• Ограниченные агрегации сцилла — базовые функции и только внутри партиции. Зато партиции в сцилле крайне эффективны.
• Про join забудьте, where очень ограничен. Нет null, not, or, like и так далее. Зато есть map-reduce. Пользователь, заходя на госуслуги получает какие-то уведомления. Типы — по партициям, и разбиваем параллельно, потом результаты — объединяем, упорядочиваем по дате, обрезаем. А вместо join — обогащение данных.
  

• Отсутствие транзакций.
  • LWT — можно проверить наличие в базе (upsert), но читает она при этом сложно, это долго.
  • batch — можно объединить запросы на вставку и удаление — но только в рамках партиции. Для разных партиций — долго и дорого, не работает.
• Не читать всю запись перед обновлением, надо обновлять отдельные поля, которые меняются, а не все, потому что нет транзакций.
• Не допускаем больших партиций. Если мы делим партиции по пользователям, а у пользователя много данных — будет очень плохо. Они разбивают уведомления по типам, а еще лучше предусмотреть поле bucket: сначала — константа, а потом можно писать год или даже месяц.
• Есть системные таблицы — large patrition — можно проверять и дальше разбираться.
• Кластерный ключ позволяет сортировать, но при разрастании партиции ей придется сначала прочитать, все, потом отсортировать — надо, чтобы по кластерному ключу работало
• Сложность развития — на оракл и сцилла. Они обобщили и унифицировали фичи для нового — ограничили оракл.
• Лучше обновлять, чем удалять. Есть type, он входит в ключ. И они специальным образом меняли.
• Только асинхронные запросы. Синхронные — очень плохо, потому что ограниченный пул потоков.
• Отказ нод и недоступность дата-центров. Есть классы, отвечающие за retry-политики. Они написали свой, чтобы видеть бизнес-метрики и мониторить ситуацию.
  • Сначала запрос внутри датацентра с кворума 3 нод. Если не получилось — retry уже без ограничения на датацентр. И ведем инциденты
  • Аналогично при записи — записать в датацентре, если нет — то куда-нибудь.
• Аналитику проектируем отдельно. Проектирование базы Scylla вообще идет от запросов.

По результатам Scylla 2-3 раза быстрее на чтении и порядок на вставке в сравнении с oracle. Сейчас в лицензии изменились ограничения открытой версии, но им хватает с запасом.

Иван Мареев из ЦУПИС. Эволюция архитектуры платежной системы: сохраняем SLA 99,99 при росте нагрузки в 30 раз

Речь идет про процессинг переводов по номеру телефона, на основе которой сделана оплата по QR-коду. Рост нагрузки в 30 раз — за 7 лет, с 20 до 600 RPS. Я пришел на доклад не с начала, слушал только историю преобразований с 2022 года, когда начали делать параллельный процессинг. И там есть интересные моменты.

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

Сделали классы обслуживания по типам платежей. Новый платеж направлялся на случайный узел, но с учетом типов платежей.

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

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

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

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

Встреча с Максутом Шадаевым

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

1. Разговор был очень конструктивным и по существу. В теории органы управления примерно так и должны общаться с профессиональным сообществом, а на практике такая открытость встречается не часто. Но и не является уникальным исключением, в эту сторону есть сдвиги.
   1. Шадаев взял обязательство устроить встречу провайдеров интернета с Роскомнадзором, наверное, не в открытом формате, но чтобы было много компаний. Потому что был вопрос, что Роскомнадзор общается с 2-3 крупными, а до остальных решения доводятся, и не учитывают специфики небольшого масштаба.
   2. Youtube блокировка – доколе? Ответ. Я могу ответить как чиновник: надо выполнять законы. А как человек и министр считаю: чем больше сервисов – тем лучше, но при равных условиях. Youtube блокирует жестко, без объяснений, не ведет коммуникации – это ведет к блокировке. Хотя ситуация сложная, есть риски блокировки в AppStore, или блокировке Android, тут блокировками не ответишь…
2. Образование в условиях, когда у всех учеников есть DeepSeek (или другой ИИ), и ИИ начинает широко применяться в компаниях. Я вынесу эту тему вперед – она важная. Пока задача решается тактически, хотя понимают, что есть стратегическая составляющая.
   1. Сделали с Яндексом стажировки учителей информатики – это правильно. Я бы тут сказал, что лучше поздно, чем никогда. Потому что еще в 2014 году в Ульяновске эту задачу успешно решали на региональном уровне в кооперации ИТ-сообщества, ВУЗов и местных властей, я был на публичном обсуждении этих решений на стачке (отчет).
   2. Прямо на встрече договорились запустить работу, чтобы облегчить нормативное регулирование для привлечения ИТ-специалистов в качестве преподавателей. Сейчас бюрократический налог очень велик, как сформулировал Олег Бунин «я готов потратить два часа, чтобы прочитать лекцию, но не готов тратить еще шесть, чтобы ее оформить по правилам». Конечно, тут утрировано, есть еще время содержательной подготовки, но если ИТ-шник ведет корпоративное обучение, то там немного. Есть ВУЗы, которые тут помогают специалистом, у них отработаны формы – но так не везде. В каком-то виде этот трек будет.
   3. Министерство ставит вопрос перед ИТ-сообществом о подготовке ИТ-шников. Была большая работа по запуску программ, есть мнение, что сейчас разрыв между отраслью и ВУЗами сокращен и ВУЗы начали готовить студентов так, чтобы выпускника могли взять джуном (ну, министерство полагает, что ситуация – такая). Но ведь, говорят, что джуны больше не нужны будут, их заменит ИИ, нужны будут сразу сеньоры. И что делать? Продолжать программу, увеличивать ее, или сокращать? Мой тут ответ: надо обеспечивать гибкость подготовки. ИТ-отрасль устроена так, что программа подготовки должна меняться каждый год по площади. То есть каждое лето происходит сборка и тиражирование программ подготовки, на основе уже проведенных пилотов. ИТ-отрасль сама не знает, как она изменится с массовым приходом ИИ, но она будет адаптироваться, и если образование будет адаптироваться за ним, каждый год обновляя программу – будет ОК. Но систему надо выстроить.
   4. Реорганизация нужна не только высшему образованию, но и среднему. В принципе, нет проблемы научить школьника достаточно, чтобы он умел программировать. В период, когда всем стали нужны сайты, многие старшеклассники освоили и подрабатывали их созданием. Но общество в целом не готово, что школьники начнут неплохо зарабатывать с 14 лет. В любом случае, программу образования надо пересобирать с учетом ИИ: чему учить, какие результаты. И использовать тут современный продуктовый подход с трассировкой целей образования и получаемых компетенций до конкретного образовательного модуля, подобно тому, как ценность для целевых групп трассируется до фич продукта. Если за единицу взять тему – набор уроков, завершающихся контрольной, то среднее образование – 1-2 тысячи таких фич (10 лет на 10 предметов на 10 тем за год). Много, но обозримо, сопоставимо с большими продуктами. И высшее – тоже. Все как с заменой легаси. А ИИ может помочь в восстановлении существующей структуры, в которой много исторических наслоений.
3. Стратегические цели министерства
   1. 80% ключевых процессов на российском софте
   2. Цифровая зрелость сопоставимо с междунароными аналогами
   3. Развитие отрасли, которое оценивают по доле отрасли в ВВП, за 5 лет его удвоили.
4. В основном министерство работает на операционные, тактические задачи. Стратегические – понимаются, и там, где есть понятный шаг – он превращается в тактику и выполняется. К этому можно по-разному относиться. Например, полагать, что, следуя велениям времени, министерство выделяет MVP или набор приоритетных фич развития и его делает, и это – хорошо. Но вот любые ли задачи можно сделать таким образом – неясно. Особенно это касается задач, с которыми не слишком понятно что делать. Но, может, это разделение труда в государстве, когда правительство занимается только тактикой. Дальше несколько примеров таких задач.
   1. Обеспечить интернет на всем пространстве страны. Это спутники Бюро 1440, все технологии отработаны и испытаны уже на орбите, и предстоит запуск 276 спутников, которые обеспечат покрытие для России. Проект делает компания, а министерство помогает организационно, договаривается про ракеты и так далее. Что будет с проектом дальше – непонятно: есть мнение, что сделать реальную конкуренцию Маску в масштабах земного шара – очень дорого и потому не реально. И думать об этом будут, когда текущий этап будет закрыт.
   2. Национальный мессенджер Max. Его запускают, государству инициировать переход, это возложено на министерство, а люди – не хотят.
      1. Тему подробно не раскрывали, но мне понятно – почему не хотят, потому что еще один мессенджер – это не удобно, у людей сложилась инфраструктура коммуникации, и переход – накладные расходы. Люди, кстати, до сих пор активно пользуются WhatsApp, хотя, казалось бы, Телеграм удобнее. Интересно, проводил ли кто исследования – почему? А еще люди переписываются по всему миру, а не только с россиянами. Ну и с функционалом есть вопросы, но это мне кажется вторичным.
      2. А вообще мне интересно: сами чиновники на Max перешли? Когда в свое время блокировали телеграм, выяснилось, что в куче учреждений он включен в структуру операционной работы, были проблемы. А сейчас?
      3. А вообще телеграм в свое время породил феномен «телеграм-проектов» – люди координировали работу в мессенджере, и делали проекты, которые иначе сделаны бы не были. Но развития внутри мессенджера или интеграции телеграм с системами ведения проектов, таск-трекерами – не произошло, насколько я знаю. Может, для Max это – возможность? В китайском WeChat, говорят, есть enterprise-версия, которая закрывает не только ведение проектов, но и потребность в ERP-системе для не слишком больших компаний.
   3. Еще одна тема связана с переходом на отечественный софт. Сейчас многие компании продолжают эксплуатировать SAP, тем более, что он стал бесплатным, вендору платить не нужно. И это создает риски.
      1. Как это решить чисто экономически, министерство не понимает. Пока есть механизм со-финансирования: если есть заказчик на потенциально повторно-используемое решение, то министерство готово взять половину финансирования под условия будущего тиражирования (насколько оно работает – я не знаю).
      2. Явно не хватает продуктовых компаний. Есть 1С, Яндекс, Postgress. На рынке было множество интеграторов, внедрявших решения зарубежных вендоров, а надо создавать свои.
      3. Над регулированием облаков, чтобы не было проблем с безопасностью, министерство планирует работать. Закон об обезличенных датасетах приняли, теперь видно, что согласовать алгоритм – слабо реально, работают над этим. А создавать гос.облако – не готово, прецедент с Max показывает, что к государственным решением относятся очень плохо. И, я думаю, в подтексте был призыв к сотрудничеству в выработке регулирования, иначе придет гос.облако (могу ошибаться).
      4. На это был встречный вопрос из зала. Есть некий комитет (детали – не знаю), который решил, что национальной ERP будет 1С, и ничего другого не нужно. А есть компании, которые готовы создать альтернативные систему, и у них есть успешный прецедент по финансам для Дом.РФ. Ответ был двойной: конкретные проекты министерство готово поддержать через со-финансирование, если есть крупный заказчик, а про конкретный комитет – просьба подойти и рассказать детали, в чем проблема.
      5. Я тут отмечу, что тут проблема с размером рынка. Министерство не видит этой проблемы, есть мнение, что продавать наружу можно только то, что хорошо продается внутри, и сначала надо освоить внутренний рынок. А опыт развития отрасли говорит, что это неверно. Отечественный и глобальный рынок имеют принципиально разную емкость, и выбор рынка был в самом начале создания продукта. Miro, IDEA и ряд других продуктов создавали именно для глобального рынка – и оно взлетело. А сейчас для глобальных продуктов проще начинать не в России…
5. Было довольно много вопросов по организации и регулированию. Часть – вполне конструктивны, и, в основном, связаны с тем, что решения принимаются в узком кругу без широкого обсуждения, как уже упоминавшийся кейс с обсуждением Роскомнадзора или с комитетом по ERP. А другие – из детской позиции: мы придумали или хотим крутую вещь, дайте нам для этого денег – так дети просят у родителей новый гаджет. Я прокомментирую несколько пунктов.
   1. ИИ очень дорого для небольших компаний, нельзя ли это как-то поддержать? Был понятный ответ: использование ИИ нужно для повышения производительности, и должно окупаться, поэтому основания для такого спонсирования – не понятны. И я тут согласен. Тем более, что знаю про многие кейсы дешевых проектов с использованием легких моделей, которые оказывались не хуже мощных для конкретных классов задач. Тут как с любым софтом: можно пробовать обеспечить быстродействие железом, а можно – тюнить софт. Но пилоты разработки субсилировать готовы на общих условиях.
   2. Датацентр в космосе. Давайте создадим, клево же, дайте нам денег. Может, и клево, но экономика пока непонятна.
   3. Все площадки открытых данных – за рубежом. Ученые готовы выкладывать данные для своих исследований, способствуя развитию исследований, но отечественной площадки нет. Ответ: мы готовы поддерживать инициативы, но не делать государственные площадки. Опыт с мессенджером Макс показывает, что индустрия должна делать сама.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 12:09, 9 ноября 2025 • нет комментариев