Post #12137
386
Channel Public Channel
BA BA & SA | 10000 Interview questions
@systemanalystinterview
Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7
- Subscribers
- 10.3K
- Photos
- 193
- Videos
- 14
- Links
- 368
Showing posts older than #12138 · Back to latest
Older Posts 20 shown
Post #12136
371
№4874 категория вопросов: #DBMS
Post #12135
423
☀Объяснение:
Проблема:
При синхронном вызове к нестабильному внешнему сервису каждый запрос ждёт таймаута (например, 30 секунд). Если таких запросов много, потоки приложения исчерпываются, и система перестаёт отвечать даже на свои внутренние запросы. Экспоненциальный ретрай (A) помогает при временных сбоях, но не защищает от длительной недоступности – ретраи всё равно будут исчерпывать ресурсы.
Что делает Circuit Breaker:
Замкнут (closed) – вызовы идут к внешнему сервису. Счётчик ошибок увеличивается.
Разомкнут (open) – при превышении порога ошибок (например, 5 ошибок за 10 секунд) все вызовы мгновенно возвращают fallback (кэш, сообщение об ошибке) без реального запроса к сервису. Это даёт сервису время на восстановление.
Полуоткрыт (half-open) – через заданное время (например, 30 секунд) пропускается один пробный вызов. Если успех – предохранитель замыкается, если ошибка – снова размыкается.
Реальный пример:
В Netflix, Hystrix (библиотека Circuit Breaker) используется для защиты от падения зависимых сервисов. Если сервис рекомендаций падает, предохранитель размыкается, и пользователь видит заглушку, а не бесконечную загрузку.
Что должен зафиксировать аналитик:
Порог ошибок (например, 5 ошибок за 10 секунд).
Таймаут открытого состояния (например, 30 секунд).
Fallback-стратегия (кэш, сообщение, пустой результат).
Вывод: Circuit Breaker обязателен для всех интеграций с внешними сервисами, чтобы избежать каскадных отказов.
Проблема:
При синхронном вызове к нестабильному внешнему сервису каждый запрос ждёт таймаута (например, 30 секунд). Если таких запросов много, потоки приложения исчерпываются, и система перестаёт отвечать даже на свои внутренние запросы. Экспоненциальный ретрай (A) помогает при временных сбоях, но не защищает от длительной недоступности – ретраи всё равно будут исчерпывать ресурсы.
Что делает Circuit Breaker:
Замкнут (closed) – вызовы идут к внешнему сервису. Счётчик ошибок увеличивается.
Разомкнут (open) – при превышении порога ошибок (например, 5 ошибок за 10 секунд) все вызовы мгновенно возвращают fallback (кэш, сообщение об ошибке) без реального запроса к сервису. Это даёт сервису время на восстановление.
Полуоткрыт (half-open) – через заданное время (например, 30 секунд) пропускается один пробный вызов. Если успех – предохранитель замыкается, если ошибка – снова размыкается.
Реальный пример:
В Netflix, Hystrix (библиотека Circuit Breaker) используется для защиты от падения зависимых сервисов. Если сервис рекомендаций падает, предохранитель размыкается, и пользователь видит заглушку, а не бесконечную загрузку.
Что должен зафиксировать аналитик:
Порог ошибок (например, 5 ошибок за 10 секунд).
Таймаут открытого состояния (например, 30 секунд).
Fallback-стратегия (кэш, сообщение, пустой результат).
Вывод: Circuit Breaker обязателен для всех интеграций с внешними сервисами, чтобы избежать каскадных отказов.
- ❤ 1
Post #12134
390
Post #12133
375
№4873 категория вопросов: #INTEGRATION
Post #12132
439
☀Объяснение:
Что такое Planning Poker?
Это метод относительной оценки трудоёмкости, где каждый член команды даёт оценку в стори-поинтах (например, 1, 2, 3, 5, 8, 13). Поинты отражают сложность, объём и неопределённостьзадачи, но не переводятся напрямую в часы или дни. Разные команды имеют разную «скорость» (velocity) – количество поинтов, которое команда закрывает за спринт.
Основной недостаток:
Поинты не являются абсолютной мерой времени. Две разные команды могут оценить одинаковую задачу в разные поинты. Даже внутри одной команды поинты не гарантируют точного перевода в часы, так как скорость может меняться (болезни, праздники, сложность интеграции). Бизнесу часто нужны прогнозы в реальных днях/часах, а не в абстрактных поинтах.
Почему не другие варианты?
A – Planning Poker не занимает много времени (обычно 15–30 минут на планирование спринта).
C – участие всех членов команды – это преимущество, а не недостаток.
D – метод как раз учитывает сложность через поинты.
Реальный кейс:
Команда оценила задачу в 5 поинтов, а другая команда – в 13. Скорость первой – 30 поинтов за спринт (2 недели), скорость второй – 50 поинтов. Реальное время разное. Бизнес, требующий сдачи к определённой дате, не может полагаться только на поинты.
Вывод: Аналитик должен объяснять стейкхолдерам, что поинты – это относительная мера для команды, а для прогнозирования сроков нужно использовать историческую скорость (velocity).
Что такое Planning Poker?
Это метод относительной оценки трудоёмкости, где каждый член команды даёт оценку в стори-поинтах (например, 1, 2, 3, 5, 8, 13). Поинты отражают сложность, объём и неопределённостьзадачи, но не переводятся напрямую в часы или дни. Разные команды имеют разную «скорость» (velocity) – количество поинтов, которое команда закрывает за спринт.
Основной недостаток:
Поинты не являются абсолютной мерой времени. Две разные команды могут оценить одинаковую задачу в разные поинты. Даже внутри одной команды поинты не гарантируют точного перевода в часы, так как скорость может меняться (болезни, праздники, сложность интеграции). Бизнесу часто нужны прогнозы в реальных днях/часах, а не в абстрактных поинтах.
Почему не другие варианты?
A – Planning Poker не занимает много времени (обычно 15–30 минут на планирование спринта).
C – участие всех членов команды – это преимущество, а не недостаток.
D – метод как раз учитывает сложность через поинты.
Реальный кейс:
Команда оценила задачу в 5 поинтов, а другая команда – в 13. Скорость первой – 30 поинтов за спринт (2 недели), скорость второй – 50 поинтов. Реальное время разное. Бизнес, требующий сдачи к определённой дате, не может полагаться только на поинты.
Вывод: Аналитик должен объяснять стейкхолдерам, что поинты – это относительная мера для команды, а для прогнозирования сроков нужно использовать историческую скорость (velocity).
Post #12131
429
- 🤔 1
Post #12130
409
№4872 категория вопросов: #REQUIREMENTS
Post #12128
444
☀Объяснение:
Сага – это последовательность локальных транзакций, каждая из которых обновляет данные в одном сервисе. Если шаг не удаётся, запускаются компенсирующие транзакции для отката предыдущих шагов.
В примере:
Сервис склада резервирует товар.
Сервис платежей списывает деньги. Если ошибка → сервис склада компенсирует резерв (отменяет резерв).
Двухфазная фиксация (2PC) медленна и не масштабируется. Общая БД – антипаттерн.
Реальный кейс: В Uber используется Saga для согласования поездки: создание заказа, поиск водителя, списание средств. При сбое любого этапа запускается компенсация.
Вывод: Для распределённых транзакций в микросервисах аналитик должен требовать Saga с явными компенсациями.
Сага – это последовательность локальных транзакций, каждая из которых обновляет данные в одном сервисе. Если шаг не удаётся, запускаются компенсирующие транзакции для отката предыдущих шагов.
В примере:
Сервис склада резервирует товар.
Сервис платежей списывает деньги. Если ошибка → сервис склада компенсирует резерв (отменяет резерв).
Двухфазная фиксация (2PC) медленна и не масштабируется. Общая БД – антипаттерн.
Реальный кейс: В Uber используется Saga для согласования поездки: создание заказа, поиск водителя, списание средств. При сбое любого этапа запускается компенсация.
Вывод: Для распределённых транзакций в микросервисах аналитик должен требовать Saga с явными компенсациями.
Post #12126
368
- ❤ 2
Post #12125
357
№4871 категория вопросов: #INTEGRATION
Post #12124
384
☀Объяснение:
Попарное тестирование основано на наблюдении, что большинство дефектов возникает из-за взаимодействия двух параметров, а комбинации трёх и более встречаются редко. Техника генерирует минимальный набор тестов, покрывающий все возможные пары значений.
Пример для 5 параметров × 10 значений: полный перебор = 100 000 тестов. Pairwise сокращает до ~50–100 тестов при том же покрытии пар. Инструменты: PICT от Microsoft, Hexawise, AllPairs.
Реальный кейс: В тестировании поисковой системы (параметры: регион, язык, категория, сортировка, фильтры) pairwise позволил сократить количество тестов с 10 000 до 200, найдя при этом 95% багов.
Вывод: Аналитик должен рекомендовать pairwise для сложных комбинаторных форм, экономя время тестирования.
Попарное тестирование основано на наблюдении, что большинство дефектов возникает из-за взаимодействия двух параметров, а комбинации трёх и более встречаются редко. Техника генерирует минимальный набор тестов, покрывающий все возможные пары значений.
Пример для 5 параметров × 10 значений: полный перебор = 100 000 тестов. Pairwise сокращает до ~50–100 тестов при том же покрытии пар. Инструменты: PICT от Microsoft, Hexawise, AllPairs.
Реальный кейс: В тестировании поисковой системы (параметры: регион, язык, категория, сортировка, фильтры) pairwise позволил сократить количество тестов с 10 000 до 200, найдя при этом 95% багов.
Вывод: Аналитик должен рекомендовать pairwise для сложных комбинаторных форм, экономя время тестирования.
Post #12122
361
- ❤ 2
Post #12121
350
№4870 категория вопросов: #TESTING
Post #12120
400
☀Объяснение:
Graceful degradation – это способность системы сохранять основную функциональность при отказе второстепенных компонентов. В примере основной функционал – просмотр фильма. Рекомендации – дополнительная функция, но из-за синхронного вызова их падение блокирует плеер.
Как правильно:
Разделить критический и не критический функционал.
При ошибке рекомендаций показывать пользователю плеер, а рекомендации загружать асинхронно (или не показывать вовсе).
Использовать таймауты и fallback-значения.
Реальный кейс: В Netflix при падении сервиса рекомендаций пользователь всё равно может смотреть фильм. Это достигается за счёт асинхронных вызовов и fallback.
Вывод: Аналитик должен закладывать в требования graceful degradation: «При недоступности модуля рекомендаций плеер должен работать, а рекомендации не должны блокировать показ».
Graceful degradation – это способность системы сохранять основную функциональность при отказе второстепенных компонентов. В примере основной функционал – просмотр фильма. Рекомендации – дополнительная функция, но из-за синхронного вызова их падение блокирует плеер.
Как правильно:
Разделить критический и не критический функционал.
При ошибке рекомендаций показывать пользователю плеер, а рекомендации загружать асинхронно (или не показывать вовсе).
Использовать таймауты и fallback-значения.
Реальный кейс: В Netflix при падении сервиса рекомендаций пользователь всё равно может смотреть фильм. Это достигается за счёт асинхронных вызовов и fallback.
Вывод: Аналитик должен закладывать в требования graceful degradation: «При недоступности модуля рекомендаций плеер должен работать, а рекомендации не должны блокировать показ».
Post #12118
384
Post #12117
369
№4869 категория вопросов: #ARCHITECTURE
Post #12115
409
☀Объяснение:
Когда за сайтом стоит несколько серверов (кластер), балансировщик распределяет запросы между ними. Если балансировщик отправляет каждый запрос на случайный сервер (round robin), то данные сессии (корзина, авторизация) могут храниться на одном сервере, а следующий запрос попадёт на другой, где этих данных нет. Пользователь «теряет» корзину или его выкидывает из системы.
Что такое sticky sessions (сессионная аффинность)?
Балансировщик «привязывает» пользователя к определённому серверу на время его сессии. Обычно это делается:
По IP-адресу (не очень надёжно, так как несколько пользователей могут быть за одним NAT).
По cookie, которую балансировщик устанавливает клиенту (более надёжно).
Все последующие запросы этого пользователя направляются на тот же сервер, где хранятся его сессионные данные.
Почему не подходят другие варианты:
B (round robin) – как раз вызывает проблему, так как запросы распределяются по очереди без учёта сессии.
C (least connections) – направляет запрос на сервер с наименьшим числом активных соединений, тоже не учитывает сессию.
D (IP hash) – один из способов реализации sticky sessions, но это не общее название механизма, а частная техника. Правильным ответом является именно термин «sticky sessions» (сессионная аффинность).
Реальный пример:
В интернет-магазине на платформе Magento с несколькими бэкенд-серверами не настроили sticky sessions. Пользователи жаловались, что корзина очищается при переходе на страницу оформления заказа. После включения sticky sessions на балансировщике (HAProxy) проблема исчезла.
Что должен зафиксировать аналитик:
В требованиях к отказоустойчивости и масштабированию указать необходимость поддержки сессионной аффинности.
Уточнить, где хранить сессии (в памяти сервера, в Redis, в БД).
Если используется Redis для централизованного хранения сессий, sticky sessions не нужны, но требуется надёжный Redis-кластер.
Вывод: Sticky sessions — простой способ решить проблему «потери» сессии при масштабировании, но он создаёт свою проблему: при отказе сервера пользователь теряет сессию. Более современный подход — централизованное хранилище сессий (Redis) и отказ от липких сессий. Аналитик должен понимать оба варианта и выбирать под требования.
Когда за сайтом стоит несколько серверов (кластер), балансировщик распределяет запросы между ними. Если балансировщик отправляет каждый запрос на случайный сервер (round robin), то данные сессии (корзина, авторизация) могут храниться на одном сервере, а следующий запрос попадёт на другой, где этих данных нет. Пользователь «теряет» корзину или его выкидывает из системы.
Что такое sticky sessions (сессионная аффинность)?
Балансировщик «привязывает» пользователя к определённому серверу на время его сессии. Обычно это делается:
По IP-адресу (не очень надёжно, так как несколько пользователей могут быть за одним NAT).
По cookie, которую балансировщик устанавливает клиенту (более надёжно).
Все последующие запросы этого пользователя направляются на тот же сервер, где хранятся его сессионные данные.
Почему не подходят другие варианты:
B (round robin) – как раз вызывает проблему, так как запросы распределяются по очереди без учёта сессии.
C (least connections) – направляет запрос на сервер с наименьшим числом активных соединений, тоже не учитывает сессию.
D (IP hash) – один из способов реализации sticky sessions, но это не общее название механизма, а частная техника. Правильным ответом является именно термин «sticky sessions» (сессионная аффинность).
Реальный пример:
В интернет-магазине на платформе Magento с несколькими бэкенд-серверами не настроили sticky sessions. Пользователи жаловались, что корзина очищается при переходе на страницу оформления заказа. После включения sticky sessions на балансировщике (HAProxy) проблема исчезла.
Что должен зафиксировать аналитик:
В требованиях к отказоустойчивости и масштабированию указать необходимость поддержки сессионной аффинности.
Уточнить, где хранить сессии (в памяти сервера, в Redis, в БД).
Если используется Redis для централизованного хранения сессий, sticky sessions не нужны, но требуется надёжный Redis-кластер.
Вывод: Sticky sessions — простой способ решить проблему «потери» сессии при масштабировании, но он создаёт свою проблему: при отказе сервера пользователь теряет сессию. Более современный подход — централизованное хранилище сессий (Redis) и отказ от липких сессий. Аналитик должен понимать оба варианта и выбирать под требования.
Post #12113
372
Post #12112
370
№4868 категория вопросов: #SYSTEMDESIGN