Системный Аналитик

На 50 откликов — 2-3 приглашения. На 2-3 собеседования — 0 офферов. И непонятно, что я сделал не так... Или в ответ: "Сделали выбор в пользу другого кандидата". И непонятно: то ли рынок мёртв, то ли ты что-то не так делаешь. Скорее всего, и то, и другое. Но второе мы точно можем исправить🤓 Что делаем мы: 🔹 Нет опыта ➡️ обучаем с нуля, ведём за руку до оффера 🔹 Не зовут на собесы ➡️ переупаковываем резюме. Даже если опыт не в IT 🔹 Зовут, но заваливаешь ➡️ проводим полноценные тестовые собеседования, разбираем твои собесы 🔹 Сопровождаем прямо в процессе найма — пока ты ходишь на собесы, мы с тобой на связи, правим стратегию на ходу Само собой даем: 📦 Слитые актуальные собеседования из реальных компаний 📦 Материалы для подготовки, шпаргалки — то, что реально спрашивают на собесах прямо сейчас 📦 Базу вопросов по тестам, кейсам, теориям — никакой воды Главное — оплата только после трудойстройства💰 Ты не платишь ни копейки, пока не получишь оффер. Никаких предоплат. Никаких «купи курс, а там уж сам». Итог: Мы уже устроили 50+ аналитиков. С нуля, с опытом, с опустившимися руками. На рынке, который уже похоронили. Надоел поиск и хочешь работать? Оставляй заявку на сайте!

Нужны актуальные вопросы с собеседований ? SA | Собеседования - твой незаменимый помощник в подготовке к собеседованиям. 🔊Обзоры собеседований c вилками на позиции: 🔵Системных аналитиков (Junior, Middle, Senior, Lead). 🔵Solution Архитекторов. 🔵С комментариями автора - как человека, который активно собеседует кандидатов. 🔊А ещё на Boosty ты найдёшь: 🔵Записи собеседований: В хорошем качестве - с тайм-кодами и названиями компаний. 🔵Статистику вопросов в разрезе каждой конкретной компании. 🔵При наличии подписки - обратную связь по твоим собеседованиям и рекомендации по их прохождению от человека, который провёл более 100 интервью в 2023–2025 годах. ➡️ Подписаться

🔥Получите навыки системного аналитика с нуля и примените их на практике с актуальными инструментами на реальных проектах. Начните обучение на курсе «Системный аналитик». 🎁Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам! 🟣Вебинар 1: «Как не допустить ошибок при написании пользовательских историй (User Story)?» ⏰5 мая в 20:00 мск Программа вебинара: 1. Вспомним, что такое пользовательская история и особенности ее написания 2. Определим типичные ошибки при составлении пользовательских историй 3. Рассмотрим пример плохо написанной пользовательской истории и ее критериев приемки 4. Проработаем варианты исправления плохо написанной пользовательской истории 5. Порефлексируем и обсудим результаты 🟣Вебинар 2: «Обзор нотации BPMN 2.0» ⏰13 мая в 18:00 мск Программа вебинара: 1. Базовые понятия нотации BPMN 2.0 2. Базовые элементы нотации BPMN 2.0 3. Плюсы и минусы нотации BPMN 2.0 4. Основные антипаттерны моделирования в нотации BPMN 2.0 🟣Вебинар 3: «Диаграмма Последовательности (Sequence Diagram) - швейцарский нож системного аналитика» ⏰19 мая в 20:00 мск Программа вебинара: 1. Смысл диаграмм и визуализаций в работе аналитика 2. Нотация Диаграммы Последовательности с нуля за 30 минут 3. Что еще освоить, чтобы приносить пользу команде Записывайтесь ➡️ OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

📊 Научитесь проектировать API и архитектуру ПО как профи, освойте SQL и NoSQL на продвинутом уровне, узнайте принципы построения сложных систем и как выбирать верные архитектурные решения. Получите актуальные навыки и инструменты. Станьте экспертом в системном анализе на курсе «Системный аналитик. Экспертный уровень» Старт группы: 29 апреля Обучение: 6 месяцев Формат: онлайн Актуальная программа обучения уже доступна для вас на сайте бесплатно. Поддержка менторов и преподавателей на каждом этапе обучения. Задайте вопрос прямо на сайте и вам ответят! 🎁Записывайтесь на бесплатный вебинар 23 апреля в 18:00 мск Тема: «Cоздаём ИИ-ассистента для системного аналитика за 1 час» Познакомьтесь с руководителем курса и задайте свои вопросы! Регистрация на сайте. Оставьте заявку на курс ➡️ OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

