BA & SA | 10000 Interview questions
10.2K subscribers
171 photos
14 videos
341 links
Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7
Download Telegram
Объяснение:

Проблема
Если параметры зашиты в код или переменные окружения на каждом сервере, изменение требует передеплоя десятков сервисов – долго и рискованно.

Централизованная конфигурация
Сервисы при старте обращаются к серверу конфигурации (Spring Cloud Config, Consul, etcd) и получают значения. Некоторые системы позволяют обновлять конфигурацию на лету через механизм watch (сервисы подписываются на изменения). Kubernetes ConfigMap можно обновить, но требуется перезапуск подов (или reinterpret средствами operator).

Преимущества
Централизованное управление одной точкой.
Возможность версионирования и отката конфигурации.
Без передеплоя (если сервис перечитывает конфиг по сигналу или периодически).

Почему не подходят другие
A – передеплой каждого сервиса при каждом изменении параметра.
C – нет стандартного механизма для любого языка.
D – глобальные env подразумевают остановку сервисов.

Реальный пример
Netflix использует Archaius + свой сервер конфигурации, чтобы управлять тысячами сервисов.

Вывод аналитика
В требованиях к архитектуре нужно указать: «Конфигурация должна быть вынесена из кода и управляться централизованно».
Please open Telegram to view this post
VIEW IN TELEGRAM
ХОЧЕШЬ ПОСТОЯННО БЫТЬ В КУРСЕ И ДЕРЖАТЬ РУКУ НА ПУЛЬСЕ НОВИНОК AI & IT ?! Технологии не ждут. А ты?

Каждую неделю — десятки обновлений. То, что вчера делали часами, сегодня нейросеть делает за минуты. Вопрос только в том, узнаешь ли ТЫ об этом первым?

Пока большинство спит, лишь немногие тестируют новые связки и вырываются вперёд. Хочешь быть среди них?

Забирай ПОДБОРКУ со свежими ИИ-инструментами и фишками. Без воды — только то, что реально упрощает работу.

👉 Делимся знаниями и аудиторией — растём вместе ⚡️ Забирай ПАПКУ бесплатно. * Отписаться можно в любой момент. Остаться — тоже. ✔️

Не выпадай из обоймы - будь всегда на острие ! 📌
🔥1
№4828 категория вопросов: #REQUIREMENTS
4828. Через полгода заказчик просит удалить функцию «печать отчёта». После удаления ломается другой модуль. Чего не хватало с самого начала?
Anonymous Quiz
15%
Детальной API-спецификации
76%
Матрицы трассируемости требований (RTM)
0%
Еженедельных созвонов с заказчиком
9%
Логирования всех вызовов функций
Объяснение:

Почему RTM важна?
В больших системах требования редко живут изолированно. Функция «печать отчёта» может использоваться в других модулях: например, отчёт может быть вложением в email, данными для экспорта в Excel, основой для графика. Удаляя её, разработчик должен знать обо всех связях.

Что такое RTM?
Это таблица, где строки — требования, столбцы — компоненты системы (тест-кейсы, модули кода, UI-экраны). На пересечении отмечается связь. Когда требование меняется или удаляется, аналитик сразу видит, какие артефакты нужно проверить.

Реальный кейс: В CRM при удалении поля «регион» из формы клиента перестала работать валидация адреса в модуле доставки — разработчик не знал о связи. RTM выявила бы её за минуту.

Вывод: RTM — не бюрократия, а инструмент контроля изменений. Аналитик обязан поддерживать её хотя бы в простом виде (Excel, Jira связи).
Please open Telegram to view this post
VIEW IN TELEGRAM
📂 Подборка каналов по ИИ и IT технологиям

Подборка каналов для тех, кто интересуется AI, работает в IT сфере и хочет расширить свой кругозор без необходимости мониторить сотни источников самому, а также сделать качественный АПГРЕЙД своих ИИ инструментов.

Что внутри:

