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

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

Команда онлайн-магистратур Центра «Пуск» МФТИ и индустриальные партнеры вуза регулярно реализуют совместные проекты. Благодаря этому студенты получают необходимый практический опыт, а партнеры — возможность осуществить важные бизнес-задачи. Например, благодаря одному из последних проектов, студенты 2 курса программы «Управление цифровым продуктом» и «Науки о данных» предложили ОАО «РЖД» инновационное решение проблемы детекции аномальных состояний пассажиров и предотвращения инцидентов на перроне. 

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

За две недели я собрал бесплатный веб-сервис, который генерирует диаграммы по текстовому описанию — без ручного рисования и без мучений с кривыми картинками от ИИ. Ключевая идея: вместо генерации изображений — генерация PlantUML-кода, затем серверный рендеринг в PNG и выдача пользователю. В статье рассказываю, как я проектировал сущности и сервисы, строил микросервисную архитектуру с очередями, поднимал PlantUML-server и MinIO, настраивал мониторинг и деплой, а также танцы с бубнами вокруг локальной LLM — и как меня спас старый ноутбук с GPU. Отдельно — про боль вайбкодинга: где ИИ-агенты помогают, а где требуют жёсткого микроменеджмента и шаблонов промптов.

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

Аналитика рынка промышленных сетей.

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

Рынок промышленных сетей формируется не громкими публикациями про IoT/IIoT и не усилиями маркетологов. Его формируют ключевые игроки отрасли — лидеры, которые создают профильные организации (ODVA - EtherNet/IP, CLPA - CC Link, PI - PROFINET/PROFIBUS/IO-Link и др.), разрабатывают стандарты и фактически устанавливают правила игры. По своей структуре это олигополистический рынок, во многом сопоставимый с картельной моделью: именно лидеры определяют направления и темпы развития. В индустриальном сегменте не рынок диктует лидерам, что делать, а лидеры управляют рынком. 

Привет, Хабр! Меня зовут Максим Галаганов, я ведущий разработчик систем доставки почты в Mail. Занимаюсь в основном почтовым сервером, но сегодня расскажу о другой задаче — как мы меняли вендора антивирусного решения. API нового решения кардинально отличался от старого, и пришлось изрядно поизобретать, чтобы всё заработало.

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

С точки зрения гейм-дизайнера, ни один из номинантов TGA не дотягивает до системной гениальности этой инди-игры. И это детальный разбор моего неофициального победителя.

Тренды в ИТ — это не про красивые слова и не про вечные «угрозы» о том, что нас вот-вот заменит ИИ и пора срочно выбирать другую профессию.

Тренды — это про то, как изменится работа с архитектурой и безопасностью в ближайшие годы, как трансформируются подходы к разработке и само мышление инженеров.тМы попросили экспертов ГК «Юзтех» поделиться своим взглядом на ИТ-тренды 2026 года.

3… 2… 1 — поехали. Ждём горячее обсуждение в комментариях.

Проекты в АСУ ТП обычно заканчиваются успешно.

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

Новые инженеры месяцами «входят в тему», модернизации откладываются, знания живут в головах отдельных людей, а слово «стандарт» сводится к упоминанию ГОСТ и ЕСКД, которые никак не помогают в реальной эксплуатации.

Почему так происходит?

Потому что во многих компаниях стандарт находится ниже проекта, а не выше него.

Эта статья — не про ГОСТы, не про шаблоны и не про конкретные контроллеры.

Она про то, почему стандарт АСУ ТП должен быть частью бизнес-системы предприятия, как он влияет на простои, деньги, людей и зависимость от подрядчиков — и почему отсутствие стандарта обходится дороже, чем его внедрение.

Если вам знакома ситуация, когда система «работает, но лучше её не трогать» — эта статья для вас.

Всем привет! Заключительная часть о требованиях, которые вспоминают в последний день перед релизом.

В первой части мы говорили о производительности и масштабируемости, во второй — о сопровождаемости, надёжности и безопасности.

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