⌛ Impact mapping Impact mapping — техника планирования, которая помогает связать требования с бизнес-результатом Результат — визуальная карта, отвечает на вопросы по порядку: 1. Зачем это делаем? (Цель) 2. Кто может помочь или помешать? (Актор) 3. Как должно измениться их поведение? (Влияние) 4. Что можем создать, чтобы вызвать это изменение? (Результат) 💡 Не строятся функции. Меняется поведение акторов для достижения цели Какую проблему решает Часто требования формируются как список функций Это приводит к проблемам: ⚪️нет связи между функциями и бизнес-целями ⚪️бэклог переполнен ⚪️приоритеты определяются субъективно ⚪️команда становится “feature factory” Традиционные артефакты (user stories, use cases): ➖описывают что сделать ➖но не требуют объяснения зачем Impact Mapping вводит причинно-следственную модель: цель ➡️ акторы ➡️ изменения поведения ➡️ решения И обратную проверку: решение ➡️ влияние ➡️ актор ➡️ цель Если цепочка не работает в обе стороны — элемент не нужен Основные элементы Всегда 4 уровня. Без исключений. 🟧 Цель Не “что улучшить”, а “какой результат получить” Пример 🟧 Улучшить UX 🟧 Увеличить конверсию с 2% до 3% за 3 месяца 🟧 без метрики невозможно понять, работает ли решение 🟧 Акторы Это люди или группы, которые могут повлиять на цель Могут помогать или мешать НЕ системные компоненты. Это не БД и не API. Это роли с поведением. Примеры акторов 🟧гостевой пользователь (без аккаунта) 🟧авторизованный премиум-подписчик 🟧агент поддержки 🟧 Система оплаты 🟧 Пользователь, Оператор поддержки 🟧 Влияния Это изменение поведения актора НЕ функция и НЕ действие системы Пример Функция: “Показывать всплывающее окно со скидкой”. Влияние: “Гостевой пользователь завершает оформление заказа вместо ухода”. Влияние должно быть наблюдаемым Если невозможно измерить, изменилось ли поведение, это не влияние 🟧 Результаты То, что создаёт команда: функции, истории, задачи, API, UI-компоненты, отчёты Результат попадает на карту, только если напрямую поддерживает влияние 🟧 несколько результатов могут поддерживать одно влияние 🟧 а один результат - несколько влияний Если сделать X → поведение изменится 🟧искать минимальное решение для проверки гипотезы Пример

Цель: Увеличить долю повторных покупок с 30% до 45% к 31 дек
│
├── Актор: Авторизованный клиент
│   ├── Влияние: Возвращается на сайт в течение 7 дней без напоминания
│   │   ├── Результат: Персонализированная главная с недавно просмотренными товарами
│   │   └── Результат: Сохранение корзины между сессиями с визуальным индикатором
│   └── Влияние: Добавляет товары в корзину быстрее, чем в прошлый раз
│       └── Результат: Повторный заказ в один клик из истории заказов
│
├── Актор: Покупатель впервые
│   └── Влияние: Создаёт аккаунт после покупки (а не до)
│       └── Результат: Предложение создать аккаунт после оформления заказа (без принудительного входа)
│
└── Актор: Агент поддержки
    └── Влияние: Решает проблемы с аккаунтом без эскалации в инженерию
        └── Результат: Самостоятельный сброс пароля с SMS-подтверждением

Когда использовать 🤩исследование нового продукта 🤩разработка функции для нескольких спринтов. Impact mapping гарантирует, что каждая часть связана с изменением поведения 🤩кросс-функциональная работа с участием продакта, инженерии, маркетинга, продаж. Карта создаёт общий язык 🤩планирование Прежде чем заполнять бэклог, создать impact-карты для каждой цели Затем извлечь функции из карт 🤩много функций, но нет бизнес-результатов Не стоит использовать ➖исправление багов ➖задачи только ради соответствия требованиям (compliance), изменения поведения нет ➖уже есть подобные инструменты ➖инфраструктурная работа (обновление БД, миграция серверов) 📎 Материалы 1. Impact Mapping на практике 2. Как создать работающий Impact Map 3. Impact Mapping на практике 4. Сайт книги от создателя подхода "Impact mapping: Как повысить эффективность программных продуктов и проектов по их разработке | Аджич Гойко" #требования ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

