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

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

Привет, Хабр! Писать статьи — дело приятное, но только если нет на плечах релиза. Релиз оказался марафоном на месяцы, где каждый день мы жили задачами и доработками. Мы делились на три фронта: кто-то закрывал критические баги («баг-фиксеры»), кто-то добивал бизнес-логику («бизнес-логеры»), а кто-то всерьез отрабатывал план «Б» — ставил свечи за успешный релиз («молитвенники за прод»). Играли мы на разных уровнях, но финальный босс у всех был один: система, которую мы героически толкали в ПРОД, как кота в переноску: и он не хочет, и нам страшно.

Но как бы там ни было, сегодня на ПРОДе живет большая система. Прям такая, что, если бы она была организмом, у нее были бы печень, почки и амбулаторная карта в Сфере Знания. 

Пользователи — сотни сотрудников. Система — новая, кнопки — непонятные, интерфейс — как квартира после переезда: ты вроде дома, но даже чайник включить страшно.

И вот представьте: в этой «квартире» все двери распахнуты настежь. Любой может зайти куда угодно, нажать любую кнопку, открыть любой экран. Кнопки, которые лучше не трогать, экраны, куда и разработчик-то без инструктажа не сунется… Получился цифровой «чулан Моники» — хаос, который мы срочно должны были привести в порядок. 

Решение было очевидным: нужна ролевая модель.

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

В своих размышлениях и прошлых попытках разработки ИИ, я добрался до сего дня llm - large language models. Однако этим моделям свойственны некоторые точности с контролем выходного результата, а именно почему получилось именно так.

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

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

Техническое задание (ТЗ) на проект, основанный на извлечении триплетов из текста, логическом выводе и масштабируемой обработке графа знаний с GPU-ускорением:

---

📘 Техническое задание: Система извлечения и логического анализа триплетов с GPU-ускорением

🔹 Цель проекта

Разработка гибридной экспертной системы, способной:

- Извлекать триплеты из неструктурированного текста с помощью LLM

- Хранить и обрабатывать триплеты в логической форме (Prolog)

- Масштабировать поиск и reasoning через кластеризацию и GPU-графовые вычисления

---

🔹 Архитектура системы

1. Модуль извлечения знаний

- Вход: текстовые данные (статьи, документы, диалоги)

- Выход: триплеты вида <субъект> — <предикат> — <объект>

- Инструменты: LLM с кастомным промптом, поддержка хотя бы одного языка. Перевод это техническая обвязка.

Каждый раз новый сотрудник приходит к вам с одними и теми же вопросами по Фигме? Или впервые видите макет в Фигме и не знаете, куда нажимать?

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

Рассказываем, какие задачи решают оркестраторы в проектах внедрения корпоративных хранилищ данных. Выясняем, в чем разница между инструментами, и почему Dagster становится все популярнее в DWH-проектах, чем Airflow.

Всем привет! Я Артём Седых, ведущий разработчик и тимлид проекта банковского сопровождения. Наш сервис — 8-летний монолит на PHP с командой из 39 человек. В цикле статей рассказываю об опыте разработки и внедрения альтернативы pinba: гибкого инструмента мониторинга, который позволяет увидеть живую систему как на ладони и понять, из‑за чего именно проседают определенные экшены. Сегодня, в продолжение первой статьи, закрываем архитектурную часть — поговорим об отправке и хранении метрик. А главное, перейдём к самому интересному: получившимся дашбордам Grafana. На конкретных примерах покажу, какие проблемы удалось обнаружить и какие рекомендации по оптимизации можно извлечь из каждого элемента.

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

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

Привет, Хабр! Часто ли вам приходилось часами смотреть на сложный JOIN, пытаясь понять, почему он работает не так, как надо? Или, может, вы только начинаете свой путь в IT и слышите со всех сторон, что без SQL никуда? Вы правы, так и есть. SQL – это не просто строчки кода, это ваш ключ к данным, настоящий швейцарский нож для любого тестировщика, аналитика или разработчика.

Все мы знаем, что можно прочитать тонну теории, но без реальной практики она быстро выветривается из головы. Именно поэтому я решил поделиться своей коллекцией проверенных тренажеров и ресурсов. Здесь есть все, чтобы вы могли уверенно «заговорить» на языке данных: от уютных песочниц для новичков до хардкорных задачек с реальных собеседований в ведущих IT-компаниях. Так что устраивайтесь поудобнее, добавляйте в закладки и поехали тренироваться!

