QA, SRM и раскатка: вопросы для собеседования (часть 2)
SRM (Sample Ratio Mismatch) — один из главных диагностических инструментов: если группы разъехались по размеру, результатам эксперимента нельзя доверять. На собеседовании спрашивают, как обнаружить SRM, какие причины за ним стоят и как безопасно раскатывать изменения после успешного теста.
Вопросы 6–10 из 20
6После успешного эксперимента вы делаете full rollout, но оставляете небольшой `holdout` (группа, удержанная от изменений). Зачем это обычно делают?
AЧтобы иметь постоянную контрольную группу и отслеживать регрессии или долгосрочные эффекты после выкатки
BЧтобы усилить `SRM` (Sample Ratio Mismatch) и проверить устойчивость статистики
CЧтобы всегда получать p-value меньше 0.05 независимо от результата
DЧтобы ускорить сбор данных, так как `holdout` (группа, удержанная от изменений) увеличивает трафик
Ответ: `Holdout` позволяет сравнивать поведение после rollout с неизменённым контролем и ловить регрессии.
Даже если эксперимент был успешным, после выкатки могут появиться эффекты на другом трафике, в другое время или при росте нагрузки. Небольшой `holdout` (группа, удержанная от изменений) даёт эталон, с которым можно сравнить метрики на длительном горизонте. Это особенно полезно для редких событий и для метрик, которые проявляются постепенно. Это особенно полезно для редких событий и для эффектов, которые проявляются постепенно.
7Эксперимент показал положительный эффект, и вы хотите выкатить фичу на всех пользователей. Какой план выкатки наиболее безопасен?
AСразу включить 100% пользователей, чтобы быстрее закончить задачу
BКаждый час случайно менять долю трафика, чтобы «усреднить» риски
CОтключить guardrail‑метрики, чтобы они не мешали выкатке
DСделать поэтапный `ramp-up` (например, 5% → 25% → 50% → 100%) с мониторингом guardrails и планом rollback.
Ответ: Безопасный rollout обычно делают через `ramp-up` с guardrails и готовым rollback‑планом.
Постепенное увеличение доли снижает риск массового инцидента, если в проде проявится баг, не видимый на малой доле. Guardrail‑метрики (краши, latency, ошибки оплаты) помогают поймать вред быстро. Rollback‑план важен не меньше: нужно заранее знать, кто и как откатывает изменения и что считается триггером для отката.
8В эксперименте конверсия в варианте B резко просела, но бизнес подозревает поломку трекинга. Какое действие лучше сделать в первую очередь?
AСразу признать, что фича ухудшила продукт, и навсегда закрыть тему
BПересчитать метрику с другим окном и выбрать то, где падения не видно
CПроверить `instrumentation` и `logging`: сравнить наличие и частоты ключевых событий в сыром логе между вариантами.
DУдалить из данных пользователей с нулевой конверсией, чтобы метрика стала стабильнее
Ответ: При подозрении на поломку метрики первым делом проверяют `logging` и наличие базовых событий по вариантам.
Резкое изменение метрики часто вызвано не поведением пользователей, а пропажей или изменением событий. Сравните сырой поток событий и долю пользователей с хотя бы одним событием конверсии в A и B. Также полезно проверить версию приложения, платформу и релизные флаги: поломка может затрагивать только часть аудитории.
9Какой из вариантов является наиболее типичной причиной `SRM` (Sample Ratio Mismatch) в продакшн‑экспериментах?
AСлишком длинная длительность эксперимента
BСлишком маленький ожидаемый эффект по метрике
CОшибка assignment: часть пользователей не получает вариант из-за фильтров, платформы, кэша или разных ключей разбиения.
DИспользование относительной метрики вместо абсолютной
Ответ: `SRM` (Sample Ratio Mismatch) часто возникает из-за ошибок в assignment и несогласованного разбиения по ключам.
Например, часть трафика может отваливаться из эксперимента на одном из шагов: в фича‑флаге, на клиенте, в сервисе или в сборе событий. Также `SRM` (Sample Ratio Mismatch) появляется, если разбиение делается по разным ключам (user_id vs device_id) в разных местах. Поэтому при `SRM` (Sample Ratio Mismatch) важно проверять всю цепочку доставки варианта и критерии включения.
10После релиза вы увидели неожиданный рост конверсии, но подозреваете, что событие конверсии отправляется дважды. Какой признак лучше всего проверяет гипотезу о дублях?
AРаспределение числа событий на пользователя и наличие уникального идентификатора для дедупликации в `logging`
BТолько среднее значение метрики по дням, без разрезов
CТолько p-value, потому что он показывает, есть ли дубли
DТолько общий объём трафика, не глядя на события
Ответ: Дубли обычно видно по всплеску событий на пользователя и по наличию уникального идентификатора для дедупликации в `logging`.
Если одно действие пользователя приводит к двум одинаковым событиям, у части пользователей будет аномально высокий event_count. Проверка уникального id (например, order_id) помогает понять, можно ли корректно дедуплицировать события. Без этой проверки рост метрики может оказаться не продуктовым эффектом, а артефактом `instrumentation`.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram