QA, SRM и раскатка: вопросы для собеседования (часть 4)
SRM (Sample Ratio Mismatch) — один из главных диагностических инструментов: если группы разъехались по размеру, результатам эксперимента нельзя доверять. На собеседовании спрашивают, как обнаружить SRM, какие причины за ним стоят и как безопасно раскатывать изменения после успешного теста.
Вопросы 16–20 из 20
16Во время `ramp-up` целевая метрика улучшилась, но guardrail‑метрика (например, crash rate) ухудшилась выше допустимого порога. Какое решение наиболее корректно?
AПродолжать `ramp-up`, потому что целевая метрика важнее любых guardrails
BПриостановить или откатить rollout и разобраться в причине ухудшения guardrails, даже если целевая метрика растёт.
CСкрыть guardrails из отчёта, чтобы не мешали принятию решения
DУвеличить размер выборки, чтобы crash rate «усреднился»
Ответ: Guardrail‑метрики нужны как стоп‑сигнал в `ramp-up`, чтобы не допустить массового ущерба.
Целевая метрика может расти даже при серьёзных проблемах качества или стабильности, которые ударят по пользователям и бизнесу позже. Поэтому guardrails задают заранее и трактуют как ограничения: нарушили порог — остановились. Это позволяет безопасно сделать rollback и исправить проблему до расширения на 100% аудитории.
17Эксперимент завершён, эффект положительный, `SRM` (Sample Ratio Mismatch) нет, метрики стабильны. Какое решение по rollout обычно считается наиболее практичным в продакшне?
AСразу включить 100% без мониторинга: раз тест успешен, риск нулевой
BСначала увеличить трафик до 100%, а guardrails подключить позже
CСделать rollout через `ramp-up` с мониторингом guardrails, готовым rollback-планом и при необходимости оставить `holdout` (группа, удержанная от изменений).
DПродолжать эксперимент бесконечно, потому что rollout всегда опасен
Ответ: Даже после успешного теста rollout лучше делать постепенно через `ramp-up` и мониторинг.
Эксперимент обычно проходит на ограниченном трафике и в конкретных условиях, а при 100% могут проявиться проблемы масштаба или редкие баги. Поэтапный `ramp-up` снижает риск и даёт время наблюдать guardrails. `Holdout` дополнительно помогает отслеживать долгосрочные эффекты и регрессии после выкатки.
18Эксперимент показал сильный рост метрики в выходные, но в будние дни эффект почти исчезает. Какой вывод и следующий шаг наиболее корректны?
AЭто доказывает, что фича работает только по выходным, поэтому можно выкатывать без дополнительных проверок
BЭто значит, что метрика сломана, и эксперимент нужно выбросить целиком без анализа
CЭто всегда `SRM`, потому что выходные отличаются от будней
DНужно учесть сезонность и возможный `novelty effect` (эффект новизны): дождаться полного цикла (например, недели) и проверить устойчивость эффекта по времени и сегментам.
Ответ: Краткосрочные всплески могут быть вызваны сезонностью или `novelty effect` (эффект новизны), поэтому важно проверять эффект на полном цикле.
Поведение пользователей меняется по дням недели, праздникам и маркетинговым активностям, и это может выглядеть как эффект фичи. Также первый контакт с новинкой может дать временный рост, который не сохраняется. Поэтому корректнее собрать данные минимум на один полный цикл и проверить устойчивость эффекта по времени и сегментам перед решением о rollout.
19Вариант B показывает заметное падение числа покупок по событиям, но по базе транзакций покупок почти столько же, сколько в A. Что лучше всего сделать, чтобы подтвердить проблему трекинга?
AСчитать, что пользователи в B перестали покупать, потому что так показывает метрика
BПодобрать другую метрику, где различий нет, и продолжать rollout
CВыкинуть первые дни эксперимента, чтобы график стал ровнее
DСделать сверку `logging` с источником истины (транзакциями) и проверить потери/дубли событий по вариантам
Ответ: Если события расходятся с источником истины, нужно делать сверку (`reconciliation`) и искать потери/дубли в `logging`.
События могут теряться из-за сетевых ошибок, изменений схемы, условий отправки или багов клиента. Сверка с транзакциями помогает понять, что бизнес‑действие было, а событие не записалось, или записалось дважды. После подтверждения расхождения корректнее чинить `instrumentation`, чем интерпретировать падение как поведение пользователей.
20Вы запустили `A/A test` и получили статистически значимую разницу по ключевой метрике. Что правильнее всего сделать перед запуском A/B?
AСразу запускать A/B: разница доказывает, что система работает
BИгнорировать результат: в `A/A test` значимость бывает всегда
CОстановить и искать причину (рандомизация, `logging`, сегментация), потому что пайплайн даёт ложные эффекты
DСменить целевую метрику на любую другую и продолжить без проверок
Ответ: Значимый эффект в `A/A test` — красный флаг: пайплайн может создавать ложные эффекты.
В `A/A test` эффект должен быть близок к нулю, а значимость должна появляться редко и случайно. Стабильное или большое различие обычно означает проблему: разные аудитории в вариантах, потерю событий, дубли, неверные фильтры включения. Если не исправить это, A/B может показать «победителя» из-за бага, а не из-за продукта.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram