1. Что требуется от диаграммы?
Показать последовательность шагов (кто что делает).
Визуализировать условие: «если утверждено → дальше, если нет → на доработку».
Отобразить параллельную работу: руководитель проверяет заявку, бухгалтер проверяет смету — они делают это независимо, и процесс продолжается только после того, как оба закончат.
2. Почему диаграмма деятельности (B) — идеальный выбор?
Создана для workflow — её основное назначение: моделирование потоков управления, алгоритмов, бизнес-процессов.
Ветвление реализуется через decision node (ромб) с несколькими исходящими потоками, каждый сопровождается условием-охранником (например, «[утверждено]» и «[требует доработки]»).
Параллелизм — через fork node (толстая горизонтальная черта): один вход, несколько параллельных выходов. И join node — слияние параллельных веток после завершения всех.
Дорожки (swimlanes) позволяют чётко разделить зоны ответственности: отдельная дорожка для сотрудника, для руководителя, для бухгалтера.
3. Почему не подходят другие варианты?
A (диаграмма классов) — описывает статическую структуру: классы, атрибуты, методы, связи. Процесс (динамику) она не показывает.
C (диаграмма последовательности) — хороша для временнóй последовательности обмена сообщениями между объектами. Но при ветвлениях она становится громоздкой (приходится использовать фреймы alt, par). Для бизнес-пользователей она сложна для восприятия.
D (диаграмма компонентов) — показывает модули системы и их интерфейсы (например, «модуль согласования», «модуль бухгалтерии»), но не внутреннюю логику процесса.
4. Реальный кейс из практики
В одном холдинге процесс согласования командировок длился 3 дня. Аналитик нарисовал диаграмму деятельности и увидел, что руководитель и бухгалтерия работают последовательно: сначала руководитель, потом бухгалтер. По диаграмме было очевидно, что их действия независимы, и их можно перевести в параллельный режим (fork/join). После внедрения изменений время сократилось до 1 дня без потери качества проверок.
5. Что конкретно должен сделать аналитик при использовании диаграммы деятельности:
Нарисовать пул (Pool) или дорожки для каждого участника.
Разместить действия (Activity) на дорожках.
Добавить начальный узел (Initial Node) и конечный узел (Final Node).
Для ветвления использовать decision node с двумя исходящими потоками, подписать условия.
Для параллельности — fork node (разделение) и join node (сборка).
Убедиться, что каждый альтернативный путь завершается понятным результатом (например, «заявка утверждена» или «отправлена на доработку»).
Вывод: Диаграмма деятельности — это универсальный и наглядный инструмент для описания процессов с логикой и параллелизмом. Она понятна и бизнес-заказчику, и разработчикам, и тестировщикам. Аналитик, владеющий этим инструментом, эффективно выявляет узкие места и неоднозначности в процессах. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
4777. На use case диаграмме «Оплатить услугу» включает «Аутентифицироваться» через «include», но оплата по SMS‑ссылке не требует логина. В чём ошибка?
Anonymous Quiz
6%
Нужно было использовать наследование между акторами
65%
Нужно было использовать отношение «extend» с условием, а не «include»
27%
«include» используется только для обязательных подфункций, а аутентификация необязательна
3%
Ошибки нет, всё правильно
На диаграмме вариантов использования (use case diagram) отношение include означает, что включаемый вариант использования (в данном случае «Аутентифицироваться») обязательно выполняется каждый раз, когда выполняется базовый вариант («Оплатить услугу»). Если хотя бы один способ оплаты не требует аутентификации (например, оплата по ссылке из SMS), то include применять нельзя — он создаст неверное требование, что аутентификация нужна всегда.
2. Правильное отношение — «extend»
Отношение extend используется, когда расширяющий вариант (в данном случае «Аутентифицироваться») выполняется не всегда, а только при наступлении определённого условия (extension condition). Это условие указывается в диаграмме или в спецификации. Например: «Аутентифицироваться» расширяет «Оплатить услугу» только если пользователь заходит через личный кабинет и не аутентифицирован ранее. При оплате по SMS-ссылке условие ложно, и аутентификация не вызывается.
3. Почему другие варианты неверны
A (наследование между акторами) — не решает проблему, наследование акторов (например, «Авторизованный пользователь» наследует «Гость») относится к ролям, а не к вариантам использования.
C — формулировка «include используется только для обязательных подфункций» верна по сути, но в ответе она подана как утверждение, что аутентификация необязательна. Однако причина ошибки не в том, что include так нельзя использовать, а в том, что нужно было выбрать extend.
D — ошибка есть, вариант неверен.
4. Реальный кейс из практики
В одном проекте аналитик нарисовал include для аутентификации во всех платёжных сценариях. Разработчик реализовал обязательный вход для всех способов оплаты, включая оплату по ссылке из email. Бизнес заказчик был в шоке: пользователи, переходя по ссылке, должны были вводить логин и пароль, что убивало удобство быстрой оплаты. Переделка стоила спринта. После этого в команде ввели правило: перед использованием include всегда задавать вопрос «А есть ли сценарий, где эта подфункция не нужна?». Если есть — использовать extend с условием.
5. Что должен сделать аналитик для предотвращения ошибки
Перечислить все возможные способы оплаты.
Для каждого способа определить, требуется ли аутентификация.
Если хотя бы один способ не требует аутентификации — выбрать extend.
Явно прописать условие расширения (например, «если пользователь не аутентифицирован и способ оплаты ≠ SMS-ссылка»).
Включить оба сценария (с аутентификацией и без) в критерии приёмки.
Вывод: Ошибка в выборе между include и extend — не просто «неточность в диаграмме», а прямая причина неверной реализации бизнес-логики и лишних затрат. Аналитик обязан различать эти отношения и всегда проверять обязательность подфункции. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
4778. В монолите выделили сервис уведомлений в микросервис. После этого часть уведомлений стала теряться при его недоступности. Какой паттерн нужно было применить?
Anonymous Quiz
1%
Синхронный REST с ретраями
94%
Асинхронное взаимодействие через брокер сообщений с гарантированной доставкой
3%
Общая база данных для заказов и уведомлений
2%
Использовать gRPC вместо REST
Изначально система была монолитом — всё работало в одном процессе. Уведомления отправлялись внутри того же приложения, поэтому проблем не было. Когда сервис уведомлений выделили в отдельный микросервис, разработчики, скорее всего, оставили синхронный вызов: сервис заказов отправляет HTTP‑запрос к сервису уведомлений и ждёт ответа. Если сервис уведомлений недоступен (упал, перегружен, обновляется), вызов завершается ошибкой, и уведомление теряется навсегда. Ретраи (повторы) помогают только при кратковременных сбоях, но не при длительной недоступности.
2. Почему асинхронный брокер сообщений — правильное решение?
Брокер (например, RabbitMQ, Kafka) работает как надёжная очередь, которая хранит сообщения, даже если потребитель временно не работает.
Сервис заказов создаёт событие «Заказ создан» и отправляет его в очередь. Ему не нужно ждать ответа → пользователь не испытывает задержки.
Сервис уведомлений читает из очереди и отправляет уведомления. Если он упал, сообщения остаются в очереди и не теряются.
Когда сервис восстановится, он заберёт все накопившиеся сообщения и обработает их.
Брокер может быть настроен на персистентность (сохранение на диск) и репликацию (копии на нескольких серверах), что исключает потерю данных даже при полном отключении брокера.
3. Почему не подходят другие варианты?
A (синхронный REST с ретраями) — если сервис уведомлений лежит 30 минут, ретраи будут бесполезны, а синхронный вызов всё равно заблокирует основной процесс (пользователь будет ждать).
C (общая БД) — возврат к монолиту на уровне данных: сервисы начнут писать в одну базу, возникнут конфликты, потеряется независимость микросервисов. Это антипаттерн.
D (gRPC) — это более быстрый и компактный протокол, но он остаётся синхронным. Проблема недоступности не решается.
4. Реальный пример из жизни
Один известный сервис доставки выделил уведомления в микросервис, оставив синхронные вызовы. В час пик сервис уведомлений упал на 40 минут. За это время тысячи заказов не получили SMS и пушей. Клиенты не знали, где курьер, и жаловались. После инцидента перешли на RabbitMQ: теперь даже при падении сервиса уведомлений на несколько часов все события накапливаются в очереди и доставляются после восстановления. Заказы не теряются, пользователи довольны.
5. Что аналитик должен зафиксировать в требованиях
Для всех фоновых операций (уведомления, логирование, отчёты) использовать асинхронные очереди.
Указать брокер сообщений, настройки персистентности и репликации.
Прописать политику повторных попыток и Dead Letter Queue.
Определить допустимую задержку (например, уведомление должно прийти не позже чем через 5 минут после события).
Вывод: При переходе на микросервисы критически важно пересмотреть способ коммуникации. Для операций, не требующих немедленного ответа, асинхронный брокер сообщений — это единственный способ обеспечить надёжность и не потерять данные. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
4779. Стартап запускает MVP интернет-магазина. Команда хочет сразу строить микросервисы, «чтобы было масштабируемо». Какой аргумент против этого решения самый весомый?
Anonymous Quiz
84%
Микросервисы сложнее в разработке и отладке на ранних этапах
6%
Микросервисы требуют больше серверов
6%
Микросервисы не поддерживают ACID-транзакции
4%
Микросервисы медленнее из-за сетевых вызовов
Частая ошибка — проектировать сложную распределённую систему там, где бизнес ещё не доказал свою жизнеспособность. Для MVP (минимально жизнеспособного продукта) главное — скорость выхода на рынок и возможность быстро менять логику. Микросервисы эту скорость убивают.
1. Почему A — самый весомый аргумент?
Микросервисы требуют настройки межсервисного взаимодействия (брокеры, API gateway, discovery), логирования, трассировки, управления конфигами, отказоустойчивости. Всё это — инженерная сложность, которая не нужна, пока нет 10 пользователей.
Отладка распределённой системы в разы сложнее: локально поднять 5 сервисов с их базами данных — это время. А если баг воспроизводится только при определённой последовательности вызовов между сервисами?
2. Почему другие варианты слабее?
B (больше серверов) — да, но облака позволяют арендовать дешёвые маленькие инстансы. Это не главная проблема.
C (нет ACID-транзакций) — действительно проблема, но для многих сценариев интернет-магазина eventual consistency допустима. Это не самый весомый аргумент на старте.
D (медленнее из-за сети) — сетевые вызовы добавляют задержку, но современные дата-центры и протоколы делают её не такой критичной. Опять же, не главное.
3. Реальный кейс
Один стартап потратил 6 месяцев на проектирование микросервисной архитектуры с Kafka, Kubernetes, сервис-мешем. К моменту запуска рынок уже заняли конкуренты с монолитом на Ruby on Rails, который они сделали за 2 месяца. Стартап закрылся.
Другой пример: известный сервис по доставке еды начинал с монолита и перешёл на микросервисы только когда нагрузка превысила 1000 заказов в минуту. До этого монолит отлично работал и позволял быстро экспериментировать с фичами.
4. Что должен сделать аналитик в такой ситуации?
Оценить стадию проекта: MVP — монолит, даже если «потом перепишем».
Зафиксировать нефункциональные требования: ожидаемая нагрузка в первый месяц, темп изменений.
Предложить модульный монолит: внутри одного приложения выделить пакеты/модули с чёткими границами. Это позволит в будущем легко вырезать их в микросервисы, если понадобится.
Настоять на том, что сложность архитектуры должна соответствовать сложности бизнеса. Не нужно строить космопорт, если пока продаёте хот-доги с лотка.
5. Когда микросервисы действительно нужны с самого начала?
Если разные модули имеют кардинально разные требования к масштабированию (например, видеообработка и простой блог).
Если в команде уже есть опыт и инфраструктура для микросервисов.
Если бизнес требует независимого развёртывания частей системы разными командами.
Вывод: Главный весомый аргумент против микросервисов на старте — избыточная сложность, которая замедляет разработку и увеличивает риск провала MVP. Аналитик, понимающий это, помогает команде не переусложнять архитектуру раньше времени. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
ТЫ ГОТОВ К ВИРУСНОМУ ПРОРЫВУ ?! ВКЛЮЧАЙСЯ ! ⚡️
Нейросети радикально меняют правила игры и никого не ждут. Мы даём тебе полную ПОДБОРКУ лучших ИИ инструментов для работы с практическими примерами и конкретными шагами для старта и роста ⚡️
Здесь собрана настоящая мощь ИИ 🔥 Подписывайся ⬅️ пока искусственный интеллект не решил, что ты вне игры ...
От свежих инсайтов до практичных лайфхаков по работе с ИИ - всё, что поможет создавать контент за считанные минуты:
▪️ секреты и примеры написания промптов для любого ИИ
▪️ создание ИИ-ассистента, который заменит целый отдел
▪️ техники продаж с помощью нейросетей
Хочешь узнать, как ИИ меняет мир прямо на твоих глазах ?!
📌 Добавляй ПАПКУ бесплатно и делись с друзьями * Ссылка ➡️ https://t.me/addlist/3PXSBSiaHSc2ZWRk Отписаться можно в любой момент. Остаться — тоже ✔️ . Получай лучшие ИИ инструменты уже сегодня - не жди ♨️ 👉 Забирай ПОДБОРКУ экспертных каналов прямо сейчас ! * Через 48 часов ссылка будет удалена ...
Нейросети радикально меняют правила игры и никого не ждут. Мы даём тебе полную ПОДБОРКУ лучших ИИ инструментов для работы с практическими примерами и конкретными шагами для старта и роста ⚡️
Здесь собрана настоящая мощь ИИ 🔥 Подписывайся ⬅️ пока искусственный интеллект не решил, что ты вне игры ...
От свежих инсайтов до практичных лайфхаков по работе с ИИ - всё, что поможет создавать контент за считанные минуты:
▪️ секреты и примеры написания промптов для любого ИИ
▪️ создание ИИ-ассистента, который заменит целый отдел
▪️ техники продаж с помощью нейросетей
Хочешь узнать, как ИИ меняет мир прямо на твоих глазах ?!
📌 Добавляй ПАПКУ бесплатно и делись с друзьями * Ссылка ➡️ https://t.me/addlist/3PXSBSiaHSc2ZWRk Отписаться можно в любой момент. Остаться — тоже ✔️ . Получай лучшие ИИ инструменты уже сегодня - не жди ♨️ 👉 Забирай ПОДБОРКУ экспертных каналов прямо сейчас ! * Через 48 часов ссылка будет удалена ...
🔥1
ИИ — ЭТО УЖЕ НЕ «КОГДА-НИБУДЬ ПОТОМ» ... ОН ПРЯМО СЕЙЧАС ПЕРЕПИСЫВАЕТ ПРАВИЛА ИГРЫ 🖋
Тексты, аналитика, продажи, дизайн, экономия десятков часов в неделю — это не футурология.
Это ваш обычный вторник, если вы в теме.
Вопрос больше не в том, заменит ли ИИ людей.
Вопрос в том, кто обгонит вас, пока вы раздумываете.
Хотите быть среди первых, кто использует нейросети на все сто?
Тогда вот что вам нужно ⚡️:
👉 ПОДБОРКА реально сильных и продвинутых экспертов по нейросетям, ИИ, IT & HR Tech, а также последние - AI Life hacks
Забирайте, пока другие бездумно скролят ленту новостей.
Отписаться можно в любой момент — без проблем ✔️
Ссылка на ПАПКУ ⬇️
https://t.me/addlist/3PXSBSiaHSc2ZWRk * Добавляйте себе в избранное и скидывайте ссылку коллегам.
Тексты, аналитика, продажи, дизайн, экономия десятков часов в неделю — это не футурология.
Это ваш обычный вторник, если вы в теме.
Вопрос больше не в том, заменит ли ИИ людей.
Вопрос в том, кто обгонит вас, пока вы раздумываете.
Хотите быть среди первых, кто использует нейросети на все сто?
Тогда вот что вам нужно ⚡️:
👉 ПОДБОРКА реально сильных и продвинутых экспертов по нейросетям, ИИ, IT & HR Tech, а также последние - AI Life hacks
Забирайте, пока другие бездумно скролят ленту новостей.
Отписаться можно в любой момент — без проблем ✔️
Ссылка на ПАПКУ ⬇️
https://t.me/addlist/3PXSBSiaHSc2ZWRk * Добавляйте себе в избранное и скидывайте ссылку коллегам.
👍1🔥1
4780. При бронировании билетов система не блокирует места на время оплаты — другой пользователь может их перехватить. Разработчики ссылаются на требования. Кто упустил сценарий?
Anonymous Quiz
1%
Разработчики
9%
Тестировщики
87%
Аналитик
3%
Архитектор
Требование могло звучать как: «Пользователь может забронировать место». Ни слова про то, что место должно блокироваться на время оплаты, чтобы его не перехватил другой. Разработчик реализовал только бронирование без блокировки, и это формально соответствует букве требования. Но бизнес ожидал стандартного для таких систем поведения (блокировка на 10–15 минут). Проблема — в неполноте требований, а именно — в отсутствии сценария конкурентного доступа.
Почему это зона ответственности аналитика?
Аналитик должен выявлять и описывать нефункциональные и логические требования, которые кажутся «очевидными» бизнесу, но не очевидны разработчику.
Конкурентный доступ (race condition) — классический сценарий для систем бронирования. Аналитик обязан был задать вопрос: «А что, если два пользователя попытаются забронировать одно место?».
Критерии приемки (Acceptance Criteria) должны включать примеры с одновременными действиями.
❌ Почему не другие варианты:
A (разработчики) — они реализовали требования «как есть». Без явного указания на блокировку у них нет оснований её делать.
B (тестировщики) — тестировщики проверяют соответствие требованиям. Если в требованиях нет сценария с параллельным бронированием, они могут его не проверить.
D (архитектор) — архитектор может предложить техническое решение (пессимистические блокировки), но только если есть соответствующее требование.
Как должно было быть в требованиях:
Аналитик должен добавить в критерии приемки:
При начале бронирования место блокируется для текущего пользователя на 10 минут.
Другой пользователь не может забронировать то же место, пока блокировка активна.
При успешной оплате блокировка снимается, место становится купленным.
При неоплате через 10 минут блокировка снимается, место снова доступно.
Пример тест-кейса, который должен быть в плане тестирования:
Пользователь А выбирает место и начинает бронирование.
Пользователь Б пытается выбрать то же место.
Ожидаемый результат: Б видит сообщение «Место временно заблокировано другим пользователем».
Реальный кейс
В одной авиакомпании при запуске нового сайта пассажиры жаловались, что после выбора места и ввода данных карты место вдруг становится недоступным — его успевал перехватить другой пассажир, более быстрый на оплату. Компания потеряла сотни тысяч рублей на возвратах и компенсациях. Аналитик не прописал блокировки, хотя в предыдущей системе они были. После инцидента требования дополнили, и блокировки внедрили.
Вывод: Аналитик обязан выявлять неочевидные сценарии, такие как конкурентный доступ, и явно описывать их в требованиях. «Очевидные» вещи для бизнеса не очевидны для разработчиков. Пропуск такого сценария — прямая ответственность аналитика, а не разработки или тестирования. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Если вы хотите зарабатывать в Telegram, вам нужна эта папка.
Там собраны материалы по:
— продвижению каналов
— маркетингу
— инфобизнесу
— привлечению трафика
— монетизации
Это концентрат знаний, который обычно собирают годами.
Очень часто мне пишут:
«Почему канал не растёт?»
«Где брать подписчиков?»
«Как начать зарабатывать в Telegram?»
И почти всегда проблема одна — нет системного понимания продвижения и маркетинга.
По сути, это концентрат знаний, который обычно собирается по крупицам из разных источников.
Я просто сделала удобную подборку, чтобы всё было в одном месте.
Если вы:
— ведёте канал
— развиваете личный бренд
— продаёте услуги
— или только хотите начать зарабатывать в Telegram
сохраните папку и добавьте её себе.
Переходите по ссылке https://t.me/addlist/PE0khuyk7UY0YjFi
Записывайся в подборку🫶
Там собраны материалы по:
— продвижению каналов
— маркетингу
— инфобизнесу
— привлечению трафика
— монетизации
Это концентрат знаний, который обычно собирают годами.
Очень часто мне пишут:
«Почему канал не растёт?»
«Где брать подписчиков?»
«Как начать зарабатывать в Telegram?»
И почти всегда проблема одна — нет системного понимания продвижения и маркетинга.
По сути, это концентрат знаний, который обычно собирается по крупицам из разных источников.
Я просто сделала удобную подборку, чтобы всё было в одном месте.
Если вы:
— ведёте канал
— развиваете личный бренд
— продаёте услуги
— или только хотите начать зарабатывать в Telegram
сохраните папку и добавьте её себе.
Переходите по ссылке https://t.me/addlist/PE0khuyk7UY0YjFi
Записывайся в подборку
Please open Telegram to view this post
VIEW IN TELEGRAM
4781. В таблице orders 100 млн записей. Запрос на сумму заказов за последний месяц выполняется 30 секунд. Индекс на order_date есть. Что ещё можно сделать для ускорения без изменения кода?
Anonymous Quiz
6%
Заменить индекс на хеш-индекс
52%
Создать материализованное представление с предрасчётом агрегатов
36%
Добавить партиционирование по order_id
5%
Увеличить кэш базы данных
Запрос SELECT SUM(amount) FROM orders WHERE order_date >= ... даже с индексом на order_date должен прочитать все строки за последний месяц. Если за месяц 10 млн записей, база данных выполняет полное сканирование этих 10 млн строк (пусть даже по индексу). 30 секунд — это много для отчёта, который нужен часто.
Почему индекс не спасает?
Индекс помогает быстро найти строки по условию WHERE, но агрегация (SUM) всё равно требует чтения всех отфильтрованных строк из таблицы (или из индекса, если индекс покрывающий). Если объём данных за месяц велик, время будет большим.
Правильное решение — материализованное представление (B):
Материализованное представление — это физическая таблица, которая хранит предварительно вычисленные агрегаты.
Можно создать:
```sql
CREATE MATERIALIZED VIEW monthly_sales AS
SELECT DATE_TRUNC('month', order_date) AS month, SUM(amount) AS total
FROM orders
GROUP BY month;
```
Запрос к этому представлению читает всего несколько строк (по количеству месяцев), а не миллионы. Время выполнения падает до миллисекунд.
Недостаток: данные нужно обновлять (полностью или инкрементально), но для отчёта с допустимой задержностью (например, обновлять раз в час) это отличное решение.
Почему не подходят другие варианты:
A (хеш-индекс) — полезен только для поиска по точному равенству, не для диапазонов и агрегаций.
C (партиционирование по order_id) — не имеет смысла для запроса по дате; партиционирование должно быть по дате, но даже с ним агрегация всё равно читает все партиции за месяц. Ускорение будет незначительным.
D (увеличить кэш) — кэш может помочь, если запрос выполняется часто и данные уже в памяти, но при первом выполнении или при большой выборке кэш не спасёт.
Реальный кейс:
В крупном онлайн-кинотеатре отчёт «выручка по месяцам» на таблице с миллиардами просмотров выполнялся 2 минуты. Создали материализованное представление, обновляющееся раз в сутки. Время отклика упало до 0.05 секунды. Маркетологи стали работать в 10 раз быстрее.
Что должен зафиксировать аналитик:
Определить, какие агрегатные отчёты критичны по времени.
Для каждого такого отчёта рассмотреть вариант материализованного представления или витрины данных.
Согласовать допустимую задержку обновления (real-time / near real-time / ежедневно).
В требованиях указать необходимость создания и обслуживания таких объектов.
Вывод: Материализованные представления — это стандартный способ ускорить тяжёлые агрегатные запросы на больших таблицах, когда допустима небольшая задержка актуальности данных. Аналитик, знающий этот механизм, может спасти производительность без сложных архитектурных изменений. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
4782. Запрос SELECT * FROM orders WHERE status = 'NEW' выполняется 10 секунд, хотя в таблице всего 10 млн строк и статус «NEW» имеют 50% записей. Индекс на status есть, но запрос всё равно медленный. В чём причина?
Anonymous Quiz
3%
Индекс повреждён, нужно перестроить
81%
Оптимизатор выбрал полное сканирование таблицы, так как селективность низкая (50%)
15%
Нужно добавить хеш-индекс
1%
Проблема в кэше базы данных