AI: реальные инструменты и внедрения, без хайпа;
IT технологии: тренды, обзоры, инсайты от первых лиц;
Карьера: как расти и не выгорать;
HR Tech: кто и как нанимает профессионалов сейчас;
AI life hacks: применение ИИ для тех, кто находиться за границей и ищет там удаленную работу.


🔗 [Добавить папку]
🔥1
№4829 категория вопросов: #TESTING
4829. При тестировании оплаты проверили успех, неверный CVV, истекшую карту — всё ок. После релиза хакеры подменили сумму в запросе с 1000 на 1. Какого теста не хватало?
Anonymous Quiz
0%
Тестирования производительности
95%
Тестирования безопасности на уровне API (подмена параметров)
4%
Юзабилити-тестирования
1%
Тестирования совместимости браузеров
Объяснение:

Как работает атака?
Хакер перехватывает запрос к API и меняет поле 
amount (сумма) с 1000 на 1. Если сервер не пересчитывает сумму на основе заказа, он списывает 1 рубль, хотя пользователь заказал товар на 1000.

Почему стандартные тесты не ловят?
Обычно тестируют интерфейс: в поле ввода 1 → ошибка. Но API-запрос можно сформировать вручную (Postman, curl) и отправить любые параметры.

Какой тест нужен?
Parameter tampering — часть тестирования безопасности API. Тестировщик должен проверить:
Не передаётся ли критическая величина (сумма, скидка, количество) из ненадёжного источника?
Пересчитывает ли сервер сумму по внутренним данным (цена из БД, количество из корзины)?

Реальный кейс: Убытки одного магазина после такой атаки составили $50 000 за ночь.

Вывод: В требованиях к интеграции нужно явно писать: «Сервер не доверяет значениям суммы, скидки, статуса, переданным клиентом».
Please open Telegram to view this post
VIEW IN TELEGRAM
№4830 категория вопросов: #BROKER
4830. В Kafka для заказов настроен ключ = order_id, партиций = 3. При отключении брокера порядок сообщений нарушается. Какой параметр не учли?
Anonymous Quiz
9%
acks=all
71%
min.insync.replicas и acks=all
5%
Слишком много партиций
15%
Продюсер не ждёт подтверждения
Объяснение:

Как работает порядок в Kafka?
По умолчанию: продюсер отправляет сообщение, лидер партиции записывает его, реплики синхронизируются асинхронно. Если лидер падает, выбирается новый лидер из реплик. Если старый лидер успел записать сообщение, но новые реплики его не получили, это сообщение теряется. Новый лидер продолжает запись с другого смещения. В результате для одного ключа 
order_id могут быть пропуски или перестановка.

Что нужно настроить?
acks=all — продюсер ждёт подтверждения от всех синхронных реплик (ISR).
min.insync.replicas — минимальное количество реплик, которые должны подтвердить запись (обычно 2). При min.insync.replicas=2 и replication.factor=3 запись успешна, если хотя бы 2 реплики в ISR.

Почему это сохраняет порядок?
Если старая реплика отстала, она не входит в ISR, и запись не произойдёт до тех пор, пока она не догонит. Таким образом, лидер не теряет сообщения, и порядок сохраняется даже при смене лидера.

Реальный пример: В одной компании из-за отсутствия 
min.insync.replicas события одного заказа (создан → оплачен → отгружен) поменяли порядок на «отгружен → оплачен». Клиенты получали товар без списания денег.

Вывод: Аналитик в требованиях должен указать: «Для гарантированного порядка и отказоустойчивости использовать 
acks=allmin.insync.replicas=2replication.factor=3».
Please open Telegram to view this post
VIEW IN TELEGRAM
№4831 категория вопросов: #SYSTEMDESIGN
4831. В соцсети миллионы лайков. Обновление likes_count в БД при каждом лайке даёт блокировки. Какое решение предложит аналитик?
Anonymous Quiz
11%
Убрать счётчик, считать COUNT(*) при каждом запросе
83%
Redis: инкремент в памяти, периодический сброс в БД
0%
Добавить колонку блокировки в таблицу
6%
Синхронная репликация
ТВОЙ БУСТ В IT И AI

