Управление продуктами: важность мониторинга ключевых показателей эффективности (KPI)
Управление продуктами предполагает необходимость обеспечения их надлежащей работы и бесперебойной работы всех процессов. Обычно для оценки состояния продуктов мы полагаемся на показатели. На показатели могут влиять различные факторы: внутренние изменения, такие как обновления пользовательского интерфейса, корректировка цен или инциденты, а также внешние факторы, например, действия конкурентов или сезонные тенденции. Поэтому важно постоянно отслеживать ключевые показатели эффективности (KPI), чтобы быстро реагировать, когда что-то идёт не по плану. В противном случае может потребоваться несколько недель, чтобы понять, что продукт был полностью неработоспособен для 5% клиентов или что конверсия снизилась на 10 процентных пунктов после последнего релиза.
Создание информационных панелей
Чтобы получить наглядное представление, мы создаём информационные панели с ключевыми показателями. Но давайте будем честными: информационные панели, за которыми никто активно не следит, мало полезны. Нам нужны либо люди, постоянно отслеживающие десятки или даже сотни показателей, либо автоматизированная система оповещения и мониторинга. И я решительно предпочитаю второе.
В этой статье я расскажу вам о практическом подходе к созданию эффективной системы мониторинга ваших KPI. Вы узнаете о различных подходах к мониторингу, о том, как создать свою первую систему статистического мониторинга, и о проблемах, с которыми вы, вероятно, столкнётесь при её внедрении в производство.
Настройка мониторинга
Давайте начнём с общей картины того, как спроектировать вашу систему мониторинга, а затем углубимся в технические детали. При настройке мониторинга необходимо принять несколько ключевых решений:
- Чувствительность. Вам нужно найти баланс между пропуском важных аномалий (ложные отрицания) и получением ложных оповещений по 100 раз в день (ложные срабатывания).
- Размеры. Сегменты, которые вы выберете для мониторинга, также влияют на вашу чувствительность. Если проблема возникнет в небольшом сегменте (например, в определённом браузере или стране), ваша система с большей вероятностью обнаружит её, если вы будете отслеживать метрики этого сегмента напрямую. Но здесь есть загвоздка: чем больше сегментов вы отслеживаете, тем больше ложных срабатываний вы будете получать, поэтому вам нужно найти золотую середину.
- Временная детализация. Если у вас достаточно данных и вы не можете позволить себе задержек, возможно, стоит рассмотреть возможность просмотра данных поминутно. Если у вас недостаточно данных, вы можете объединить их в пакеты по 5–15 минут и отслеживать их вместо этого. В любом случае всегда полезно иметь более высокий уровень ежедневного, еженедельного или ежемесячного мониторинга наряду с мониторингом в реальном времени, чтобы отслеживать долгосрочные тенденции.
Процессы мониторинга
Мониторинг — это не только техническое решение. Это также касается процессов, которые у вас есть:
- Вам нужен человек, который будет отвечать за мониторинг и реагирование на оповещения. Раньше мы справлялись с этим с помощью ротации дежурных в моей команде, где каждую неделю один человек отвечал за просмотр всех оповещений.
- Помимо автоматического мониторинга, стоит также проводить ручные проверки. Вы можете настроить дисплеи в офисе или, по крайней мере, иметь процесс, при котором кто-то (например, дежурный) просматривает показатели раз в день или неделю.
- Вам необходимо установить обратную связь. Когда вы просматриваете оповещения и оглядываетесь на инциденты, которые могли пропустить, найдите время, чтобы настроить параметры вашей системы мониторинга.
- Ценность журнала изменений (записи обо всех изменениях, влияющих на ваши KPI) невозможно переоценить. Это помогает вам и вашей команде всегда иметь контекст о том, что произошло с вашими KPI и когда. Кроме того, это даёт вам ценный набор данных для оценки реального воздействия на вашу систему мониторинга при внесении изменений (например, выяснение того, какой процент прошлых аномалий ваша новая система действительно могла бы обнаружить).
Фреймворки для мониторинга
Существует множество готовых фреймворков, которые можно использовать для мониторинга. Я бы разделил их на две основные группы.
Первая группа включает в себя создание прогноза с доверительными интервалами. Вот некоторые варианты:
- Вы можете использовать statsmodels и классическую реализацию моделей ARIMA для прогнозирования временных рядов.
- Другой вариант, который обычно хорошо работает из коробки, — Prophet от VK. Это простая аддитивная модель, которая возвращает интервалы неопределённости.
- Существует также GluonTS, фреймворк для прогнозирования на основе глубокого обучения от AWS.
Вторая группа фокусируется на обнаружении аномалий, и вот несколько популярных библиотек:
- PyOD: самый популярный инструмент для обнаружения выбросов/аномалий на Python с более чем 50 алгоритмами (включая методы временных рядов и глубокого обучения).
- ADTK (Anomaly Detection Toolkit): создан для неконтролируемого/основанного на правилах обнаружения аномалий временных рядов с простой интеграцией в pandas dataframes.
- Merlion: сочетает прогнозирование и обнаружение аномалий для временных рядов, используя как классические, так и ML-подходы.
Статистический подход к мониторингу
Основная идея мониторинга проста: используйте исторические данные для построения доверительного интервала (CI) и обнаружения, когда текущие показатели выходят за рамки ожидаемого поведения. Мы оцениваем этот доверительный интервал, используя среднее значение и стандартное отклонение прошлых данных. Это базовая статистика.
Пример: мониторинг количества поездок на такси
Для проверки этого мы будем использовать популярный набор данных NYC Taxi Data. Я загрузил данные за май — июль 2025 года и сосредоточился на поездках, связанных с высокообъёмными автомобилями, работающими по найму. Поскольку у нас сотни поездок каждую минуту, мы можем использовать поминутные данные для мониторинга.
Построение первой версии
Итак, давайте попробуем наш подход и построим доверительные интервалы на основе реальных данных. Я начал с набора ключевых параметров по умолчанию:
- Временное окно ±15 минут вокруг текущей метки времени.
- Данные за текущий день плюс тот же день недели за предыдущие три недели.
- Доверительный интервал, определённый как ±3 стандартных отклонения.
Теперь давайте создадим пару функций с бизнес-логикой для расчёта доверительного интервала и проверки того, выходит ли наше значение за его пределы.
Анализ результатов
Давайте посмотрим на результаты. Сначала мы видим довольно много ложных положительных срабатываний (однократные точки за пределами CI, которые, по-видимому, обусловлены нормальной изменчивостью).
Существуют два способа настройки нашего алгоритма для учёта этого:
- Доверительный интервал не обязательно должен быть симметричным. Мы можем использовать более высокий коэффициент для верхней границы (например, использовать 5 вместо 3).
- Данные довольно волатильны, поэтому будут случайные аномалии, когда одна точка выходит за пределы доверительного интервала. Чтобы уменьшить количество ложных положительных оповещений, мы можем использовать более надёжную логику и запускать оповещение только тогда, когда несколько точек выходят за пределы CI (например, по крайней мере 4 из последних 5 точек или 8 из 10).
Однако существует ещё одна потенциальная проблема с нашими текущими CI. Как вы можете видеть, есть довольно много случаев, когда CI чрезмерно широк. Это выглядит не так, и может снизить чувствительность нашего мониторинга.
Улучшение точности
Итак, после первой итерации мы определили несколько потенциальных улучшений для нашего подхода к мониторингу:
- Используйте более высокий коэффициент для верхней границы, поскольку нас меньше беспокоят увеличения. Я использовал 6 стандартных отклонений вместо 3.
- Работайте с выбросами, чтобы отфильтровать прошлые аномалии. Я экспериментировал с удалением или ограничением верхних 10–20% выбросов и обнаружил, что ограничение на уровне 20% наряду с увеличением периода до 5 недель работало лучше всего на практике.
- Подавайте сигнал тревоги только тогда, когда 4 из последних 5 точек находятся за пределами CI, чтобы уменьшить количество ложных положительных оповещений, вызванных нормальной волатильностью.
Операционные проблемы
Мы обсудили математику, стоящую за системами оповещения и мониторинга. Однако есть несколько других нюансов, с которыми вы, вероятно, столкнётесь, как только начнёте развёртывать свою систему в производственной среде. Поэтому я хотел бы рассмотреть их, прежде чем заканчивать.
Отстающие данные. Мы не сталкиваемся с этой проблемой в нашем примере, поскольку работаем с историческими данными, но в реальной жизни вам придётся иметь дело с задержками данных. Обычно требуется некоторое время, чтобы данные достигли вашего хранилища данных. Поэтому вам нужно научиться различать случаи, когда данные ещё не поступили, и фактические инциденты, влияющие на качество обслуживания клиентов. Самый простой подход — посмотреть на исторические данные, определить типичный лаг и отфильтровать последние 5–10 точек данных.
Различная чувствительность для разных сегментов. Вы, скорее всего, захотите отслеживать не только основной KPI (количество поездок), но и разбивать его по нескольким сегментам (например, партнёры, районы и т. д.). Добавление большего количества сегментов всегда полезно, поскольку помогает вам обнаружить более мелкие изменения в определённых сегментах (например, что в Манхэттене возникла проблема). Однако, как я упоминал выше, есть обратная сторона: больше сегментов означает больше ложных положительных оповещений, с которыми вам нужно будет иметь дело. Чтобы держать это под контролем, вы можете использовать разные уровни чувствительности для разных сегментов (скажем, 3 стандартных отклонения для основного KPI и 5 для сегментов).
Более умная система оповещения. Кроме того, когда вы отслеживаете множество сегментов, стоит сделать вашу систему оповещения немного умнее. Представьте, что у вас есть мониторинг основного KPI и 99 сегментов. Теперь представьте, что у вас глобальный сбой, и количество поездок падает везде. В течение следующих 5 минут вы (надеюсь) получите 100 уведомлений о том, что что-то сломалось. Это не идеальный опыт. Чтобы избежать такой ситуации, я бы построил логику для фильтрации ненужных уведомлений. Например:
- Если мы получили одно и то же уведомление в течение последних 3 часов, не запускайте другое оповещение.
- Если есть уведомление о падении основного KPI плюс более чем в трёх сегментах, оповещать только об изменении основного KPI.
В целом, усталость от оповещений — это реальность, поэтому стоит минимизировать шум.
Резюме
Мы рассмотрели множество аспектов оповещения и мониторинга. Позвольте мне подвести итог пошаговым руководством по началу мониторинга ваших KPI.
- Первый шаг — собрать журнал изменений прошлых аномалий. Вы можете использовать его как набор тестовых случаев для вашей системы и для фильтрации аномальных периодов при расчёте CI.
- Далее создайте прототип и запустите его на исторических данных. Я бы начал с самого высокого уровня KPI, опробовал несколько возможных конфигураций и посмотрел, насколько хорошо он ловит предыдущие аномалии и генерирует ли много ложных оповещений. На этом этапе у вас должно быть жизнеспособное решение.
- Затем попробуйте его в производстве, поскольку именно здесь вам придётся иметь дело с задержками данных и увидеть, как мониторинг на самом деле работает на практике. Запустите его на 2–4 недели и настройте параметры, чтобы убедиться, что всё работает должным образом.
- После этого поделитесь мониторингом с коллегами и начните расширять его охват, включив в него другие сегменты. Не забывайте постоянно добавлять все аномалии в журнал изменений и устанавливать обратную связь для постоянного улучшения вашей системы.