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

Жизненный цикл программного обеспечения включает в себя множество этапов. Так в работе [1] выделяют активности по предпроектному обследованию, внедрению программного обеспечения и непосредственно пост-проекту имплементации. Этап поддержки и развития относится к пост-проекту внедрения и призван обеспечить непрерывное функционирование разработанной и запущенной в продуктивный режим работы программной системы. По большому счету, это именно тот результат, который изначально ожидается от реализации любого программного продукта: его постоянное и качественное функционирование для удовлетворения нужд пользователей и достижения стратегических целей предприятия.

Существует множество различных сводов знаний, применимых к комплексным программным системам: PMBoK для управления проектами, BABoK для бизнес-анализа, BPM CBOK для управления бизнес-процессам, EABoK для управления кооперативной архитектурой, а также SWEBoK по программной инженерии. Практически во всех сводах знаний делается акцент именно на внедрение и смежные активности, забывая про то, что имплементация программного продукта завершается его передачей в поддержку. Одним из немногих литературных источников по данной тематике является ITIL [2], описывающий четыре домена знаний, позволяющих осуществлять сопровождение решения после его реализации.

В контексте BABoK и расчета бизнес-кейса, выполняемого при предпроектном обследовании, довольно часто рассчитывается показатель TCO (Total Cost of Ownership, совокупная стоимость владения), демонстрирующий постоянные и переменные затраты, которые понесет компания при внедрении программного обеспечения. Одной из постоянных статей затрат является сумма поддержки и развития информационной системы. Таким образом, знание особенностей выполнения этапа поддержки и развития программной системы позволяет рационально планировать затраты и разумно ограничивать содержание проекта имплементации.

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

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

У каждого есть своя граница, где Postgres ещё применим, а дальше —уже нет. Обычно это где-то между одним и пятью терабайтами, дальше жить с этим «больно».

База просто не может обработать большой объем данных с той скоростью, которую способны выдать диски.

И вот — Postgres 18, впервые за долгое время, предлагает не косметическую, а фундаментальную новинку. То, что в Oracle есть уже 20+ лет — асинхронный ввод-вывод (аsync IO).

Попробуем посмотреть async IO и ответить на вопрос - стал ли Postgres ближе к «взрослым» нагрузкам?

Примечание: Статья посвящена формату XBRL-CSV2 (тэг "@context":"www.cbr.ru/xbrl_csv2").

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

Введение.

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

Эти формы содержат гиперкубы с открытыми осями. При большой вариативности значений таких осей реестровые отчеты становятся чрезвычайно объемными.

Решение этой проблемы — создание производного от XBRL-XML формата: XBRL-CSV.

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

Остальные колонки — это данные, которые определяют три аспекта показателя:

Если вы достаточно давно занимаетесь разработкой ПО, то, вероятно, сталкивались с такой ситуацией: CRUD-приложение, обслуживающее небольшую группу пользователей, развёрнутое в кластере Kubernetes и вдобавок с половиной функций CNCF. В теории выглядит впечатляюще. В реальности же это машина Руба Голдберга, решающая задачи, которых у команды на самом деле нет.

В качестве противоположного примера возьмём Levels.fyi. Сегодня этот сайт помогает миллионам разработчиков сравнивать зарплаты и карьерные перспективы, но в начале его «бэкендом» были просто Google Формы, сохраняемые в Google Таблицы. Никаких микросервисов, никакого Kubernetes, никакой шины событий. Самые простые инструменты, которые можно придумать. Такая легковесная система обеспечила владельцам сервиса скорость её развития. Они проверили жизнеспособность идеи, расширили аудиторию и начали вкладываться в более сложные системы только тогда, когда стало ясно, что продукт рабочий. Иными словами, простота не стала для них препятствием, а превратилась в залог успеха. Стоит также помнить о том, что некоторые из самых сложных инфраструктур изначально были очень простыми: например, Airbnb, Facebook*, Reddit. Прежде, чем завоевать всемирную популярность, они были фрагментарными монолитами.

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

Привет! Я Рамиль Сакаев — аналитик в команде Авито Авто. В статье рассказываю, как адаптированная RFM-методология помогла нам выявить недоработанные зоны CRM-коммуникаций и создать бенчмарк для маркетологов.

Аббревиатуры MES, WMS, ERP и им подобные давно стали синонимами цифровизации. О них пишут, их предлагают, их «внедряют». Но за красивыми терминами часто теряется суть — какую конкретно задачу решают эти системы? 

В этом материале мы поговорим о MES (Manufacturing Execution System) — системе управления производственными процессами. Благодаря маркетинговым обещаниям, в массовом представлении MES часто выглядит как «серебряная пуля». Стоит ее внедрить — и брак волшебным образом исчезнет, себестоимость устремится к нулю, а производительность взлетит до небес. Звучит заманчиво, но насколько эта картина соответствует реальности?

