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

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

Бытует мнение, что «кто рано встает, тому Бог подает», а успешные CEO спят по 4 часа и начинают день в 5 утра. Но если вы чувствуете, что ваш мозг оживает только тогда, когда город засыпает, а лучший код пишется между полуночью и пятью утра - возможно, дело не в прокрастинации, а в особенностях работы вашего разума.

Как показывают исследования, ночной образ жизни - это не баг, а фича высокоразвитого интеллекта.

Привет! Эта статья - текстовая версия моего стрима с разбором задачи на бесконечную ленту по System Design из https://t.me/siliconchannel/141 этого поста.

Рассмотрим классическую задачу из System Design интервью - персональная лента подписок. По сути, мы проектируем упрощённый клон Instagram. Сама задача звучит следующим образом:

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

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

Проблема почти никогда не в платформах и не в подрядчиках.

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

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

Почему так происходит, при чём здесь Greenfield и Brownfield, когда стандарт начинает приносить реальные деньги — в проектах и в ремонтах — и почему начинать стандартизацию нужно именно с PLC-кода, а не с BI, — разбираем на практике.

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

Вдохновением стал курс от ШАДа 2025 года, буду использовать оттуда множество чудесных картинок.

Объявим главные вопросы, на который нужно дать ответ, для решения задачи ML-ем. А также, основные проблемы в рексисе о которых нужно думать заранее.

Миронов В.О., Кальченко С.Н.

Добрый день, уважаемые хаброгорожане;‑) Крайние тренды по части тестирования современных больших языковых моделей выходят на невиданные высоты и ставится цель: пересматривать не только всю систему анализа моделей, но и саму структуру эволюции нашего подхода к пониманию больших языковых моделей в самом широком контексте. Здесь мы всё больше «скатываемся» к математическому описанию объекта промпта и его понятия. По большому счету, наибольшее понимание, а именно, формирование идей в машинном представлении, основано на геометрическом понимании «форм» слов, а не алгебраическом, в виде векторов, эмбеддингов и матриц, хотя это тоже очень важно на базовом уровне. Отличный пример такого подхода изложен в этой статье, где как раз и показано, что важно, топологическое представление пространства слов и их смыслов, так как оно максимально гибко и позволяет работать с двумя главными понятиями для словоформ: значение и время, в течение которого это значение сохраняется для текущего контекста.

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

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

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

В качестве примера я выбрал развитие электротехнической промышленности и специализированного станкостроения, которые и сегодня входят в наивысшие приоритеты. Будет 3 части: 1) Царская Россия, 2) Советская Россия, 3) Современная Россия.

Сегодня Часть 1: Технологический суверенитет в царской России

1.   Газовое и электрическое освещение

Катализатором развития электротехнической промышленности можно считать развитие освещения.

Этап 1. Газовое освещение (1840-1870-е)

В 1835 году была создана первая российская акционерная газовая компания «Общество для освещения Санкт-Петербурга газом». Основатели ее интересные ребята: механики Рейенбах и Штраус, нотариус Пигасовский, генерал-майор Бетхер – современным языком говоря – эксперты в технологии плюс юридическая и GR-поддержка. Но даже дворцовые связи генерал-майора Бетхера не позволили построить газовый завод на берегу Мойки, недалеко от Дворцовой площади, поскольку вид возводимых заводских стен и труб «оскорбил взор августейших особ» и последовало «высочайшее повеление» о переносе предприятия в Каретную часть города, за Обводной канал. В итоге проект «застрял» на 3 года и смета значительно выросла из-за прокладки дополнительных газовых магистралей, которые пришлось вести вдоль Обуховского проспекта; Общество построило первый газовый завод у Обводного канала в 1839 году и стало заниматься уличным освещением столицы.

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

Но потом задал себе вопрос, а как собрать 4 на 4? И тут меня понесло... Нашел в интернете множество вариантов, формул.

Затем посмотрел на квадрат с другой точки зрения, в силу своей фантазии:

Мы, люди разных национальностей и вероисповеданий по разному воспринимаем порядок вещей и явлений.
К примеру западной формы мышления - размещаем информацию слева направо, сверху вниз.
А в арабском мире (я как то изучал арабскую письменность в детстве) пишут справа налево, но при этом, также сверху вниз.
Так вот, если в таблице 3 на 3 заполнять по порядку 1,2,3... 9 и сравнить с порядком расположения чисел в магическом квадрате возникает ощущение, что заполняемость магического порядка, это некий иной порядок размещения чисел, скажем условно "инопланетянский".

