BA & SA | 10000 Interview questions

№4885 категория вопросов: #ARCHITECTURE

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

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

Что такое распределённая трассировка:
Это метод мониторинга, который назначает каждому внешнему запросу уникальный trace ID. Этот ID передаётся через все сервисы в заголовках HTTP/gRPC. Каждый сервис при обработке запроса записывает span (отрезок работы: начало, конец, метаданные, возможная ошибка). Все спаны отправляются в центральный коллектор (Jaeger, Zipkin). Затем можно визуализировать полную временную диаграмму выполнения запроса, увидеть, сколько времени занял каждый вызов, и найти узкое место.

Как это помогает:
Локализация ошибки – видно, в каком сервисе возникла ошибка и на какой стадии.
Анализ производительности – можно найти медленные вызовы.
Зависимости сервисов – визуализация графа вызовов.
Пример работы (Jaeger):
Клиент отправляет запрос с заголовком X-B3-TraceId: abc123.
Сервис А создаёт спаны для своих действий и вызывает сервис Б, передавая тот же trace ID.
Сервис Б делает то же самое.
В веб-интерфейсе Jaeger можно выбрать trace abc123 и увидеть всю цепочку с длительностью каждого этапа.

Почему не подходят другие варианты:
A (метрики, Prometheus) – показывают агрегированные данные (среднее время ответа сервиса, количество ошибок), но не индивидуальный путь запроса.
C (централизованное логирование, ELK) – можно связать логи по trace ID, но без временных отрезков и визуализации цепочки это менее удобно, требует ручного анализа.
D (health checks) – проверяют доступность сервиса, а не отслеживают запросы.

Реальный пример:
В Uber используется распределённая трассировка Jaeger для отладки сценариев поездок. Инженеры могут взять конкретный failed-запрос, посмотреть, что поиск водителя занял 10 секунд из-за задержки в сервисе геопозиционирования, и оптимизировать именно его.

Что должен зафиксировать аналитик:
Требование: «В архитектуре должна быть реализована распределённая трассировка с использованием стандартов OpenTelemetry».
Каждый сервис должен пробрасывать заголовки trace ID при вызовах.
Временные метки должны быть синхронизированы по всем узлам (NTP).

Вывод: Распределённая трассировка — обязательный компонент отказоустойчивых микросервисных систем, позволяющий видеть «путь» запроса и быстро находить проблемные зоны.

№4884 категория вопросов: #ARCHITECTURE

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

Что такое принцип наименьших привилегий (PoLP)?
Это фундаментальный принцип информационной безопасности, согласно которому любой субъект (пользователь, процесс, сервис) должен иметь только те права доступа, которые минимально необходимы для выполнения его функций, и не более. Даже если сервису нужно много файлов, ему можно дать доступ только к определённой директории и права на чтение, но не на запись или выполнение.

Почему в примере нарушен PoLP:
Сервису резервного копирования достаточно прав на чтение файлов из определённых каталогов и записи в каталог бэкапов. Ему не нужны права на установку программ, изменение конфигурации системы, доступ к другим сервисам. Выдача прав администратора даёт всё это, что резко увеличивает риски.

Реальные последствия нарушения:
При взломе сервиса атакующий получает полный контроль над хостом (root/Administrator).
Он может установить вредоносное ПО, получить доступ к данным других приложений, использовать сервер для атак на другие системы.

Как правильно:
Создать отдельную учётную запись для сервиса.
Выдать ей права на чтение только необходимых директорий (например, C:\data\, /var/www/).
Запретить интерактивный вход (только сервисный).
Использовать групповые политики или мандатный контроль доступа (SELinux/AppArmor).

Пример из практики:
В Amazon Web Services пользователям рекомендуют создавать IAM-роли с минимальными правами для каждого сервиса (например, EC2 может читать только свой S3-бакет, а не все бакеты компании).

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

Вывод: Принцип наименьших привилегий — краеугольный камень защищённой системы. Нарушение этого принципа многократно увеличивает ущерб от успешной атаки.

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

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

Двухфазная фиксация (2PC):
Протокол, обеспечивающий строгую атомарность в распределённой среде. Имеет две фазы:
Подготовка (prepare) – координатор опрашивает все узлы, могут ли они зафиксировать транзакцию; узлы блокируют ресурсы и отвечают «готов».
Фиксация (commit) – если все готовы, координатор даёт команду commit, иначе – rollback.

Недостатки 2PC, критичные для требований:
Блокировки – ресурсы заблокированы на всё время транзакции (включая ожидание ответов). Это увеличивает задержку.
Координатор – единая точка отказа – если координатор упал после отправки commit, система может зависнуть.
Плохая масштабируемость – при большом числе участников растёт время и вероятность сбоев.
Не подходит для высокодоступных систем – требование «высокая доступность» несовместимо с 2PC, так как при сетевом разделении 2PC блокируется.

Saga (Сага):
Разбивает распределённую транзакцию на последовательность локальных транзакций. Каждая локальная транзакция обновляет свой сервис и публикует событие. Если транзакция не удалась, запускаются компенсирующие транзакции (откат выполненных шагов).

Варианты реализации Saga:
Хореография – сервисы обмениваются событиями без центрального координатора.
Оркестрация – центральный оркестратор управляет шагами и компенсациями.

Преимущества Saga:
Нет длительных блокировок – каждая локальная транзакция быстро фиксирует изменения.
Высокая доступность – нет единой точки отказа (в хореографии). Даже при оркестрации можно перезапустить оркестратор.

Масштабируемость – каждый сервис может обрабатывать свои транзакции независимо.
Недостаток Saga:
Конечная согласованность (eventual consistency) – в момент между шагами данные могут быть несогласованы (например, деньги списаны, товар ещё не зарезервирован). Но для многих бизнес-сценариев это допустимо.

