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

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

ИТ-проекты – это далеко не только создание новых систем с нуля. Существенная часть специалистов занята поддержкой и сопровождением действующих систем. А когда в состав ИТ-системы добавляется новое ПО (или заменяется какой-то из её компонентов), актуальной задачей является перенос архивных данных и настройка взаимодействия нового софта с окружающим ландшафтом. При этом задачей-максимум является добавление новых свойств для системы, улучшающих пользовательский опыт или процессы администрирования и сопровождения. Ниже я расскажу, как мы провели классификацию объектов информационной модели при интеграции действующей системы расчета производственных показателей с внешней, вновь создаваемой системой управления НСИ.

После моей статьи про АИС «Налог-3» (как одну из самых мощных государственных IT-систем России) в комментариях больше всего спорили не про масштабы данных и вопроса, «видит ли ФНС всё». Основной скепсис вызвал мой тезис о необходимости внедрения больших языковых моделей (LLM) в работу налоговых органов.

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

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

Если вы читаете меня впервые: я не аналитик со стороны и не «диванный эксперт». За моими словами 12 лет работы в налоговых органах, в том числе на руководящих должностях. Из системы я ушёл совсем недавно и прекрасно понимаю, как это работает изнутри.

Статья -  комментарий / возражение к статье Осознанный вайб-кодинг. Осознанный вайб-кодинг наверное лучше не Осознанного, но последний тоже работает.

Автоматизированное тестирование API часто начинается с простых решений в виде коллекций Postman или скриптов на коленке. Такой подход работает на старте, но быстро исчерпывает себя.

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

Статья поделена на три части.

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

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

Недавно снова услышал вайб: да все эти принципы это только направление и их можно не придерживаться. И таких людей не переубедишь. Приводи им примеры или нет - свой опыт им не передашь. Да и слушать у нас как-то стало не модно. У нас же все теперь гибко и как договоритесь. И требовать каких-то стандартов отрасли - это уже абьюз…

Интеграционные тесты тормозят и не нужны, линтер можно и не использовать. Нарушение архитектурных принципов - так мы ж делаем MVP - зачем оно нам?

Я в корне не согласен с таким подходом и буду это разбирать на примере SOLID и перфораторной дрели...

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

Здесь про архитектуры, GRPO и про то, почему бенчмарки больше ничего не значат.

Дальше — слово автору.

За последнее десятилетие Федеральная налоговая служба (ФНС) совершила фундаментальный переход от традиционной модели администрирования к подходу, основанному на анализе больших баз данных.

Если вы соприкасались с налоговой системой - проходили проверки, бывали на комиссиях в инспекциях, общались с налоговыми органами, то вы слышали про АИС «Налог-3», одну из самых масштабных государственных IT-платформ в России.

Я проработал в системе налоговых органов 12 лет - от рядового инспектора в ИФНС до заместителя начальника отдела проведения налоговых проверок Управления ФНС - и наблюдал эту трансформацию изнутри. В этой статье я хочу показать, насколько эта система действительно мощная, как она эволюционировала, что она реально умеет сегодня и почему, несмотря на весь объём данных, это пока не «искусственный интеллект, который всё делает сам»

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

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

Я — независимый разработчик, и хочу рассказать о своём open-source проекте ATMO NeuroYoga — мобильном приложении для заботы о нервной системе. Текущая версия 1.4.1 уже доступна и включает упражнения NeuroYoga breathing и интерактивные точки акупрессуры. Но главная цель проекта — ATMO Shield, полностью оффлайн инструмент для непрерывного мониторинга и защиты нервной системы на основе вариабельности сердечного ритма (HRV).

Цель статьи — провести классификацию и иерархическое деление требований на группы с конкретными примерами из лабораторной практики. Разделение требований на группы и подгруппы необходимо для правильного построения проектного решения, основанного на анализе требований, а не на "представлениях о хорошем". Особенно это актуально для систем, подчиняющихся строгим стандартам, таким как ГОСТ ISO/IEC 17025-2019, который устанавливает общие требования к компетентности, беспристрастности и стабильной работе лабораторий.

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

Предельная унификация a.k.a. IDEAV — хранение вообще всего как список Entity — Attribute — Value с дополнительным полем ID. Звучит пугающе, но реализация скрыта под капотом, а снаружи нам доступен максимально родной и дружественный интерфейс.

Я работаю системным и бизнес-аналитиком, но периодически вижу обсуждения, что аналитики не нужны, либо не нужны били изначально, потому что 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 получил следующие определения:
Цифровизация — это перевод процессов, данных или взаимодействий в цифровой формат. Это не замена человека машинами, а переход от аналоговых или бумажных систем к цифровым инструментам.

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