В статье Создание собственной системы F&R в «Магните»: функциональный дизайн было рассказано о том, что компания «Магнит» столкнулась с ограничениями существующих решений класса Forecast & Replenishment, по производительности, гибкости и скорости реакции.

Так мы решили создать собственное решение.

Я Алексей Соболеков, ИТ-архитектор в Magnit Tech, расскажу о ключевых архитектурных принципах и решениях Magnit F&R. Будет полезно Архитекторам, Техлидам, CTO, и всем, кто проектирует архитектуру высоконагруженных облачных решений на базе Open Source технологий.

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

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

Привет! Не успел мир договориться, что вообще подразумевать под агентами, как в инфополе обычные агенты заменились аж сразу мультиагентными системами. Обычно большинство статей про агентов начинаются с фразы "на фреймворке X..." — ну так с фреймворком каждый может, а ты попробуй без него.

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

Это — текстовая расшифровка небольшого доклада с  Форума молодых учёных, про Web 4.0: проблематика, решения и даже прототип, с которым можно невозбранно поиграться.

В предыдущей части кейса мы рассказали о внедрении Службы каталогов Dynamic Directory – отечественного аналога Active Directory, который позволил заменить MS AD и решить задачи централизованного управления учетными записями и политиками. Однако для зрелой распределенной инфраструктуры этого недостаточно: необходим инструмент централизованного управления жизненным циклом рабочих станций и серверов – тот самый функционал, который в Windows‑мире обеспечивают Microsoft System Center Configuration Manager (SCCM) и Windows Server Update Services (WSUS). В этой статье речь пойдет о том, как мы в рамках пилота внедрили платформу РОСА Центр управления (РОСА ЦУ) и с ее помощью заменили WSUS и SCCM в инфраструктуре заказчика.

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

Однако, бывают и более масштабные проекты, требующие более тщательного анализа и выбора вариантов запуска ERP-решения. Например, компания имеет распределенную географию работы, число конечных пользователей велико, часть из которых и компьютером то не пользовались, плюс ожидается, что КИС будет сильно кастомизирована под потребности заказчика. Здесь не получится взять и сразу запустить новое ИТ-решение на всех локациях и для всех пользователей. Хотя, нет, получится, но риск того, что все закончится провалом, достаточно велик. Как быть в этом случае? Необходима более разумная и согласованная со всеми стратегия запуска ERP-системы. Подобную стратегию называют по-разному: где-то концепция имплементации, в других источниках – стратегия развертывания, мы же будем называть ее стратегией внедрения.

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

В наши дни в мире разработки программного обеспечения, где взаимодействие между различными сервисами и системами является одним из самых важных моментов, глубокое понимание жизненного цикла API (Application Programming Interface) играет ведущую роль в успешном создании, поддержке и продвижении цифровых продуктов.

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

В данной публикации я хотел бы рассказать про самые важные стадии жизненного цикла API, а также по каждому этапу добавить интересные статистические данные, проведя анализ основных международных отчётов, таких как Postman State of Api , NordicAPIs и многих других.

Привет! Меня зовут Николай Олигеров. Сейчас я работаю аналитиком данных в Яндекс Путешествиях, а до этого я был продуктовым аналитиком в Лавке — мой рассказ будет именно про неё.

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

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

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

Как использовать метрику потока Throughput и реалистично прогнозировать на основе симуляции Монте-Карло. Разберем динамику Throughput (пропускной способности) за значимые периоды времени, насколько она вариативна, посмотрим на кластеризацию по типам работы).

Разбираем метрику через обслуживание в пабе в пятничный вечер в сравнении с АйТи-командой (с паттернами и примерами). Тема довольно актуальная, так как сейчас в США и Европе расцвет прогнозирования на основе именно метрик потока и появляется много плагинов с Монте-Карло (но не все из них доступны в РФ).

Он заговорил, и стрелок застыл, поражённый: к нему обращались Высоким Слогом Гилеада! — Сделай милость, стрелок‑сэй. Не пожалей золотой. Один золотой — это ж такая безделица. Высокий Слог. В первый миг разум стрелка отказался его воспринять. Прошло столько лет — Боже правый! — прошли века, тысячелетия; никакого Высокого Слога давно уже нет. Он — последний. Последний стрелок.

Стивен Кинг

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

Осторожно! В статье намеренно используются фрагменты сгенерированного текста!