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

Всем привет, меня зовут Миша, и я разрабатываю платформу Яндекс Еды. Первые компоненты были написаны почти 10 лет назад (когда Еда ещё была стартапом Foodfox), и у нас накопилось много кода, который просто хорошо работает, а иногда даже «работает — не трогай». Но в процессе развития и устоявшиеся части системы нужно трогать, про что мои коллеги уже писали — как мы повышали версию PHP, пилили монолит и снимали нагрузку с БД. 

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

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

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

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

Вот и в софте у нас самая честная оценка - я не знаю.

А как быть, когда все же надо дать оценку? Чтобы ответить на этот вопрос, подготовил небольшой обзор, в котором мы рассмотрим:

1. Что твердят источники

2. Что творит индустрия

3. Что говорит здравый смысл

Или почему shiny tech stack ≠ рабочий продукт. Каждую неделю выходят новые «киллеры» фреймворков, базы данных, фреймворки на фреймворки, UI-библиотеки, подходы к state management, архитектурные паттерны и всё прочее.

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

Как пилить монолит на микрофронты, углубиться в суть синхронности и асинхронности, обсудить отсутствия документации и её влияния на накопление технического долга – все это в рамках System Analyst Meetup от ГК «Юзтех» и компании «Синимекс».

Привет, Хабр! Сегодня у нас откровенный разговор с Денисом Глуховым — руководителем ЦК архитектуры блока цифровой трансформации РСХБ-Интех. Узнаем, как выглядит рабочий день специалиста, который хорошо знаком с кухней цифровой трансформации в крупном банке и превращает сложные бизнес-требования в эффективные технологические решения.

Денис, как начинается твой рабочий день? Есть ли у тебя утренние ритуалы или привычки?

Мой рабочий день начинается c момента,  когда я оставляю авто на перехватывающей парковке и сажусь в МЦД. Я открываю ноутбук и по пути на работу просматриваю накопившуюся почту, отвечаю на сообщения, просматриваю календарь и распределяю задачи, ранжируя их по приоритетам. Территориально с командой находимся на Теплом Стане, но фактически работаю на два офиса, так как большое количество очных встреч проходит с руководством в офисе в Москва-Сити. Люблю офис на Теплом Стане: там лучше думается. Мой обязательный утренний ритуал — самый большой завтрак в корпоративном кафе.

Какие основные задачи и проекты ты планируешь к выполнению сейчас? Как ты определяешь приоритеты?

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

Привет! Меня зовут Азамат, я backend-разработчик в Циане. В работе мне часто приходится пересматривать архитектуру компонентов или проектировать её с нуля. Со временем у меня накопились подходы и наблюдения, которыми хочу поделиться.

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

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

Привет, Хабр! Меня зовут Константин Архипов, я scrum-мастер продукта «Среда ЭДО» в МТС. Последние несколько лет я занимаюсь электронным документооборотом и вижу, насколько это сложный процесс и как его недооценивают.

Малый бизнес может взять коробочное решение и подключиться к ЭДО через оператора. Крупный уже давно и основательно занимается in-house-разработкой — с такими объемами не остается другого выхода. Например, в экосистеме МТС существует несколько инстансов биллингов, где рассчитываются счета и формируются закрывающие документы. Интегрировать каждый биллинг со своим оператором ЭДО нерационально, поэтому мы объединяем потоки данных в нашем продукте «Среда ЭДО» и в начале месяца обрабатываем и маршрутизируем в день до 350 тысяч документов из разных источников.

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

Мы в МТС вместе с коллегами из других компаний суммировали свой опыт и подготовили карту внедрения ЭДО — она должна помочь с первыми шагами. В этом материале я расскажу, зачем нужна карта, с чего надо подступиться к ЭДО и чем опасна ситуация, когда все действуют по принципу «гром не грянет — мужик не перекрестится».

Системным аналитикам часто приходится проектировать процессы авторизации, выбирать протоколы и описывать требования к аутентификации. Но когда дело доходит до SSO (Single Sign‑On) — архитектурных решений становится неожиданно много:
OIDC, SAML, Kerberos… Что из этого выбрать и почему?

