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

Долгоживущие системы нельзя просто взять и заменить, это дорого. Переезд может оказать дороже новой системы.

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

В этой части статьи

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

Обеспечение соответствия старому поведению. Пока новая реализация не доказала, что ведёт себя так же, любое изменение рискованно. Требуется повторить даже то, что вы не обещали (Закон Хайрама)

Каждый Java-объект в HotSpot начинается со служебного заголовка размером 12 байт. В JDK 27 по умолчанию он сжимается до 8 — это JEP 534, финальный шаг внедрения Compact Object Headers. Для типовых бэкендов это 5–15% экономии heap, для приложений с миллионами мелких объектов (особенно на Scala, Clojure и иммутабельных коллекциях) — до 30%, без изменений в прикладном коде.

В конце 2025 года в нашей региональной девелоперской компании мы запустили Кайдзен‑офис.

Это такой формат, когда любой сотрудник может предложить идею, как улучшить работу. От «давайте перестанем дублировать отчёты в Excel и Power BI» до «давайте перестроим маршрут согласования заявок». Уже за сам факт того, что сотрудник озвучил потенциально полезную идею (то есть экспертная группа её положительно оценила), мы платим небольшое, но приятное денежное вознаграждение. А уж если идея доходит до внедрения и начинает приносить измеримый эффект, цифры уже другого, ещё более приятного порядка.

По моему мнению, Кайдзен сам по себе — просто потрясающая вещь для развития кадров, вовлечения сотрудников в процессное управление и тому подобное. Но это не основная тема данной истории. Эта история о том, как оценить все эти идеи не субъективно, а по‑настоящему. Что действительно является оптимизацией, которая принесёт деньги, а что — просто галлюцинация, с которой согласились эксперты.

К моменту запуска Кайдзен‑офиса компания за пару лет выросла с 50 до 300+ человек. Это девелопер, который занимается региональной экспансией: новые объекты, новые регионы, новые команды от месяца к месяцу. Процессы выстраивались на ходу и при этом обязаны были масштабироваться. Что‑то закреплялось в регламентах, что‑то существовало в режиме «у нас принято так». Процессный офис — это я и трое моих коллег‑аналитиков.

Идеи пошли на удивление быстро, по 10–15 в месяц. Часть из них вообще не про процессы: «нужно меньше совещаний», «давайте сделаем меньше урн для мусора в офисах». Часть про автоматизацию: «эту задачу можно полностью забрать в RPA». А часть, как мы и хотели, про реальную перестройку процессов: маршруты согласования, разделение зон ответственности, временные окна обработки заявок.

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

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

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

Замечаете, что безопасность становится важнейшим атрибутом качества современных систем. А знакомы ли вы с концепцией Zero Trust? Не упустили ли вы момент перехода к непрерывной проверке безопасности?

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

Давайте на примере таск-трекера посмотрим как разные уровни ABAC влияют на логику фронтэнда и бэкэнда. Разберём как системному аналитику с помощью экспериментальной методики — постанализа юзкейсов — быстро оценить ситуацию и понять, когда принять решение простое, а когда сложное.

Меня зовут Андрей Рыжик, я Product Owner BI-направления в компании «Белый код». Эта статья – обзор платформы rapeed: in-memory OLAP-движка с собственным форматом хранения, нестандартной алгеброй связей между источниками и несколькими клиентами поверх единого ядра. 

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

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

Лёгенькое эссе о том, почему мне до сих пор интересно вести базу знаний в Obsidian, делать в ней заметки, искать связи и усложнять себе жизнь.

Каждый процесс в вашей компании — наследие прошлого. Жёстко? Возможно. Но логика верна. Каждый бизнес-процесс, который ваша организация выполняет сегодня, был спроектирован для мира без ИИ. Всё — от цепочек согласований до последовательностей передачи задач и обработки исключений — было построено на человеческом суждении. И всё это было выстроено вокруг предположения, что программное обеспечение может автоматизировать задачи, но координировать работу будут люди. Это предположение больше не работает.

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

