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

Публичный лидерборд — это рейтинг моделей на одной дистанции: все решают одни и те же задачи, и видно, у кого процент продуктивно-эффективности выше. Звучит как ответ за пять минут и принятие решения о том, что устанавливать к себе на мощности, а что пропустить.
На деле дистанция у всех своя: чужие версии моделей, чужие настройки, чужие режимы инференса. Мы проверили на себе: полгода и полсотни часов машинного времени ушли на то, чтобы понять, почему чужие цифры показывают не ту картину.
Внутри — четыре причины, почему цифры врут, и три истории, в которые трудно поверить: модель на 27 млрд параметров догнала модель на 284 млрд; «кодинговая» модель провалила кодинг; есть задачи, которые не берёт ни одна модель, ни на одном из шести языков. И таблица, после которой вы навсегда начнёте фиксировать настройки.

Привет, Хабр! Меня зовут Иван Тарасов, я TUL Architecture Governance в техплатформе Авито. Одна из моих команд — SLA — создаёт условия для повышения технической надёжности, а также развивает инструменты NFR и сценарии стабильности.

В этой статье я расскажу, как в Авито устроена система измерения надёжности: от SLI/SLO/SLA и разницы между Stability Rate и Uptime, до устройства NFR для REST/RPC-сервисов, шин данных и кастомных операций.

Также поясню, чем концепция бюджета ошибок в Авито отличается от канонического описания в книге Google SRE, и почему это не случайное отклонение, а намеренное решение.

Предметное поле банковского приложения для сотрудников: как его визуализировать — как лес, дерево или граф? Я Валерий Разномазов, тимлид команды системных аналитиков проекта «Цифровой офис сотрудника», в рамках которого мы создаем приложение для сотрудников Россельхозбанка. В этой статье я рассказываю, как мы строили модель данных для приложения «Цифровой офис сотрудника» в РСХБ и почему отказались от классического «дерева» в пользу ориентированного ациклического графа (Directed Acyclic Graph, DAG).

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

Риски, которые «съедают» бюджет застройщика

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

Риски, которые несёт застройщик:

Задержки сроков и вопросы к качеству...

Про Iceberg сейчас много чего понаписано. Либо обзор «формат будущего, открытость, лейкхаус», после которого непонятно, где нажать, либо разбор одного механизма — снимки отдельно, каталог отдельно, права отдельно. Iceberg плохо объясняется словами, поэтому я собрал стенд, где все части уже соединены и поднимаются одной командой. Trino, каталог Lakekeeper, права в OpenFGA через OPA, вход через Keycloak, S3 на RustFS, а из инструментов нужен только DBeaver. В статье — путь одного запроса через все компоненты, снимки и откат таблицы, права мышкой и обслуживание таблиц с рекомендациями для рабочей системы.

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

Привет! Кажется, что не так давно мы впервые рассказывали о нашей работе с платформой BPMSoft в департаменте корпоративных систем ЛАНИТ, где я выполняю задачи аналитика. Но год прошел, календарь перевернут и пришло время добавить новые главы к описанию нашего взаимодействия с этой low-code системой.

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

В репозитории проекта лежит 146 YAML-файлов с контентом: персонажи, сюжеты, настройки моделей. На каждом деплое они импортируются в базу — прямо там же, где выполняются миграции схемы.

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

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

Остановил Python сервис с моделью машинного обучения, .NET API продолжил работать и вернул HTTP 503. После восстановления Python запрос снова завершился с HTTP 200, без перезапуска основного приложения.

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

Просто стало интересно — что такое описательный анализ. Математический анализ, функциональный анализ знаю. А описательный?

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

Как теоретическую основу я использовал идеи из следующих источников:

Process Mining — Ван дер Аалст, «Process Mining: Data Science in Action (2016). Методология извлечения знаний о процессе из логов событий.»

EDA (Exploratory Data Analysis) — Тьюки, 1977. Принцип: сначала смотреть на данные, потом строить модели.

Lean Six Sigma — DMAIC (Define, Measure, Analyze, Improve, Control). Стандартная методология улучшения процессов.

Я не применяю всех методов, описываемых в Process Mining: Data Science in Action. Для данного анализа достаточно понимать, что наука о данных — это, в частности, превращение данных в реальную ценность.

В этой статье ценность — понимание процесса. Мы не строим прогнозы, не используем машинное обучение. Мы делаем описательный анализ: превращаем сырые логи в картину того, как процесс работает на самом деле.

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

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