⌛ Impact mapping Impact mapping — техника планирования, которая помогает связать требования с бизнес-результатом Результат — визуальная карта, отвечает на вопросы по порядку: 1. Зачем это делаем? (Цель) 2. Кто может помочь или помешать? (Актор) 3. Как должно измениться их поведение? (Влияние) 4. Что можем создать, чтобы вызвать это изменение? (Результат) 💡 Не строятся функции. Меняется поведение акторов для достижения цели Какую проблему решает Часто требования формируются как список функций Это приводит к проблемам: ⚪️нет связи между функциями и бизнес-целями ⚪️бэклог переполнен ⚪️приоритеты определяются субъективно ⚪️команда становится “feature factory” Традиционные артефакты (user stories, use cases): ➖описывают что сделать ➖но не требуют объяснения зачем Impact Mapping вводит причинно-следственную модель: цель ➡️ акторы ➡️ изменения поведения ➡️ решения И обратную проверку: решение ➡️ влияние ➡️ актор ➡️ цель Если цепочка не работает в обе стороны — элемент не нужен Основные элементы Всегда 4 уровня. Без исключений. 🟧 Цель Не “что улучшить”, а “какой результат получить” Пример 🟧 Улучшить UX 🟧 Увеличить конверсию с 2% до 3% за 3 месяца 🟧 без метрики невозможно понять, работает ли решение 🟧 Акторы Это люди или группы, которые могут повлиять на цель Могут помогать или мешать НЕ системные компоненты. Это не БД и не API. Это роли с поведением. Примеры акторов 🟧гостевой пользователь (без аккаунта) 🟧авторизованный премиум-подписчик 🟧агент поддержки 🟧 Система оплаты 🟧 Пользователь, Оператор поддержки 🟧 Влияния Это изменение поведения актора НЕ функция и НЕ действие системы Пример Функция: “Показывать всплывающее окно со скидкой”. Влияние: “Гостевой пользователь завершает оформление заказа вместо ухода”. Влияние должно быть наблюдаемым Если невозможно измерить, изменилось ли поведение, это не влияние 🟧 Результаты То, что создаёт команда: функции, истории, задачи, API, UI-компоненты, отчёты Результат попадает на карту, только если напрямую поддерживает влияние 🟧 несколько результатов могут поддерживать одно влияние 🟧 а один результат - несколько влияний Если сделать X → поведение изменится 🟧искать минимальное решение для проверки гипотезы Пример

Цель: Увеличить долю повторных покупок с 30% до 45% к 31 дек
│
├── Актор: Авторизованный клиент
│   ├── Влияние: Возвращается на сайт в течение 7 дней без напоминания
│   │   ├── Результат: Персонализированная главная с недавно просмотренными товарами
│   │   └── Результат: Сохранение корзины между сессиями с визуальным индикатором
│   └── Влияние: Добавляет товары в корзину быстрее, чем в прошлый раз
│       └── Результат: Повторный заказ в один клик из истории заказов
│
├── Актор: Покупатель впервые
│   └── Влияние: Создаёт аккаунт после покупки (а не до)
│       └── Результат: Предложение создать аккаунт после оформления заказа (без принудительного входа)
│
└── Актор: Агент поддержки
    └── Влияние: Решает проблемы с аккаунтом без эскалации в инженерию
        └── Результат: Самостоятельный сброс пароля с SMS-подтверждением

Когда использовать 🤩исследование нового продукта 🤩разработка функции для нескольких спринтов. Impact mapping гарантирует, что каждая часть связана с изменением поведения 🤩кросс-функциональная работа с участием продакта, инженерии, маркетинга, продаж. Карта создаёт общий язык 🤩планирование Прежде чем заполнять бэклог, создать impact-карты для каждой цели Затем извлечь функции из карт 🤩много функций, но нет бизнес-результатов Не стоит использовать ➖исправление багов ➖задачи только ради соответствия требованиям (compliance), изменения поведения нет ➖уже есть подобные инструменты ➖инфраструктурная работа (обновление БД, миграция серверов) 📎 Материалы 1. Impact Mapping на практике 2. Как создать работающий Impact Map 3. Impact Mapping на практике 4. Сайт книги от создателя подхода "Impact mapping: Как повысить эффективность программных продуктов и проектов по их разработке | Аджич Гойко" #требования ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

🌐 Web as Native WebView и Web as Native WebView —  встроенный в мобильное приложение компонент, который отображает веб-страницы (HTML, CSS, JavaScript) внутри приложения Важно: 🔹 это не отдельное приложение (не Chrome/Safari) 🔹он управляется нативным кодом 🔹 пользователь не видит, что это веб Web as Native —  подход, при котором веб-интерфейс используется как мобильное приложение Web —  интерфейс и часть логики 🔸рисует UI 🔸обрабатывает пользовательские сценарии Native —  оболочка (контейнер) 🔸открывает экраны 🔸управляет WebView 🔸даёт доступ к функциям устройства

