BA & SA | 10000 Interview questions
10.4K subscribers
191 photos
14 videos
364 links
Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7
Download Telegram
№4907 категория вопросов: #SECURITY
4907. Для защиты взаимодействия между микросервисами требуется взаимная аутентификация без участия человека, гарантирующая, что обе стороны являются теми, за кого себя выдают, на уровне транспортного уровня. Какой протокол обеспечивает это?
Anonymous Quiz
34%
OAuth2
22%
JWT
39%
mTLS
5%
Basic Auth
Объяснение:

В микросервисной архитектуре сервисы общаются друг с другом по сети. Злоумышленник может попытаться подделать запрос или перехватить данные. Требуется не только шифрование трафика, но и проверка подлинности обоих участников (сервис-клиент и сервис-сервер). Традиционные методы (Basic Auth, API‑ключи) работают на уровне приложения и могут быть скомпрометированы.

Что такое mTLS (Mutual TLS)?
Это расширение протокола TLS, при котором не только сервер предоставляет сертификат клиенту, но и клиент обязан предъявить свой сертификат серверу. Обе стороны проверяют сертификаты друг друга, удостоверяясь, что они принадлежат доверенным сущностям. Это обеспечивает:
Взаимную аутентификацию – сервер знает, кто клиент, клиент знает, что сервер настоящий.
Шифрование трафика – все данные передаются в зашифрованном виде.
Защиту от подделки – сертификаты подписаны доверенным центром (CA) или внутренним PKI.

Сравнение с другими вариантами:
A (OAuth2) – протокол авторизации, обычно с участием пользователя и получением токена доступа. Не является транспортным протоколом и не обеспечивает взаимную аутентификацию на уровне соединения.
B (JWT) – формат токена для передачи утверждений (claims) между сторонами. JWT не гарантирует, что клиент – это тот, за кого себя выдаёт, без дополнительных механизмов.
D (Basic Auth) – передача логина/пароля в открытом виде (или Base64). Устаревший и небезопасный метод для межсервисного взаимодействия.

Реальный пример:
В Kubernetes с Istio (Service Mesh) mTLS включён по умолчанию для всех сервисов внутри кластера. Это позволяет автоматически шифровать и аутентифицировать весь трафик без изменения кода приложений.

Что должен зафиксировать аналитик:
«Для межсервисного взаимодействия использовать mTLS для взаимной аутентификации и шифрования».
«Сертификаты должны управляться централизованным PKI с автоматической ротацией».

Вывод: mTLS — это стандарт для безопасной коммуникации в микросервисных системах, особенно когда критичны защита от подделки и шифрование на транспортном уровне. Аналитик, закладывающий этот протокол в требования, повышает общую безопасность системы.
Please open Telegram to view this post
VIEW IN TELEGRAM
Сэкономила вам время ⌚️
Самый ценный ресурс


Я собрал каналы по Искусственому интеллекту.

Все в одном месте:
⚪️ лучшие нейросети и сервисы;
⚪️готовые промпты;
⚪️реальные кейсы ;
⚪️способы зарабатывать с помощью ИИ

Добавляйте каналы, все полезное уже здесь ⚡️
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Доя масштабного и перспективного проекта в FinTech, Локация: Минск, РБ
ищем амбициозных и ориентированных на развитие специалистов:

1. Руководитель отдела карточных продуктов
Требования:
Опыт в карточном бизнесе от 3 лет, опыт управления P&L карточного портфеля, опыт управления продуктовой командой (от 3 человек), аналитические навыки
Задачи:
1. Управление портфелем карточных продуктов (дебетовые, кредитные, премиальные)
2. Разработка и запуск новых продуктов: от гипотезы до релиза (анализ рынка, требования к IT, юнит-экономика, маркетинг, обучение продавцов).
3. Формирование тарифной политики и ценообразование
4. Увеличение транзакционной активности и снижение оттока по картам.
5. Управление P&L карточного портфеля

