متاح الآن! بحث تيليغرام 2025 — أهم رؤى العام 
BA & SA | 10000 Interview questions
الذهاب إلى القناة على Telegram
Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7
إظهار المزيد📈 نظرة تحليلية على قناة تيليجرام BA & SA | 10000 Interview questions
تُعد قناة BA & SA | 10000 Interview questions (@systemanalystinterview) في القطاع اللغوي الروسية لاعباً نشطاً. يضم المجتمع حالياً 10 210 مشتركاً، محتلاً المرتبة 3 873 في فئة الحياة الوظيفية والمرتبة 64 191 في منطقة روسيا.
📊 مؤشرات الجمهور والحراك
منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 10 210 مشتركاً.
بحسب آخر البيانات بتاريخ 15 يونيو, 2026، تحافظ القناة على نشاط مستقر. خلال آخر 30 يوماً تغيّر عدد الأعضاء بمقدار 301، وفي آخر 24 ساعة بمقدار -1، مع بقاء الوصول العام مرتفعاً.
- حالة التحقق: غير موثّقة
- معدل التفاعل (ER): يبلغ متوسط تفاعل الجمهور 3.19%. وخلال أول 24 ساعة من النشر يحصد المحتوى عادةً 2.35% من ردود الفعل نسبةً إلى إجمالي المشتركين.
- وصول المنشورات: يحصل كل منشور على متوسط 326 مشاهدة. وخلال اليوم الأول يجمع عادةً 240 مشاهدة.
- التفاعلات والاستجابة: يتفاعل الجمهور بانتظام؛ متوسط التفاعلات لكل منشور يبلغ 3.
- الاهتمامات الموضوعية: يركز المحتوى على مواضيع رئيسية مثل объяснение, индекс, user_id, субд, паттерн.
📝 الوصف وسياسة المحتوى
يصف المؤلف القناة بأنها مساحة للتعبير عن الآراء الذاتية:
“Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7”
بفضل وتيرة التحديث المرتفعة (أحدث البيانات بتاريخ 16 يونيو, 2026) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة الحياة الوظيفية.
10 210
المشتركون
-124 ساعات
+1267 أيام
+30130 أيام
أرشيف المشاركات
Запустите рекламу в телеграм-каналах через Яндекс Директ
Перфоманс-реклама в мессенджере продолжает работать:
• Таргетинг по тематикам и регионам
• Умный подбор каналов
• Гибкие модели оплаты (CPC и CPV)
Яндекс Директ знает, как привлечь целевую аудиторию 💰👌
Попробовать
#реклама
yandex.ru
О рекламодателе
4865. Заказчик утвердил пороги скоринга (отказ < 50, проверка 50–70). Через месяц бизнес просит изменить пороги на 40 и 65. Изменение требует перевыпуска релиза. Что упустил аналитик?
☀Объяснение:
Что такое consumer lag (отставание потребителя)?
Это разница между смещением последнего сообщения в очереди и смещением, которое уже обработал потребитель. Если сообщения приходят быстрее, чем обрабатываются, очередь растёт, и задержка доставки (латентность) увеличивается. Например, очередь растёт на 100 сообщений в секунду, через час в ней будет 360 000 необработанных сообщений, а новое сообщение будет ждать обработки часы.
Причины consumer lag:
Медленная бизнес-логика (тяжёлые запросы в БД, вызовы внешних API).
Недостаточное количество потребителей (один consumer на много партиций).
Сетевые задержки или блокировки.
Как решить:
Увеличить количество параллельных потребителей (в RabbitMQ – добавить экземпляры приложения, слушающие ту же очередь; в Kafka – увеличить число consumer’ов в группе, но не больше числа партиций).
Оптимизировать обработку – асинхронные вызовы, пакетная обработка (batch), распараллеливание внутри потребителя.
Использовать flow control – если потребитель не успевает, можно временно приостановить чтение.
Почему не другие варианты:
A (retry storm) – это проблема синхронных ретраев, а не медленного потребителя.
C (deadlock) – взаимоблокировка, не связано с очередью.
D (split brain) – проблема распределённых систем, когда два узла думают, что они лидеры.
Реальный кейс:
В системе логистики потребитель Kafka обрабатывал каждое сообщение (заказ) синхронно, вызывая внешний API доставки (среднее время 200 мс). При пике 5000 сообщений/сек очередь начала расти на 2000 сообщений/сек. Увеличили количество партиций с 1 до 10 и запустили 10 потребителей. Потребление выросло в 10 раз, и отставание прекратилось.
Что должен зафиксировать аналитик:
В требованиях к интеграции указать допустимый consumer lag (например, не более 10 000 сообщений).
Предусмотреть автоматическое масштабирование потребителей (Kubernetes HPA по длине очереди).
Мониторинг: алерт, если lag превышает порог.
Вывод: Consumer lag – главная метрика здоровья систем на основе очередей. Аналитик должен закладывать требования к пропускной способности и мониторингу отставания.
Везти из Азии — не для всех. Но цифры стоит знать
Давай по-честному. Везти машину из Азии — это не панацея и не волшебная таблетка. Это просто способ заплатить за машину её реальную цену, без наценки в полтора-два конца. Кому-то это подходит, кому-то нет: если важно забрать машину сегодня, если кредит уже одобрен и горит — твой вариант салон. А если есть пара месяцев и желание не переплачивать — есть смысл хотя бы посмотреть цифры.
В подборке — конкретные модели 2026 года, по которым разница в цене такая, что окупает все ожидания и хлопоты. Без обещаний, просто факты
Смотреть
#реклама
О рекламодателе
4864. В очереди RabbitMQ сообщения поступают быстрее, чем потребитель успевает их обрабатывать. Со временем очередь растёт, задержка обработки увеличивается. Как называется эта проблема и как её решить?
☀Объяснение:
Что такое CAP-теорема?
В 2000 году профессор Эрик Брюер сформулировал, что в распределённой системе (данные хранятся на нескольких узлах) невозможно одновременно гарантировать все три свойства:
Consistency (C) – строгая согласованность: после успешной записи все последующие чтения видят эту запись (нет устаревших данных).
Availability (A) – доступность: каждый запрос получает ответ (даже если часть узлов недоступна).
Partition tolerance (P) – устойчивость к сетевым разделениям: система продолжает работать, когда связь между узлами нарушена.
При сетевом разделении (например, кабель между дата-центрами оборван) система вынуждена выбирать между C и A.
Если выбираем CP (согласованность + устойчивость к разделениям), то при разделении блокируем запись, чтобы не нарушить согласованность. Доступность падает: некоторые запросы не получают ответа.
Если выбираем AP (доступность + устойчивость к разделениям), то разрешаем запись в каждый раздел независимо, но потом данные могут расходиться (согласованность нарушена).
Почему пример иллюстрирует CAP?
В задаче сказано: система должна быть строго согласованной и доступной. При сетевом разделении она перестаёт принимать запись. Это значит, что система жертвует доступностью для сохранения согласованности. То есть система выбрала CP. CAP-теорема объясняет, почему невозможно иметь и то, и другое одновременно.
Разбор других вариантов:
A (теорема Геделя) – о неполноте формальных систем, к распределённым БД не относится.
C (закон Амдала) – о максимальном ускорении при распараллеливании, не про согласованность.
D (теорема Коуза) – экономическая, о трансакционных издержках.
Реальный пример из практики:
Банковская система (CP) – при разделении между офисами временно запрещает списания, чтобы не возникло отрицательного баланса. Доступность снижена, но деньги в безопасности.
Социальная сеть (AP) – при разделении дата-центров вы всё равно можете поставить лайк (доступность), но счётчик лайков может временно расходиться (eventual consistency).
Что должен зафиксировать аналитик:
В требованиях к распределённой системе явно указать, что важнее: строгая согласованность или доступность.
Например: «В системе управления запасами товара допустима задержка репликации не более 5 секунд, но запись товара должна быть всегда доступна (AP)» или «Платёжная система должна быть строго согласованной (CP)».
Вывод: CAP-теорема – фундаментальное ограничение, которое аналитик обязан понимать при проектировании распределённых систем. Нельзя попросить «идеальную систему», нужно выбирать компромисс.
Премиальный гибридный минивэн VOYAH МЕЧТА/DREAM
Ваш роскошный «офис на колесах» : адаптивная пневмоподвеска, интеллектуальный привод, впечатляющий запас хода.
Просторный салон премиум-класса: комфортные кресла второго ряда с большими диапазонами электрорегулировок, подогревом, ветриляцией и массажем.
Выбирайте VOYAH МЕЧТА / DREAM в наличии на гибких условиях покупки: выгода по трейд-ин, господдержка.
Успейте зафиксировать цену!
Узнать больше
#реклама
voyah.su
О рекламодателе
4863. Распределённая система должна гарантировать, что все узлы видят одни и те же данные в любой момент времени и оставаться доступной даже при сбоях. При сетевом разделении система перестаёт принимать запись. Какую теорему иллюстрирует этот пример?
☀Объяснение:
Когда сервис A вызывает сервис B через REST API, он ждёт ответа. Если B недоступен (сетевая проблема, падение, перезагрузка), A получает ошибку. Если A не сохранил данные локально, они теряются навсегда. Даже с ретраями (повторными попытками) при длительном сбое (например, 30 минут) данные всё равно потеряются после исчерпания попыток.
Как асинхронная очередь решает проблему
Брокер сообщений (RabbitMQ, Kafka, Amazon SQS) действует как надёжный буфер:
Сервис A отправляет сообщение в очередь и не ждёт ответа (асинхронно).
Если сервис B недоступен, сообщение остаётся в очереди.
Очередь хранит сообщения на диске (персистентность), поэтому даже перезапуск брокера не удалит их.
Когда B восстанавливается, он забирает все накопившиеся сообщения и обрабатывает их.
Гарантируется доставка «хотя бы один раз» (at‑least‑once), а при правильной настройке – идемпотентная обработка.
Почему другие варианты не подходят:
A (синхронный REST + ретраи) – ретраи помогают при кратковременных сбоях (секунды), но при длительной недоступности (часы) данные теряются. Кроме того, ретраи могут создать дополнительную нагрузку на восстанавливающийся сервис (эффект «retry storm»).
C (периодическая синхронизация) – например, раз в час. За это время данные могут устареть, а при сбое в момент передачи всё равно возможна потеря. Не подходит для интерактивных сценариев.
D (общая БД) – антипаттерн в микросервисной архитектуре: сервисы начинают зависеть от схемы данных друг друга, теряется независимость, сложно эволюционировать
Реальный кейс из практики:
Сервис заказов интернет-магазина должен был отправлять данные в CRM. Изначально использовали синхронный REST. При падении CRM на 10 минут 200 заказов не попали в CRM, и менеджеры не видели их. После перехода на RabbitMQ заказы публиковались в очередь. При сбое CRM сообщения накапливались в очереди (до 10 000 за час). После восстановления CRM обработала все заказы за несколько минут. Потери данных были исключены.
Что должен зафиксировать аналитик в требованиях:
«Взаимодействие между сервисами при не критическом ко времени отклика сценарии должно быть асинхронным через брокер сообщений».
«Очередь должна быть персистентной (сохранение на диск) и реплицированной для отказоустойчивости».
«Потребитель должен быть идемпотентным, чтобы при повторах не создавать дубли».
Вывод: Выбор между синхронным и асинхронным взаимодействием – это компромисс между простотой и надёжностью. Для критичных данных, которые нельзя терять, и при допустимой задержке асинхронная очередь – единственно правильное архитектурное решение.
☀Объяснение:
Когда сервис A вызывает сервис B через REST API, он ждёт ответа. Если B недоступен (сетевая проблема, падение, перезагрузка), A получает ошибку. Если A не сохранил данные локально, они теряются навсегда. Даже с ретраями (повторными попытками) при длительном сбое (например, 30 минут) данные всё равно потеряются после исчерпания попыток.
Как асинхронная очередь решает проблему
Брокер сообщений (RabbitMQ, Kafka, Amazon SQS) действует как надёжный буфер:
Сервис A отправляет сообщение в очередь и не ждёт ответа (асинхронно).
Если сервис B недоступен, сообщение остаётся в очереди.
Очередь хранит сообщения на диске (персистентность), поэтому даже перезапуск брокера не удалит их.
Когда B восстанавливается, он забирает все накопившиеся сообщения и обрабатывает их.
Гарантируется доставка «хотя бы один раз» (at‑least‑once), а при правильной настройке – идемпотентная обработка.
Почему другие варианты не подходят:
A (синхронный REST + ретраи) – ретраи помогают при кратковременных сбоях (секунды), но при длительной недоступности (часы) данные теряются. Кроме того, ретраи могут создать дополнительную нагрузку на восстанавливающийся сервис (эффект «retry storm»).
C (периодическая синхронизация) – например, раз в час. За это время данные могут устареть, а при сбое в момент передачи всё равно возможна потеря. Не подходит для интерактивных сценариев.
D (общая БД) – антипаттерн в микросервисной архитектуре: сервисы начинают зависеть от схемы данных друг друга, теряется независимость, сложно эволюционировать
Реальный кейс из практики:
Сервис заказов интернет-магазина должен был отправлять данные в CRM. Изначально использовали синхронный REST. При падении CRM на 10 минут 200 заказов не попали в CRM, и менеджеры не видели их. После перехода на RabbitMQ заказы публиковались в очередь. При сбое CRM сообщения накапливались в очереди (до 10 000 за час). После восстановления CRM обработала все заказы за несколько минут. Потери данных были исключены.
Что должен зафиксировать аналитик в требованиях:
«Взаимодействие между сервисами при не критическом ко времени отклика сценарии должно быть асинхронным через брокер сообщений».
«Очередь должна быть персистентной (сохранение на диск) и реплицированной для отказоустойчивости».
«Потребитель должен быть идемпотентным, чтобы при повторах не создавать дубли».
Вывод: Выбор между синхронным и асинхронным взаимодействием – это компромисс между простотой и надёжностью. Для критичных данных, которые нельзя терять, и при допустимой задержке асинхронная очередь – единственно правильное архитектурное решение.
IT-сфера снова переживает бурные времена. AI-технологии влияют на классические подходы, а компании, которые не успевают адаптироваться - теряют позиции. В этой ситуации решает не количество информации, а её качество.
Мы собрали папку каналов для тех, кто не просто «следит за трендами», а реально работает с цифрами, тестирует AI инструменты и адаптирует свои процессы под новые реалии.
Только практические советы и реальные кейсы👇🏻
Сохранить папку 📨
Доступно 48 часов❗️
Про деньги и порядок без шума
Есть каналы, где учат «больше хотеть».
И есть те, где становится спокойнее.
Здесь — про деньги, мышление и порядок.
Без мотивации.
Без шума.
Без обещаний.
Для взрослых людей,
которые строят жизнь и бизнес надолго.
Смотреть
#реклама 16+
О рекламодателе
4862. Два сервиса должны обмениваться данными. Если сервис-получатель временно недоступен, данные теряются. Какой тип взаимодействия выбрать?
☀Объяснение:
При загрузке данных из разных источников (CSV, старые базы, ручной ввод) часто появляются дубли. Первичного ключа нет, и нужно выявить все строки-дубликаты (а не просто узнать, какие комбинации полей дублируются). Например, клиент Иванов Иван с email ivan@mail.ru может встретиться три раза с разными
id (если бы id был). Нужно найти все эти три записи, чтобы потом оставить одну (чистка данных).
Что делает ROW_NUMBER()?
Оконная функция ROW_NUMBER() присваивает уникальный номер каждой строке внутри группы. Группа определяется PARTITION BY (поля, по которым ищем дубли). Порядок нумерации внутри группы задаётся ORDER BY (можно по любому полю, например, по условному id, если есть, или дате). Первая строка в группе получает номер 1, вторая – 2 и т.д. Все строки с номером > 1 – дубликаты.
Пример запроса:
sql
WITH ranked AS (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY fio, email, phone ORDER BY id) AS rn
FROM clients
)
SELECT * FROM ranked WHERE rn > 1;id, можно использовать ORDER BY (SELECT NULL) или любую константу – тогда порядок произвольный, но дубли всё равно будут отмечены.
Почему другие варианты не подходят:
C (GROUP BY + HAVING) – покажет, какие комбинации полей встречаются более одного раза, но не выдаст сами записи. Например, вы узнаете, что (Иванов, ivan@mail.ru) дублируется, но не получите три строки для анализа.
B (временная таблица) – технически можно: вставить уникальные записи во временную таблицу, потом сравнить. Но это громоздкий и медленный способ, особенно для больших объёмов.
D (добавить PK) – автогенерируемый ключ не найдёт существующие дубли. Он только предотвратит новые дубли, если добавить уникальное ограничение.
Реальный кейс:
В одной компании при миграции из старой CRM в новую выяснилось, что в таблице customers15% записей – дубли по ФИО+email. Аналитик использовал ROW_NUMBER(), сгенерировал отчёт с дублями и передал бизнесу на чистку. Без оконных функций пришлось бы писать сложные самосоединения, которые работали бы часы.
Что должен зафиксировать аналитик в требованиях к качеству данных:
«Периодически проводить проверку на дубли по критическим полям с использованием оконных функций».
«Результаты проверки должны включать все дублирующиеся строки, а не только комбинации полей».
Вывод: Для выявления полных дубликатов записей (а не просто факта дублирования) оконная функция ROW_NUMBER() – самый эффективный и наглядный инструмент.