Компания по ремонту и отделке квартир в Москве дала мне пять рабочих смет. По ним система выдала 310 замечаний (прогоны 16–21.08.2026). Самая дорогая находка — общий итог одной сметы занижен на 515 786 ₽. Это занижение нашлось ещё при обследовании смет перед ТЗ, а правило под него я написал потом, так что здесь заслуга внимательного чтения, а не кода. Код интереснее другим: 51 подтверждённое замечание он выдал сверх эталонного списка ошибок, составленного при том обследовании. В списке их не было.

Все 310 замечаний выдаёт код с правилами. ИИ-слой написан и покрыт тестами на заглушке, но на живой модели ещё не запускался: ключа доступа нет, платформу выбирает заказчик. Рабочую версию я ему передал, и она обходится без интернета.

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

В собственном маркетплейсе я однажды обнаружил ошибку в обработчике платежей. Логика выглядела правильной: проверить статус PENDING, перевести операцию в SUCCESS и начислить баланс. Но при одновременной обработке двух webhook’ов оба запроса могли пройти проверку и начислить деньги дважды. Этот код я написал сам, без AI.

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

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

Приветствуем, Хабр.

Врываемся в новую неделю с обширным интервью от Сергея Кушниренко @dalerank автора одной из лучших наших книг 2025–2026 года: «Game++. Устройство и оптимизация игрового движка». Сергей ведёт на Хабре отличный блог, а также создал сайт https://dalerank.github.io/, на котором выкладывается более глубокий и обширный контент, чем обычные лонгриды в формате Хабра. Под катом Сергей ответил на наши вопросы, рассказал о своём подходе к профессии и искусству программирования, языке C++, своей прекрасной дебютной книге, а также о новой книге «Прагматичный C++», которую только что сдал в редактуру.

Для наших читателей — промокод «GAME++» на эту книгу.

Добро пожаловать под кат

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

Российские компании охотно берут готовые управленческие методологии, будь то KPI, OKR, ЦКП и статистики, Lean или Agile. Чаще всего их внедряют как свод правил, который достаточно аккуратно повторить, и гораздо реже как теорию, которую сначала нужно понять, проверить на своих условиях и доработать. Разница между этими подходами решает, получит ли компания работающий инструмент или дорогую имитацию.

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

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

Я к вам пишу — чего же боле?
Агент все может написать.
Но за ошибки поневоле
Придется вам же отвечать.

(Письмо инженера Татьяны к вайбкодеру Евгению)

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

У одного из сотрудников TRI было около шести Excel-таблиц. Он выгружал данные из 1С, переносил их в свои файлы и занимался тем, чем приходится заниматься после переноса данных: сводил, пересчитывал, проверял. Когда в компании решили выяснить, сколько времени на это уходит, продуктовый директор Магомед Ахматов предложил завести ещё одну таблицу. В ней предполагалось учитывать время, потраченное на предыдущие.

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

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

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

Построение принципиальной схемы по шаблону

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

Рассмотрим в качестве примера один из рабочих алгоритмов доработки оформления принципиальной схемы в nanoCAD BIM Электро. Последовательность действий включает несколько этапов:

1. Создание принципиальной схемы по выбранному шаблону (рис. 1).

Когда говорят о ручном переносе данных в 1С — заказов с сайта, сделок из CRM, оплат из своей программы, — обычно считают время: столько-то документов в день на столько-то минут. Это честная, но самая маленькая часть счёта. Время видно. Ошибки и задержка — нет, потому что всплывают они в другом отделе и в другой день.

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

Microsoft Project долгое время являлся эталонной системой управления проектами. В 2022 году российские компании начали процесс импортозамещения, но отказаться от зарубежного ИТ-решения полностью так и не получилось: около 40% отечественных организаций продолжают использовать этот инструмент. При этом зарубежный разработчик продолжает вставлять палки в колеса: Microsoft удалил Publisher и отключил Project Online. Что делать? Искать замену. Рассмотрим возможности аналога MS Project — полностью импортонезависимой ИСУП Directum Projects и сравним функциональность и технические критерии платформы.

Привет, Хабр! Меня зовут Антон Алексеев, я ML Ops-инженер в Авито. 

В конце июля мы с коллегами съездили в Иокогаму на KubeCon + CloudNativeCon Japan 2026. Ко второму дню я заметил, что слайды выступающих повторяются: спектр изоляции тенантов, квоты, bin packing, «GPU дорогие — давайте делить». Мы решаем в Авито ту же задачу, поэтому я разберу шесть докладов про GPU и LLM-инференс и расскажу, что из этого мы уже пробовали или собираемся попробовать. А в конце будет немного про саму Японию.