WebView —  инструмент Web as Native —  архитектурный подход Большинство «Web as native»-реализаций используют WebView как основной инструмент

Как работает WebView 1. приложение создаёт WebView 2. передаёт URL 3. WebView загружает страницу 4. отрисовывает интерфейс 5. пользователь взаимодействует с ним Если нужен доступ к устройству — используется bridge (API между Web и Native внутри приложения) Пример архитектуры Пользователь      ↓ Мобильное приложение      ↓   WebView      ↓ Web Frontend      ↓ Backend API WebView — только “контейнер”,  вся логика чаще всего в вебе Способы открытия WebView ➡️ Прямое открытие экрана Самый простой вариант: пользователь нажал → открылся экран с WebView Минус: видна загрузка (белый экран), что создаёт ощущение “медленного” приложения ➡️ Предзагрузка Приложение: 🔹создаёт WebView заранее 🔹загружает страницу в фоне → пользователь открывает — страница уже готова → улучшает perceived performance (ощущаемую скорость) ➡️ Skeleton / Loader Пока WebView загружается показывается нативный placeholder или skeleton UI → создаёт ощущение скорости, даже если фактическая загрузка не изменилась ➡️ Кэширование 🔹WebView использует кэш 🔹можно хранить статические ресурсы → ускоряет повторное открытие и снижает нагрузку на сеть ➡️ Гибридный экран (частично native) 🔹шапка и кнопки — нативные 🔹контент — WebView → снижает ощущение “веба” и улучшает UX за счёт нативных элементов Где используется WebView 🔸статьи и контент 🔸 личные кабинеты 🔸формы и платежи 🔸 fallback-экраны Пример: маркетплейс Почему WebView ➖ UI часто меняется → веб позволяет обновлять без релиза приложения ➖ маркетинг управляет страницами → не требует участия мобильной команды ➖ важно быстро выкатывать изменения → веб быстрее в доставке Web: 🔹 каталог 🔹 карточка товара → высокая изменяемость, много UI-логики Native: 🔹оплата 🔹push 🔹доступ к устройству → критичные функции, требующие безопасности и интеграций Сценарий: покупка 1. User → Web: нажимает "Купить" 2. Web → Native: startPayment 3. Native → Backend: выполняет запрос 4. Native → Web: возвращает результат Безопасность Риски: 🔸XSS уязвимость    → вредоносный JS может вызвать нативные методы через bridge 🔸загрузка чужих URL    → можно отобразить фишинговую или вредоносную страницу 🔸доступ к cookies    → возможна утечка пользовательских данных ❗️Главная зона риска — взаимодействие между Web и Native, здесь веб получает доступ к возможностям устройства Плюсы и минусы ➕ быстро → можно использовать уже готовый веб и не писать UI с нуля ➕ дёшево → меньше затрат на разработку и поддержку двух платформ ➕ единый код → изменения делаются в одном месте и сразу доступны всем ➖ медленнее → из-за дополнительного слоя (браузерный движок + рендеринг)  ➖ хуже UX → веб-интерфейс уступает нативному по отзывчивости и плавности  ➖ зависимость от сети → без интернета приложение может частично или полностью не работать 📎 Материалы 1. Из браузера — в приложение: внутренняя кухня WebView 2. От Web к Native с React 3. ОМП рассказала о новых возможностях WebView в ОС «Аврора» 4. WebView: забыть нельзя интегрировать #веб ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

🎤 Вебинар Актуальные вопросы ИБ в закупках BPM платформ 31 марта разберем что нужно учитывать при автоматизации бизнес-процессов с точки зрения РБПО. В последние годы теме РБПО уделяется много внимания, как на законодательном, так и на инженерном уровне. В ответ на новые требования появляются новые методики и инструменты, которые позволят выполнить эти требования на практике. Соответственно, и в тендерной документации выделяют под эти вопросы отдельные разделы. Разберем следующие вопросы: • Нюансы законодательства по 152-ФЗ и 187-ФЗ • Типовые отраслевые объекты КИИ • ГОСТ Р 56939–2024, проблемы сертификации • Приказа ФСТЭК № 117, правомерность ссылок на п.50 • Удорожание проектов при покрытии по ГОСТ Р 56939–2024 • Этапность работ по РБПО 👤 Спикер: Игорь Клопотов, директор продукта OpenBPM 📅 Когда: 31 марта, 16:00 МСК 👉 Регистрация по ссылке #реклама О рекламодателе erid: 2W5zFHdC2kh

