متاح الآن! بحث تيليغرام 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 أيام
أرشيف المشاركات
☀Объяснение:
Feature Toggles (Feature Flags) – это механизм, позволяющий включать или выключать определённую функциональность во время выполнения программы без выкатки нового кода. Значения флагов обычно хранятся в централизованной конфигурации (файл, база данных, Redis) или в стороннем сервисе (LaunchDarkly, ConfigCat). Код содержит проверку (if feature_is_enabled('new_payment')) и в зависимости от флага выполняет новый или старый алгоритм.
Как решается задача тестирования на 5% пользователей:
· Создаётся флаг new_payment с правилом: включён для 5% случайных user_id (по модулю или хешу).
· Остальные 95% продолжают использовать старую оплату.
· При обнаружении ошибки администратор меняет правило на 0% (или false) – система мгновенно переключает всех обратно на старый код. Никакого передеплоя не требуется.
Виды Feature Toggles:
1. Release Toggles – для скрытия незавершённого кода до релиза.
2. Experiment Toggles – для A/B-тестирования (как в примере).
3. Ops Toggles – для управления производительностью (например, отключить тяжёлый отчёт).
4. Permission Toggles – для доступа новых фич только определённым пользователям (бета-тестеры).
Преимущества:
· Безопасный rollout: можно включить функцию постепенно для групп пользователей.
· Мгновенный откат: при проблемах выключаем флаг за секунды.
· Независимость от циклов релиза: можно деплоить код с флагами, а включать позже.
· Возможность канареечных релизов (canary releases) и A/B-тестов.
Недостатки:
· Усложнение кода (много if/else).
· Со временем накапливаются устаревшие флаги (технический долг).
· Требуется централизованное хранилище с хорошим временем ответа.
Реальный пример:
В Netflix тысячи флагов используются для постепенного включения новых алгоритмов рекомендаций. При обнаружении падения метрик (например, снижение времени просмотра) оператор отключает флаг за минуты, а не готовит hotfix.
Что должен зафиксировать аналитик:
· «Ключевые изменения бизнес-логики должны быть реализованы через Feature Toggles».
· «Процесс отката: при выключении флага система переходит на предыдущее поведение в течение 1 минуты».
· «Устаревшие флаги должны удаляться после 2 релизов, для этого завести техническую задачу».
Вывод: Feature Toggles – стандарт де-факто для безопасной доставки изменений в высоконагруженных системах. Аналитик, закладывающий их в требования, даёт команде возможность контролировать выпуск без риска.
4880. Команда внедряет новую систему оплаты, но хочет сначала протестировать её на 5% пользователей. Если возникнут проблемы, остальные 95% не должны пострадать. Какой механизм позволяет включать и вы
☀Объяснение:
Use Case Points (UCP) – метод оценки трудоёмкости, первоначально разработанный Густавом Карлссоном для оценки разработки. Однако его модификации активно применяются и для оценки тестирования. В основе лежит анализ вариантов использования (use cases), а не низкоуровневых входов/выходов, как в TPA.
Базовые элементы для расчёта UCP тестирования:
Акторы (actors) – внешние сущности, взаимодействующие с системой. Каждому актору присваивается вес (простой, средний, сложный) в зависимости от протокола взаимодействия (GUI, API, файл).
Транзакции – элементарные шаги в потоке событий use case. Это может быть ввод данных, выбор из списка, нажатие кнопки, получение сообщения. Каждая транзакция добавляет определённое количество тестовых точек.
Коэффициенты сложности – поправки на технические характеристики (распределённость, производительность, безопасность) и на опыт команды.
Формула UCP для тестирования (упрощённо):
text
UCP (тестирование) = (UUCW + UAW) × TCF × EFUUCW (Unadjusted Use Case Weight) – сумма весов транзакций по всем use cases. UAW (Unadjusted Actor Weight) – сумма весов акторов. TCF (Technical Complexity Factor) – на основе 15 технических факторов (например, распределённая обработка, производительность). EF (Environmental Factor) – на основе 8 факторов среды (например, опыт команды, мотивация). Как получить из UCP оценку в часах тестирования: Обычно используют эмпирическую калибровку: одна точка UCP ≈ 5–20 человеко-часов тестирования (зависит от проекта). Умножают на поправочные коэффициенты (например, на регрессионное тестирование 1.2). Преимущества UCP: Основан на early-артефактах (use cases), которые есть уже на стадии анализа. Учитывает как функциональность, так и нефункциональные факторы (технические). Прозрачен для заказчика (видно, из чего складывается оценка). Недостатки: Требует детальной спецификации use cases. Коэффициенты TCF и EF частично субъективны. Непосредственно для тестирования метод менее распространён, чем TPA. Реальный пример: В проекте по созданию интернет-банка было 12 use cases с 48 транзакциями и 4 акторами (клиент, администратор, оператор, внешний платёжный шлюз). UUCW = 120, UAW = 20, TCF = 1.1, EF = 1.0. Итого UCP = (120+20) × 1.1 = 154. Умножив на 6 часов на точку (калибровка прошлых проектов), получили 924 человеко-часа на тестирование. Оценка совпала с фактическими затратами с точностью 15%. Что должен зафиксировать аналитик: Использовать UCP для ранней (укрупнённой) оценки тестирования, когда ещё нет детальных спецификаций экранов. Калибровать коэффициент «часы на точку» по истории завершённых проектов. Включать в TCF отдельные нефункциональные требования. Вывод: UCP для тестирования – полезный метод, особенно когда нужно быстро дать оценку при планировании, а детальные спецификации ещё пишутся.
4879. Метод оценки трудоёмкости тестирования, основанный на количестве транзакций в вариантах использования (use cases), количестве акторов и коэффициентах сложности. Как он называется?
☀Объяснение:
Проблема:
В классической монолитной архитектуре с одной реляционной базой данных чтение и запись используют одни и те же таблицы и индексы. Тяжёлые аналитические запросы (отчёты, поиск) блокируют или тормозят транзакционные операции (создание заказов, обновление остатков). Попытки настроить индексы для чтения ухудшают производительность записи, и наоборот.
Суть CQRS (Command Query Responsibility Segregation):
Паттерн, предложенный Грегом Янгом, разделяет компоненты системы на две части:
Команды (Commands) – изменяют состояние системы (create, update, delete). Они выполняются строго последовательно и могут возвращать только подтверждение или ошибку, но не данные.
Запросы (Queries) – читают состояние, не изменяя его. Они могут возвращать сложные, денормализованные данные, оптимизированные для конкретного экрана или отчёта.
Как это реализуется технически:
Модель команд работает с нормализованным хранилищем (обычно реляционная БД), оптимизированным на скорость записи и целостность.
Модель запросов работает с денормализованными read-моделями – отдельными таблицами, кэшами (Redis), поисковыми движками (Elasticsearch) или репликами основной БД с другими индексами.
Синхронизация между командной и query-моделями происходит асинхронно (через события, CDC или брокер сообщений). Это означает, что read-модель может отставать от реальности на несколько секунд (eventual consistency).
Плюсы CQRS:
Развязка нагрузки – тяжёлые отчёты не мешают транзакциям.
Независимая оптимизация – для запросов можно использовать хранилища, идеально подходящие под задачу (поисковые движки, графовые БД, колоночные хранилища).
Масштабирование – можно масштабировать read-модели горизонтально, не затрагивая write-модель.
Минусы:
Сложность – нужно поддерживать синхронизацию и терпимость к задержкам.
Дублирование данных – та же информация хранится в нескольких местах.
Не подходит для систем, где нужна строгая согласованность «чтение своих изменений сразу» (например, в финансовом приложении после перевода пользователь должен видеть новый баланс мгновенно).
Когда CQRS необходим:
Системы с высоким соотношением чтения к записи (например, каталог товаров).
Системы, где у чтения и записи разные требования к производительности.
Проекты, где read-модель может быть построена на специализированном хранилище (Elasticsearch, Redis, Cassandra).
Реальный пример:
В онлайн-кинотеатре просмотр страницы с фильмами (чтение) обрабатывается через read-реплики и кэш, а добавление новых фильмов (запись) – через master-базу. CQRS позволил сократить время отклика главной страницы с 1.5 с до 0.1 с.
Что должен зафиксировать аналитик:
«Модели чтения и записи должны быть разделены на уровне логики и, при необходимости, на уровне инфраструктуры».
«Согласованность между ними – конечная (eventual), допустимая задержка не более 2 секунд».
«Для каждого отчёта или экрана проектируется отдельная read-модель (может быть даже отдельная таблица)».
Вывод: CQRS – мощный паттерн для систем, где нагрузка на чтение кардинально отличается от нагрузки на запись. Аналитик, предлагающий CQRS, должен также предусмотреть стратегию обновления read-моделей и механизмы обработки рассинхрона.
ИИ меняет всё вокруг. Кто разбирается в трендах, тот управляет будущим.
Вот отличная подборка сильных экспертов по AI & IT для твоего профессионального роста — всё в одном месте.
Забирай ПОДБОРКУ и оставайся на шаг впереди 💪🏻
* Там — живые инструменты, реальные кейсы и понятные схемы, как использовать нейросети с толком и высоким КПД.
Добавляй ПАПКУ в свой актив и делись с друзьями! 📌
👉 Делимся знаниями и аудиторией — растём вместе ⚡️
* Отписаться можно в любой момент. Остаться — тоже. ✔️
4878. Система испытывает тормоза из-за того, что одни и те же таблицы одновременно читаются для отчётов и изменяются в транзакциях. Какой архитектурный паттерн разделяет модели чтения и записи, позволяя оптимизировать их независимо?
НЕБОЛЬШОЙ АПГРЕЙД ТВОЕЙ ЛЕНТЫ, КОТОРЫЙ ДАСТ ХОРОШИЙ БУСТ ТВОЕЙ КАРЬЕРЕ
Друзья, наш канал попал в подборку ТГ-каналов про AI & IT, технологии и карьеру — получилась тусовка «для своих» 😎
Мы собрали каналы для себя, которые реально полезны:
➕ следить за ИИ — от свежих инструментов до реальных кейсов
➕ разбираться в технологиях — тренды, обзоры и объяснения
➕ расти в IT — советы по карьере, поиску работы и развитию
➕ быть в теме HR Tech — как технологии меняют найм и управление, ИИ для удаленки и работы за рубежом
🆒 Осталось только добавить папку себе ✔️https://t.me/addlist/k7k1VvVVo1YzNTU0 👉 Делимся знаниями и аудиторией — растём вместе ⚡️
☀Объяснение:
Что такое MoSCoW?
Это метод приоритизации требований, где каждая фича относится к одной из категорий:
Must have – критически важно, без этого релиз не имеет смысла (обычно не более 40–50% от общего объёма).
Should have – очень важно, но может быть заменено обходным путём или реализовано позже.
Could have – желательно, но не критично (если время позволяет).
Won’t have – явное исключение (договорённость, что эта фича не делается в текущем релизе).
Как помогает MoSCoW?
Заказчик сначала относит все 20 фич к категориям. После обсуждения часто выясняется, что реальных Must have всего 5–6. Остальные переносятся на следующие версии. MoSCoW даёт заказчику инструмент осознанного выбора: если он настаивает на 10 Must have, команда показывает, что это физически не укладывается в сроки, и предлагает согласовать «жертвы».
Почему не другие варианты:
A (WSJF) – требует численной оценки ценности и длительности, хорошо для ранжирования бэклога, но менее нагляден для переговоров о границах релиза.
C (голосование) – не структурирован, ведёт к усреднению, а не к жёсткому отбору.
D (story points) – это оценка трудоёмкости, а не приоритизация бизнес-ценности.
Реальный кейс: В разработке мобильного приложения заказчик хотел 15 фич в первом релизе. Аналитик провёл MoSCoW-сессию, и в Must попало 6 фич. Остальные перенесли на второй релиз. Релиз вышел в срок, а второй релиз был доработан позже.
Что должен зафиксировать аналитик:
Регламент: «Каждое требование классифицируется по MoSCoW перед планированием релиза».
Критерии для Must have: если фича не выполнена, релиз не выпускается.
Процесс пересмотра: если появляется новая Must have, другая Must have должна быть перемещена в Should или Could (правило «вход только через выход»).
Вывод: MoSCoW – простой и эффективный способ приоритизации, особенно на этапе согласования границ релиза с бизнесом.
4877. Заказчик требует 20 фич в релизе, но команда понимает, что сделать всё невозможно за отведённое время. Какой метод приоритизации поможет выделить обязательный минимум и договориться о сокращении объёма?
☀Объяснение:
В чём проблема реляционных БД?
В социальных сетях запрос «друзья друзей» требует трёх
JOIN (пользователь → друзья → друзья друзей). При миллионах пользователей такой запрос выполняется очень долго, даже с индексами. Для поиска путей произвольной длины (например, «связь через 5 шагов») реляционная БД практически не приспособлена.
Что такое графовая БД?
В графовой БД данные хранятся как вершины (пользователи, интересы, посты) и рёбра (дружба, лайк, подписка). Обход графа происходит через обход смежных вершин, что на порядки быстрее JOIN-ов. Например, в Neo4j запрос на поиск друзей друзей:
cypher
MATCH (u:User {id: 123})-[:FRIEND]->(friend)-[:FRIEND]->(friendOfFriend)
RETURN friendOfFriend
Этот запрос выполняется за миллисекунды на графах с миллиардами рёбер.
Почему не подходят другие NoSQL:
Документо-ориентированные (MongoDB) – хранят вложенные структуры, но не оптимизированы для связей произвольной глубины.
Ключ-значение (Redis) – хорош для кэша, но не для сложных запросов к связям.
Колоночные (Cassandra) – для аналитики и временных рядов, не для графов.
Реальный кейс: LinkedIn использует графовую БД для рекомендаций «люди, которых вы можете знать». Facebook хранит социальный граф в TAO (своя графовая БД). В компаниях с большими графовыми данными производительность после перехода с реляционной БД на графовую вырастает в 10–100 раз.
Что должен зафиксировать аналитик:
Требование: «Для хранения социального графа и быстрых запросов на обход связей использовать графовую БД (Neo4j, Neptune, JanusGraph)».
Типичные запросы: поиск друзей друзей, рекомендации по общим интересам, проверка связей на расстоянии до 3.
Вывод: Графовые БД – лучший выбор для сильно связных данных, где важна скорость обхода отношений.https://t.me/boost/SystemAnalystInterview
Давайте поддержим активностью
4876. Социальная сеть должна быстро находить друзей друзей (path length 2) и общие интересы. Реляционная БД с JOIN-ами работает медленно. Какой тип NoSQL базы данных оптимален для хранения связей и быстрого обхода графа?
☀Объяснение:
Что такое Strangler Fig?
Название происходит от фикуса-душителя, который обвивает дерево-хозяина и постепенно его заменяет. В архитектуре – это стратегия постепенной замены старой системы новой без «большого взрыва» (big bang). На начальном этапе создаётся фасад (прокси, API Gateway), который маршрутизирует запросы: часть отправляется в старый монолит, часть – в новый микросервис. Постепенно функционал переносится, и доля запросов к старой системе уменьшается. В конце концов монолит отключается.
Как это работает на практике:
Создаётся маршрутизатор (Nginx, Zuul, Envoy).
Выделяется первый модуль монолита (например, «каталог товаров») и реализуется как отдельный микросервис.
В маршрутизаторе настраивается правило: запросы к
/catalog/* направляются в новый сервис, все остальные – в монолит.
Следующий модуль («корзина») выделяется аналогично.
Постепенно все маршруты переключаются.
Когда трафик на монолит падает до нуля, он отключается.
Преимущества:
Нет даунтайма.
Возможность отката (при проблемах с новым сервисом можно быстро переключить маршрут обратно).
Каждый этап даёт бизнес-ценность независимо.
Реальный кейс: Amazon переписывал свою архитектуру несколько лет по паттерну Strangler Fig. Каждый микросервис вырезался из монолита и запускался в отдельное окружение. В итоге монолит исчез без единой остановки сервиса.
Что должен зафиксировать аналитик:
Требование: «Замена функциональных модулей должна происходить итеративно, с сохранением работоспособности системы на каждом этапе».
План маршрутизации (какие URL идут на новый сервис).
Критерии переключения (например, когда новый сервис прошёл нагрузочное тестирование).
Вывод: Strangler Fig – стандартный паттерн для безопасного рефакторинга больших систем.4875. Устаревший монолит нужно постепенно заменять на микросервисы без остановки системы. Какой паттерн позволяет направлять часть запросов на новый функционал, а часть – на старый, постепенно увеличивая долю нового?