Но время идёт, технологии совершенствуются. У нас, промышленников, появляются возможности внедрить какое-то улучшение на производстве — где-то оптимизировать процесс и сэкономить. Вот только как провернуть такое с 80-метровой печью, всегда наполненной жидким раскалённым металлом?

Меня зовут Евгений Щелоков, начальник участка доменной печи № 3 ЕВРАЗ ЗСМК.  Я расскажу, как мы в ЕВРАЗе модернизировали систему автоматического распределения вдувания пылеугольного топлива (ПУТ) по фурменным линиям, что в результате позволило нам снизить (и довольно существенно) расход дорогого кокса. Если интересно, как можно применять IT для такой узкой и непростой цеховой задачи, — приходите за подробностями под кат.

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

3.3. Что я сделал бы иначе

Закладывал бы MLOps с первого дня, а не «сначала модель, потом инфраструктура». Параллельно — дешевле.

Автоматизировал бы тестирование данных раньше. Самые неприятные баги — не в коде, а в «тихом» изменении распределения.

Завёл бы playbook для инцидентов. Когда что-то падает в три часа ночи, нужен чеклист, а не паника.

Глава 4. Чеклист: готов ли проект к масштабированию

Это самая практичная часть — её можно унести с собой.

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

Три захода, шесть прогонов, четыре миллиона токенов. Демки обещали магию. Реальный проект дал швы, грабли и один по-настоящему страшный момент с ложным одобрением. Но из всего этого мы вытащили приёмы, которые сделали наш обычный процесс лучше. А workflow оставили для тех случаев, когда одного ревьюера действительно не хватает.

-Gartner прогнозирует, что 80% инициатив в управлении данными провалятся к 2027г.

-MIT подводит статистику - 95% AI-проектов не срабатывают и основная причина - незрелость компаний в работе с данными.

-Chief Data Officer, высший руководитель функции управления данными, живёт в компании в среднем 30 мес.(2.5 года) Логично, что руководитель функции, инициативы которой проваливаются достаточно быстро выгорает.

Поговорим о причинах.

Думаю, причина этой статистики одна - заблуждение в сути работы с данными и AI.

Соблазнительно считать, что данные будут работать вместо вас, AI агент заменит сотрудников. Но они работают только вместе с вами.

Представьте: сотни микросервисов, неделя на поиски API, устаревшая документация. Backstage от Spotify превращает хаос в порядок — и возвращает контроль над масштабом.

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

Продолжаем data mining путешествие в погоне за удачей. Адаптивность — последний фактор в нашем разборе, хотя и не последняя статья серии. Если интеллект отвечает на вопрос «насколько у человека мощный когнитивный аппарат», то адаптивность отвечает на вопрос «насколько устойчиво он функционирует под давлением и насколько быстро восстанавливается». В популярной литературе адаптивность считается едва ли не главным фактором жизненного успеха. Данные показывают более скромную, фрагментированную и в нескольких местах контринтуитивную картину.

Опыт ERP-архитектора: почему ChatGPT сначала выдавал красивые, но непроверяемые процессы — и почему решение оказалось не в промптах, а в предметной модели, технологической последовательности и проверяемых артефактах.

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

Одна из таких профессий - 1С-аналитик. Разбираем, чем занимается специалист, какие навыки нужны на старте и на какую зарплату можно ориентироваться....

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

Меня зовут Ксения Зайцева и я старший бизнес‑аналитик в компании «ДАР». Я хотела бы поделиться кейсом, который поможет начинающим тим‑лидам заранее предусмотреть аналитический тупик в стиле «вроде всё понятно, но что‑то не сходится».

В HR‑аналитике есть метрики, которые «должны считаться просто»: выбрать статус, взять дату, посчитать кандидатов. На практике такие истории иногда заканчиваются нулём, потом несколькими миллиардами, а потом неделей расследований — как вообще устроены данные и почему всё это работает.

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