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

Привет, Хабр! Меня зовут Олег Гуров, я Presales Solutions Architect на продукте MWS GPT — платформе для работы с LLM. Мы начали развивать ее в МТС Web Services два с половиной года назад: собрали песочницу на несколько видеокарт, где тестировали модели, проверяли гипотезы, искали применение в бизнесе. Мы быстро поняли, что в МТС интерес к LLM есть, и развернули внутренний сервис, где любой сотрудник или разработчик продукта мог попробовать их в деле. 

За первый год у нас появилось более 15 тысяч пользователей и 150+ внутренних проектов, использующих платформу. Сейчас наш сервис выдает больше 0,5 трлн токенов в год. Что это за цифра и как ее оценить? Для токенайзера Llama 3, например, это около 0,5 млрд страниц текста, отправленного в модели и полученного от них.

В январе 2025-го мы вышли на новый уровень зрелости: технология показала эффективность, команда набрала темп, и мы решили запустить продукт для внешних заказчиков. Так и появилась коммерческая платформа MWS GPT.

В статье рассказываем о подходе к построению DWH на базе единой инфраструктуры данных (Unified Data Infrastructure), разработанной Andreessen Horowitz. 

Разбираемся, почему модель a16z полезна в быстрорастущих компаниях или тех, кто переходит к data-driven управлению.

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

Вам интересно, какую нагрузку способен выдержать n8n, прежде чем он поднимет белый флаг? Мы выжали из него все соки — и результаты впечатлили.

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

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

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

Игровой движок Quake невероятно сильно повлиял на технологию разработки игр. Он активно лицензировался, в том числе, для использования в таких топовых играх как «Half-Life», «Call of Duty» и «Star Wars: Jedi Knights». Вероятно, наиболее серьёзное влияние оказали те многочисленные разработчики, которые научились писать игры, занимаясь его моддингом, а затем принесли с собой его принципы в другие студии, обогатив ими развитие других движков.

Большая часть того, что уже написано о движке Quake — это информация с акцентом на технологию 3D-рендеринга или многопользовательские сетевые игры. Но почти без внимания остаётся инновационная система объектов — парадигма, с опорой на которую дизайнеры уровней создают динамические взаимодействия, не прибегая к написанию кода.

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

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

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

По всей вероятности, нужна какая-то подводка. А очень может быть, сначала надо открыть людям целый новый мир, и только потом, в его свете, доносить идею.

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

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

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

Это не теория и не маркетинговая сказка. Это реальный проект, с реальными цифрами, диалогами и сложными решениями. Меня зовут Владимир Финк, я генеральный директор компании INTEKEY, и эта история началась несколько лет назад, когда мы только выводили на рынок нашу WMS-систему. Мы тогда были молодыми и голодными, но уже тогда в нашем ДНК было заложено правило: сначала думаем, потом — делаем. И, как оказалось, это был наш главный козырь.

Привет! Меня зовут Гильметдинов Ильнур, ведущий эксперт Дирекции роботизации банка Уралсиб.

Сегодня хочу рассказать о вызове, с которым мы столкнулись в самом начале пути масштабирования RPA (Robotic Process Automation) внутри банка: как научить коллег, не имеющих опыта в программировании, не просто пользоваться роботами — а создавать их самостоятельно?

Это звучит амбициозно — и даже немного наивно. Но именно с этого начался наш путь к созданию внутреннего курса по RPA на платформе PIX.

Рефакторинг исторического кода с переходом на сервисную архитектуру напоминает игру в дженгу — надо аккуратно перестроить существующий проект и не сломать его. Но если вы меняете архитектуру с учётом жёстких требований PCI DSS в финтех-проекте, то одновременно с игрой в дженгу вам нужно балансировать на шаре и решать сложные уравнения. В этом мы убедились на собственном опыте.

Меня зовут Анатолий Яшкир. Я руководитель разработки финтеха ВКонтакте. В этой статье расскажу о специфике финтеха и нашем кейсе рефакторинга исторического кода с переходом на сервисную архитектуру. 

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

Сбор телеметрии нужен для отслеживания состояния сети, если качество сети проседает в какой-то области, то нужно провести работы по восстановлению работоспособности LTE. Также это понимание, какой версии прошивка, какая сим-карта стоит в модеме на текущий момент.

Всем привет! В первой части https://habr.com/ru/articles/958356/ мы познакомились с форматом XBRL-CSV2, который позволяет упаковать сложность XBRL-отчетности в простые и удобные для обработки CSV-таблицы. Мы обсудили, как данные и их метаописания (маппинг) преобразуются из XML-представления в реляционное.