Меня зовут Иван Балашов, я руковожу направлением цифрового производства в К2Тех. Мы занимаемся внедрением именно таких решений на промышленных предприятиях. В основе этой статьи — живой кейс, и я предлагаю посмотреть на MES без розовых очков и разобрать на примере, как MES повышает эффективность бизнеса. 

Привет, Хабр! На связи Егор Марюшко.

Я не верю в то, что ИИ отберёт у бизнес и системных аналитиков работу.

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

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

В данной статье разберём промт для создания критериев приемки (Acceptance Criteria) для User Story, проверим его работу на наиболее распространённых и доступных ИИ: ChatGPT, DeepSeek, Qwen, Алиса (Яндекс GPT), GigaChat.

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

Всем привет! Опыт защиты высоконагруженных сервисов, в том числе на базе 
1С-Битрикс показывает, насколько критичным с точки зрения обеспечения безопасности веб-приложения является настройка его системного окружения. Защита такого приложения - это не только включение подсистем защиты и своевременные обновления, а комплексный подход, охватывающий все слои ИТ-инфраструктуры. Недостаток в любой ее точке может свести на нет все усилия разработчиков по написанию безопасного кода и привести к серьезным последствиям: от утечки конфиденциальных данных до деградации связанных бизнес-процессов с финансовыми и репутационными потерями.

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

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

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

Привет! Этот пост — перевод очень хардовой статьи про внутренности vLLM и того, как устроен инференс LLM. Переводить было сложно из-за англицизмов и отсутствия устоявшегося перевода многих терминов, но это слишком классная статья, и она обязана быть на русском языке! А дальше — слово автору:

От paged attention, непрерывного батчинга, кэширования префиксов , specdec и т.д. — до мульти-GPU и мультинодового динамического сервинга LLM под нагрузкой.

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

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

Привет, Хабр! Меня зовут Дмитрий Овчаренко, я технический директор департамента разработки для финансового сектора IBS, более десяти лет создаю сложные ИТ-решения для лидеров рынка, а также преподаю в Учебном центре IBS.

Недавно мы провели внутрикорпоративный эфир Ask Me Anything («Спроси меня о чем угодно»). Коллеги могли задать любой вопрос о работе архитектора ПО. В этой статье поделюсь самыми интересными и неожиданными из них.

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

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

Используя традиционные методы, команде из нескольких аналитиков может потребоваться 3–4 недели на таксономизацию данных. За это время выявленные проблемы уже перезреют, возможности будут упущены, а критически важное окно для быстрого реагирования закроется. Конечно, вы можете использовать ранее заготовленную таксономию, но она будет охватывать только те категории, которые вы смогли предвидеть заранее.

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

CrewAI — фреймворк интересный. Он похож на самый быстрый способ удивить своего босса: легкий, у него очень низкий порог входа, он по дизайну нацелен на мультиагентность и из него можно очень быстро собирать MVP с вау-эффектом. В статье поговорим о том как создавать агентов на фреймворке, что у них внутри, где фреймворк хорош, а куда брать его не нужно.

Мультиагентная система без подходящей задачи — это, как говорится, токены на ветер, поэтому мы сколотим банду агентов, которые нам будут анализировать arxiv-статьи про LLM и посмотрим как это работает.

Привет! Меня зовут Егор Козлов, я работаю NLP-инженером в red_mad_robot. Мы активно внедряем в бизнес AI-агентов — автономных и полуавтономных программных сущностей, которые самостоятельно выполняют задачи и принимают решения в интересах бизнеса. 

В статье расскажу о принципах работы AI-агентов — с особым вниманием к workflow-агентам и мультиагентным системам (MAS). И поделюсь практическим кейсом внедрения мультиагентной среды для автоматического анализа и исправления уязвимостей в коде.

Привет, друзья! Если вы из тех, кто не боится нырять за результатом в глубины A/B-тестирования, то эта статья для вас. Меня зовут Максим, я продакт менеджер в Купере — сервисе доставки продуктов из магазинов и ресторанов. Зона моей ответственности — пользовательский опыт после оформления заказа: от активного экрана до функций вроде оценки, чаевых партнерам и добавления товаров в уже собранный заказ.

Этот материал — реальный кейс из нашей практики. Речь в нем пойдет о неудачных, «красных» A/B-тестах — после которых гипотезы отправляются в корзину. Один из таких провальных экспериментов мы достали из небытия, разобрали по косточкам и превратили в работающий продукт. Опыт работы с ним оказался полон инсайтов, о них мой рассказ. 

Привет! Я Дмитрий Дин, тимлид в диджитал-продакшне Далее. Сегодня расскажу, как мы разработали свою BI-систему с гибкими дашбордами и реактивными фильтрами — и для этого я собрал библиотеку ReGraph.

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