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

Сходил на выставку «Фотоника» (31.03–02.04.2026), взял каталог оборудования Т8 — посмотреть, до чего современная технология доросла. Ради интереса выбрал модель агрегатора и попробовал рассчитать трассу. А потом вспомнил свой опыт строительства и эксплуатации магистральной сети. Правильный расчет — еще не всё. Для конкретной трассы нужно учитывать внешние факторы: логистику, климат, вандализм, доступ к опорам, затраты на эксплуатацию. Не каждый расчет, верный на бумаге, годится для реальной линии в труднодоступном районе. Так родился еще один раздел — разбор практических проблем.

Мы привыкли, что повтор r в ECDSA — это случайный сбой: плохой генератор, ошибка реализации, повтор nonce. Но что, если за одним repeated-r скрывается целое семейство дефектов (defect-family), которое можно не только обнаружить, но и перенести на другие закрытые ключи?

Представляем закрытую исследовательскую систему — стратификационный анализ ECDSA-подписей на secp256k1. Вместо точечных аномалий мы смотрим на фазовые корпуса подписей, используем торическую геометрию, kNN и перестановочные тесты. Результат:

· Во внешнем корпусе из 30 адресных контекстов и 6257 подписей repeated-r найден только в 1 контексте, межадресных коллизий r — 0. · 58 из 58 контролируемых переносов defect-family с реального адреса-донора на панель реальных адресных целей прошли с полной ECDSA-валидацией реконструированных подписей. · Встроенный publication-safety audit заблокировал открытый bundle, обнаружив 498 проблем (30 критических) — от raw (r,s,z) до восстановленных синтетических k и фрагментов закрытых ключей.

В публичной версии отчёта — только математика, агрегаты и безопасные листинги. Никаких инструкций по эксплуатации. Это продолжение методологии AuditCore, но уже на уровне стратифицированного анализа.

От вайбкодинга к профессиональной ИИ-разработке на примере LanChess: 3300 промптов, 832 коммита, 100 тыс. строк кода и путь от POC к продакшен-сервису.

Поздний вечер, я смотрю в терминал. Celery worker на восьмиядерном сервере перемалывает 67 партий блица на Lichess одного из пользователей. Через минуту этот человек получит персонализированную аналитику и упражнения от сервиса, аналогов которого в России найти пока не удалось. Я же сижу и думаю, стоит ли выводить этот сервис из закрытого режима по инвайтам.

Менее чем за 3 месяца я написал 100 тыс. строк кода и ни одной — своими руками. Мне пришлось стать оператором персональных данных. РКН порекомендовал мне убрать авторизацию от Google. А ВК не давал мне подключить свою авторизацию, пока я не стал самозанятым.

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

Начну с контекста. Я играю в EA FC (ранее FIFA) в режиме Clubs (11×11), где каждым виртуальным игроком управляет человек. Сам по себе режим интересный, но мне, как человеку, который любит цифры и аналитику, довольно быстро стало не хватать доступной статистики.

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

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

695 строк конфига, одна валидация, 10 GB upload limit по умолчанию и env-переменная, которая никогда не срабатывает. Десять ошибок управления конфигурацией, собранных из реальных проектов.

Меня зовут Иван Васильев, я ведущий аналитик в Ви.Tech, IT-дочке ВсеИнструменты.ру. Хочу показать, как из на первый взгляд простой формулы KPI выросла инженерная задача: нам нужно было не просто посчитать интегральный показатель эффективности поставщика, а объяснить, какая именно закупка его ухудшила и почему. В статье разберу, почему для агрегированных метрик не работает наивный подход, как мы пришли к remove-one analysis и где пришлось отдельно фиксировать логику расчета, чтобы результат вообще можно было интерпретировать.

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

Ответить на него можно было бы общими словами. Но затем появился уточняющий вопрос:
| А какая именно закупка ухудшила показатель?

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

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

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

Ответ на то, что использовать — очевиден не всегда, потому что возможности частично пересекаются: и робот может отправить письмо, и бизнес-процесс тоже. Но граница между ними большущая.

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

Представьте: вы подходите к коллеге и спрашиваете: «Сколько у нас продаж в этом квартале?» Звучит просто. Но за кулисами начинается ад. О каком квартале речь — календарном или финансовом? А «продажи» — это отгруженные товары, оплаченные заказы или подписанные договоры?

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

Контролируемая эволюция RAG-системы: оценка mcp серверов и кеширование результатов запрос-ответ

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

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

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

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

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

В билетном сервисе сразу несколько сложных задач: нужно исключить double booking, обновлять карту мест в реальном времени и выдерживать read-heavy нагрузку на каталог событий. Разберём архитектуру системы и ключевые технические компромиссы.

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-процессе, когда с источника данных «протянут» информационный поток со своей логикой преобразований, который «кладет» некорректные данные в приемник.