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

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

AI-агенты не только научились превращать документ в код. Они могут сделать и противоположное: превратить код обратно в документ. Зачем нам это?

Долгое время действовало негласное правило: продукт = код. И именно вокруг кода выстраивалась вся логика контроля:

Привет, Хабр! Меня зовут Анастасия Черникова, я занимаюсь разработкой компиляторных технологий и инструментов на базе LLVM в Синтакоре.

Неопределенное поведение (undefined behavior, UB) по-разному выглядит с точки зрения компилятора и разработчика. Для первого оно, как правило, открывает дополнительные возможности для оптимизации. Для программиста же UB может стать проблемой, особенно если оно остается незамеченным и не учитывается при разработке.

В этой статье рассмотрим подход к поиску UB с использованием статического анализа. В качестве примера я использую clang-tidy: сначала разберу, как устроены существующие чекеры и как работают AST matchers, а затем покажу, как расширять их и добавлять собственные проверки, если стандартных возможностей оказывается недостаточно.

Данный материал подходит для тех сотрудников, которые не имеют опыта работы или недавно пришли на проект, связанный с хранилищами данных.

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

Информацию описываем вам из нашей практики работы нашего аналитика хранилищ данных.

Работу аналитика хранилищ данных можно разделить на две части:

1. Организация интеграции данных от какого‑либо источника к какому‑либо приемнику;

2. Поиск и решение проблем, связанных с некорректными выходными данными на приемнике, возникающих, например, в результате каких‑либо технических сбоев или изменения требований к предоставляемым данным со стороны бизнеса.

В этой статье хотим с вами поговорить именно о второй части, так как, согласно практике, именно по ней отсутствует какая-либо документация по действиям для устранения каких-либо проблем.

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

В статье речь пойдет об ETL-процессе, когда с источника данных «протянут» информационный поток со своей логикой преобразований, который «кладет» некорректные данные в приемник.

Когда-то я был молодым и активным. И под воздействием средств массовой информации, окружения и прочитанных довольно глупых книг я искренне считал, что человек с активной жизненной позицией, прилагающий значительные усилия, может в жизни добиться всего. В целом, я и сейчас наблюдаю такую же позицию у активной части молодёжи. Более того — в технологической среде эта вера ещё сильнее. Hustle culture, гаражные мифы Кремниевой долины, «если ты не добился — значит, мало хотел».

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

Знакомо?

Привет, Хабр! Меня зовут Екатерина Сивакова, я тимлид аналитики в Дзене (VK), а до этого работала в других бигтехах, и везде так или иначе сталкивалась с изучением CJM и пользовательской аналитикой. Сегодня хочу рассказать, как мы в Дзене делали единый инструмент по изучению пользовательского пути, зачем это понадобилось и что из этого вышло. А ещё о том, сколько это реально стоило по времени и ресурсам, потому что ответ отличается от первоначальной оценки примерно в 60 раз.

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

Привет! Я Никита, Staff-инженер в крупном финтехе. В этой статье я хочу поделиться нашим опытом построения системы observability. Мы прошли путь от простых логов до сквозной трассировки, и я покажу, как это работает на фронтенде.

TL;DR: В статье разбираем опыт внедрения OpenTelemetry в крупном финтех-проекте.
Проблема: Логи без контекста не позволяют быстро найти причину 500-й ошибки в распределенной системе.
Решение: Сквозная трассировка (Distributed Tracing) от фронтенда до бэкенда.
Что внутри: Реализация CompositeLogger на TypeScript, патчинг fetch для сохранения контекста и примеры того, как превратить технические трейсы в карту бизнес-процесса. А именно - frontend реализация и практические детали интеграции.

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

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

В этой статье я хочу рассказать как мы от потребности в нормальной аналитике WB и OZON прошли путь до создания своего SaaS - продукта на Datalens + PostgreSQL с оптимизацией JOIN’ов, историей себестоимости, автоматизацией процессов и классными решениями.

TL;DR Индустрия жжет мегаватты, чтобы GPT научился говорить «мне жаль» убедительнее. Спойлер: не научится. Transformer — это калькулятор с хорошей памятью, у него нет «себя», которое можно было бы поставить на чужое место. Мы построили Metabolic AI Runtime, где проблема пользователя становится его напряжением, и он генерирует ответ не из шаблонов, а чтобы вернуть себя в равновесие. Машинная эмпатия — это не «You are a helpful assistant», это архитектура, у которой есть что терять.

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

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