Вы тоже сможете вырасти до хардового аналитика уровня Middle+. Как? Добавьте к своим скилам навыки в проектировании архитектуры и интеграций веб-сервисов! Три месяца назад мы уже писали про этот курс. Сейчас пишем еще раз, потому что у курса вышло полезное обновление, уже доступное ученикам, независимо от того, когда они его купили. ————— 📚 Первое: в портфолио включили примеры интеграций от крупных BigTech-компаний. Это позволит вам понять, как технологии применяются в реальных бизнес-контекстах. 🌐 Второе: обновили портфолио. Теперь в нём есть задания повышенного уровня сложности для каждой темы. Это небольшие реальные проекты, с помощью которых можно не только проверить, но и улучшить свои навыки! ✔️Третье: вышел новый модуль про проектирование баз данных - нормализация, транзакции, основы DWH, индексы. 💬Четвертое: стал активен чат учеников (общение, обмен опытом, помощь внутри сообщества) ————— • Результат после прохождения курса: 15 рабочих проектов в портфолио-резюме • Доступ к урокам и всем обновлениям останется навсегда • Фундаментальная база • Всю программу и отзывы смотрите в боте курса Когда перейдете в бот курса, то получите бесплатные открытые уроки по архитектуре и интеграциям. Польза 👇 @studyit_help_bot Скидка на курс от канала — 1 500₽ на Stepik по промокоду SYS до конца марта.

🔥 SPRINT OFFER в YADRO для системных аналитиков: Телеком и BIOS/BMC! В YADRO стартовал SPRINT OFFER для системных аналитиков. Это возможность пройти все этапы отбора и получить оффер в компанию всего за три дня. Мы в поиске специалистов в два направления: 🚀 Телеком Разработка компонентов мобильных сетей и систем управления сетью. Команда работает с архитектурой базовых станций и телеком-платформами для стандартов GSM/LTE/5G. Технологии: LTE/5G/GSM, 3GPP/RFC/O-RAN/ITU. 💻 BIOS/BMC Разработка и поддержка системного ПО для серверов и модулей серверных платформ. Технологии: BMS, BIOS/UEFI, Embedded, Linux, высокоскоростные интерфейсы, протоколы интеграции Системные аналитики в этих командах работают с формализацией требований к продукту, технической документацией и взаимодействуют с командами архитектуры, разработки и тестирования. Уровень: Специалист / Старший / Ведущий. Формат работы: Удалённая работа или офис в городах присутствия — Москве, Санкт-Петербурге, Нижнем Новгороде, Екатеринбурге, Минске. ⚙️ Как проходит SPRINT OFFER: 1️⃣ Подайте заявку до 29 марта и пройдите HR-скрининг. 2️⃣ Пройдите техническое и менеджерское интервью. 3️⃣ Получите оффер в течение 3 дней. 💙 Подайте заявку до 29 марта и всего за 3 дня начните свой путь в компании, которая задает новые стандарты в технологической среде!

Системный аналитик. Экспертный уровень - онлайн курс, где вы научитесь: 1. Проектировать API и сложные архитектуры ПО. 2. От анализа простых требований к проектированию масштабируемых систем. 3. Современным стандартам API и архитектурным паттернам, необходимых для работы над высоконагруженными проектами уровня Senior. *Программа обучения в доступе на сайте. Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями на практике! Вебинар 1: Ошибки системного аналитика при описании REST API. 6 апреля в 20:00 мск 1. Типовые ошибки при описании REST API: структура, контракты и форматы данных 2. Где чаще всего возникает недопонимание между аналитиком и разработкой 3. Как оформлять описание REST API так, чтобы его было удобно реализовывать и тестировать Вебинар 2: Как микросервисы убивают целостность данных и что с этим делать системному аналитику. 15 апреля 20:00 мск 1. Обратная сторона микросервисной архитектуры или куда пропадают данные, когда монолит режут на отдельные сервисы. Почему некоторые отчёты теперь собирают вручную, а заказ может быть оплачен, но не доставлен. Разберём, как стриминг через брокеры превращается в чёрный ящик и почему «гарантированная доставка» — это только начало истории. 2. Шаблоны без кода: CQRS, Event Sourcing и что делать, чтобы сообщения не терялись по дороге. Поговорим про сверку данных — как понять, что две базы не зажили своей жизнью, и как закладывать сверку в требования, чтобы потом не было проблем. 3. Чек-лист на каждый день: как проверить любой сценарий на «развал данных» ещё до прода. Какие вопросы задавать команде про гарантии доставки, идемпотентность и сверку данных, чтобы не слышать в ответ «ну, так исторически сложилось». Вебинар 3: Пользовательские сценарии (Use Cases): как превратить бизнес-требования заказчика в задачи на разработку. 23 апреля 18:00 мск Программа вебинара: 1. Введение в пользовательские истории (User Stories): основы и принципы. 2. Изучение бизнес-требований: как превратить требования заказчика в конкретные истории. 3. Формулировка User Stories: примеры из практики и общие подходы. 4. Постановка задач в разработку. Записывайтесь ➡️ OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

