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

Привет, меня зовут Николай, я 23 года в DevOps, последние пару-тройку месяцев копаюсь в архитектуре AI-агента (Hermes Agent)

В предыдущих двух статьях я разбирал, почему AI-агенты сходят с ума на длинных сессиях (сжатие контекста) и почему Chain-of-Thought это пост-хок нарратив, а не трассировка мышления. Статьи неплохо зашли, но в комментариях меня справедливо пропесочили: "нейрослоп с характерными эпитетами, очередной набор запросов к ИИ". Ну и по делу в принципе. Пишем руками, нудное это дело если честно, все равно вычитку в агента отдал в итоге.

И сегодня я расскажу про два инструмента, которые использую постоянно: Premortem и Prism. Не в теории, а на моём собственном опыте.

Prism это не моё изобретение. Это форк из Cranot/super-hermes, доработанный под мои задачи. В оригинале — пять независимых скилов структурного анализа. Premortem — вообще классика, из книги Klein «The Power of Intuition» и военной аналитики. Но я их доработал так, что это не просто "очередная методология для митапов", а работающий pipeline, который находит баги архитектуры.

Продолжаем разбирать HikariCP: как выбирать размер пула, что учитывать в Kubernetes и при нескольких сервисах, почему большой maximumPoolSize не всегда помогает, какие настройки стоит пересмотреть перед продом и какие ошибки чаще всего приводят к проблемам с базой.

Это статья написана дипломированным инженером‑конструктором (по первому образованию), разработчиком систем автоматизированного проектирования (САПР) и (по известным причинам) вынужденно ставшим сертифицированным специалистом по системам офисного документооборота.

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

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

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

Изучите принципы информационного моделирования на практике.

Разбираем возможности с помощью демонстрационного архитектурного проекта в nanoCAD BIM Строительство: двухэтажного загородного дома «с нуля».

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

В конце прошлого года я открыл для себя n8n. Написал написал четыре бота для личных задач, опубликовал статью на Habr и уже строил планы на безоблачное будущее в мире автоматизаций. Но идиллия длилась недолго. Появился OpenClaw — проект, который окрестили «убийцей AI‑агентов». И тут у меня закрались сомнения: не пора ли выбросить старые наработки и мигрировать на новый стек? Я погрузился в изучение, разобрался и принял решение: остаюсь на n8n. OpenClaw для создания персональных AI‑агентов оказался слишком сложным, дорогим и неоправданным решением. Но давайте по порядку — от теории к практике.

Внедрение ERP-систем подразумевает изменение бизнес-процессов компании. Организация вынуждена принять такой способ выполнения операций, как это изначально задумано и реализовано вендором в программном решении. Особенность состоит в том, что процессы в информационной системе уже оптимизированы и унифицированы, тем самым имплементация решений класса ERP является одним из наиболее распространенных способов усовершенствования бизнес-процессов. В данном случае мы говорим о реинжиниринге бизнес-процессов [1].

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

Можно попытаться разобраться в крайностях реинжиниринга, используя свод знаний по корпоративной архитектуре, представленный методологией TOGAF [2], который говорит о том, что во главе всего должна стоять прежде всего бизнес-архитектура. Именно через ее призму необходимо рассматривать все происходящее в компании и ИТ-архитектуре, в частности. Более детальное погружение в тематику бизнес-процессов обратит нас к набору знаний BPM CBoK [3].

Привет всем, на связи снова Дарья Борисова, системный аналитик из ПСБ. Продолжаю развеивать мифы о REST API. Если вы пропустили первую и вторую часть, то советую заглянуть туда: ведь мы уже разобрали некоторые заблуждения о природе REST. Сегодня мы разберем нюансы транспортных и бизнес-ошибок, погрузимся в кеширование и узнаем, действительно ли REST должен быть прокси для базы данных.

Переходите под кат, начинаем!

Привет, Хабр! Меня зовут Михаил Афанасьев, я главный специалист в команде кибербезопасности Platform V в СберТехе, занимаюсь подготовкой продуктов к прохождению сертификации ФСТЭК России. Хочу рассказать о режиссуре LLM-агентов и о том, как выбор ролей и написание промптов превращают хаотичный поток запросов к нейросети в надёжную инженерную систему.

15 мая в Инфостарте стартует новый поток онлайн-курсов для специалистов, которые работают с 1С, ИТ-проектами, требованиями, ТЗ и безопасностью.

Ждать старта, чтобы начать обучение, не нужно: доступ к материалам открывается сразу после оплаты. До 15 мая можно спокойно посмотреть первые уроки, разобраться с платформой и войти в поток уже подготовленным.

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

Представьте систему, в которой решение о многомиллионной сделке принимается без участия продавца — пока тот ждёт ответного звонка. Именно так работает цифровая проверка контрагентов в российском агробизнесе 2024–2025 годов.

И это не алгоритм какого‑то стартапа. Это то, что происходит в Excel‑таблице службы безопасности агрохолдинга каждый раз, когда закупщик передаёт новый ИНН.