Собрали с коллегами обновленную папку с каналами, которые реально прокачивают навыки и дают актуальные инструменты:

+ IT-направления: системный анализ, Python, JavaScript, frontend, тестирование
+ технологии и инструменты: всё, что ускоряет работу и рост в IT
+ AI для карьеры и бизнеса: как использовать нейросети, чтобы зарабатывать
+ обзор нейросетей: что сейчас работает и что стоит изучать
+ промты: готовые решения + логика создания своих

подписаться🎁  https://t.me/addlist/uyDjlf_VhiNjNWNi

💌 записать свой канал в папку тут
1
Объяснение:

Проблема прямого обновления в БД:
Таблица 
posts имеет колонку likes_count. Каждый лайк выполняет UPDATE posts SET likes_count = likes_count + 1 WHERE id = ?. Это вызывает блокировку строки (row lock) на время обновления, а при тысячах лайков в секунду — конкуренцию и падение пропускной способности.

Как решает Redis:
Redis хранит счётчики в памяти: 
INCR post:123:likes. Операция атомарная и очень быстрая (микросекунды).
Отдельный фоновый процесс (воркер) каждые N секунд (например, 10) читает текущие значения из Redis и обновляет БД: 
UPDATE posts SET likes_count = current_value WHERE id = ?.
При падении Redis счётчики можно восстановить из БД (если сохранять периодически) или из логов событий (Kafka).

Допустима ли eventual consistency?
Да. Пользователь видит, что лайк добавился, но в БД он может отразиться с задержкой в несколько секунд. Для лайков это приемлемо.

Реальный пример: Twitter и Instagram используют подобную архитектуру: лайки, ретвиты, подписки сначала идут в Redis, затем асинхронно записываются в основное хранилище.

Вывод: Аналитик, проектируя высоконагруженный счётчик, должен заложить требование: «Использовать Redis как временный счётчик с асинхронной записью в БД, согласованность — в конечном итоге (eventual consistency)».
Please open Telegram to view this post
VIEW IN TELEGRAM
№4832 категория вопросов: #SECURITY
4832. В медицинской системе нужно хранить диагнозы зашифрованно. Администраторы БД не должны видеть открытые данные. Где выполнять шифрование?
Anonymous Quiz
15%
В хранимых процедурах БД
79%
На уровне приложения (до записи в БД)
4%
Прозрачное шифрование диска
2%
Передать ключи администраторам
80% системных аналитиков заваливают собеседования из-за глупых ошибок

Самый простой способ подготовиться к собеседованию — это послушать, как его проходят другие.

В канале System | Собеседования собрали базу реальных технических интервью, чтобы вы могли учиться на чужих ошибках, а не на своих.

Что внутри:
💘 Разборы живых записей — от проектирования API до работы с БД
💘 Ключевые вопросы лидов из бигтеха
💘 Анализ ответов — где кандидат «поплыл» и как нужно было ответить правильно

Подписывайтесь, чтобы получить доступ к базе живых разборов и увереннее чувствовать себя на собесах.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Объяснение:

Угроза – администраторы БД имеют полный доступ к данным. Прозрачное шифрование диска (TDE) расшифровывает данные для БД, так что администратор всё равно видит их через SQL. Хранимые процедуры тоже выполняются внутри БД, где ключи доступны.
Правильное решение – Application-level encryption: приложение шифрует данные перед отправкой в БД, ключи хранятся в приложении (например, в Vault). Администратор БД видит только бинарный мусор. Приложение расшифровывает данные при чтении для авторизованных врачей.
Требования – необходимо управлять ключами (ротация, доступы), обеспечивать возможность поиска по зашифрованным данным (через детерминированное шифрование или отдельные индексы).
Реальный стандарт – HIPAA, GDPR рекомендуют шифрование на уровне приложения для особо чувствительных данных.
Please open Telegram to view this post
VIEW IN TELEGRAM