4773. При росте до миллиона пользователей видеочата: медиасерверы перегружены, БД не выдерживает записей комнат. Какое архитектурное решение масштабирует систему?
Anonymous Quiz
2%
Увеличить мощность одного сервера (вертикальное масштабирование)
95%
Горизонтальное масштабирование с шардированием комнат по географическому признаку и WebRTC SFU
0%
Переписать всё на одном сервере на Go
4%
Хранить все комнаты в Redis без репликации
Рано или поздно упираемся в физические пределы (память, CPU, сеть). К тому же медиасерверы (WebRTC) требуют низкой задержки — один сервер физически не обработает миллион пользователей.
Почему B — правильное решение?
Горизонтальное масштабирование (добавление серверов) — каждую комнату можно отдать на отдельный сервер или группу серверов.
Шардирование по географическому признаку — пользователи из России идут на сервер в Москве, из Европы — во Франкфурт, что снижает задержку (latency).
WebRTC Selective Forwarding Unit (SFU) — сервер, который ретранслирует потоки между участниками, оптимизируя трафик. SFU могут быть объединены в кластер.
Пример схемы:
Балансировщик (например, HAProxy) по геолокации направляет запрос на создание комнаты на ближайший SFU-кластер.
База данных комнат шардирована по room_id или географическому региону.
При выходе из строя одного SFU, участники переподключаются к другому в том же регионе (failover).
❌ Почему не C (один сервер на Go)?
Не поможет, проблема в распределении нагрузки, не в языке.
❌ Почему не D (только Redis без репликации)?
Redis не подходит как первичное хранилище для метаданных комнат (нет персистентности, сложно масштабировать запись). Можно использовать Redis как кэш, но нужна основная БД с репликами.
Реальный кейс:
Zoom использует географически распределённые кластеры медиасерверов. При создании комнаты она назначается на ближайший дата-центр, внутри дата-центра — на конкретный сервер. Балансировка и шардирование позволили масштабироваться до сотен миллионов участников.
Что должен заложить аналитик:
Требование к географической маршрутизации (например, «время ответа не более 100 мс для 95% пользователей»).
Отказоустойчивость кластера — при падении одного сервера комнаты перераспределяются.
Мониторинг загрузки медиасерверов и автоматическое добавление новых узлов.
Шардирование БД по room_id или по региону.
Вывод: Проектирование масштабируемой системы видеоконференций — это не про «взять сервер побольше», а про распределённую архитектуру с географическими шардами и специализированными медиасерверами. Аналитик, понимающий эти принципы, закладывает в требования горизонтальное масштабирование и географическую маршрутизацию. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
4774. Заказчик просил автоматически находить аномалии и сообщать о них. Аналитик записал общее требование. На приёмке система находила не те аномалии и уведомляла слишком часто. Что упустил аналитик?
Anonymous Quiz
0%
Согласование с разработчиками
99%
Конкретизацию термина «аномалия» и правил уведомления (бизнес-правила, пороги, примеры)
1%
Требования к производительности
1%
Прототип интерфейса уведомлений
Согласно исследованию Atlassian за апрель, команды, использующие автоматизацию отчётности в Jira, экономят до 15 часов в неделю на административных задачах. Это не просто цифры — это время, которое можно направить на стратегические задачи.
Чтобы помочь вам внедрить подобные улучшения, мы собрали папку в сфере ИТ и управления проектами:
• методики планирования и контроль сроков с учётом автоматизации
• обзоры платформ для командной работы и аналитики
• разбор типовых ошибок и способов их избежать
• реальные кейсы внедрения ИТ‑решений.
Структурированные знания — ваш конкурентный актив.
Сохранить папку себе 📨
❤2
С
Что должен был сделать аналитик:
Задать уточняющие вопросы:
«Что именно вы считаете аномалией? Приведите 3–5 конкретных примеров».
«Как часто нужно проверять? Раз в час, раз в день?»
«Как уведомлять? Email, SMS, телеграм, дашборд?»
«Кто получатель уведомлений?»
Перевести ответы в проверяемые критерии:
Аномалия = разница между фактическими продажами за последний час и средними за тот же час за последние 7 дней превышает 20%.
Проверка каждый час.
Уведомление в телеграм-бота менеджера по продажам.
Задокументировать примеры:
Пример аномалии: продажи упали с 100 до 70 (на 30%) → уведомление.
Пример не-аномалии: продажи упали с 100 до 92 (на 8%) → уведомления нет.
Реальный кейс:
В финтех-стартапе заказчик просил «автоматически находить подозрительные транзакции». Аналитик написал общее требование. Разработчик реализовал детектор по сумме > 1 млн рублей. На проде выяснилось, что подозрительными считаются мелкие транзакции в необычное время. Переделка стоила 2 недели. После внедрения чек-листа с вопросами к заказчику подобное не повторялось.
Вывод: Любое субъективное понятие должно быть разложено на измеримые бизнес-правила, пороги и примеры. Иначе система будет делать «не то», а вы будете переделывать. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2👍1
Привет, собрали с коллегами новую папку каналов
Тут и программирование — Python, библиотеки, подготовка к собеседованиям IT-сферы
И новости AI — тренды, апдейты, новые инструменты
И нейросети в бизнесе — автоматизация, идеи заработка для разных сфер
Подписаться тут
Please open Telegram to view this post
VIEW IN TELEGRAM
🔖 Экспертные материалы от специалистов по ИИ — без воды, только суть и рабочие инструменты🔖 Актуальные изменения в мире ИИ, новости — чтобы быть в курсе🔖 Аналитика, кейсы и разборы ситуаций — всё, что помогает глубже понимать рынок Искусственного Интеллекта и принимать грамотные решения🤩 Егор Никитин | Event | Нейросети - Нейросети в event сфере, практика использования ИИ. Отделение «ИИ для бизнеса» РЭУ им. Плеханова.📲 Мы в MAX
В ПАПКЕ ЕЩЕ БОЛЬШЕ УНИКАЛЬНЫХ КАНАЛОВ:📌 Знатоки Рынка📌 Новые Предложения📌 Новые ИИ инструменты
Организаторы:
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
4775. В требовании «уведомлять при изменении статуса заказа» разработчик сделал уведомление только для «Доставлен», а бизнес ждал для всех статусов. Какой артефакт требований предотвратил бы это?
Anonymous Quiz
6%
Use Case Diagram
79%
Матрица отслеживания требований (RTM) или явный список статусов в критериях приемки
1%
ER-диаграмма
14%
Диаграмма последовательности
🤔1
Фраза «изменение статуса» — это неоднозначность. Разработчик интерпретировал её как «любое изменение»? Нет, он решил, что достаточно одного ключевого изменения — финального статуса «Доставлен». Бизнес же подразумевал все статусы: «Принят», «Оплачен», «Передан в доставку», «Доставлен». Без явного перечисления каждый понимает по-своему.
Что такое матрица отслеживания требований (RTM) и критерии приемки?
RTM (Requirements Traceability Matrix) — таблица, которая связывает каждое требование с конкретными проверяемыми пунктами, тест-кейсами и реализацией.
Критерии приемки (Acceptance Criteria) — это список условий, которые должны быть выполнены, чтобы пользовательская история считалась готовой. Они пишутся на понятном бизнесу языке и часто в формате Given-When-Then.
Как должен был выглядеть правильный артефакт?
Пример критериев приемки (Gherkin):
```gherkin
Feature: Уведомление об изменении статуса заказа
Scenario Outline: Отправка уведомления при переходе в конкретный статус
Given заказ находится в статусе "<начальный_статус>"
When статус заказа меняется на "<конечный_статус>"
Then клиенту отправляется push-уведомление
And текст уведомления содержит "<текст>"
Examples:
| начальный_статус | конечный_статус | текст |
| Черновик | Принят | Ваш заказ принят |
| Принят | Оплачен | Заказ оплачен, спасибо |
| Оплачен | Передан в доставку | Заказ передан курьеру |
| Передан в доставку | Доставлен | Заказ доставлен, приятного аппетита! |
| * | Отменён | (уведомление не отправляется) |
```
Что даёт такой список?
Разработчик точно знает, на какие статусы реагировать.
Тестировщик может проверить каждый переход.
Бизнес видит полную картину и может скорректировать до начала разработки.
Никаких «сюрпризов» на приёмке.
Почему не подходят другие варианты?
A (Use Case Diagram) — показывает только общие сценарии (акторы, цели), но не детализирует статусы.
C (ER-диаграмма) — описывает структуру данных (таблицы, связи), а не бизнес-правила.
D (Диаграмма последовательности) — показывает обмен сообщениями между объектами, но тоже не перечисляет статусы.
Реальный кейс из практики
В одной логистической компании заказчик потребовал уведомления «на каждом этапе движения посылки». Аналитик не уточнил этапы. Разработчик сделал уведомления только при смене города (3 этапа). Бизнес же хотел 12 этапов (прибытие на сортировку, убытие, прибытие в регион и т.д.). Переделка стоила двух спринтов. После внедрения практики «явный список в критериях приемки» подобное прекратилось.
Что должен сделать аналитик, чтобы предотвратить проблему?
Перечислить все возможные статусы (взять из модели данных или из общения с бизнесом).
Для каждого статуса указать, нужно ли уведомление (да/нет) и какой текст.
Оформить это в виде таблицы или сценариев Gherkin.
Согласовать таблицу с заказчиком до передачи в разработку.
Включить эти сценарии в тест-план и критерии приемки.
Вывод: Избегайте общих фраз. Любое требование, которое содержит слова «изменение», «различные», «некоторые», «в зависимости от ситуации» без конкретики — это мина замедленного действия. Явный список значений или таблица — дешёвый способ спасти команду от переделок. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
4776. В процессе согласования командировки участвуют сотрудник, руководитель и бухгалтерия. Нужно показать альтернативные потоки (утверждено / доработка) и параллельные действия. Какая диаграмма UML подойдёт?
Anonymous Quiz
1%
Диаграмма классов
69%
Диаграмма деятельности (Activity Diagram)
30%
Диаграмма последовательности
1%
Диаграмма компонентов
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