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

Все любят безопасность, пока не приходится её настраивать. Первая версия нашего аудита напоминала пульт управления АЭС: бесконечно гибко, но без инструкции не взлетишь. Мы признали поражение, послушали стоны администраторов и сделали «версию 2.0» — с классами событий и логикой, понятной человеку, а не только компилятору. История работы над ошибками, которая превратила «полочный» софт в рабочий инструмент.

Я работаю системным и бизнес-аналитиком, но периодически вижу обсуждения, что аналитики не нужны, либо не нужны били изначально, потому что DDD и вот это всё, либо не нужны становятся сейчас из-за развития нейросетей и трансформации разработки. Однако на своем опыте я вывел несколько причин, почему аналитики всё таки нужны:

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

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

Тушитель пожаров - аналитики на проектах часто выступают в роли затыкателя дыр, выполняя все возможные временные функции от тестировщика до тех.писа.

Собиратели конструкторов - аналитики заменяют разработку в проектах с лоу-код и ноу-код конструкторами.

Вайб-кодеры - в настоящее время за счет нейросетей аналитик может самостоятельно тестировать идеи в коде и прототипах вообще без разработчиков.

Привет, Хабр! Меня зовут Артем Евтеев, я ведущий аналитик в МТС Web Services. Кажется, каждый бизнес-аналитик (и не только) хотя бы раз в жизни слышал о книге «Разработка требований к программному обеспечению» Карла Вигерса и Джой Битти.

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

В жизни теория нередко сочетается с практикой. Но так ли это в профессии бизнес-аналитика в ИТ-компании — предлагаю разобраться. 

Согласно Hype Cycle от Gartner за 2025 год, AI-агенты достигли пика завышенных ожиданий. Но что скрывается за хайпом с технической точки зрения? Самое время разобраться, чтобы не ждать от технологии чудес, а использовать её по назначению.

В статье объединим теорию и практику построения AI-агентов. Сначала разберем ключевые концепции: цикл Perception-Reasoning-Action, модель PEAS (Performance, Environment, Actuators, Sensors), уровни автономии. А затем, опираясь на эти принципы, построим работающего AI-агента 3-го уровня автономии. Наш технологический стек: 

- Оркестратор n8n;

- LLM через агрегатор OpenRouter;

- Telegram в качестве пользовательского интерфейса.

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

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

Привет, Хабр! Меня зовут Андрей Боков, я главный архитектор отдела разработки хранилищ данных в «Газпром ЦПС». Если вы хоть раз сталкивались с тем, что информация о сотрудниках не соответствует в различных корпоративных системах, например, 1С, электронный документооборот, корпоративный портал, система управления проектами, – вы понимаете, о чем сейчас пойдет речь. Мы пробовали решить эту проблему точечными интеграциями, но с ростом числа систем увеличивался и хаос в данных. Нам был нужен единый контур, который позволит проследить путь данных от источников до отчета.

Так началась работа над корпоративным хранилищем данных (КХД). Мы выбрали многослойную архитектуру и методологию Data Vault 2.0 – подход, который сохраняет историю изменений и дает возможность подключать новые источники без перепроектирования структур хранилища. В статье я расскажу про наш опыт, который будет полезен специалистам по работе с данными: руководителям, архитекторам, аналитикам и инженерам. Подробно опишу, как мы строили ядро КХД и какие уроки и инсайты вынесли по результатам реализации.

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

Я Артем Лыков, ведущий RnD-разработчик в МТС Web Services. А параллельно — аспирант в Лаборатории интеллектуальной космической робототехники Сколтеха (руководитель Дмитрий Тетерюков), где лидирую направление когнитивной робототехники. Вместе с коллегами по лаборатории мы описали способ обойтись без многомесячных записей движений и сложных симуляций, опираясь на уже существующие VLA-модели и модульный агентный подход, позволяющий генерировать будущие действия робота прямо из картинки и текста, проверять их, править, повторять и в итоге добиваться результата, сравнимого со специализированными решениями. В этом материале я разберу архитектуру PhysicalAgent, покажу, как мы реализовали цикл Perceive → Plan → Reason → Act для роботов, и расскажу, чем нам помогли открытые видеомодели и как этот подход помогает переносить навыки между разными платформами.

Привет, Хабр! Меня зовут Роман Стрекаловский, я корпоративный архитектор в «Столото». Мой первый рабочий день начался с экскурсии в лотерейный центр — место, где воплощаются мечты миллионов. Блестящие шары, гул вращающихся барабанов, атмосфера напряжённого ожидания — всё это производило сильное впечатление. Я сразу почувствовал: здесь живёт энергия, которая двигает бизнес.

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

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

И я хочу поделиться этой историей с вами.

1 Операционная надежность (надежность операций, процессов, функций)

Регулятор (ЦентоБанк) уже несколько лет ведет «крестовый поход» под знаменем «Операционная надёжность»: выпускает «одноименные» Положения (850-П / 787-П, 779-П), Стандарты Банка России (СТО БР БФБО-1.5-2023), ГОСТы (ГОСТ 57580.3 / 57580.4, с его участием), а также методические рекомендации (18-МР) и формы обязательной отчетности по «Операционной надёжности» (operational resilience).