👍 LikeC4 LikeC4 — open-source инструмент моделирования архитектуры в нотации C4 Используется подход Architecture as Code — архитектура системы описывается на простом декларативном языке (DSL) Выполняет задачи: 💙 хранение архитектурной модели системы в репозитории 💙 авто-генерация диаграмм при изменении модели Это помогает поддерживать архитектурную документацию в актуальном состоянии LikeC4 позволяет описывать элементы архитектуры: 💙системы 💙контейнеры 💙компоненты 💙связи между ними На основе этого описания автоматически создаются архитектурные диаграммы Как работает? Описывается архитектура в двух блоках: 🟡модель (Model): определение сущностей (люди, системы, контейнеры) и связей между ними 🟡представления (Views): описание того, какие диаграммы нужно сгенерировать из модели По шагам 1️⃣Архитектура системы описывается с помощью DSL-языка. Описание включает: ➖ участников системы ➖сервисы, БД ➖взаимодействия между ними 2️⃣LikeC4 анализирует DSL-описание и формирует архитектурную модель системы, которая содержит: 🟣элементы архитектуры 🟣связи между ними 🟣структуру системы 3️⃣ На основе модели автоматически создаются архитектурные диаграммы: ➖контекст системы ➖контейнерная архитектура ➖компонентная структура ❗️Если архитектура системы изменяется, меняется DSL-описание. Все диаграммы автоматически обновляются Нет дублирования данных Пример описания архитектуры (через DSL) Упрощенная модель веб-приложения:

model {
  user = person "User"

  system webApp "Web Application" {
      container frontend "Frontend"
      container backend "Backend"
      container database "Database"
  }

  user -> webApp.frontend "uses"
  webApp.frontend -> webApp.backend "API"
  webApp.backend -> webApp.database "reads/writes"
}

В этом примере: 💙определён пользователь системы 💙описана система Web Application 💙указаны контейнеры системы 💙заданы связи между элементами Пример описания представления (Views)

views {

  view container webApp {
    title "Web Application Containers"
    include 
  }
}

Этот блок определяет, какую диаграмму нужно построить из архитектурной модели В данном случае генерируется контейнерная диаграмма системы Плюсы и минусы ➖архитектурная модель - часть исходного кода проекта ➖диаграммы всегда соответствуют архитектурной модели ➖напрямую использует принципы модели C4, упрощает архитектурное моделирование ➖подходит для сложных систем, удобен для микросервисных архитектур, распределённых систем, крупных платформенных решений ➖необходимо знать синтаксис DSL ➖диаграммы нельзя редактировать напрямую мышью, только через код ➖относительно новая технология, мало примеров использования, обучающих материалов, меньше интеграций. ➖только диаграммы (нет встроенной документации/ADR, как в Structurizr) Инструменты и интеграции LikeC4 обычно используется вместе с: 💙Visual Studio Code — редактор с поддержкой DSL 💙Node.js — среда выполнения CLI 💙 Docker — запуск без локальной установки 📎 Материалы 1. Официальный сайт 2. Онлайн пример построения #инструменты ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

В IT заходишь, а страх заходит с тобой? Знакомо же:

— Только начал вкатываться, а уже знаешь, что ничего не знаешь. — Смотришь вакансии, и внутри всё сжимается — «да меня никогда блин не возьмут». — Слышишь про сокращения — и сразу мысль «а вдруг я следующий, хотя работы ещё даже нет?»

И дело не только в рынке. Это реальная тревога, которая живёт в голове и теле и мешает: 🟧учиться (потому что «аче толку, всё равно не устроюсь») 🟧ходить на собеседования (потому что страшно) 🟧верить в себя (потому что внутренний критик орёт громче всех) Я давно слежу за блогом Владислава Князева @godnolytika. Он 7 лет проработал аналитиком в финтехе, вырос до тимлида, а затем поступил в МГУ на психолога — помогать айтишникам справляться с тем, что творится в голове. Сейчас он ведет терапевтическую группу для тех, кто в IT (и тех, кто только входит). Это безопасное место, где можно: 🟧 разобраться с тревогой про будущее и вот этим «я никогда не найду работу» 🟧 приручить своего внутреннего критика (синдром самозванца) 🟧 перестать бояться ошибок и конкурентов 🟧 найти опору, когда рынок штормит 🕐 Старт — 21 марта. Формат: онлайн, 12 встреч, по субботам. Осталось 2 места. Как попасть: Напишите Владу в Telegram — @fenrrr, он пришлет программу и пригласит на бесплатный 15-минутный поддерживающий созвон, чтобы понять, что группа тебе точно подойдет.

