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

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

Одним из наиболее удобных инструментов для этого сегодня является оркестрация с использованием BPMN-диаграмм, где визуальное моделирование бизнес-процесса превращается в исполняемую логику.

База данных — это сердце системы. И в какой-то момент это сердце начинает давать сбои. Не от объема данных, а от их разнородности. Таблица users разрастается до 200 колонок. Одни нужны для логина каждую секунду, другие — для годового отчета раз в год. В итоге, чтобы прочитать два "горячих" поля, база тащит с диска целый блок с "холодными" данными. Это неэффективно.

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

95% корпоративных ИИ-пилотов проваливаются. IBM Watson Health - $62 млн впустую, Zillow - $880 млн убытков, McDonald’s - чат-бот, заказывающий 260 наггетсов. Почему? Потому что компании внедряют ИИ вслепую, без понимания своих процессов.

Но есть и другой путь. В этой статье я показываю, как связка ДРАКОН + LLM превращает хаос в управляемую систему и становится фундаментом для агентских ИИ.

Вместо «чёрного ящика» - понятная визуальная карта, где каждый шаг прозрачен.
Вместо слепого доверия - гибридный процесс: человек и ИИ делят зоны ответственности.
Вместо провала - три уровня автоматизации, от 30% до 70%, с чёткими расчётами времени, рисков и ROI.

На примере сети СТО мы показываем:

как LLM на основе ДРАКОН-схемы проектирует агентов для записи клиентов, управления складом и поддержки механиков,

как сократить время на создание ТЗ с месяца до недели,

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

Это не теория. Это инженерный план:

Уровень 1: 5-7 часов экономии в неделю, риск провала - 5%,

Уровень 2: 15-20 часов, риск - 20%,

Уровень 3: 30-35 часов, риск - 35%.

И всё это - на открытых, доступных инструментах: Llama 3, Mistral, Qwen и языке ДРАКОН, который понимает и директор, и программист.

Потому что реальный ужас - не в том, что ИИ захочет нас уничтожить. А в том, что мы сами разрушим бизнес, не понимая, как работает то, чем управляем.

Статья для тех, кто устал от хайпа и хочет действовать - с пониманием, а не на авось.

Я ненавижу идею соло-разработки. Не просто не люблю презираю как явление, которое почему-то принято романтизировать. Не сами игры, ведь я, как и вы, искренне восхищаюсь такими кейсами, как Animal Well, Stardew Valley, Papers, Please и многие другие. Нам всем нужна путеводная звезда. Но я ненавижу то, как этот путь “одиночки-страдальца” нормализуют и даже стандартизируют, превращая исключение из правил в какой-то достижимый идеал.

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

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

— «А какая тогда альтернатива?»

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

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

Привет, Хабр! На связи Александр Усачёв, системный аналитик в группе облачных продуктов Рунити. В основе нашей облачной платформы Рег.облако лежит микросервисная архитектура: каждый сервис отвечает за свой участок бизнес-логики — от биллинга до управления сетями. Между собой они обмениваются задачами через брокер сообщений. 

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

Курсы учат «эталонному» ТЗ на десятки страниц с диаграммами и ссылками на стандарты. Такое полотно текста выглядит надёжным, но на практике это оборачивается задержками. Пока аналитик пишет документацию «по правилам», команда ждёт задачу. Для бизнеса, который ждал изменений «ещё вчера», это выглядит так, будто аналитик тормозит процесс, хотя он просто следует инструкции.

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

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

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

- Плоской спиралью (planar spiral) – дорожка закручена по окружности или квадрату.

- Меандровой линией (meander line) – зигзагообразная структура, увеличивающая эффективную длину проводника.

- Многослойной спиралью – когда витки распределены между разными слоями печатной платы.

1. Конструкция и особенности

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

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

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

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

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

ИТ-архитектура предприятия (Enterprise IT Architecture) — это системное представление структуры, компонентов и взаимодействий всех информационных технологий, которые поддерживают бизнес-процессы, ценности и стратегию организации. Иными словами — это “скелет” технологической среды, который обеспечивает реализацию бизнес-архитектуры и поддержку бизнес-способностей.

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

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

Мы привыкли думать, что «общество не допустит» появления опасного ИИ. Но что, если это иллюзия - такая же, как вера Германии в 1940-м, что атомная бомба невозможна? История показывает: технологии не ждут морального одобрения. Они распространяются тогда, когда становятся возможными - независимо от этики, запретов и «общественного мнения».

Сегодня ИИ уже здесь. Он открыт, глобален и децентрализован. Llama 3, Mistral, Qwen - доступны любому студенту. А миллионы решений о кредитах, найме и даже приговорах уже принимаются алгоритмами без участия человека.

