¡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 229 suscriptores, ocupando la posición 3 867 en la categoría Carrera profesional y el puesto 63 919 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 229 suscriptores.
Según los últimos datos del 23 junio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de 325, 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.56%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 2.54% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 363 visualizaciones. En el primer día suele acumular 259 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 24 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 229
Suscriptores
-424 horas
-57 días
+32530 días
Archivo de publicaciones
4618. Какой подход позволяет системам обмениваться данными напрямую, без промежуточных компонентов?
👩🏫Объяснение:
Dead Letter Queue (DLQ, очередь «мертвых писем») — это специальная очередь в системах обмена сообщениями для сообщений, которые не удалось обработать.
Как это работает — пошагово:
Сообщение поступает в основную очередь
Потребитель пытается его обработать → возникает ошибка
Повторные попытки (Retry): Система делает несколько попыток (например, 3-5 раз)
Если все попытки провалились → сообщение перемещается в DLQ
Инженеры анализируют сообщения в DLQ, находят причину ошибки
После исправления сообщения можно вернуть в основную очередь
Причины попадания в DLQ:
Неверный формат данных в сообщении
Ошибка валидации (например, отсутствует обязательное поле)
Временная недоступность зависимого сервиса
Баг в коде потребителя
Пример из жизни:
Представьте почтовое отделение. Если письмо нельзя доставить (неверный адрес, получатель умер), его не выбрасывают, а кладут в специальную папку «неврученная почта» для дальнейшего разбора.
Почему это важно:
Предотвращает зацикливание: «Отравленные» сообщения не блокируют очередь
Упрощает отладку: Все проблемные сообщения в одном месте
Позволяет восстановление: После исправления ошибки данные не теряются
👩🏫Объяснение:
gRPC (Google Remote Procedure Call) — это современный высокопроизводительный фреймворк для удаленного вызова процедур, разработанный Google.
Ключевые особенности:
Protocol Buffers (protobuf):
Бинарный формат (в отличие от текстового JSON/XML)
Занимает меньше места, быстрее сериализуется/десериализуется
Строгая типизация через .proto файлы
Пример определения:
protobuf
message User {
int32 id = 1;
string name = 2;
string email = 3;
}
HTTP/2:
Мультиплексирование (несколько запросов в одном соединении)
Сжатие заголовков
Server push (сервер может отправлять данные без запроса)
Типы взаимодействия:
Унарный (один запрос — один ответ)
Стриминг (потоковая передача в обе стороны)
Клиентский или серверный стриминг
Где применяется:
Внутренняя коммуникация микросервисов
Системы реального времени (чат, уведомления)
Когда важны производительность и низкая задержка
👩🏫Объяснение:
Change Data Capture (CDC) — это современный, эффективный паттерн интеграции, который кардинально меняет подход к синхронизации данных между системами.
Как работает (упрощенно):
1. Каждая серьезная СУБД (PostgreSQL, MySQL, Oracle) ведет журнал транзакций (Write-Ahead Log, WAL; binlog). Это низкоуровневая последовательность всех операций изменения данных (INSERT, UPDATE, DELETE), записанная перед их фактическим применением к таблицам. Цель СУБД — обеспечение согласованности и восстановление после сбоев.
2. CDC-агент (например, Debezium) подключается к СУБД не как обычное приложение, а читает этот журнал транзакций.
3. Агент превращает низкоуровневые записи журнала в удобные, структурированные события (например, { "op": "c", "after": { "id": 123, "name": "New Product" } }).
4. Эти события публикуются в шину событий (чаще всего Apache Kafka).
Практическое применение для системного аналитика:
1. Актуализация кэшей и поисковых индексов: При изменении товара в основной БД, событие через CDC мгновенно отправляется в Elasticsearch для обновления поискового индекса.
2. Построение агрегированных витрин данных: События из операционной БД стримятся в систему аналитики (например, ClickHouse) для построения актуальных отчетов.
3. Микросервисная синхронизация: Сервис «Заказы» и сервис «Доставка» имеют свои БД. При создании заказа, событие через CDC уведомляет сервис «Доставка», что нужно планировать доставку. Это альтернатива прямому вызову API.
4. Аудитинг и compliance: Полный поток всех изменений данных можно сохранять для целей аудита.
Роль аналитика: При проектировании систем, где критична актуальность данных или требуется реагирование на изменения, предлагать рассмотреть CDC как более эффективную и надежную альтернативу традиционному опросу (polling) по расписанию.
4617. Какой подход к интеграции описывает паттерн Change Data Capture (CDC)?
Привет, друзья! Собрали для вас полезные каналы по ИИ, нейросетям и IT
В папке ты найдёшь:
• ИИ и нейросети — как применять в работе и бизнесе, кейсы, ошибки • ChatGPT, Midjourney, Claude и другие инструменты — гайды, промпты, обновления • Автоматизация и no-code — боты, сервисы, оптимизация процессов • Программирование и IT — практические советы, разборы, тренды • ИИ для контента и маркетинга — тексты, дизайн, видео, рост продуктивностиПодойдёт, если ты: — работаешь в IT или только входишь в сферу — используешь нейросети для работы или бизнеса — хочешь автоматизировать рутину и зарабатывать больше — следишь за технологиями и трендами ➕ https://t.me/addlist/BYPqfhbxQONjYmJi ✈️ Сохраняй папку по ссылке выше — доступ открыт 48 часов
👩🏫Объяснение:
Backpressure (Обратное давление) — это механизм устойчивости и саморегулирования в системах, работающих с потоками данных. Его можно сравнить с предохранительным клапаном в водопроводе, который не дает трубе разорваться при слишком высоком давлении.
Классическая проблема без Backpressure:
1. Продюсер (Producer) генерирует сообщения с высокой скоростью (например, 10 000 в секунду).
2. Консьюмер (Consumer) может стабильно обрабатывать только 1 000 сообщений в секунду.
3. Сообщения начинают накапливаться в очереди (буфере).
4. Очередь переполняется → потребляется вся доступная память → процесс консьюмера (или брокера) падает с OutOfMemoryError. Система ломается.
Как работает Backpressure?
Это сигнальная обратная связь от получателя к отправителю. Консьюмер явно или неявно сообщает: «Стоп! Я перегружен, присылай данные медленнее или подожди».
Реализации в разных технологиях:
* На уровне TCP: Протокол TCP имеет встроенный механизм контроля перегрузки (congestion control) — получатель указывает размер своего приемного буфера (window size).
* Reactive Streams (RxJava, Project Reactor): Это стандартизированная модель, где Subscriber запрашивает у Publisher N элементов, и только после их обработки запрашивает следующую порцию (request(N)).
* Apache Kafka: Консьюмеры сами управляют offset'ами. Если консьюмер отстает, он просто не перемещает offset дальше, и сообщения остаются в партиции. Продюсер же может регулировать отправку на основе мониторинга отставания (lag) консьюмеров.
* HTTP/2 и gRPC: Поддерживают механизмы управления потоком (flow control).
Почему это важно для аналитика?
При проектировании высоконагруженных интеграций необходимо понимать не только happy path, но и поведение системы под нагрузкой. Нужно задавать вопросы:
* Что произойдет, если источник данных начнет генерировать информацию в 100 раз быстрее, чем обычно?
* Есть ли в нашей архитектуре механизмы, которые не дадут системе-приемнику «утонуть» в таком потоке?
* Как система сообщит о перегрузке? (Через метрики? Через падение? Через замедление?)
Без Backpressure система либо теряет данные (если очередь ограничена), либо падает. С Backpressure она устойчиво снижает производительность, но продолжает работать, давая время на масштабирование или устранение проблемы.
4616. С каким сценарием помогает справиться механизм «Обратного давления»?
👩🏫Объяснение:
В монолитной системе с одной базой данных согласованность обеспечивается ACID-транзакциями (Atomicity, Consistency, Isolation, Durability). Вы можете обновить 5 таблиц в одной транзакции, и либо все изменения применятся, либо ни одно.
В микросервисной архитектуре это невозможно:
* У каждого сервиса своя база данных.
* Невозможно использовать распределенные 2PC (Two-Phase Commit) транзакции из-за проблем с производительностью, блокировками и доступностью.
* Бизнес-транзакция (например, «Оформить заказ») затрагивает несколько сервисов: Заказы, Платежи, Склад, Доставка.
Как же обеспечить, чтобы либо все сервисы выполнили свою часть, либо ни один? Здесь на помощь приходит Saga.
Суть паттерна Saga:
Saga разбивает единую ACID-транзакцию на последовательность локальных транзакций, каждая в своем сервисе. Каждая локальная транзакция публикует событие, которое запускает следующую локальную транзакцию в другом сервисе.
Ключевой элемент Saga — Компенсирующие транзакции (Compensating Transactions):
Если на каком-то шаге Saga происходит ошибка, система должна «откатиться». Но просто «удалить заказ» в базе сервиса Заказов — недостаточно. Нужно выполнить логически обратные действия:
* Не delete order, а set order status = CANCELLED.
* Не delete payment, а initiate refund (запустить процесс возврата денег).
* Не delete reservation, а release stock (вернуть товар на склад).
Типы реализации Saga:
1. Оркестрация (Orchestration): Есть центральный оркестратор (отдельный сервис), который командует, что делать каждому сервису и в каком порядке. Он знает всю логику Saga и управляет компенсациями.
2. Хореография (Choreography): Сервисы общаются друг с другом через события, без центрального дирижера. Каждый сервис знает, на какие события ему реагировать и какие события публиковать после этого. Компенсация также запускается событиями.
Пример Saga «Оформление заказа» (Хореография):
1. Order Service: Создает заказ в статусе PENDING, публикует OrderCreated.
2. Payment Service (подписан на OrderCreated): Списывает деньги, публикует PaymentCompleted.
3. Warehouse Service (подписан на PaymentCompleted): Резервирует товар, публикует StockReserved.
4. Order Service (подписан на StockReserved): Меняет статус заказа на CONFIRMED. Saga завершена успешно.
Сценарий ошибки (откат):
Если Warehouse Service не может зарезервировать товар (нет на складе), он публикует StockReservationFailed.
* Payment Service (подписан на StockReservationFailed): Запускает возврат денег (компенсирующая транзакция), публикует PaymentRefunded.
* Order Service (подписан на PaymentRefunded или StockReservationFailed): Меняет статус заказа на CANCELLED.
Роль системного аналитика: При проектировании сквозных бизнес-процессов в микросервисной архитектуре необходимо явно моделировать Saga. Нужно:
1. Определить границы и шаги бизнес-транзакции.
2. Спроектировать события, которые будут связывать шаги.
3. Самый важный этап: Для каждого шага определить и описать компенсирующую транзакцию. Что делать, если следующий шаг не удался? Отмена, возврат, уведомление?
4. Выбрать подходящий тип реализации (оркестрация или хореография).
Это сложный, но абсолютно необходимый паттерн для поддержания целостности данных в современных распределенных системах.
4615. Паттерн «Сага» используется для решения проблемы...
👩🏫Объяснение:
Dead Letter Queue (DLQ) — это не просто «мусорная корзина», а важнейший инструмент обеспечения надежности и наблюдаемости в асинхронных системах.
Как работает типичный сценарий с DLQ:
1. Получение сообщения: Сервис-получатель (консьюмер) берет сообщение из основной очереди.
2. Ошибка обработки: Сообщение не может быть обработано. Причины:
* Ошибка в данных: Неверный формат, отсутствует обязательное поле, ссылка на несуществующую сущность (например, order_id=999999).
* Ошибка в бизнес-логике: Нарушение инварианта (например, попытка отгрузить товар с отрицательным остатком).
* Внешняя недоступность: Сервис-получатель зависит от другой системы (БД, API), которая временно недоступна.
3. Повторные попытки (Retry): Консьюмер не удаляет сообщение сразу. Он помечает его как необработанное и возвращает в очередь (или откладывает). Сообщение будет предпринято несколько попыток (например, 3 или 5) с интервалом.
4. Помещение в DLQ: Если после всех попыток сообщение все еще не может быть обработано, брокер (например, RabbitMQ, AWS SQS) автоматически перемещает его в специальную очередь — Dead Letter Queue.
Зачем это нужно? Без DLQ было бы так:
* «Отравленное» сообщение вечно циркулировало бы в основной очереди, постоянно вызывая ошибки и загружая логи.
* Оно могло бы блокировать обработку других, корректных сообщений, стоящих за ним в очереди (в FIFO-очередях).
* Невозможно было бы выявить систематическую ошибку в данных или коде без ручного поиска в логах.
Практическое применение DLQ:
1. Изоляция проблемы: Основная очередь очищается от битого сообщения и продолжает нормально работать.
2. Аварийное оповещение: Факт попадания сообщения в DLQ — это триггер для отправки алерта команде разработки или поддержки (CRITICAL: Сообщения падают в DLQ!).
3. Анализ и отладка: Инженер может вручную взять сообщение из DLQ, изучить его содержимое, понять причину сбоя (валидация, баг, проблема во внешней системе).
4. Восстановление (Replay): После того как причина устранена (баг исправлен, данные подправлены), сообщения из DLQ можно вернуть в основную очередь для повторной, уже успешной, обработки.
Роль системного аналитика: При проектировании интеграций через очереди требовать настройки DLQ и прописывать в требованиях процесс реагирования на попадание туда сообщений (мониторинг, алертинг, процедуры анализа).
4614. Для чего в асинхронной интеграции используется очередь «мертвых писем»?
👩🏫Объяснение:
Point-to-Point (P2P) — это наивный подход к интеграции, при котором каждая система взаимодействует с другой напрямую, по собственному, уникальному для каждой пары протоколу и формату данных.
Почему это становится проблемой?
Формула количества потенциальных связей для N систем: N * (N-1) / 2. Для 5 систем это 10 связей, для 10 систем — уже 45, для 20 — 190 связей. Каждая связь — это:
* Отдельный коннектор/адаптер.
* Свой формат сообщений (XML, JSON, CSV, фиксированная длина).
* Свой протокол (HTTP, FTP, JDBC, сокеты).
* Своя логика обработки ошибок и повторных попыток.
Конкретные последствия для бизнеса и разработки:
1. Неподдерживаемость: Чтобы изменить формат данных в одной системе, нужно найти и обновить все системы, которые с ней взаимодействуют. Это долго, дорого и чревато ошибками.
2. Отсутствие контроля и видимости: Нет единой точки, через которую проходят все данные. Невозможно централизованно применять политики безопасности, логировать все сообщения, отслеживать производительность интеграций или внедрить сквозную трассировку транзакций.
3. Сложность тестирования: Чтобы протестировать изменение в одной системе, нужно поднимать и настраивать все системы, от которых она зависит и которые от неё зависят.
4. Риск возникновения «тихой» поломки: Система A изменила поле в сообщении для системы B. Система C, которая тоже читает это сообщение (но об этом забыли), ломается, потому что не ожидает нового формата.
Альтернативы, которые должен знать аналитик:
* Интеграционная шина (ESB): Централизованный посредник, который берет на себя трансформацию и маршрутизацию данных.
* Шина событий (Event Bus): Системы публикуют события в общую шину, а подписчики получают их, не зная об отправителе (слабая связанность).
* API Gateway: Унифицированный вход для внешних клиентов.
Роль аналитика: Выявлять подобные хаотичные связи на ранних этапах анализа существующей архитектуры (as-is) и предлагать в целевом состоянии (to-be) консолидацию интеграций через стандартизированные интерфейсы и централизованные узлы.
4613. К какому основному недостатку приводит широкое использование прямых точечных интеграций между множеством систем?