2. Руководитель отдела кредитных продуктов
Требования:
Опыт в розничном кредитовании от 3 лет, запуск кредитных продуктов от идеи до релиза, понимание скоринга и кредитного риска, управление продуктовой командой от 3 человек, аналитические навыки, опыт в POS-кредитовании/рассрочке/кредитных картах, знакомство с альтернативным скорингом
Задачи:
1.Управление портфелем кредитных продуктов (кредитные карты, потребительские кредиты, автокредиты, рассрочка, POS-кредиты).
2. Разработка и запуск новых кредитных продуктов: от гипотезы до релиза
3. Формирование процентной политики (ставки, комиссии, льготные периоды,условия досрочного погашения).
4.Организация процесса кредитования (от заявки до сделки
5. Увеличение проникновения кредитных продуктов в действующую клиентскую базу (cross-sell, up-sell).
6. Управление P&L кредитного портфеля

3. Delivery Manager
Требования:
Опыт работы delivery-менеджером / project-менеджером в банке от 3 лет, понимание жизненного цикла разработки ПО, опыт управления кросс-функциональными проектами, знание Agile-практик, навык работы с JIRA / Confluence

Задачи:
1. Управление портфелем проектов розничного блока: от идеи до релиза и пост-релизного сопровождения.
2. Координация запуска новых продуктов
3. Контроль качества изменений
4. Организация сбора и фиксации бизнес-требований, контроль полноты документации перед передачей в разработку.
5. Сбор метрик delivery-процессов (lead time, cycle time, объём незавершёнки), проведение ретроспектив и непрерывное улучшение.
 
Контакт для связи: @Alena_Gvozdz
№4908 категория вопросов: #ARCHITECTURE
4908. Для проверки отказоустойчивости системы команда намеренно отключает случайные микросервисы или задерживает их ответы, чтобы убедиться, что система корректно обрабатывает сбои. Как называется эта практика?
Anonymous Quiz
9%
Нагрузочное тестирование
71%
Тестирование на отказоустойчивость
18%
Chaos Engineering
2%
Пентест безопасности
Объяснение:

Chaos Engineering — это практика экспериментов на распределённых системах, чтобы выявить их слабые места и повысить устойчивость к реальным сбоям. В отличие от обычного тестирования, здесь сбои вносятся намеренно, часто в производственной среде, но контролируемым образом.

Как это работает:
Инструмент (например, Chaos Monkey от Netflix) случайным образом отключает сервисы, задерживает сетевые пакеты, вызывает ошибки.
Команда наблюдает за поведением системы: восстанавливается ли она, не теряет ли данные, не ухудшается ли пользовательский опыт.
На основе результатов усиливают отказоустойчивость: добавляют ретраи, таймауты, circuit breaker, redundant узлы.

Сравнение с другими вариантами:
A (Нагрузочное тестирование) — проверяет производительность под большой нагрузкой, а не устойчивость к сбоям.
B (Тестирование на отказоустойчивость) — похоже, но это более общий термин, а Chaos Engineering — конкретная практика, которая фокусируется на экспериментировании в продуктивной среде и автоматизации.
D (Пентест) — проверяет безопасность, а не отказоустойчивость.

Реальный пример:
Netflix создала Chaos Monkey, который случайно выключает инстансы в AWS. Это помогло инженерам убедиться, что система самовосстанавливается, и инциденты стали редкостью, а не катастрофой.

Что должен зафиксировать аналитик:
«В архитектуре должна быть предусмотрена возможность проведения экспериментов по Chaos Engineering».
«Ключевые метрики (ошибки, задержки, успешность запросов) должны отслеживаться во время таких экспериментов».

Вывод: Chaos Engineering — это не просто «проверим, упадёт ли», а систематический подход к повышению надёжности сложных распределённых систем.
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔1
№4909 категория вопросов: #BROKER #INTEGRATION
4909. В системе на основе очередей сообщение с некорректными данными вызывает ошибку потребителя. При повторных попытках обработка останавливается, и очередь блокируется. Какой механизм изолирует «плохие» сообщения, чтобы очередь продолжала работать?
Anonymous Quiz
1%
Увеличение количества потребителей
9%
Транзакционная запись
88%
Dead Letter Queue (DLQ)
2%
Автоматический повтор с экспоненциальной задержкой
Объяснение:

В брокерах сообщений (RabbitMQ, Kafka, SQS) потребитель может упасть при обработке конкретного сообщения из-за ошибки в данных (например, некорректный JSON, отсутствие обязательного поля). Если настроить автоматические повторные попытки, это сообщение будет циркулировать бесконечно, блокируя обработку других сообщений (особенно в очередях с гарантией порядка). Это приводит к простою всей системы.

Что такое Dead Letter Queue (DLQ)?
DLQ — это специальная очередь (или топик), куда направляются сообщения, которые не удалось обработать после нескольких попыток (например, 3). Механизм работает так:
Сообщение попадает в основную очередь.
Потребитель пытается обработать его N раз (например, 3) с увеличивающейся задержкой (exponential backoff).
После исчерпания попыток сообщение автоматически перемещается в DLQ.
Основная очередь продолжает обрабатывать новые сообщения без блокировки.
Администратор или отдельный сервис анализирует DLQ, исправляет данные и повторно отправляет сообщение в основную очередь.

Сравнение с другими вариантами:
A (Увеличение потребителей) – не помогает, так как все потребители будут получать одно и то же «плохое» сообщение и падать.
B (Транзакционная запись) – обеспечивает атомарность, но не решает проблему изоляции ошибочных сообщений.
D (Автоматический повтор) – полезен для временных сбоев, но бесполезен для ошибок в данных; повтор будет бесконечным, пока очередь не заблокируется.

Реальный пример:
В сервисе заказов при интеграции со сторонним API иногда приходят заказы с некорректным форматом адреса. Без DLQ такие заказы «зависали» в очереди и блокировали обработку всех остальных. Внедрение DLQ позволило перемещать проблемные заказы в отдельную очередь, где их вручную правили операторы, а основной поток заказов обрабатывался без задержек.

Что должен зафиксировать аналитик:
«Для каждой критической очереди должна быть настроена Dead Letter Queue».
«Количество повторных попыток — не более 3, с экспоненциальной задержкой».
«Предусмотреть мониторинг DLQ и алертинг при накоплении сообщений».

Вывод: DLQ — это обязательный паттерн для отказоустойчивой обработки сообщений, позволяющий изолировать проблемные данные и не останавливать основной бизнес-процесс.
Please open Telegram to view this post
VIEW IN TELEGRAM
🖥 Привет, друзья! Собрали новую папку по нейросетям, IT, ИИ

В этой папке собраны каналы, которые помогут прокачать навыки, автоматизировать работу и оставаться в курсе технологий


Что именно внутри:
▪️Свежие новости из мира нейросетей и AI
▪️ Готовые промпты и инструкции для популярных моделей
▪️ Кибербезопасность и защита данных
▪️ IT: Python, JavaScript, разработка и полезные инструменты
▪️ Вакансии, стажировки и удалённая работа в IT
▪️ Автоматизация бизнеса, процессов и рутины с помощью ИИ
▪️ Реальные случаи внедрения искусственного интеллекта в компании
▪️ Полезные сервисы, боты и расширения

Посмотреть и подписаться 👉 https://t.me/addlist/JA1NIlQX5gZkMjYy
№4910 категория вопросов: #ARCHITECTURE
4910. При перегрузке внешнего API вызовы исчерпывают ресурсы сервиса А. Какой паттерн временно приостанавливает вызовы?
Anonymous Quiz
14%
Retry with backoff
12%
Bulkhead
48%
Circuit Breaker
26%
Timeout
1
Объяснение:

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

Что делает Circuit Breaker:
Паттерн отслеживает ошибки при вызове внешнего сервиса и имеет три состояния:
CLOSED (замкнут) – вызовы идут к внешнему сервису. Счётчик ошибок увеличивается.
OPEN (разомкнут) – при превышении порога ошибок (например, 5 ошибок за 10 секунд) все вызовы мгновенно возвращают fallback-ответ (кэш, сообщение об ошибке) без реального запроса к сервису. Это даёт внешнему сервису время на восстановление.
HALF-OPEN (полуоткрыт) – через заданное время (например, 30 секунд) пропускается один пробный вызов. Если он успешен – предохранитель замыкается (CLOSED), если нет – снова размыкается (OPEN).

Реальный пример:
В Netflix, Hystrix (реализация Circuit Breaker) защищает сервисы от падения зависимостей. Если сервис рекомендаций падает, предохранитель размыкается, и пользователь видит заглушку, а не бесконечную загрузку.

Что должен зафиксировать аналитик:
«Для всех вызовов внешних API должен быть реализован паттерн Circuit Breaker».
«Порог ошибок – 5 за 10 секунд, таймаут открытого состояния – 30 секунд».
«Предусмотреть fallback-стратегию (кэш, сообщение, дефолтное значение)».

Вывод: Circuit Breaker — обязательный паттерн для всех синхронных интеграций, чтобы избежать каскадных отказов и исчерпания ресурсов системы.
Please open Telegram to view this post
VIEW IN TELEGRAM
Добрый день!
Папка, собранная исключительно из учебных каналов — точно будет для вас полезной!

В папке собраны каналы, которые:
- рассказывают про ЕГЭ и ОГЭ для обучающихся в школе;
-каналы
репетиторов
- каналы про олимпиады;
- каналы для обучения языку;
- каналы посвященные тематическим предметам ВУЗов;
- каналы для учителей, предназначенные для повышения их квалификации.


Присоединиться к папке можно по ссылке
https://t.me/addlist/91bCxG05F61kOGJi
№4911 категория вопросов: #ARCHITECTURE
4911. Клиент шлет POST /orders. Из-за таймаута ответ не получен. Повторный запрос с тем же телом создает дубликат. Как гарантированно избежать дублей на стороне сервера без изменения бизнес-логики?
Anonymous Quiz
8%
Использовать PUT вместо POST с тем же ID
85%
Добавить заголовок Idempotency-Key и проверять его
6%
Установить Retry-After в ответе на первый запрос
2%
Отправить запрос с Cache-Control: no-store
👍1
Объяснение:
Метод POST не обязан быть идемпотентным по спецификации. Заголовок Idempotency-Key (нестандартный, но де-факто индустриальный стандарт, используемый Stripe/PayPal) позволяет серверу запомнить ключ и результат первой обработки. При повторном запросе сервер возвращает сохраненный ответ, не выполняя логику повторно.
А — нельзя использовать PUT, если ID генерируется сервером.
С — Retry-After говорит клиенту, когда повторять, но не отменяет дубли.
D — Cache-Control влияет только на промежуточные кэши, а не на семантику обработки запроса сервером.
УСПЕВАЕШЬ СЛЕДИТЬ ЗА НОВИНКАМИ ?! Технологии не ждут ...

* Когда подписки устарели (outdated) -
пора сделать АПГРЕЙД своего информационного поля.

Это ПОДБОРКА ведущих Telegram-каналов — тех самых людей, которые не просто читают новости, а сами их создают.

📂 Добавляй ПАПКУ — и получи полный АПГРЕЙД своей ленты:

* Сделай свою подписку умнее, пока другие читают вчерашние новости ⚡️
Отписаться можно в любой момент. Остаться — тоже ✔️
1👍1🔥1
НЕБОЛЬШОЙ АПГРЕЙД ТВОЕЙ ЛЕНТЫ, КОТОРЫЙ ДАСТ ХОРОШИЙ БУСТ ТВОЕЙ КАРЬЕРЕ

Друзья, наш канал попал в подборку тг-каналов про AI & IT, технологии и карьеру — получилась тусовка «для своих» 😎

Мы собрали каналы для себя, которые реально полезны:
следить за ИИ — от свежих инструментов до реальных кейсов
разбираться в технологиях — тренды, обзоры и объяснения
расти в IT — советы по карьере, поиску работы и развитию
быть в теме HR Tech — как технологии меняют найм и управление, ИИ для удаленки и работы за рубежом

🆒 Осталось только добавить папку себе ✔️https://t.me/addlist/dDKo2ardPVBiYThk
👍1