BA & SA | 10000 Interview questions

☀Объяснение:

Работать без перебоев — измеримая характеристика. SLA (Service Level Agreement) должно содержать конкретные цифры:

Доступность (uptime) — например, 99.9% (это допустимо ~43 минуты простоя в месяц).
RTO (Recovery Time Objective) — максимальное время восстановления.
RPO (Recovery Point Objective) — допустимые потери данных в минутах/часах.
Время отклика поддержки — например, ответ в течение 15 минут.

Без этих цифр заказчик и исполнитель будут спорить: «перебой» — это 1 минута или 1 час? SLA позволяет объективно измерить качество обслуживания.

Реальный пример: В контракте на облачный сервис прописывают 99.95% доступности. Если простой превышает оговорённый лимит, исполнитель выплачивает штраф.

Вывод: Аналитик должен переводить расплывчатые пожелания в измеримые SLA.

№4837 категория вопросов: #REQUIREMENTS

☀Объяснение:

Подробное объяснение:
Модель Кано классифицирует требования по влиянию на удовлетворённость:
Базовые (must-have) — если их нет, пользователь сильно недоволен, но их наличие не повышает лояльность (например, проверка орфографии: пользователи её ожидают, но не говорят о ней).

Линейные (чем больше, тем лучше) — например, скорость работы приложения.

Восхитители (attractive) — неожиданные фичи, которые вызывают восторг (тёмная тема для некоторых аудиторий).
Ошибка аналитика: он спросил «насколько важно?» и получил ответы, не отражающие реальной категории. Базовые фичи кажутся неважными («это и так должно быть»), а восхитители — переоценёнными в опросах. Правильный подход: задавать вопросы в паре: «Как вы отреагируете, если функция есть?» и «Как отреагируете, если её нет?». Тогда можно определить тип.

Реальный кейс: В одном приложении доставки пользователи говорили, что «отслеживание курьера в реальном времени» важно, а «точное время доставки» — нет. После внедрения оказалось, что точное время гораздо критичнее. Модель Кано помогла бы выявить, что точное время — базовая функция, а трекинг — восхититель.

Вывод: Аналитик должен использовать модель Кано для выявления скрытых ожиданий и не доверять прямым оценкам важности.

№4836 категория вопросов: #REQUIREMENTS

☀Объяснение:

Почему это реальный кейс
В микросервисной архитектуре у разных клиентов (мобильное приложение, веб-версия, интеграции партнёров) могут быть разные графики обновления. Если разработчики API меняют контракт (удаляют поле name, разбивают его на firstName и lastName) и сразу выключают старую версию, клиенты, которые не обновились, ломаются. Это классическая проблема breaking change.

Что должен был сделать аналитик
Зафиксировать требование обратной совместимости: новая версия API не должна удалять поля, которые использовались в старой. Вместо этого добавлять новые поля (firstName, lastName) и сохранять старое поле name (можно вычислять как конкатенацию).

Внедрить grace period: объявить дату устаревания (deprecation) старой версии, например, через 6 месяцев. Всё это время обе версии работают параллельно. В ответах старой версии добавить заголовок Deprecation: true и ссылку на документацию новой версии.

План миграции: клиенты (мобильное приложение) должны перейти на новую версию в течение grace period. Только после того, как все клиенты переключились, старую версию можно отключать.
Мониторинг: отслеживать, какие клиенты всё ещё используют старую версию, и напоминать им о необходимости обновления.

Почему не подходят другие варианты
A (увеличить срок предупреждения) — без политики параллельной работы и обратной совместимости всё равно ломает клиентов в момент отключения.
C (переписать мобильное приложение до отключения) — на практике часто невозможно, так как обновление зависит от пользователей.
D (откатить API) — временное решение, не решающее проблему в будущем.

Реальный пример
GitHub API версионирует через даты (например, 2022-11-28). Старые версии поддерживаются минимум 6 месяцев после объявления deprecation. В заголовках ответа присылают Sunset с датой отключения. Это даёт клиентам время на миграцию.