Под знаменем «Операционная надёжность» - делается попытка «скрестить» (где-то «ежа с ужом», но сама идея достойная) бизнес-архитектуру (архитектуру процессов, как технологических, так и бизнес – хотя разделение их не понятное), EA (enterprise architecture) / ИТ-архитектуру, ITSM (CMDB, управление инцидентами, в том числе, инцидентами операционной надежности), информационную безопасность (вкл. ГОСТ 57580.1 / 57580.2), надежность / отказоустойчивость / ОНиВД, риск-менеджмент (опер-риски, 716-П), импортозамещение (ФТК). Подобный «единый узел» - это проекции «одного и того же» на разные плоскости (EA, BPM, GRC, ИБ, ITIL и др.) с разными словарями / концепциями, поэтому формализовать его видимо равносильно притчи / сценарию «Вавилонская башня». Однако «язык графа» сближает такое восприятие и снижает барьер сложности.

Далее будем говорить только о Форме 0409072 (далее ф072) — «Сведения о показателях операционной надёжности кредитной организации и применяемых ею информационных технологиях при осуществлении банковской деятельности и деятельности в сфере финансовых рынков», точнее о ее части – шифре \ шифровке архитектуры предприятия. «Операционная надёжность» - это всего лишь контекст. 

Почему векторной базы/RAG недостаточно для качественной памяти ИИ-агентов. Приближаем поведение агента к человеческому с помощью архитектурных решений поверх LLM

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

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

Представление чисел в IT сфере - одна из самых простых вещей, которую интуитивно знает каждый разработчик, аналитик, тестировщик, админ (нужное подчеркнуть).

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

Точные определения и механизмы легко гуглятся.

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

Это первая статья о том, как идея проходит путь от прототипа до полноценного продукта — с участием архитектуры на каждом шагу. Формат — ADR (Architecture Decision Records): каждое решение зафиксировано по дням, чтобы показать реальную эволюцию проекта. Продукт вымышленный, проблемы — настоящие. Те самые, с которыми сталкиваются архитекторы и команды. Документация и код — в открытом доступе на GitHub.

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

На связи команда Research & Insights Центра стратегии цифровых продуктов МТС. Мы подготовили исследование мирового и российского рынка ИИ-агентов. Это третий материал на его основе: в первом рассказали об инсайдах исследования, во втором — о видах агентов. А в этом покажем, какие три сценария развития ИИ выделяют инвесторы, в какой верят больше всего и как в эту картину вписывается тренд на ИИ-агенты. 

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

На примере разработки AI-консультанта для своего агентства расскажу о системном подходе к проектированию архитектуры production-ready AI-агентов, который мы применяем при создании агентских систем для бизнеса. Чтобы они не были дорогой игрушкой, а приносили эффект и оправдывали своё назначение.

Поехали...

Чем хорош малый бизнес, особенно на своем старте? Ему не нужны сложные инструменты: он в состоянии увидеть состояние дел расчетами «на коленке», а план действий уместить карандашом на трамвайном билетике.

А когда бизнес подрастает? Скажем, его месячная выручка становится 100М+, количество сотрудников исчисляется сотнями, а бизнес-процессы усложняются настолько, что перестают быть прозрачными, покрываются «туманом войны».

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

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

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

Мультиагентные системы — главный тренд в AI‑разработке. AutoGPT, CrewAI, LangGraph, Microsoft AutoGen обещают армию специализированных агентов, которые вместе решат любую задачу.

Сделал систему на 5 агентов, а потом передумал и сделал на одного.

История о том, что иногда с ИИ надо упрощать, а не усложнять.

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

Меня зовут Бастина Алина. В Альфа-Банке работаю уже более 5 лет, прошла путь от системного аналитика до руководителя группы разработки инструментов для IT-сотрудников. Один из этих инструментов — сервис ассессмента. 

Что будет в статье? Сначала немного формальностей, а далее погрузимся в тему: как ассессмент связан с (другими) процессами развития сотрудника внутри банка, как оценка навыков проводилась раньше, почему пришлось ее менять и как мы дошли до того, что имеем сейчас.

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

В статье «Система канбан в бережливом производстве: принципы и внедрение», см. сайт: https://sky.pro/wiki/management/sistema-kanban-v-berezhlivom-proizvodstve-printsipy-i-vnedrenie/, так описывается методика Канбан:

«Когда инженер Toyota Тайити Оно посетил американские супермаркеты и был впечатлен их системой пополнения запасов. Он заметил, что товары пополняются только после того, как покупатели забирают их с полок — это было противоположностью традиционному "выталкивающему" производству. Вернувшись в Toyota, Оно адаптировал эту концепцию для производственной среды.

К 1970-м годам система канбан стала неотъемлемой частью Toyota Production System (TPS), которая впоследствии трансформировалась в известную миру философию бережливого производства (Lean Manufacturing). В отличие от традиционного прогнозного планирования, канбан основывается на реальном потреблении, что позволяет значительно сократить запасы и минимизировать перепроизводство».