Но главная угроза - не в «восстании машин». Она в том, что мы сами перестаём думать, делегируя всё больше решений системам, которые «знают лучше». И даже те, кто имеет доступ к самым продвинутым ИИ, часто не понимают, как они работают. Это не сознание - это статистическая интуиция, «инопланетный разум», который эффективен, но непрозрачен.

В статье мы разбираем:

почему «подпольный ИИ» - худший сценарий, а открытость - единственный шанс на контроль;

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

почему даже CEO не понимают, как работает их собственный ИИ;

и как избежать судьбы «ученика Герострата» - человека, который разрушил будущее, не осознавая, что делает.

Это не призыв к запретам. Это призыв к ответственности: развивать не только ИИ, но и наш собственный разум, чтобы научиться понимать то, что мы не понимаем.

Потому что наивность - роскошь, которую человечество не может себе позволить в эпоху ИИ.

Привет! Меня зовут Лиза — я аналитик по информационной безопасности в направлении внедрения Naumen Contact Center. В Naumen я работаю около трех лет.

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

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

За долгую практику работы с сервисом накопилось большое количество кейсов, когда PostHog помогал мне получать и обрабатывать данные. Хочу поделиться знаниями с начинающими дизайнерами, аналитиками и продактами.

ClickHouse — одна из самых популярных систем для анализа данных. По информации TheirStack, этот инструмент использует более 3 700 компаний по всему миру. 

У ClickHouse быстрая аналитика, эффективное сжатие и отличное масштабирование. Но у системы есть и недостатки — ограниченная поддержка UPDATE и DELETE, а также сложная миграция.

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

Привет! Меня зовут Бромбин Андрей. В этой статье разберём структурные паттерны ООП. Используя примеры на Java и простые метафоры, поймём природу шаблонов: как они работают, зачем нужны и чего требуют от нас взамен. Почему дизайн называют удачным при использовании паттернов по назначению, и почему так бывает не всегда.

Книг и статей о шаблонах проектирования, как песен о любви, потому что в разработке эта тема волнует каждого начинающего и не очень специалиста. Помните, как пели Чиж и Ко: «а не спеть ли мне песню о любви?» — давайте и я попробую.

Tudum.com — фан-портал Netflix с более чем 20 млн MAU, где скорость публикации и персонализации упирается в архитектуру. В статье — путь от «классического» CQRS с Kafka и read-store к узкому месту предпросмотров, а затем — к RAW Hollow: in-memory состоянию с сжатием и read-after-write на требовательных запросах. Разбираем, как отказ от Page Data/KV и I/O на горячем пути упростил контур чтения и дал прирост производительности, какие компромиссы это привнесло и почему такой подход срабатывает для контента, меняющегося не каждую секунду.

Это перевод классной статьи с детальным обзором архитектур главных опенсорсных LLM: очень структурировано, доходчиво и с изумительными картиночками. И такой обзор просто обязан быть на русском языке. Поговорим про DeepSeek V3/R1, OLMo 2, Gemma 3, Mistral Small 3.1, Llama 4, Qwen3, SmolLM3, Kimi K2, GPT-OSS, Grok 2.5, GLM-4.5, Qwen3-Next.

Ну а дальше слово автору:

Прошло семь лет с момента разработки оригинальной архитектуры GPT. На первый взгляд, оглядываясь назад на GPT-2 (2019) и вперед на DeepSeek-V3 и Llama 4 (2024-2025), можно удивиться тому, насколько структурно похожими остаются эти модели.

Однако я считаю, что все еще есть большая ценность в изучении структурных изменений самих архитектур, чтобы увидеть, чем занимаются разработчики LLM в 2025 году.

Привет, хабр! В прошлой статье мы говорили о применении языков разметки для описания графических артефактов, идее языка разметки для аналитиков и приложении для генерации макетов UI и BPMN схем.

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

Когда компания только начинает проект по внедрению SIEM или подключению к SOC, разговор обычно крутится вокруг выбора вендора и сценариев корреляции. А вот о EPS (events per second) вспоминают редко. И зря: от этой метрики напрямую зависит эффективность обработки событий и, как следствие, надежность всей системы защиты.

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

В этом гайде мы разберем:

• почему компании полезно знать свой EPS;

• как этот показатель влияет на архитектуру SOC и стоимость лицензирования SIEM;

• как определить свой EPS без «угадывания на глаз» и ошибок в расчетах;

• и, наконец, что стоит спросить у провайдера SOC, прежде чем подписывать договор.