Но сбор данных — это только половина дела. Вторая, не менее важная часть — это их проверка на целостность, непротиворечивость и соответствие бизнес-правилам. В классическом XBRL за это отвечает формульный слой (Formula Layer). Сегодня мы поговорим о том, как мы превратили эти формулы в исполняемые SQL-скрипты, создав так называемый «слой отделяемых формул».

С помощью ИИ вполне можно сгенерировать сайт‑визитку или игру в крестики‑нолики, составить план отпуска или сделать более сложные вещи. А как насчёт того, чтобы сгенерировать ПО для управления атомной станцией или самолётом? Или как насчёт планирования не отпуска, а проекта на сотни человеко‑лет? Это в принципе возможно и можно ли доверять результатам работы ИИ?

В статье сначала будет немного теоретических рассуждений на эту тему, идея банальная: сложные задачи нужно декомпозировать. Затем рассмотрим это на конкретном примере, разобьём разработку приложения для HR отдела на три шага: 1) описание процесса приёма сотрудников на работу, 2) описание модели состояний для кандидата при прохождении собеседований, 3) генерация кода.

В заключении опишем профит от моделирования, если вы используете ИИ. И профит от ИИ, если вы занимаетесь моделированием.

Привет! Меня зовут Женя Орлов, я руковожу NLP-разработкой в red_mad_robot. Мы экспериментируем с мультиагентными системами и изучаем, как LLM ведут себя в разных архитектурах. В процессе накопилось много наблюдений и рабочих инсайтов — хочу поделиться тем, что помогает нам при проектировании AI-агентов. 

В последнее время внимание инженеров и исследователей привлекают агентные архитектуры — системы, где LLM координирует работу внутренних инструментов и других моделей. Разберём два основных подхода к построению агентных систем. 

В статье Архитектура высоконагруженной платформы Magnit F&R было рассказано о ключевых архитектурных принципах и решениях.

Сегодня хочу поделиться практическим опытом: как в Magnit Tech изменилась концепция Data Lakehouse, где она блестяще сработала — и где подвела.

Я, Алексей Соболеков, лид архитектуры F&R.

И это история о том, как красивая теория сталкивается с физикой доступа к данным.

В каждой компании независимо от ее размера и вида деятельности проводятся совещания. Многие сотрудники, да и руководители разных уровней считают, что совещания отнимают много времени и зачастую зримого результата от них не наблюдается. Тем не менее они регулярно проводятся. Проведение совещания — это прихоть руководителя компании или что‑то другое, что необходимо для деятельности компании?

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

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

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

Привет, Хабр! Меня зовут Николай Бушков, я работаю архитектором в команде Engineering Productivity R&D в Т-Банке (группа «Т-Технологии»). В начале лета я выступал на конференции MTS True Tech Day c докладом «Не эксперимент, а стратегия: путь к системному использованию AI в SDLC». А сейчас хочу поделиться текстовой версией описания сценариев использования искусственного интеллекта (ИИ) в программной инженерии, которые реализуются у нас в компании. Уверен, наш опыт будет полезен многим для генерации и фильтрации идей применения ИИ, а также сравнения их с положением дел в ваших рабочих процессах. В конце статьи кратко сформулирую наше видение дальнейшего развития и приглашу поучаствовать в  исследовании ИИ в инженерной культуре России.

Вечные переделки и продукты, не решающие реальные проблемы? Возможно, вашей команде не хватает фазы Discovery.

Из этой статьи вы узнаете, как внедрить фреймворк, который делит работу на две четкие стадии: Исследование (Discovery) и Реализация (Delivery).

На практическом примере разберем:

- Как провести глубинное исследование проблемы до написания первой строчки кода.
- Что входит в процессы бизнес- и системного анализа на каждом этапе.
- Шаги внедрения фреймворка на вашем проекте.

Перестаньте тушить пожары и начните создавать востребованные продукты.

Business Process Model and Notation (BPMN) — это стандартизированное графическое представление, предназначенное для облегчения визуализации, понимания и взаимодействия сложных бизнес-процессов. Этот метод предоставляет целостную структуру, обеспечивающую единообразие описания между различными участниками, эффективно устраняя разрыв между технической и нетехнической аудиториями. BPMN использует набор стандартизированных символов, позволяющих компаниям системно описывать свои операционные потоки. Такая наглядность особенно важна в средах, где критичны оптимизация процессов и соблюдение регламентов, — она дает ясное представление о том, как действия, события и точки принятия решений взаимосвязаны внутри процесса.

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

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

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