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

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

Представьте: вы заходите в репозиторий, открываете папку schemas и через пять минут понимаете, как устроена база во всём проекте, со всеми связями. Никаких устаревших диаграмм в Confluence, никаких гаданий по коду миграций. Схема базы данных становится частью кодовой базы — её можно версионировать, ревьюить, тестировать. Модель в формате ArchDB становится единым источником истины, из которого автоматически генерируются документация, DDL-скрипты и даже ORM-сущности. Звучит как мечта? Для нас с командой это стало реальностью, когда мы перешли на ArchDB.

Разбираем, как спроектировать систему бронирования билетов на интервью по System Design. Обсудим, как избежать двойных бронирований, справиться с большим объемом чтения, обновлять карту мест в реальном времени и ускорить поиск мероприятий.

AI уже ускоряет создание кода, ADR и документации, но одновременно повышает нагрузку на ревью, проверку и контроль стабильности. Поэтому следующий шаг для инженерных команд - не просто встроить AI в текущий SDLC, а пересобрать сам процесс поставки вокруг контекста, harness, quality gates и learning loop.

TL;DR: Claude Code слил свои исходники, потому что у него нет инстинкта самосохранения. Проблема не в баге, проблема в архитектуре: LLM-агенты не владеют ничем и не боятся ничего. Пока у ИИ нет шкурного интереса, вайбкодинг - это русская рулетка с корпоративными секретами.

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

В течение последнего года я занимался разработкой аналитической панели для продавцов на маркетплейсах Wildberries и Ozon, а в перспективе планируется интеграция с Яндекс.Маркет. Я хотел бы поделиться своим опытом и представить систему WBOZYA-dash, которая предназначена для анализа продаж через эти маркетплейсы. До конца весны 2026 выпущу, думаю, с десяток статей на эту тему, а пока сделаю общий обзор своей системы.

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

Пока юристы спорят, можно ли считать код объектом авторского права, а идею программы охраняемой, разработчики уже несколько месяцев живут в новом мире. Мире 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 в разных задачах — в своей статье я хочу поделиться этим опытом. Буду рад, если моя статья станет полезна тем, кому предстоит работать с методом.