¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
BA & SA | 10000 Interview questions
Ir al canal en Telegram
Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7
Mostrar más📈 Análisis del canal de Telegram BA & SA | 10000 Interview questions
El canal BA & SA | 10000 Interview questions (@systemanalystinterview) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 10 219 suscriptores, ocupando la posición 3 869 en la categoría Carrera profesional y el puesto 64 071 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 10 219 suscriptores.
Según los últimos datos del 18 junio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de 334, y en las últimas 24 horas de -4, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 3.25%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 2.45% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 332 visualizaciones. En el primer día suele acumular 250 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 2.
- Intereses temáticos: El contenido se centra en temas clave como объяснение, индекс, user_id, субд, паттерн.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 19 junio, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Carrera profesional.
10 219
Suscriptores
-424 horas
+237 días
+33430 días
Archivo de publicaciones
Магистратура для карьеры в IT: практика и портфолио
Магистратура, которая готовит к реальной работе!
В нашем Telegram-канале вы узнаете о программах ИТМО и МИФИ в партнерстве с Яндекс Практикумом.
Здесь вы получите не теорию, а практические навыки, решая бизнес-кейсы. К выпуску — 10+ проектов в портфолио и карьерная поддержка: помощь с резюме и подготовка к собеседованиям. Формат 100% онлайн позволяет учиться из любого города, совмещая с работой.
Подписывайтесь, чтобы узнать актуальные новости о приеме на 2026 год. Превратите обучение в старт карьеры мечты!
Подписаться
#реклама 16+
О рекламодателе
☀Объяснение:
Проблема
Когда сервис В недоступен, множество экземпляров сервиса А одновременно начинают повторные попытки с фиксированным интервалом. Это создаёт синхронизированные всплески нагрузки, которые мешают восстановлению. Это называется retry storm (шторм повторных вызовов).
Решение
Экспоненциальная задержка (exponential backoff) — интервал между ретраями удваивается (1, 2, 4, 8 секунд). Это раздвигает по времени пики нагрузки.
Джиттер (jitter) — случайное небольшое смещение, чтобы разные экземпляры не синхронизировались.
Ограничение числа ретраев (например, 5 попыток).
Circuit Breaker — после определённого числа ошибок быстрый сброс без вызова вообще.
Почему не другие варианты
A — deadlock относится к блокировкам в БД.
C — race condition — состояние гонки, не то.
D — thundering herd — асинхронная проблема, но решение с очередями не прямое.
Реальный случай
В Amazon одна из внутренних систем легла из-за retry storm. После внедрения экспоненциального бэккотта и джиттера инциденты прекратились.
Требования аналитика
Политика ретраев: начальная задержка 1 сек, максимум 10 сек, коэффициент 2, джиттер 0-30%.
4822. Сервис А, получив ошибку, начал повторять запросы каждую секунду, создавая лавину нагрузки на сервис В, которая не давала ему восстановиться. Как называется этот эффект и как его предотвратить?
☀Объяснение:
Проблема
Нереалистичные нефункциональные требования (NFR) — частая ошибка стартапов. Заказчик может назвать цифру «10 000» без обоснования, потому что «конкуренты так могут» или «на всякий случай».
Что должен сделать аналитик
Уточнить источник цифры: откуда ожидается такой рост, есть ли маркетинговые прогнозы или это просто желание.
Предложить компромисс: сделать архитектуру, которая позволит горизонтально масштабироваться, но не строить инфраструктуру на полную мощность сейчас (например, использовать облачные сервисы с автосейлингом).
Задокументировать риск: «При резком росте нагрузки без дополнительных инвестиций система может не выдержать. Требуется повторная оценка через 6 месяцев».
Почему не другие варианты
A — согласиться без анализа — приведёт к перерасходу бюджета или невыполнимому обязательству.
C — отказ от проекта без попытки обсуждения — не гибко.
D — игнорирование — безответственно.
Реальный кейс
Один стартап по доставке еды требовал 5000 RPS с первого дня. Аналитик предложил использовать масштабируемый облачный кластер, но с минимальной конфигурацией. После запуска пик оказался 50 RPS. Экономия составила 80% бюджета.
Аналитика портфеля другого брокера в «Финам AI-скринер»
⚡ С помощью «Финам AI-скринер» теперь можно бесплатно проанализировать портфели, открытые у стороннего брокера.
✅ В сервисе доступно:
— более 15 видов умных сигналов для акций и облигаций
— прогнозы по 3 сценариям роста и расчёт дивидендов
— оценка рисков и доходности — узнайте, где потенциал, а где подводные камни
Это просто и безопасно: подключение за 1 минуту по «API-токену» для чтения.
📊 Тестируйте виртуальные портфели, находите лучшие инвестиционные возможности и принимайте решения на основе ИИ.
Попробовать новый сервис можно уже сейчас — не теряйте время, находите точки роста!
Попробовать
Финансовые услуги оказывает: АО «Инвестиционная компания «ФИНАМ».
#реклама 16+
broker.finam.ru
О рекламодателе
4821. Вы аналитик в стартапе. Заказчик требует, чтобы система обрабатывала 10 000 заказов в секунду, хотя текущий пик — 10 заказов в секунду. Разработка такого уровня масштабирования обойдётся в утроение бюджета. Ваши действия?
☀Объяснение:
Требования
Врач (роль) — доступ к картам пациентов, но только своего отделения (контекст — отделение).
Администратор — все карты (вышестоящая роль).
Лаборант — доступ только к типу данных «анализы» (контекст — тип данных).
Почему RBAC с контекстными ограничениями
Ролевая модель (RBAC) назначает разрешения ролям, а не пользователям. Врачи, лаборанты, админы — это роли. Добавляются ограничения:
У врача: условие
patient.department == user.department.
У лаборанта: условие data_type == 'lab_results'.
У администратора: нет условий.
Почему не другие
DAC — владелец данных решает, кому дать доступ. Не подходит для медорганизации.
MAC — жёсткая классификация (секретно/несекретно), не подходит для бизнес-правил.
Только ACL — глобальные списки доступа для каждого объекта, трудоёмко.
Реальный пример
Electronic Health Record (EHR) системы используют RBAC с атрибутами (отделение, специализация). Лаборанты видят анализы, но не диагнозы (диагнозы только у врачей).
Что должен зафиксировать аналитик
Роли и права.
Контекстные ограничения (фильтры).
Иерархию ролей (старшая роль включает младшие).VOYAH PASSION EVR –
полноприводный гибридный седан для бизнеса и путешествий.
Адаптивная пневмоподвеска, превосходный дизайн, изящный и стремительный облик.
Комфорт класса люкс, захватывающая динамика – 5,9 секунды до 100 км/ч – и бескомпромиссные цифровые решения!
Выбирайте гибридный седан VOYAH СТРАСТЬ/PASSION – от 4 190 000₽ в наличии – с Господдержкой и выгодой по трейд-ин.
Узнать больше
#реклама
voyah.su
О рекламодателе
4820. Врач в медицинской системе должен иметь доступ к картам пациентов только своего отделения. Администратор больницы — ко всем. Лаборант — только к результатам анализов, но не к диагнозам. Какая модель разграничения доступа наиболее подходит?
☀Объяснение:
Проблема
Наивное описание синхронными сообщениями (сплошная стрелка с заполненным концом) подразумевает, что вызывающий объект ждёт ответа. Для внешнего платёжного шлюза типично: вы отправляете запрос, затем получаете асинхронный ответ через некоторое время (callback, webhook). Изображать это как синхронный вызов неправильно.
Как правильно
Асинхронное сообщение — открытая стрелка (линия со стрелкой на конце, но без заливки). Оно означает, что управление не блокируется.
Получение callback — изображается как входящее асинхронное сообщение от банка к контроллеру, часто с пометкой «callback» или «webhook».
Можно также использовать фрагмент
async или показать запуск отдельного потока (активационная полоска).
Почему это важно
Асинхронное взаимодействие даёт другую последовательность: клиент получит подтверждение не сразу, а позже. На диаграмме это влияет на временные рамки.
Реальный пример
В интеграции с PayPal: ваш сервер отправляет запрос и продолжает работу. Через несколько секунд PayPal присылает уведомление на ваш endpoint. На диаграмме последовательности это показывается как два асинхронных сообщения (туда и обратно), возможно, с фреймом par для параллельных действий.
Вывод
Аналитик, рисуя диаграмму последовательности, должен различать синхронные и асинхронные вызовы. Это влияет на проектирование таймаутов, ретраев и обработки callback.4819. Вы описали диаграмму последовательности для сценария «Оплата заказа». В ней участвуют объекты: Клиент, Контроллер, СервисПлатежей, Банк. На самом деле Банк — внешняя система, отвечающая асинхронно через callback. Как это правильно изобразить?
Сократите затраты на автоматизацию с BIXANIT
Автоматизация систем освещения, вентиляции, кондиционирования, отопления.
Узнать больше
#реклама 16+
bixanit.com
О рекламодателе
☀Объяснение:
Суть задачи
Нужно выбрать один из двух взаимоисключающих путей в зависимости от суммы заявки: либо подпись финдиректора, либо подпись руководителя отдела. Два пути никогда не выполняются одновременно.
Что такое XOR-шлюз
Исключающий шлюз (XOR) имеет один вход и несколько выходов (или наоборот, несколько входов и один выход при слиянии). При ветвлении он активирует ровно один путь, проверяя условия-охранники (например,
[сумма > 1 млн] и [сумма <= 1 млн]). При слиянии он пропускает поток дальше, когда завершится любой из входящих путей (но в данном случае слияние не требуется).
Как моделировать
Шаг 1: после создания заявки — XOR-шлюз с двумя исходящими потоками:
Условие 1: сумма > 1 млн → задача «Подпись финдиректора».
Условие 2: сумма ≤ 1 млн → задача «Подпись руководителя отдела».
Затем оба потока сходятся в общую точку (например, в задачу «Передать в бухгалтерию»).
Почему не другие шлюзы
AND — запустил бы оба пути одновременно (подпись и финдиректора, и руководителя) и потребовал бы завершения обоих, что неверно.
OR — мог бы активировать один или оба пути, тоже не подходит.
Событие-таймер — ждёт наступления времени, не имеет отношения к условиям.
Реальный пример
В ERP-системе закупки до определённой суммы утверждает начальник отдела, выше — финансовый контролёр. XOR-шлюз идеально отображает это правило.
Вывод
XOR применяется для ветвления «или-или» на основе бизнес-данных. Аналитик должен правильно выбрать тип шлюза в зависимости от логики.4818. В процесс согласования заявки на закупку добавлен этап «Если сумма > 1 млн, требуется подпись финансового директора, иначе — только руководителя отдела». Какой элемент BPMN нужен?
