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

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

Основы основ, описанные в ISA-95 или ГОСТ Р МЭК 62264-1-2014, всегда звучат в рассказах, презентациях или описаниях. Авторы используют такие термины, как SCADA, PLC, IIoT-платформа или MES. Но вот правила работы и уровни промышленной автоматизации часто трактуют неверно. 

И это очень зря. Уровни автоматизации – это такая особенная штука, которая при неудачном смешивании может вызвать целую кучу проблем. Потому всегда нужно держать в голове пирамидку АСУ ТП/АСУП, о которой мы сегодня и поговорим. И не пугайтесь. Как и всегда, я постараюсь рассказать понятно даже о самом сложном. Добро пожаловать в основы Цифрового Завода.

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

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

Что получилось:

📌 Bpium — документация вокруг функций, а не задач. Готовый шаблон CRM спрятан в подвале сайта. По моей оценке 90% пользователей его не найдут. Предложила задаче-центричную архитектуру и 5 тикетов в Jira.

📌 DirectAdmin — гайд по миграции с cPanel заставляет администратора импровизировать в 80% шагов. Для почты и DNS инструкций нет вообще. Нашла 5 системных проблем, спроектировала структуру Plan→Do→Check и скрипты-помощники.

📌 AmoCRM — разработчик тратит 48 минут вместо 5 на типовую интеграцию. 860% лишнего времени. От 275 тысяч до 3+ миллионов рублей в год оценочных потерь вендора. Предложила раздел со сценариями, визуальные маркеры и перекрёстные ссылки.

Моя методика (7 шагов): выбрать интересный продукт, найти сценарий пользователя, пройти путь с секундомером, искать паттерны (не опечатки!), посчитать цену в деньгах, спроектировать решение, упаковать в историю.

Главное: я не собирала портфолио под вакансии. Я собирала ответ на вопрос «нравится ли мне эта работа?». А кейсы получились сами.

В статье — полный разбор каждого кейса, схемы «было/стало», BPMN-диаграмма (упрощенная), таблица пяти проблем и чек-лист, по которому вы сможете собрать такое же портфолио.

Я регулярно выкладываю посты в блог НормЦРМ. На двух языках: русском и английском.

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

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

Сейчас расскажу во всех деталях, как именно это реализовано. Вдруг вы тоже так захотите?

У меня в ленте бесконечно мелькают размышления о том что все профессии больше не нужны, и только продакты/маркетологи/дизайнеры…etc останутся на коне благодаря вайбкодингу. Так вот, не останутся. Но кони у многих загнутся (Фотографы и копирайтеры, привет!).

По моей версии единственными конкурентными останутся T-shaped специалисты, так называемые принципалы. У которых есть хорошая база академического образования в визуальном дизайне, чтобы делать сочную картинку, есть понимание психологии пользователя, запросов рынка и методологий исследований. Которые знают как собрать минимально необходимую дизайн-систему с нуля под каждый определенный продукт, знают как собрать это всё в каком-нибудь Flutter/FlutterFlow, правильно заанимировать, как проработать воркфлоу и все корнер-кейсы, могут упаковать продукт в эффектную айдентику, создав бренд с нуля. При этом ещё и знают где и как продвигать продукт, ну а архитектуру и базы данных со всеми подключенными ручками уже могут делегировать нейросетям. 

AI резко удешевил запуск MVP, но может так же резко повысить цену ошибок в архитектуре. Когда основу системы генерирует LLM, команда получает быстрый результат и «черный ящик» с техдолгом внутри. Код работает, а почему он устроен именно так, никто до конца не понимает.

Где именно спрятана бомба замедленного действия и как с этим жить инженерам? Как AI-генерация меняет роль архитектора, почему классические ревью перестают быть достаточными и какие виды тестирования становятся критичными?

В современном финтехе скорость, надежность и глубина предоставляемой информации особенно важны. За интуитивно понятным интерфейсом, который видит трейдер, скрывается сложная архитектура из взаимосвязанных сервисов, отвечающих за сбор, обработку и доставку рыночных данных в реальном времени. Мы — команда MarketData компании «Финам», в этой статье мы рассказываем, как устроена наша система изнутри.

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

В рамках исследования я проанализировал ведущий польский сайт (более 4000 вакансий) с вакансиями для IT-специалистов. Отобрал 194 вакансии, где полностью или частично выполняются функции системного аналитика, знакомые российскому рынку. Что получилось…

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

Продолжение моей статьи Мечтают ли архитекторы об электроовцах?, в которой я обещал привести практический пример.

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

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

Привет, Хабр! Меня зовут Дмитрий Овчаренко, я технический директор департамента разработки IBS для финансового сектора. За последние десять с лишним лет я успел поработать архитектором, тимлидом и техдиром, внедрять SOA, потом микросервисы, потом облака — и наступить на приличное количество грабель. В этой статье честно расскажу несколько таких историй, в которых либо ошибался сам, либо не дожал архитектурно, либо слишком доверился контексту. Без пожаров дата-центров и апокалипсисов, но с теми самыми локальными провалами, которые в реальных системах случаются чаще всего. Надеюсь, эти кейсы окажутся полезными для всех, кто проектирует, особенно в эпоху вайб-кодинга, и потом живет с результатами своих решений.

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

В современных условиях, где цепочки поставок становятся всё сложнее, а границы всё тоньше, эффективное управление транспортной логистикой является важным элементом для производственных и торговых предприятий и превращается из вспомогательной функции в мощный конкурентный инструмент. Многие компании, внедряющие комплексные ERP-системы, такие как 1С:ERP Управление предприятием 2.5, сталкиваются с тем, что 1С:ERP предоставляет мощный базовый инструментарий, но он не всегда «ложится» на бизнес-процессы компании и требуется их адаптация под уникальные бизнес-процессы предприятия.

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

Фундамент: что предлагает «коробочная» 1С:ERP для транспорта

Перед тем, как говорить о доработках, важно понять, что предлагает «коробочная» версия 1С:ERP — отправную точку. Типовая конфигурация 1С:ERP включает в себя базовый, но надежный каркас для управления транспортом:

А никто не обещал, что на хакатоне будет легко.

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

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

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

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

Мы в Beeline Cloud собрали несколько open source инструментов, которые помогут решить эту задачу: одни позволят запустить такой код в изолированной среде, другие — вести учет сгенерированных фрагментов кода в репозиториях.

Сегодня наконец-то у нас появилась возможность рассказать  об одном из самых интересных и сложных технических проектов Engee - модернизации системы управления испытаниями автоматики для «Транснефть - Автоматизация и метрология». Совместный проект подтолкнул разработчиков Engee к ускорению реализации поддержки Modbus TCP в пакете Engee.Интеграции. С коллегами мы примерили несколько вариантов решения - и с использованием генерации кода, и со стендом реального времени, и с пакетом Engee.Интеграции и командным редактированием моделей. А началось всё с существенной боли...

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

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

Нюанс какой: я зашёл «с места в карьер», как будто все уже знают, кто я, откуда и почему я так пишу и так думаю. А по факту — нет, конечно. Поэтому этот пост — «паспорт»: кто я, откуда выросла идея, почему я вообще полез в код, почему у меня агенты, почему «завод», и что я могу обсуждать с инженерами предметно (а что — не могу и не буду, потому что там секреты/безопасность/коммерческое ядро).

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