Как на таком рынке вообще можно устроиться?! В 2026-м этим вопросом задается почти каждый, перед кем стоит проблема поиска работы. Булат — практикующий ментор и солюшен-архитектор, выросший из системного аналитика. В прошлом году он сам трижды (!) попадал под сокращения, но в итоге смог устроиться на еще большую ЗП, чем была до всех сокращений. Впечатляющий маневр? Думаю, да. А ведь вся нужная инфа для таких же камбэков уже лежит у него в канале: 🔹Где искать работу в РФ и как искать работу аналитиком вне РФ? 🔹Что спрашивают на собеседованиях и что на них отвечать? 🔹Как выбить себе офер повкуснее? 🔥 Топ постов на канале: - Текущие реалии хх - Где искать работу (+полезные ресурсы в комментариях) - Пример собеса на 550К на руки с решением задачи по System Design (оффер получен) - Интервью в AEON Payment — финтех на Кипре - Запись собеседования на СА, 480к на руки Подписывайся — @na_sobese, если устал сидеть без дела и хочешь уже устроиться на работу.

Оффер на 300к без программирования До такого уровня можно вырасти примерно за 2 года работы бизнес-аналитиком в IT. А если ты еще новичок, то стартануть от сотки в месяц. Если не планируешь заниматься программированием или тестированием, рекомендую посмотреть видос в закрепе канала IT с Юлей В нем Юля, ведущий бизнес-аналитик простым языком объясняет: — чем занимается бизнес-аналитик и почему это лучшее направление для входа в IT — как с нуля зайти в профессию в 2026 году и зарабатывать от 100к — ее путь и реальные истории трудоустройства новичков в IT Плюс дает сборник с разбором самых частых вопросов от HR с правильными ответами и разбором логики. Посмотри, потом будешь рад, что не пролистал: https://t.me/+uo6fInc09gE0Njcy

🔈 Как найти работу в 2026 году Вы все слышали о том, что происходит с рынком труда (если коротко там полный трэш) - hh / rabotaby глючит, вакансии исчезают, конкуренция х10, а рекрутеры просто не отвечают. Каждую неделю новые правила, и ты либо под них подстраиваешься, либо идешь нахер. Эта подборочка может закрыть базу. Не моего авторства, но я посмотрела и там прям очень хорошо, можно использовать. 🔴10 ключевых лайфхаков по резюме 🔴Нужны ли сопроводительные и что там писать 🔴Как отвечать на вопрос «Расскажите о себе» 🔴Как рассказывать о своем факапе? 🔴13 шаблонных отказов рекрутеров - что они означают. 🔥 Разборы резюме для АНАЛИТИКОВ ну и то, что нам особенно интересно - про офферы и ЗП 🔴45 офферов по разным ИТ ролям: от аналитика до тим тим лида за 850к 🔴Какой аналитик получил 0,5 млн. 🔴Сколько может получать аналитик в 50+ лет 🔴Как получить 75к евро с релокацией в Европу 🔴Какой тим лид получил 1,2 млн 🔴Пошаговый план как выйти в найме на 1 млн руб Сохраняйте, читайте, подписывайтесь erid: 2VtzqxYtABE

🎮 Способы распила монолита на микросервисы Правило:

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