Почему Saga подходит под требования «низкая задержка, высокая доступность»:
Нет блокировок → низкая задержка.
Нет единой точки отказа → высокая доступность.
Компенсации позволяют откатить изменения без глобальных блокировок.

Реальный пример:
В Uber для заказа поездки используется Saga: создание заказа → поиск водителя → списание средств → уведомление. Если поиск водителя не удался, запускается компенсация: отмена заказа и возврат средств.

Что должен зафиксировать аналитик:
«Для критичных по доступности и латентности распределённых операций использовать паттерн Saga».
«Для каждого шага определить компенсирующее действие (что делать при отказе)».
«Допустима конечная согласованность с максимальным окном 5 секунд».

Вывод: 2PC подходит для систем, где строгая атомарность важнее доступности и задержки (например, банковский перевод внутри одного кластера). Для микросервисов с высокими требованиями к доступности и скорости Saga – стандарт.

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

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

Правила BPMN для завершения процесса:
В нотации BPMN процесс может иметь несколько конечных событий (end events). Каждое конечное событие обозначает отдельный, завершённый путь выполнения. Разные исходы процесса (успех, отказ, требование доработки, отмена) должны вести к разным конечным событиям, чтобы диаграмма отражала семантику бизнеса.

Почему не одно конечное событие (A)?
Если свести все три исхода в одно конечное событие, то на диаграмме будет непонятно, какой результат достигнут. Более того, для «Отправлена на доработку» может потребоваться дополнительная информация (например, комментарий проверяющего), что невозможно выразить единой точкой выхода.

Почему не два конечных события (успех/ошибка)?
В бизнес-процессе «Отправлена на доработку» – это не ошибка, а нормальное, ожидаемое состояние (например, заявка требует правок). Моделировать его как ошибку было бы некорректно и сбивало бы с толку аналитика и исполнителя.
Как изобразить на диаграмме:
После шлюза (XOR или OR) расходятся три потока.
Каждый поток ведёт к своему конечному событию.
У конечных событий можно задать имена (например, «Утверждено», «Отклонено», «На доработку»).

Реальный пример:
В процессе найма сотрудника возможны исходы: «Принят», «Отклонён», «Резерв». Каждый исход завершает процесс по-разному (в HR-системе разные статусы заявки). Три конечных события – стандартная практика.

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

Вывод: Количество конечных событий в BPMN должно соответствовать количеству бизнес-исходов процесса. Неверное количество приводит к потере информации и неверной реализации.

№4881 категория вопросов: #BPMN

Пока поезд не ушёл, успейте забрать готовые схемы и инструкции!

Внутри вас ждут 300+ практических материалов, которые помогут привлекать трафик, получать заявки и увеличивать продажи.

Суть весьма простая: внедряете инструменты, которые уже сработали у нас - и получаете новый результат в деньгах!

Подпишитесь на подборку
и получите доступ👇
https://t.me/addlist/2ozqmVS4cDozZWNi

Кажется, в 2026 году появилась новая профессия — успевать за обновлениями.

Только разобрался с одной нейросетью — выходит новая. Только внедрил инструмент — рынок уже обсуждает следующий. AI, IT и digital сейчас меняются быстрее, чем многие успевают читать новости.

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

Здесь про маркетинг, ИИ, автоматизацию, трафик, продукты, разработку и то, что действительно влияет на деньги, а не только на количество просмотров.

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

Забрать папку себе 🗂

Если вы планируете зарабатывать в Telegram — без этой папки вам будет сложно.

Это не просто информация — это выжимка опыта, на сбор которой обычно уходят годы.

Мне регулярно задают одни и те же вопросы:

✅«Почему нет роста?»
✅«Откуда брать подписчиков?»
✅«Как выйти на доход в Telegram?»

И в большинстве случаев причина одна — нет чёткого понимания, как работает продвижение и маркетинг.

Все знания обычно собираются по частям из разных источников.
Я упростила этот путь и собрала всё в одном месте.

Сохраняйте и добавляйте себе.

Переход по ссылке: https://t.me/addlist/7wOVy3SDM2diNjUy

Записывайся в подборку🫶

Раскрываем секреты🤫

Как нам удается стабильно зарабатывать с блога 300-500к+ рублей🔥

Мы собрали свою ЛИГУ ЭКСПЕРТОВ и упаковали опыт в конкретные шаги, которые можно внедрить и увидеть рост уже в этом месяце.

🎁Более 300 подарков про:

▪️ТРАФИК

— Как выйти на первые 1000 подписчиков в Telegram без бюджета и рекламы
— Секретные связки, дающие поток заявок уже за 7 дней
— База проверенных блогеров для рекламы в Telegram
— Как бесплатно привлекать подписчиков из Threads и получать заявки системно
— Подборка топовых сервисов для поиска рекламных каналов в МАХ
— Движуха в МАХ, где можно набрать подписчиков бесплатно!

▪️ПРОДАЖИ

— Простые инструменты ИИ для ускорения работы и ведения вашего блога
— Продающие скрипты для переписок, которые реально закрывают на оплату
— Система регулярных продаж руками команды
— Как эксперту вытащить КЭШ из блога за 24 часа
— Схема продаж на холодную аудиторию
— Автоворонки, которые продают за вас пока вы отдыхаете

И много других мощных подарков!

Чек-листы, статьи, уроки и подкасты - как стабильно находить клиентов
и делать продажи в новых реалиях.

Чтобы забрать подарки подпишитесь на всех экспертов из папки👇
https://t.me/addlist/2ozqmVS4cDozZWNi

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

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 – стандарт де-факто для безопасной доставки изменений в высоконагруженных системах. Аналитик, закладывающий их в требования, даёт команде возможность контролировать выпуск без риска.