Привет, Хабр! Я Наталья Самсонова, фулстек-аналитик в ГК «Юзтех». Последнее время работаю пресейл-аналитиком в продуктовой команде. Несколько десятков встреч с клиентами в этом качестве позволили мне заметить значительную разницу в целеполагании заказчиков в проектах заказной и продуктовой разработки. О чем конкретно речь и почему это важно при выборе интеграционной платформы — рассказываю в статье.

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

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

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

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

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

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

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

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

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

Одна из ключевых проблем ИИ — склонность к «галлюцинациям», то есть к генерации убедительно звучащих, но ложных ответов. Яркий пример на картинке :) Как это можно исправить или улучшить? Есть разные способы. Одно из самых простых решений, позволяющих значительно повысить точность и достоверность ответов, — RAG (Retrieval Augmented Generation). Это генерация с дополненной выборкой. 

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

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

Постепенно стало ясно, что под "Ralph loop" уже начинают понимать очень разные, а иногда и почти противоположные вещи. И это не просто мое ощущение: вокруг Ralph довольно быстро появились публичные пересказы, упрощающие его по-разному [1] , [2], [3], а затем и публичные поправки к этим интерпретациям - [4], [5], [6], [7].

И поэтому любой разговор о нем очень быстро начинает напоминать сцену из Spider-Verse: “все вроде говорят про одного и того же Человека-паука и каждый уверен, что именно его версия и есть настоящая.”

Давайте разложим все по полочкам. А Питеров Паркеров Ральфов по их мирам.

Среди существующих реализаций встречаются следующие варианты - см. Таблицу

Если что-либо можно измерить числами, то это уже вселяет оптимизм. Значит мы имеем дело с более-менее понятным объектом или явлением, которое можно описать устоявшимися правилами. И, казалось бы, что тут такого, измерить влажность почвы? Вроде простоя и понятная задача, но в ней всё оказывается не так уж просто. Давайте разбираться!

Типичная ситуация в ИТ-проектах: приходит задача на автоматизацию, бизнес-аналитик начинает с нуля собирать требования, рисовать процесс, согласовывать его с заказчиком, выявлять исключения, уточнять роли и данные. Проходит время, задача уходит в разработку. Через месяц — новый запрос, и снова тот же путь. Процессы рисуются «под задачу», не связаны между собой, в каждом проекте — своя терминология и своё видение.

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

Роли, иерархии, департаменты — всё это придумано для людей. ИИ-агенты устроены иначе. Мы 6 месяцев проверяли, что произойдёт, если не назначать агентам роли и дать им самоорганизоваться. 25 000 задач, 8 моделей, до 256 агентов. Результат: назначать роли — антипаттерн. Система, где агенты сами выбирают специализацию, превосходит систему с координатором на 14%. 8 агентов создали 5 006 уникальных ролей. Агенты сами решают, когда не участвовать — и это повышает качество. В статье — полный разбор эксперимента и практические рекомендации.

Добрый день, дорогие читатели!

Поделюсь с вами опытом составления артефакта, который объединяет уровни абстракции проектируемого решения в одном месте: развертка вариантов использования по статусной модели с маппингом на API.

Специалисты проектного института «Сибирьэнергопроект» (входит в инженерный центр «СибИАЦ») столкнулись с парадоксом современного проектирования: 3D-модель, созданная для анализа и координации, в финале упиралась в ручной труд по подготовке 2D-чертежей для заказчиков.

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

Так начался поиск решения, который привел команду к возможностям автоматизации в программе nanoCAD BIM Строительство. В этой статье мы покажем, как с помощью nanoCAD BIM Строительство был реализован принципиально иной подход: от создания «умных» параметрических объектов до настройки автоматического получения 2D-видов, спецификаций и планов, что в итоге кратно сократило цикл проектирования протяженных объектов.

Всем привет! Меня зовут Александр Чепрасов, я бизнес-аналитик компании QSOFT. В этой колонке я расскажу, как беспорядок в данных ритейл-компаний может разрушить продажи — и конечно, как этого избежать.

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

Накопленный беспорядок в мастер-данных напрямую конвертируется в измеримые финансовые потери: