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

Всем привет! Меня зовут Перебиковский Ярослав и это моя первая статья для Хабр.

Я ведущий разработчик компании «Эм Си Арт» — интегратора Битрикс24. Мы давние партнеры Битрикс24 и у нас в арсенале есть множество кастомных и, что важнее, интересных решений. Одним из них хотелось бы поделиться — расскажу о нем в разрезе пользователя, разработчика, архитектуры и опишу использованные подходы.

У одного из наших клиентов возникла нетривиальная задача — интегрировать CRM Битрикс24 с сайтом, написанным на Go. В качестве брокера сообщений клиент использовал Kafka - как самый устойчивый к нагрузкам и подходящий по ряду других параметров. Но оказалось, что готовых решений для интеграции с этим стеком технологий не было ни у нас, ни на рынке вообще. Поэтому решили написать собственный модуль с нуля.

Продолжение цикла статей о проектировании информационных систем.

Все статьи:

Введение

Видение системы

В этой части рассмотрим сущности Use Case и User Story

Привет! Маркетплейсы очень сильно изменили нашу жизнь, сделав ее супер удобной. Это классно, но думаю всем знакома картина, когда добавил товар в корзину, отвлекся, а он уже на 500р дороже. Или дешевле. Или вообще продается на косарь меньше на другом маркетплейсе. Ах да, как насчет «зачеркнутых выгодных» цен вида ̶1̶7̶0̶0̶0̶ 800р?

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

Приступим!

🚀 Новая статья: От Intel 086 до нейросетей: исповедь охотника за бизнес-процессами

Почему отличные идеи застревают на бумаге? Почему стратегии теряются в дороге от менеджера до программиста? Проблема не в людях - проблема в инструментах.

🧠 Когнитивная нагрузка - главный враг эффективности. Исследования показывают: наш мозг может удерживать всего 4±1 элемента одновременно. А что мы ему даём? BPMN-схемы с сотнями элементов, UML-диаграммы для разработчиков, текстовые ТЗ, которые никто не дочитывает. Это не управление знаниями - это интеллектуальный терроризм.

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

Решение оказалось неожиданным - язык ДРАКОН. Созданный в СССР Владимиром Паронджановым, он учитывает особенности человеческого восприятия. Принципы симультанизации (увидеть всю картину сразу) и эргономики делают сложное простым.

В статье я делюсь личным опытом:

✅ Как одна схема ДРАКОН заменила месяцы работы программистов.

✅ Как коллективное обсуждение схемы выявило разногласия между руководителями.

✅ Как непрофессионал создавал CRM-систему визуально.

✅ Как ДРАКОН стал единой платформой вместо BPMN+UML.

ДРАКОН - не просто язык. Это способ мышления, делающий бизнес управляемым. Он устраняет фрагментацию знаний, сокращает время на разработку на 40-60%, повышает качество решений.

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

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

 Пару слов о нашей команде и о том, чем мы занимаемся. У нас 6 инженеров данных и 5 аналитиков — вместе мы помогаем продуктовым командам (тем, кто развивает сайты и приложения) создавать дашборды и отчёты. Они нужны для того, чтобы коллеги видели, как их изменения влияют на бизнес-метрики и поведение пользователей.

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

Как появилась задача

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

Однако наш продукт выдавал отчёты только к 16:00. Кому-то хватает часа на подготовку, кому-то трёх, но пользователи жаловались: они просто не успевают осмыслить данные и сформулировать выводы.

Коллеги обратились к нам с запросом: перенести формирование отчетов на 12:00, чтобы оставалось больше времени на анализ. И мы стали думать, как это сделать своими силами без увеличения команды.  

Вторая статья специалиста по архитектуре ИТ-систем и трансформации ИТ-ландшафта Дениса Прилепского из серии «Строим корпоративную GenAI-платформу: от концепции до ROI». На этот раз он разбирает GenAI «под капотом» и шаг за шагом выстраивает корпоративную платформу, которая превращает хайп вокруг ИИ в реальные результаты для бизнеса.

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

Чуть более 10 лет назад, когда я служил не очень большим, но и не очень маленьким начальником в федеральном министерстве, мне предложили пройти российско-китайскую программу в Китайской академии руководящих кадров Пудун (CELAP) в Шанхае. Ядумал, что это будет очередная командировка с ритуальными поклонами.
Оказалось — нет. Совсем нет.

Если говорить ИТ метафорами, нам дали доступ в бэкенд системы управления Китаем. Представьте себе, что вы — инженер, и вас внезапно пригласили заглянуть внутрь исходного кода ОС, на которой держится страна с населением 1,4 миллиарда.
Таково ощущение от первых дней в Пудуне.

CELAP — не просто академия. Это один из самых закрытых и влиятельных центров подготовки элиты КНР, прямо в подчинении Центрального комитета КПК.
Сюда не попасть по конкурсу или связям — попасть можно только по решению системы. Здесь не просто учат не менеджеров.

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