Качественный сервис после распила обладает: 💙слабой зависимостью (loose coupling) — изменения не ломают соседей 💙высокой внутренней связностью (high cohesion) — сервис решает одну бизнес-задачу Стратегии 💙 Декомпозиция по бизнес-доменам Основана на Domain-Driven Design 💙Каждый сервис = один Bounded Context: собственная логика и данные 💙Границы определяются бизнес-процессами, а не слоями кода 💙 Пошаговый переход 1. Анализ предметной области, выделение контекстов Например, где заканчивается работа склада и начинается работа логистики 2. Определить владельцев данных. Н-р, какие таблицы в монолитной БД принадлежат какому контексту 3. Запретить прямой доступ к «чужим» таблицам 4. Выделить API 5. Отдельный деплой 💙 Пример Каталог (товары, цены) и "Заказы" (корзина, оформление). Их можно разделять Заказы хранят цену на момент покупки и не зависят от текущей цены каталога ❤️Не применять ♥️плохо формализован домен и нет четких бизнес-процессов ♥️ нет владельца продукта ♥️ часто меняющиеся границы (MVP) 💙 Strangler Fig Безопасный способ рефакторинга "на ходу", когда монолит нельзя останавливать 💙Перед монолитом ставится маршрутизатор: API Gateway или обратный прокси (nginx, HAProxy) 💙Новая функциональность создаётся в микросервисах, старая постепенно удаляется. 💙 Пошаговый переход 1. Выбрать изолированный use-case 2. Реализовать его как сервис 3. Настроить маршрутизацию 4. Переключить трафик 5. Удалить старую реализацию 💙 Пример Личный кабинет переносится по частям: сначала профиль, затем смена пароля, затем всё остальное. Монолит постепенно очищается ❤️Не подходит ♥️если нужен быстрый полный переход ♥️ монолит невозможно маршрутизировать 💙 Декомпозиция по данным (Database per Service) Не самостоятельная стратегия, а обязательное условие микросервисов Каждый сервис владеет собственной БД. Общих таблиц нет. Доступ к данным — только через API Подходы 💙разные схемы в одной СУБД 💙физически отдельные БД 💙копии данных + события 💙Event-driven синхронизация 💙 Пошаговый переход 1. Определить владельца таблиц 2. Запретить cross-schema JOIN 3. Выделить БД 4. Перевести взаимодействие через API 5. Настроить события при необходимости Пример Order Service получает собственную БД. Остальные сервисы работают с заказами только через API ❤️Не применять ♥️требуются жёсткие распределённые транзакции ♥️нет инфраструктуры событий 💙 Декомпозиция по нагрузке (Performance-driven) Выносится компонент, создающий нагрузку 💙 Пошаговый переход 1. Найти узкое место (метрики, профилирование) 2. Выделить код 3. Перевести в асинхронный режим 4. Добавить кэширование 💙 Пример Поиск товаров выносится в сервис с собственным Elasticsearch и масштабируется отдельно ❤️Не применять ♥️если проблема в плохом SQL, а не в архитектуре ♥️нагрузка не критична 💙 Декомпозиция по частоте изменений Выносится модуль, который меняется чаще остальных, чтобы ускорить релизы 💙 Пошаговый переход 1. Анализ истории коммитов 2. Выделение часто меняющегося модуля 3. Отделение данных 4. API и независимый деплой 💙 Пример Блок Акции и предложения обновляется ежедневно. Его вынос позволяет деплоить изменения без затрагивания ядра системы ❤️ Не применять Частые изменения вызваны хаосом требований 📎 Материалы 1. Шпаргалка по миграции монолита на микросервисы 2. Когда и как переходить с монолита на микросервисы. Предпосылки и общие понятия 3. Архитектура микросервисов: Разрушение монолита 4. Как НЕ надо распиливать монолит 5. Микросервисная архитектура: от монолита к гибкой системе 📚 Книги Сэм Ньюмен - Создание микросервисов #архитектура ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

Бесплатный веб «Архитектурные паттерны - на чем сыпятся даже senior'ы (старшие специалисты)» 5 марта в 19:00 мск — приходи, разберемся какие навыки необходимы системному аналитику для зп 300К и позиции мидл в 2026ом и почему 90% из вас недозарабатывают Ведущий: сооснователь Академии Системного Анализа СТЕП БАЙ СТЕП Дмитрий Колосов - практикующий специалист, техлид кластера в крупном холдинге онлайн коммерции Для кого вебинар: для тех, кто хочет повышения или новый сочный оффер (предложение) и устал сидеть в клетке новичка со скучными задачами, размытой сферой ответственности, переработками, маленькой ЗП и страхом потерять работу Что ты получишь: 1. Поймешь на реальном кейсе, какие архитектурные решения стоят 300К+ в месяц 2. Узнаешь, на каких нюансах владения паттернами подлавливают на интервью даже опытных аналитиков 3. Научишься выбирать паттерны так, чтобы система была отказоустойчивой, а твои решения — неоспоримыми для разработчиков 4. Закрепишь теорию на практике: решишь каверзную задачу в прямом эфире и разберешь ошибки в проектировании 5. Увидишь на примерах учеников, как знание архитектурных паттернов помогает забирать предложения на 300К+ и аргументировать свою стоимость Дата: 5 марта в 19:00 мск Переходи по ссылке и регистрируйся 😎 Erid: 2SDnjcRRnCR Название: ООО "СТЕП БАЙ СТЕП" ИНН: 0800013217

❌🛫 Актуалочка для россиян Если когда в России окончательно заблокируют телеграм, мы всё равно продолжим вести все наши каналы. Хотим узнать Ваше мнение по поводу ВК: будете ли Вы читать нас там?