Я однажды примерно за сутки сжег около $100 на голосовом агенте.

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

В какой-то момент два не очень умных голосовых процесса могли довольно долго вежливо говорить друг другу что-то в духе:

Это первая статья из цикла о том, как я пытался сделать алерты Zabbix в домашней лаборатории чуть умнее, прикрутив к ним локальную LLM и не получить на выходе архитектурного монстра Франкенштейна.

В теории хотелось простого: система принимает события мониторинга, понимает их контекст, не дергает лишний раз по пустякам и подсказывает, куда смотреть в первую очередь. Но на практике необходимо начинать не с модели, не с кода и даже не с Docker Compose, а с нормального ТЗ.

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

Часть 1: Вводная и формирование ТЗ -> вы здесь
Часть 2: Выбор локальной LLM
Часть 3: Формирование HLD и немного LLD
Часть 4: Что из этого вышло

nanoCAD GeoniCS, nanoCAD Облака точек и другие специализированные инструменты помогают «Северо-Западной энерго-ресурсной компании» (СЗЭРК) быстро создавать топопланы, проектировать инфраструктуру и проходить государственную экспертизу.

В этой статье на конкретном примере масштабного проекта – города-спутника «Евроград» под Санкт-Петербургом – мы наглядно продемонстрируем, как современное российское программное обеспечение позволяет в сжатые сроки решать комплексные инженерные задачи.

Меня зовут Андрей Рыжик, я разработчик BI в компании «Белый код». Это бонусная статья из серии, в которой мы изучаем российские BI-системы с поддержкой ETL для клиентов из малого и среднего бизнеса с бюджетом до 1,5 млн рублей. Сегодня разбираем не BI-систему, а инструмент, без которого многие BI-проекты в России буксуют, – экстрактор данных из 1С от компании «Денвик-Аналитика».

Я раньше был уверен, что понимаю, как работает отслеживание в интернете. Очистил cookies - чист. Включил VPN - спрятался. Поставил блокировщик - стал почти невидимым. Звучит логично, правда?

Проблема в том, что всё это работает только на уровне, который уже давно не является основным.

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

И самое неприятное - этот отпечаток можно получить без cookies, без авторизации и даже без твоего явного согласия. Ты можешь открыть сайт впервые, но для системы ты уже «кто-то знакомый».

Когда я начал разбираться в теме глубже, оказалось, что классические методы вроде Canvas или WebGL - это лишь вершина айсберга. Под ними скрывается целый слой менее очевидных техник: тайминговые атаки, сетевые отпечатки, поведенческие модели и даже попытки идентификации на уровне конкретного железа.

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

Небольшой мысленный эксперимент на стыке машинного обучения и продуктового менеджмента. О том, почему одна и та же задача «определить, что нужно клиенту» может выглядеть по-разному со стороны product'а и data scientist'а. Разбор на примере корпоративного ДМС, где у одного контракта сразу три стейкхолдера с разными работами.

Вводная: почему эта тема вообще возникла

Я много лет проработала начальником управления аналитики в страховой компании, а сейчас прохожу курс Ивана Замесина по Advanced JTBD. В какой-то момент на воркшопе меня зацепила структура, которую он назвал «графом работ» — и я поймала себя на мысли, что она похожа на знакомую мне из Data Science модель. Только с противоположным назначением.

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

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

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

Что здесь нового, - спросите вы – опять повторение давно избитых тем? Увы, есть моменты, над которыми стоит задуматься… Расскажем пару полезных историй из нашей практики…

Итак, вы нашли своего идеального кандидата. Возможно, он даже очень силён, но спустя 2 месяца всё ещё не вышел на ожидаемую продуктивность. Более того, вы заметили, что производительность команды только снизилась, потому что другие инженеры тратят время на онбординг нового человека.

Наверное, я не открою Америку, если скажу, что это довольно тревожный сигнал.

Причём часто в проекте уже есть документация. Очень много документации. Есть обучающие вебинары по продукту, отдельный портал со всеми схемами, ссылки на внутренние страницы, доступы, инструкции, записи созвонов и ещё несколько документов “это обязательно прочитай”. Но почему-то это всё равно не помогает быстро войти в систему.

Почему?

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

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

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

В идеале это помогает сократить время онбординга: команда меньше тратит время на повторяющиеся объяснения, новый человек быстрее выходит на самостоятельность, а сама система становится понятнее не только новичку, но и тем, кто давно в ней работает.

Привет! Я Софа, ведущий b2e дизайнер в Perfomance Lab, и я считаю, что внутренние продукты недооценены, а процесс их создания в корне отличается от b2c/b2b.

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

Как победить хаос изменений в 1C, SAP и микросервисах? Авторская модель управления изменениями через Задания на разработку (ЗНР) и Релизные контейнеры, которая синхронизирует бизнес-процессы и код, предотвращая сбои в сложном ИТ-ландшафте.