Привет! Это снова я, Паша Лукьянов. Я по-прежнему deputy CTO в AGIMA и по-прежнему рассказываю о принципах работы архкомитета у нас в компании. В первой части статьи я объяснил, из каких критериев состоят наши Definition of Ready (DoR) и Definition of Done (DoD), а также что представляет собой наша статусная модель. А теперь поговорим об этапах проработки архитектурных документов. Если вы внедряете архитектурный комитет в своей компании и прописываете процессы — вам сюда.

Привет! Меня зовут Павел Лукьянов, я deputy CTO в AGIMA. Каждую пятницу с 3 до 4 пополудни я занят. Не звоните мне и не ищите меня. В это время у нас еженедельная встреча архитектурного комитета, где я и другие умные люди обсуждаем важные вопросы. Как правило, в центре внимания новые проекты или капитальные перемены на старых. Меняется стек? Это к нам. Обновляем архитектуру? Окей, давайте подумаем. Запускаем проект с нуля? Подберем оптимальные решения.

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

Это первая статья специалиста по архитектуре ИТ-систем и трансформации ИТ-ландшафта Дениса Прилепского из серии «Строим корпоративную GenAI-платформу: от концепции до ROI». В этой части он объясняет, зачем вообще нужен архитектурный подход при внедрении GenAI-решений и как грамотная архитектура помогает пройти путь от идеи до реальной бизнес-ценности.

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

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

В предыдущей статье мы выяснили как создать два класса (Хост и Енкодер, класс А и класс В) один из которых (А) не может работать без использования функций другого класса (В, а может, и без данных из этого класса В не может работать), но при этом совершенно не зависит от этого класса В! То есть класс А может запросто работать с любым другим классом (C, D, … ) вместо класса В, при некотором условии изложенном в предыдущей статье. По моему, та статья может быть хорошей разминкой для понимания концепции Внедрения Зависимостей. И, определенно, эта статья может считаться продолжением темы практической архитектуры ПО.

Привет, Хабр! На связи Сергей Гайдамаков. Продолжаем обсуждать и тестировать набор реплик MongoDB. 

В предыдущей статье мы рассмотрели структуру отдельного узла MongoDB, разобрали свойства параметров writeConcern и readConcern для работы с набором реплик MongoDB. 

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

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

Мы в Авто.ру шли к этому состоянию гейтвея довольно долго. История его началась в 2015 году: десятки разработчиков, сотни ручек, почти 300 000 строк кода — и релизы, которые можно катить неделю. Чтобы спасти наш стремительно деградирующий time-to-market и вернуть разработке гибкость, мы решили попробовать GraphQL-федерацию. Спойлер: кажется, получилось.

Меня зовут Кирилл Ершов, я бэкенд-разработчик в Авто.ру, и в этой статье я расскажу, как мы перешли от REST к федерации GraphQL: зачем нам это понадобилось, с какими подводными камнями мы столкнулись, как выглядели первые миграции трафика, к чему всё это привело на данный момент в цифрах и инфраструктуре. 

Привет! Распознаванием речи (ASR) уже никого не удивишь, но качественное распознавание на разговорном русском языке, а особенно в телефонии — очень сложная штука: люди редко говорят как профессиональные дикторы, часто бывает плохое качество звука с постоянными шумами на фоне и в целом есть миллиарды прочих нюансов. Наша компания занимается голосом больше 8 лет, есть собственные классные модели синтеза, распознавания и продукты на их основе, поэтому экспериментов мы проводим очень много и за появлением новых голосовых моделей следим очень внимательно. 

В свободном доступе уже есть самый узнаваемый Whisper, есть интересные модели GigaAM от Сбера, не так давно Т-Банк выложил в открытый доступ свою модель T-One — давайте заглянем под капот нашего внутреннего бенчмарка и посмотрим насколько кто хорош.

Поехали!

Это третья статья из цикла «Проектирование GraphQL API».

В предыдущих статьях мы рассмотрели основы GraphQL и принципы проектирования схемы. Теперь перейдем к архитектуре — фундаменту, определяющему, как GraphQL API будет работать в реальных условиях.

В отличие от классического подхода, где BI-система жестко фиксирует связи, мы реализовали модель, которая сама определяет, какие таблицы и связи нужны под конкретный дэшлет, и формирует оптимальный запрос «на лету». Это наша новая Адаптивная модель данных Luxms BI.

Я, Николай Павлов, инженер по обработке данных, и в статье мы разберём, как на практике построить такую модель на примере небольшого проекта: поднимем ClickHouse в Docker, создадим схему «снежинка» с тестовыми данными, соберём адаптивную модель и построим дэшборд с экономическими метриками интернет-магазина.

В этой статье расскажем про новую адаптивную модель данных в Luxms BI. Мы реализовали подход, при котором модель сама понимает, какие таблицы и связи нужны под конкретный дэшборд, и строит оптимальный SQL-запрос. Это делает аналитику быстрее, а работу с данными — действительно self-service.

Расскажем как это работает, чем отличается от старого подхода и какие преимущества дает аналитикам и бизнесу.

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

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