Sanity-check и оценка: вопросы для собеседования (часть 4)
Оценка порядка величины, проверка результатов на здравый смысл, Fermi-задачи — навыки, которые защищают от ошибок на порядки. На собеседовании могут спросить: «сколько данных генерирует Яндекс.Метрика за день?» или попросить проверить, правдоподобен ли результат запроса. Аналитик, который не делает sanity check, рискует принять решение на основе бага.
Вопросы 16–20 из 20
16Известно, что в продукте 5 миллионов сессий в день, но нет данных, сколько событий в среднем приходится на одну сессию. Какой подход к грубой оценке числа событий в день наиболее адекватен?
AВзять одно событие на сессию по умолчанию и зафиксировать это число как точную оценку, не уточняя реальное распределение событий
BПостроить границы: задать разумную нижнюю и верхнюю оценку числа событий на сессию и получить диапазон оценки числа событий в день
CВзять медианное число событий на сессию по соседнему продукту с похожим профилем и применить его к нашим 5 миллионам сессий
DИспользовать число событий на пользователя из публичных бенчмарков и умножить его на месячную аудиторию для пересчёта в день
Ответ: Когда данных нет, полезно строить диапазон через нижнюю и верхнюю границы, а не одну точку.
В грубой оценке можно взять минимально возможное число событий на сессию как нижнюю границу и реалистичный максимум как верхнюю границу. Тогда вы получите диапазон, который легко сравнить с ограничениями системы и прошлым опытом. Подход «один к одному» произвольно занижает оценку, а умножение сессий на `MAU` бессмысленно: единицы не складываются. Если позже появятся данные, диапазон сузится — это и есть рабочая модель оценки на ходу.
Подробный разбор → 17Коллега утверждает, что ежедневный объём выгрузки равен 5 ПБ. При этом вы знаете: 100 миллионов записей в день, средний размер записи около 200 байт. Какой вывод проверки порядка величины наиболее верен?
A5 ПБ согласуется с 100 миллионами строк в день, объём событий действительно выходит на петабайтный уровень
BРеалистичная оценка около 5 ТБ: видимо, в отчёте перепутали букву обозначения единицы измерения
CРеалистичная оценка около 500 ГБ: 200 байт на запись близко к одному килобайту на каждое событие
DРеалистичная оценка порядка 20 ГБ: значение 5 ПБ расходится с прикидкой на 5 порядков
Ответ: Сравнение с порядком величины быстро выявляет перепутанные единицы вроде байт и КБ/МБ/ГБ при подсчёте объёмов.
100 миллионов × 200 байт ≈ 20 миллиардов байт, то есть порядка 20 ГБ, а вовсе не петабайты. Разница в сотни тысяч раз почти всегда означает ошибку в единицах или появление лишних множителей в расчёте. Такая грубая прикидка нужна, чтобы не обсуждать инфраструктуру на неверных входных значениях. После выявления расхождения стоит уточнить, что именно считается записью и где мог появиться неверный коэффициент.
Подробный разбор → 18Система пишет 1 `TB` логов в день. По предположениям, размер одного события — от 200 до 500 байт. Какой диапазон количества событий в день наиболее разумен по порядку величины?
AОт 2 до 5 миллионов событий в день, если исходить из заданного объёма логов и среднего размера одного события
BОт 20 до 50 миллионов событий в день при заданных границах размера события и суммарном объёме логов в сутки
CОт 2 до 5 миллиардов событий в день, исходя из заданного диапазона размеров события и общего объёма логов
DОт 200 до 500 миллиардов событий в день при указанных предположениях о размере события и объёме данных
Ответ: Используйте нижнюю и верхнюю границы размера одного объекта, чтобы получить границы для общего количества объектов.
Если логов 1 `TB` в день, то при 500 байтах на событие получится около 2 миллиардов событий, а при 200 байтах — около 5 миллиардов. Это грубая прикидка, но она даёт правильный порядок величины. Такой диапазон помогает проверить, не ошиблись ли вы в единицах измерения или в оценке размера события. Затем можно уточнять средний размер и сжатие.
Подробный разбор → 19Вам нужно прикинуть, сколько места займут новые события, но неизвестны точные значения: сколько событий на пользователя в день и сколько байт в одном событии. Какой подход к оценке наиболее правильный?
AВзять одно правдоподобное число для обеих величин и считать его точной оценкой, чтобы быстрее принять решение и не задерживать команду
BВзять оптимистичный сценарий по обеим величинам, чтобы заложить минимальный требуемый объём хранилища и не переплатить за резерв
CРазложить на единицы измерения и построить нижнюю и верхнюю границы по частоте и размеру событий, фиксируя допущения и ограничения
DВзять данные другого продукта со схожим профилем как точную оценку для частоты и размера событий и перенести числа на наш случай
Ответ: Когда данных не хватает, лучше строить нижнюю и верхнюю границы и постепенно уточнять допущения по мере поступления фактов.
Начните с разложения на единицы измерения: пользователи в день, события на пользователя, байт на событие. Затем задайте консервативные допущения и получите нижнюю и верхнюю границы для итогового объёма. Такая грубая прикидка помогает принимать решения под неопределённость и быстро ловить несоответствия с ограничениями. Варианты «не оценивать» и «брать одно число» игнорируют неопределённость, а «только оптимистичный сценарий» систематически занижает риски.
Подробный разбор → 20У вас 1 млн сессий в день. Максимально реалистичный рост конверсии от фичи вы оцениваете как +1 процентный пункт, а маржа с одной покупки — 100 ₽. Какую верхнюю оценку дополнительной маржи в день даст грубая прикидка?
AОколо 10 тыс ₽ в день
BОколо 100 тыс ₽ в день
CОколо 10 млн ₽ в день
DОколо 1 млн ₽ в день
Ответ: Верхняя оценка по грубой прикидке помогает быстро понять максимум эффекта по ограничениям ещё до точного эксперимента.
Верхняя оценка дополнительной маржи: 1 млн сессий × 0.01 (рост конверсии +1 п.п.) × 100 ₽ маржи = 1 млн ₽ в день. Это и есть потолок эффекта при заявленных предположениях. Около 10 млн ₽ соответствовали бы росту +10 п.п. — нереалистично много для одной фичи. Около 100 тыс ₽ — занижение примерно в 10 раз (рост +0.1 п.п. вместо +1). Около 10 тыс ₽ — занижение ещё на порядок и физически не сходится с входными данными.
Подробный разбор →