QA, SRM и раскатка: вопросы для собеседования (часть 4)
SRM (Sample Ratio Mismatch) — один из главных диагностических инструментов: если группы разъехались по размеру, результатам эксперимента нельзя доверять. На собеседовании спрашивают, как обнаружить SRM, какие причины за ним стоят и как безопасно раскатывать изменения после успешного теста.
Вопросы 16–20 из 20
16Во время постепенной раскатки целевая метрика улучшилась, но страховочная метрика (например, доля сбоев) ухудшилась выше допустимого порога. Какое решение наиболее корректно?
AПриостановить или откатить раскатку и разобраться в причине ухудшения страховочной метрики до решения по дальнейшему этапу
BПродолжать раскатку как запланировано, опираясь на улучшение целевой метрики и считая просадку страховочной временным шумом
CПеренести анализ страховочной метрики на финальный этап выкатки и принимать решение только по целевой метрике на текущем этапе
DУвеличить размер выборки на текущей доле трафика и продолжить наблюдение, ожидая что значение страховочной вернётся к норме
Ответ: Страховочные метрики работают как стоп‑сигнал в раскатке, чтобы не допустить массового ущерба.
Целевая метрика может расти даже при серьёзных проблемах со стабильностью или качеством, которые ударят по пользователям и бизнесу позже. Поэтому страховочные метрики задают заранее и трактуют как ограничения: пробили порог — остановились. Это позволяет безопасно откатить изменение и разобраться с причиной до расширения на всю аудиторию. Скрывать метрики или ждать «усреднения» — антипаттерны, которые приводят к накоплению ущерба.
Подробный разбор → 17Эксперимент завершён, эффект положительный, `SRM` (Sample Ratio Mismatch) нет, метрики стабильны. Какое решение по раскатке обычно считается наиболее практичным в проде?
AСделать раскатку через постепенное наращивание трафика с мониторингом страховочных метрик и готовым планом отката изменений
BСразу включить изменение на 100% трафика без мониторинга страховочных метрик и без готового плана отката после успешного теста
CСначала увеличить трафик до 100%, а страховочные метрики и план отката подключить позже, при появлении первых сигналов вреда
DПродолжать эксперимент на текущем трафике без изменения долей и считать это финальной формой раскатки фичи на аудиторию
Ответ: Даже после успешного теста раскатку лучше делать постепенно, с мониторингом страховочных метрик и планом отката.
Эксперимент обычно проходит на ограниченном трафике и в конкретных условиях, а при 100% могут проявиться проблемы масштаба или редкие баги. Поэтапное наращивание трафика снижает риск и даёт время наблюдать за страховочными метриками. Контрольный сегмент без изменений (удержанная группа) дополнительно помогает отслеживать долгосрочные эффекты и регрессии после выкатки. Резкая раскатка на 100% или бесконечный эксперимент игнорируют эти риски.
Подробный разбор → 18Эксперимент показал сильный рост метрики в выходные, но в будние дни эффект почти исчезает. Какой вывод и следующий шаг наиболее корректны?
AСчитать, что фича работает преимущественно по выходным, и выкатывать её на всю аудиторию без проверки устойчивости эффекта
BУчесть сезонность и возможный эффект новизны: дождаться полного цикла (например, недели) и проверить устойчивость по сегментам
CСчитать различие между будними и выходными признаком поломки метрики и полностью отказаться от анализа результатов эксперимента
DСчитать наблюдаемое различие следствием перекоса в распределении групп и переопределить дизайн теста после факта без проверок
Ответ: Краткосрочные всплески могут быть вызваны сезонностью или эффектом новизны, поэтому важно проверять эффект на полном цикле.
Поведение пользователей меняется по дням недели, праздникам и маркетинговым активностям, и это может выглядеть как эффект фичи. Также первый контакт с новинкой может дать временный рост, который не сохраняется. Поэтому корректнее собрать данные минимум на один полный цикл и проверить устойчивость эффекта по времени и сегментам перед решением о раскатке.
Подробный разбор → 19Вариант B показывает заметное падение числа покупок по событиям, но по базе транзакций покупок почти столько же, сколько в A. Что лучше всего сделать, чтобы подтвердить проблему инструментирования событий?
AСверить логи событий с таблицей транзакций как источником истины и проверить потери и дубликаты событий покупки
BПринять падение событий как реальное и зафиксировать просадку покупок только по дашборду событий без сверки с транзакциями
CПодобрать другую метрику успеха без расхождений между источниками и продолжить раскатку по альтернативной метрике без сверки
DСократить окно анализа до последних дней и пересчитать метрику только по свежим событиям, не сверяясь с базой транзакций
Ответ: Если события расходятся с источником истины, нужно делать сверку и искать потери и дубликаты в логах.
События могут теряться из-за сетевых ошибок, изменений схемы, условий отправки или багов клиента. Сверка с транзакциями помогает понять, что бизнес-действие было, а событие не записалось — или записалось дважды. После подтверждения расхождения корректнее чинить инструментирование событий, чем интерпретировать падение как поведение пользователей.
Подробный разбор → 20Вы запустили A/A тест и получили статистически значимую разницу по ключевой метрике. Что правильнее всего сделать перед запуском A/B?
AСразу запускать A/B: значимая разница в A/A доказывает, что система измерений работает корректно
BИгнорировать результат: значимость в A/A теста бывает почти всегда, она ничего не говорит о пайплайне
CОстановить и искать причину (рандомизация, логирование, сегментация), потому что пайплайн даёт ложные эффекты
DСменить целевую метрику на любую другую и продолжить запуск без проверок и дополнительных исправлений
Ответ: Значимый эффект в A/A тесте — красный флаг: пайплайн может создавать ложные эффекты.
В A/A тесте эффект должен быть близок к нулю, а значимость должна появляться редко и случайно — не чаще, чем уровень alpha. Стабильное или большое различие обычно означает проблему: разные аудитории в вариантах, потерю событий, дубли, неверные фильтры включения, ошибки логирования. Если не исправить это, A/B может показать «победителя» из-за бага, а не из-за продукта. Игнорировать или менять метрику без диагностики — путь к неверным решениям.
Подробный разбор →