Тогда я решил научится мыслить образно как "инопланетяне" и научится легко заполнять магические квадраты на пустых ячейках. Тем самым научившись логике и порядку - применять эти же знания в повседневной жизни и при разработках скриптов
Вариантов 4 на 4 квадратов было много, и один из самых известных это квадрат Юпитера, размещенный в гравюре Альбрехта Дюрера "Меланхолия".

Всем привет! Меня зовут Кирилл Грищук, я Tech Lead в команде Инфомодели в Авито. Мы занимаемся тем, что обрабатываем формы от пользователей: от 5 млн до 15 млн форм в минуту, а это более 150 тысяч в секунду. 

В этой статье на примере Авито я рассказываю, зачем мы стремимся к SLI 99.99%. Внутри — обзор и сравнение решений по доставке неизменных данных, учитывая специфику нашего сервиса. Показываю на примере форм, какие интересные доработки мы придумали, чтобы достичь этих четырёх девяток, и какие ошибки совершали по пути.

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

Заходишь на Хабр.Карьеру, открываешь вакансии системных аналитиков, а в требованиях всё как обычно: построение информационных систем, понимание архитектуры, ТЗ, BPMN, базовый SQL. Нигде ни слова о знании GPT или умении промптить. Формально профессия как будто не изменилась. 

Тем временем в свежем отчёте OpenAI о корпоративном применении ИИ опубликовали статистику: использование ChatGPT в корпоративной среде за год выросло в 8 раз, а объём запросов от одного человека — в среднем на 30%.

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

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

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

Эту фразу из "Макбета" Шекспира автор осмелится перевести как "благодаря зуду на кончиках моих пальцев может появиться что-то очень странное".

Изначально хотелось всего-лишь ознакомиться с Verilog, но, "опасное это дело, выходить за порог: стоит ступить на дорогу и, если дашь волю ногам, неизвестно куда тебя занесет".

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

Надеюсь, это окажется кому-то полезным, так же как когда-то автору был полезен игрушечный hoc из книги Кернигана и Пайка "Unix - программное окружение".

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

Вспомним основные моменты проектирования процессов. Под бизнес-архитектурой подразумевается совокупность двух взаимосвязанных составляющих: организационной структуры и бизнес-процессов. Оргструктура бывает линейной, функциональной, дивизионной и матричной, каких-то сложностей с ее моделированием обычно не бывает. Бизнес-процессы описывают в моделях «Как есть» и «Как будет», где последняя характеризует работу компании после внедрения ИТ-решения. Моделирование подразумевает собой последовательную декомпозицию процесса с дальнейшим проектированием операций в той или иной графической нотации. Выделяют нотации верхнего и нижнего уровней, к которым можно отнести ARIS VACD, BCM, IDEF0 и UML AD, BPMN 2.0, ARIS eEPC [1-3].

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

Привет, Хабр! Меня зовут Евгений Мичурин, я senior BI-разработчик в Авито.

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

Мы решили навести порядок и создали фреймворк автосертификации BI‑отчётов. В этой статье рассказываю, как он работает, какие критерии мы выбрали и как мотивировали команды участвовать в процессе.

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

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

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

Одна из таких стратегий - арбитраж ставок финансирования (funding rate arbitrage). Это безопасная стратегия с небольшим количеством рисков, которая доступна каждому. Из навыков тут при наличии автоматической системы тут нужно лишь умение открывать позиции на разных биржах.

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

Здравствуйте, меня зовут Дмитрий Карловский и я... серийный убийца устоявшихся стандартов. Сегодня я выследил и нанёс критический урон UTF-8. И сейчас я расскажу, как я его переиграл и уничтожил новым стандартом кодирования текста — Unicode Compact Format.

Для начала — немного контекста. Я не программист и не разработчик. Последние 12 лет я проработал в Федеральной налоговой службе. Начинал с низов, занимался выездными и камеральными проверками (проводил лично и курировал). Два месяца назад я уволился, завел свой телеграм‑канал и теперь работаю в налоговом консалтинге.

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

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

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

После моей статьи про АИС «Налог-3» (как одну из самых мощных государственных IT-систем России) в комментариях больше всего спорили не про масштабы данных и вопроса, «видит ли ФНС всё». Основной скепсис вызвал мой тезис о необходимости внедрения больших языковых моделей (LLM) в работу налоговых органов.

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

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

Если вы читаете меня впервые: я не аналитик со стороны и не «диванный эксперт». За моими словами 12 лет работы в налоговых органах, в том числе на руководящих должностях. Из системы я ушёл совсем недавно и прекрасно понимаю, как это работает изнутри.