В статье — подробный разбор SSO:

• Что это такое, как работает и где мы сталкиваемся с этим каждый день (вход через Google, корпоративные порталы, файловые ресурсы Windows);

• Как устроены OIDC, SAML и Kerberos — и чем они отличаются на каждом этапе: от запроса до logout;

• Кому какой протокол подходит и как избежать архитектурных ловушек (например, использование SAML в мобильном приложении — это боль);

• И, конечно, схемы, псевдокод и чек‑листы выбора.

Flowable Async Executor (также известный как Job Executor) — это ключевой компонент Flowable. По сути, это многократно используемый, автономный компонент, работающий внутри различных движков Flowable и обеспечивающий асинхронное выполнение логики.

Привет, Хабр! В этой статье рассмотрим невинный на первый взгляд параметр shuffle=True в train_test_split.

Под «перемешать» подразумевается применение псевдо‑рандомного пермутационного алгоритма (обычно Fisher‑Yates) к индексам выборки до того, как мы режем её на train/test. Цель — заставить train‑и-test быть независимыми и одинаково распределёнными (i.i.d.). В scikit‑learn эта логика зашита в параметр shuffle почти всех сплиттеров. В train_test_split он True по умолчанию, что прямо сказано в документации — «shuffle bool, default=True».

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

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

И ещё. Предлагается не NoCode или LowCode, а скорее, оченьдаже-Code. В общем, это – другое!

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

Появилась у меня задача по мониторингу и оценке производительности проекта на микросервисной архитектуре. Для решения был выбран Jaeger. Он давно на рынке, активно развивается (не так давно вышла версия 2, в которой упростилось развертывание и появилась интеграция OpenTelemetry). На мой взгляд, Jaeger – отличное решение для трейсинга, но документация ощущается как не до конца собранный пазл: важные вещи разбросаны, а для понимания приходится обращаться к исходному коду или искать примеры в GitHub-репозиториях.

Цель данной статьи показать на практике, как внедрить Jaeger в продукт на микросервисах.

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

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

Меня зовут Кирилл, и на протяжении последних двух лет я мечтал научиться проходить System Design интервью. Но только недавно взялся за дело всерьёз.

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

Всем привет, 

Команда devhands.io сделала с Владимиром Перепелицей интервью, посвященное сравнению наиболее популярных решений в области очередей и брокеров сообщений — Kafka, RabbitMQ, NATS.

Владимир — эксперт по большим проектам, очередям и Tarantool, Solution Architect в Exness, создатель S3 в VK Cloud, регулярный спикер и член ПК конференций Highload. А мы, R&D-центр devhands.io, разрабатываем образовательные программы по хайлоаду, перформансу, архитектуре, базам данных и другим направлениям.

Под катом – расшифровка интервью.

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

Но для начала я напомню суть модели архитектуры TOGAF.

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

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

Для чего это необходимо делать?

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

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

Всем привет! Меня зовут Андрей, уже несколько лет я работаю тимлидом/техлидом в разных компаниях и различных проектах. В последнее время подход Domain Driven Design у всех на слуху. Хотя этот подход развивается уже много лет (с 2003), только сейчас на него обращают активное внимание и многие команды пробуют внедрять его у себя.

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

Привет, Хабр! Меня зовут Илья Волынкин, я CTO платформы МТС Exolve. Когда мы говорим про VoIP-телефонию, первая ассоциация — Asterisk. Это open-source ПО захватило рынок и его аналоги не так популярны. На True Tech Day я рассказал про наш опыт с FreeSwitch — инструментом, решающим гораздо более масштабные задачи. 

Благодаря ему мы смогли построить платформу, которая позволяет реализовывать сложные сценарии, добавлять разные модули (например, с AI под капотом), и собирать себе системы телефонии по принципу Lego. Под катом: рассказ про то, как сейчас усложнилась инфраструктура для звонков, какие есть варианты реализации VoIP и как это может развиться в будущем.