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