Вывод для аналитика
При проектировании API всегда закладывайте:
Параллельную работу нескольких версий.
Минимальный срок поддержки старой версии (например, 6–12 месяцев).
Обратную совместимость: добавляйте поля, не удаляйте и не меняйте типы существующих.
Механизм уведомления клиентов о deprecation (заголовки, email, документация).

№4835 категория вопросов: #INTEGRATION

☀Объяснение:

Почему это реальный кейс?
В проектах интеграции с курьерскими службами нередко возникает неоднозначность термина «быстрый». Для логиста «быстрота» может означать минимальное время до прибытия к клиенту с учётом текущих заказов курьера. Для разработчика, не спросившего уточнений, «быстро» — это минимальная дистанция на карте (евклидово расстояние или время в пути без трафика). Результат: система предлагает курьера, который находится за углом, но у него ещё три невыполненных заказа, а реально свободный курьер из соседнего района — через 15 минут. Заказчик недоволен, бизнес теряет деньги.

Что должен был сделать аналитик?

Задать уточняющие вопросы:
«Как именно измерить "быстроту"? По времени, по расстоянию, по рейтингу?»
«Учитываем ли мы текущую загрузку курьера (активные заказы)?»
«Где брать данные о времени освобождения? Из какого API?»
«Нужно ли учитывать пробки, время суток?»
Перевести ответы в измеримое бизнес-правило:

«Система выбирает курьера с минимальным ожидаемым временем прибытия к месту заказа, рассчитанным как: (время завершения текущих заказов курьера) + (расчётное время в пути от его текущей позиции до точки заказа). Данные о текущих заказах получаем из API курьерской системы. При равенстве времени выбираем курьера с более высоким рейтингом».

Зафиксировать требование с критериями приёмки:
Пример 1: Курьер А свободен и находится за углом (1 мин), курьер Б занят на 20 мин, но его время пути 5 мин. Итог: А — 1 мин, Б — 25 мин → выбираем А.

Пример 2: Оба курьера свободны, но А — 5 мин пути, Б — 10 мин → выбираем А.

Последствия для проекта, если не уточнить
Разработчик тратит время на реализацию не того алгоритма.
На приёмке выявляется несоответствие → переделка (стоит в 5–10 раз дороже, чем уточнение на этапе анализа).

Заказчик теряет доверие.
Курьеры распределяются неэффективно → задержки доставки, недовольные клиенты.

Вывод для системного аналитика
Любое субъективное прилагательное («быстрый», «удобный», «лучший», «оптимальный») — красный флаг. Всегда конкретизируйте: по какой метрике, на основе каких данных, с какими допущениями. Превратите "быстрый" в формулу или таблицу принятия решений. Это основа качественных требований.

№4834 категория вопросов: #REQUIREMENTS

☀Объяснение:

Зачем – защита от брутфорса, DDoS, ошибок в клиентском коде, неравномерной нагрузки.
Как работает token bucket
У каждого клиента (IP, API-ключ) есть корзина с токенами (например, 10 токенов).
Каждый запрос забирает 1 токен.
Корзина пополняется с заданной скоростью (например, 1 токен в 0.1 секунды).
Если токенов нет, возвращается HTTP 429 Too Many Requests.
Где реализовывать – на API Gateway (единая точка входа), чтобы не дублировать в каждом микросервисе.
Почему не очередь – очередь сглаживает всплески, но не останавливает злоумышленника, который может забить очередь и создать проблемы.
Вывод – аналитик должен прописывать лимиты (10 запросов/сек) и поведение при превышении в требованиях к публичным API.

№4833 категория вопросов: #SYSTEMDESIGN

☀Объяснение:

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

80% системных аналитиков заваливают собеседования из-за глупых ошибок

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

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

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

Подписывайтесь, чтобы получить доступ к базе живых разборов и увереннее чувствовать себя на собесах.

№4832 категория вопросов: #SECURITY

☀Объяснение:

Проблема прямого обновления в БД:
Таблица 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)».