Анализ и проектирование систем *

Привет, Хабр!

Собрать Lakehouse на слайде несложно. Берём S3-совместимое хранилище, добавляем Iceberg, Spark, Trino, Kafka, Airflow и каталог данных. Получается современно, масштабируемо и архитектурно красиво. Гораздо сложнее сделать так, чтобы эта конструкция работала в определенных корпоративных сценариях. В статье попробуем отделить архитектурную концепцию от маркетинга и разобраться, как на самом деле идут проекты внедрения Data Lakehouse в России: какие решения доступны на рынке, какие проблемы платформа не решает, когда её внедрение имеет смысл и как выбрать подход к миграции.

Полтора года назад разговор про AI и архитектуру обычно сводился к одному вопросу: насколько быстрее теперь пишется код. Сейчас вопрос звучит иначе. Если значительная часть проектирования и реализации переходит к AI‑агентам — что происходит с самой системой принятия архитектурных решений?

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

Эта статья — про несколько вещей, которые выглядят совершенно по-разному в зависимости от того, с какой стороны экрана ты сидишь. Будет полезно и аналитикам, которые ругают «криворуких вендоров», и разработчикам, которые не понимают, почему их идеальное правило ненавидят в SOC.

В прошлой статье мы разбирали, как передать копию базы 1С подрядчику без реальных персональных данных.

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

Например, попросить:

← Предыдущая глава

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

Допустим, вы построили конвейер передачи данных. Собрали множество агентов в нужную вам конфигурацию, например в последовательную цепочку. Прогнали ее на контрольном множестве примеров и получили ожидаемые результаты. Более того, в большинстве случаев система работает в допустимых рамках, но на определённых вопросах просто рассыпается. И тут помимо удивления возникают вопросы — почему так и как все исправить? Самое быстрое решение — доработать промпты. Но правка промптов, написание скилов это в каком‑то смысле поиск пути наощупь. Причина, по которой ваша мультиагнетная система (MAS) может резко изменить своё поведение весьма вероятно кроется в свойствах системы, а не отдельных её частей.

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

Разбор всех видов SCD (slowly changing dimensions) по Кимбаллу:
— от простого к сложному
— на примерах
— с цитатами Кимбалла

В конце обзора — заполненная шкала со всеми типами и подсказками

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

Для тех, кто держит или собирается держать LLM внутри контура: тимлидов, DevOps, архитекторов. Здесь конфиги, цифры и грабли, а не введение в трансформеры.

Что вы унесёте: историю пяти последовательных конфигураций с тем, что каждая дала и чего стоила; рабочий набор флагов vLLM под одну карту Blackwell; три неочевидных бага и обходы; разбор реального счёта с отношением вход/выход 452:1.

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

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

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

Возможно, подписки можно как‑то объединить в единый пул? Именно этот вопрос мы будем рассматривать в нашей статье

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

Сложности начинаются, когда такого агента нужно запустить в проде.

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

Я работаю в офисе (вспоминается песня "Ленинграда") и моим основным рабочим инструментом уже очень долгое время является Excel. Рискую показаться предвзятым, но на мой взгляд Excel - это лучший продукт Microsoft. И вообще электронные таблицы, как класс приложений, - это абсолютно гениальное изобретение человечества. Наверное многие считают из злом, но давайте пройдемся по фактам:

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

Привет! Меня зовут Игорь. В статье рассказываю про инструмент для бэкапа сообщений из VK с сохранением вложений.

Почему PLM-системы не понимают ЕСКД: от проблемы совместимости к проектированию собственной модели данных

Разработчики описывают изменения кодом, инфраструктура — декларативными манифестами, а архитектура до сих пор часто живёт в draw.io и PNG. Почему диаграмма без модели быстро устаревает и как собрать архитектурный control plane из знакомых деталей: API server, графа, CMDB, diff/review и operator pattern? А может нам нужно решение с ResourceDefinition, типизированными связями, Temporal workflows и change sets.

Обзор возможностей nanoCAD BIM ВК для проектирования водяных систем пожаротушения: расчёт оросителей по СП 485.1311500.2020, гибкая настройка параметров помещений, автоматическая расстановка фитингов, цветовая индикация труб и оросителей, гидравлические отчёты и интеграция с 3D-моделью. Всё в одном инструменте – от расстановки оборудования до выпуска документации.

Привет, Хабр! На снова команда Research & Insights Центра стратегии цифровых продуктов МТС. Мы уже разобрали мировой рынок 5G и объяснили, почему в России нельзя взять и «включить» эту технологию. В этой статье поговорим о том, кто и за что будет платить…

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

В какой‑то момент я осознал, что у меня много источников данных, есть мощная машинка в виде MacBook Pro M4 Max со 128 гигами оперативки, и надо как‑то это объединить, чтобы эффективно использовать. Всё же такую покупку согласовывали под использование ИИ, а не просто так я решил потратить деньги.

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

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

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

В статье не буду рассказывать о том, как установить Hermes, подключить Codex и наслаждаться. Будут локальные модели, виртуалки, шишки и преодоление в истинно инженерном стиле.

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

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

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

Мне кажется, мы сейчас примерно в такой точке отношений с LLM.

Большая языковая модель за несколько минут способна сделать то, на что раньше уходили дни работы аналитиков, архитекторов и дизайнеров. Она нарисует архитектуру предприятия, бизнес-процесс, карту функций, модель управления, структуру исследования, концепцию продукта, требования к ERP, презентацию руководству. Всё получится аккуратно, современно и настолько убедительно, что заказчик совершенно естественно может посмотреть на результат и сказать: «Вот оно. Наконец-то всё стало понятно».

Но в серьёзной аналитике после первого впечатления должен прозвучать другой вопрос: что находится за этим холстом?

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

На INFOSTART A&PM EVENT 2026 секция будет посвящена работе с требованиями, данными и знаниями, описанию сложных систем, взаимодействию со стейкхолдерами и повышению качества анализа.