Пошаговое руководство по обнаружению реальных аномалий без ложных срабатываний
Делиться
При разработке и управлении продуктами крайне важно обеспечить их ожидаемую производительность и бесперебойную работу. Обычно мы полагаемся на метрики для оценки состояния наших продуктов. На наши ключевые показатели эффективности (KPI) может влиять множество факторов: от внутренних изменений, таких как обновления пользовательского интерфейса, корректировки цен или инциденты, до внешних факторов, таких как действия конкурентов или сезонные тенденции. Именно поэтому важно постоянно отслеживать KPI, чтобы иметь возможность быстро реагировать на любые отклонения. В противном случае может пройти несколько недель, прежде чем выяснится, что ваш продукт полностью сломался у 5% клиентов или что конверсия упала на 10 процентных пунктов после последнего релиза.
Чтобы добиться такой прозрачности, мы создаём информационные панели с ключевыми метриками. Но, честно говоря, информационные панели, которые никто активно не отслеживает, малоэффективны. Нам нужны либо люди, постоянно отслеживающие десятки, а то и сотни метрик, либо автоматизированная система оповещений и мониторинга. Я решительно предпочитаю последний вариант. Поэтому в этой статье я расскажу вам о практическом подходе к созданию эффективной системы мониторинга ключевых показателей эффективности (KPI). Вы узнаете о различных подходах к мониторингу, о том, как создать свою первую систему статистического мониторинга и с какими трудностями вы, вероятно, столкнётесь при её внедрении в эксплуатацию.
Настройка мониторинга
Давайте начнём с общей картины построения вашей системы мониторинга, а затем перейдём к техническим деталям. При настройке мониторинга необходимо принять несколько ключевых решений:
- Чувствительность . Вам необходимо найти правильный баланс между пропуском важных аномалий (ложноотрицательными срабатываниями) и непрерывным потоком ложных срабатываний по 100 раз в день (ложноположительными срабатываниями). Мы обсудим, какие рычаги помогут вам это изменить, позже.
- Параметры. Сегменты, которые вы выбираете для мониторинга, также влияют на вашу чувствительность. Если проблема возникает в небольшом сегменте (например, в конкретном браузере или стране), ваша система с гораздо большей вероятностью обнаружит её, если вы отслеживаете показатели этого сегмента напрямую. Но в этом есть подвох: чем больше сегментов вы отслеживаете, тем больше ложных срабатываний вы получите, поэтому вам нужно найти золотую середину.
- Детализация по времени. Если у вас много данных и вы не можете позволить себе задержки, возможно, стоит обратить внимание на поминутные данные. Если данных недостаточно, вы можете объединить их в 5–15-минутные сегменты и отслеживать их. В любом случае, всегда полезно проводить более детальный ежедневный, еженедельный или ежемесячный мониторинг в дополнение к мониторингу в режиме реального времени, чтобы отслеживать долгосрочные тенденции.
Однако мониторинг — это не только техническое решение. Он также касается используемых вами процессов:
- Вам нужен человек, ответственный за мониторинг оповещений и реагирование на них. Раньше в моей команде это решалось с помощью дежурств: каждую неделю один сотрудник отвечал за проверку всех оповещений.
- Помимо автоматического мониторинга, стоит проводить и ручные проверки. Можно установить телевизионные экраны в офисе или, по крайней мере, организовать процесс, когда кто-то (например, дежурный) будет проверять показатели раз в день или неделю.
- Вам необходимо наладить обратную связь. Просматривая оповещения и анализируя инциденты, которые вы могли пропустить, уделите время тонкой настройке параметров системы мониторинга.
- Ценность журнала изменений (записи всех изменений, влияющих на ваши ключевые показатели эффективности) невозможно переоценить. Он помогает вам и вашей команде всегда иметь представление о том, что и когда произошло с вашими ключевыми показателями эффективности. Кроме того, он предоставляет ценный набор данных для оценки реального влияния изменений на вашу систему мониторинга (например, для определения того, какой процент прошлых отклонений ваша новая система действительно отследит).
Теперь, когда мы рассмотрели общую картину, давайте перейдем к техническим деталям того, как на самом деле обнаруживать аномалии в данных временных рядов.
Рамки для мониторинга
Существует множество готовых фреймворков для мониторинга. Я бы разделил их на две основные группы.
Первая группа предполагает создание прогноза с доверительными интервалами. Вот несколько вариантов:
- Вы можете использовать statsmodels и классическая реализация моделей типа ARIMA для прогнозирования временных рядов.
- Другой вариант, который обычно работает довольно хорошо «из коробки», — это Prophet от Meta. Это простая аддитивная модель, возвращающая интервалы неопределённости.
- Существует также GluonTS — фреймворк прогнозирования на основе глубокого обучения от AWS.
Вторая группа фокусируется на обнаружении аномалий, и вот некоторые популярные библиотеки:
- PyOD : самый популярный набор инструментов Python для обнаружения выбросов и аномалий с более чем 50 алгоритмами (включая временные ряды и методы глубокого обучения).
- ADTK (Anomaly Detection Toolkit) : создан для неконтролируемого/основанного на правилах обнаружения аномалий временных рядов с простой интеграцией в кадры данных Pandas.
- Merlion : объединяет прогнозирование и обнаружение аномалий во временных рядах, используя как классический подход, так и подход машинного обучения.
Я упомянул лишь несколько примеров; существует гораздо больше библиотек. Вы можете, конечно же, опробовать их на своих данных и посмотреть, как они работают. Однако я хочу поделиться гораздо более простым подходом к мониторингу, с которого я обычно начинаю. Несмотря на то, что он настолько прост, что его можно реализовать одним SQL-запросом, во многих случаях он работает на удивление хорошо. Ещё одно существенное преимущество этой простоты заключается в том, что его можно реализовать практически в любом инструменте, в то время как внедрение более сложных подходов машинного обучения может быть затруднительным в некоторых системах.
Статистический подход к мониторингу
Основная идея мониторинга проста: использовать исторические данные для построения доверительного интервала (ДИ) и выявления случаев, когда текущие показатели выходят за рамки ожидаемого поведения. Мы оцениваем этот доверительный интервал, используя среднее значение и стандартное отклонение прошлых данных. Это всего лишь базовая статистика.
[
textbf{Доверительный интервал} = (textbf{mean} – textsf{coef}_1 times textbf{std},; textbf{mean} + textsf{coef}_2 times textbf{std})
]
Однако эффективность этого подхода зависит от нескольких ключевых параметров, и сделанный вами выбор существенно повлияет на точность ваших оповещений.
Первое, что нужно решить, — это как определить выборку данных, используемую для расчёта статистики. Обычно мы сравниваем текущую метрику с аналогичным периодом за предыдущие дни. Это включает два основных компонента:
- Временное окно: обычно я беру окно в пределах ±10–30 минут вокруг текущей временной метки, чтобы учесть краткосрочные колебания.
- Исторические данные по дням: я предпочитаю использовать один и тот же день недели за последние 3–5 недель. Этот метод учитывает недельную сезонность, которая обычно присутствует в бизнес-данных. Однако в зависимости от особенностей вашей сезонности вы можете выбрать другие подходы (например, разделив дни на две группы: будни и выходные).
Другим важным параметром является выбор коэффициента, используемого для определения ширины доверительного интервала. Обычно я использую три стандартных отклонения, поскольку это охватывает 99,7% наблюдений для распределений, близких к нормальному.
Как видите, нужно принять несколько решений, и универсального ответа не существует. Самый надёжный способ определить оптимальные настройки — поэкспериментировать с различными конфигурациями, используя собственные данные, и выбрать ту, которая обеспечит наилучшую производительность в вашем конкретном случае. Поэтому сейчас самое время опробовать этот подход на практике и посмотреть, как он работает на реальных данных.
Пример: мониторинг количества поездок на такси
Для проверки мы воспользуемся популярным набором данных NYC Taxi Data (открытые данные). Я загрузил данные с мая по июль 2025 года, сосредоточившись на поездках, связанных с арендой автомобилей с большим количеством пассажиров. Поскольку каждую минуту у нас совершаются сотни поездок, мы можем использовать поминутные данные для мониторинга.
Создание первой версии
Итак, давайте попробуем наш подход и построим доверительные интервалы на основе реальных данных. Я начал с набора ключевых параметров по умолчанию:
- Временное окно ±15 минут вокруг текущей временной метки,
- Данные за текущий день плюс данные за тот же день недели за предыдущие три недели,
- Доверительный интервал определяется как ±3 стандартных отклонения.
Теперь давайте создадим пару функций с бизнес-логикой для расчета доверительного интервала и проверки, выходит ли наше значение за его пределы.
# возвращает набор исторических данных def get_distribution_for_ci(param, ts, n_weeks=3, n_mins=15): tmp_df = df[['pickup_datetime', param]].rename(columns={param: 'value', 'pickup_datetime': 'dt'}) tmp = [] for n in range(n_weeks + 1): lower_bound = (pd.to_datetime(ts) — pd.Timedelta(weeks=n, minutes=n_mins)).strftime('%Y-%m-%d %H:%M:%S') upper_bound = (pd.to_datetime(ts) — pd.Timedelta(weeks=n, minutes=-n_mins)).strftime('%Y-%m-%d %H:%M:%S') tmp.append(tmp_df[(tmp_df.dt >= lower_bound) & (tmp_df.dt <= upper_bound)]) base_df = pd.concat(tmp) base_df = base_df[base_df.dt < ts] return base_df # вычисляет среднее значение и стандартное отклонение, необходимые для вычисления доверительных интервалов def get_ci_statistics(param, ts, n_weeks=3, n_mins=15): base_df = get_distribution_for_ci(param, ts, n_weeks, n_mins) std = base_df.value.std() mean = base_df.value.mean() return mean, std # перебор всех временных меток в исторических данных ci_tmp = [] for ts in tqdm.tqdm(df.pickup_datetime): ci = get_ci_statistics('values', ts, n_weeks=3, n_mins=15) ci_tmp.append( { 'pickup_datetime': ts, 'mean': ci[0], 'std': ci[1], } ) ci_df = df[['pickup_datetime', 'values']].copy() ci_df = ci_df.merge(pd.DataFrame(ci_tmp), how='left', on='pickup_datetime') # определение CI ci_df['ci_lower'] = ci_df['mean'] - 3 * ci_df['std'] ci_df['ci_upper'] = ci_df['mean'] + 3 * ci_df['std'] # определение, находится ли значение за пределами CI ci_df['outside_of_ci'] = (ci_df['values'] < ci_df['ci_lower']) | (ci_df['values'] > ci_df['ci_upper'])
Анализ результатов
Давайте посмотрим на результаты. Во-первых, мы наблюдаем довольно много ложноположительных триггеров (единичных точек за пределами CI, которые, по-видимому, обусловлены нормальной изменчивостью).
Чтобы учесть это, мы можем скорректировать наш алгоритм двумя способами:
- Индекс CI не обязательно должен быть симметричным. Если нас меньше беспокоит увеличение количества поездок, можно использовать более высокий коэффициент для верхней границы (например, 5 вместо 3).
- Данные весьма изменчивы, поэтому иногда будут возникать аномалии, когда одна точка выходит за пределы доверительного интервала. Чтобы уменьшить количество ложных срабатываний, можно использовать более надёжную логику и активировать оповещение только в том случае, если несколько точек выходят за пределы доверительного интервала (например, как минимум 4 из последних 5 точек или 8 из 10).
Однако есть ещё одна потенциальная проблема с нашими текущими CI. Как видите, во многих случаях CI слишком широк. Это выглядит неестественно и может снизить чувствительность нашего мониторинга.
Давайте рассмотрим один пример, чтобы понять, почему это происходит. Распределение, которое мы используем для оценки доверительного интервала (CI) на данном этапе, бимодальное, что приводит к более высокому стандартному отклонению и более широкому доверительному интервалу. Это связано с тем, что количество поездок вечером 14 июля значительно выше, чем в другие недели.
Итак, в прошлом мы столкнулись с аномалией, которая влияет на наши доверительные интервалы. Есть два способа решения этой проблемы:
- Если мы ведем постоянный мониторинг, мы знаем, что 14 июля был аномально высокий спрос, и можем исключить эти периоды при построении наших CI. Этот подход требует определённой дисциплины для отслеживания этих аномалий, но он окупается более точными результатами.
- Однако всегда есть и более быстрый и неэффективный подход: мы можем просто отбросить или ограничить выбросы при построении CI.
Повышение точности
Итак, после первой итерации мы выявили несколько потенциальных улучшений нашего подхода к мониторингу:
- Используйте более высокий коэффициент для верхней границы , поскольку нас меньше волнует рост. Я использовал 6 стандартных отклонений вместо 3.
- Работа с выбросами для отфильтровывания прошлых аномалий. Я экспериментировал с удалением или ограничением 10–20% пиковых значений и обнаружил, что ограничение на уровне 20% в сочетании с увеличением периода до 5 недель работает на практике лучше всего.
- Выдавайте оповещение только в том случае, если 4 из последних 5 точек находятся за пределами доверительного интервала, чтобы сократить количество ложных срабатываний, вызванных нормальной волатильностью.
Давайте посмотрим, как это выглядит в коде. Мы обновили логику в get_ci_statistics, чтобы учесть различные стратегии обработки выбросов.
def get_ci_statistics(param, ts, n_weeks=3, n_mins=15, show_vis = False, filter_outliers_strategy = 'none', filter_outliers_perc = None): assert filter_outliers_strategy in ['none', 'clip', 'remove'], «filter_outliers_strategy должен быть одним из 'none', 'clip', 'remove'» base_df = get_distribution_for_ci(param, ts, n_weeks, n_mins, show_vis) if filter_outliers_strategy != 'none': p_upper = base_df.value.quantile(1 — filter_outliers_perc) p_lower = base_df.value.quantile(filter_outliers_perc) if filter_outliers_strategy == 'clip': base_df['value'] = base_df['value'].clip(lower=p_lower, upper=p_upper) если filter_outliers_strategy == 'remove': base_df = base_df[(base_df.value >= p_lower) & (base_df.value <= p_upper)] std = base_df.value.std() среднее = base_df.value.mean() вернуть среднее, std
Нам также необходимо обновить способ определения параметра outside_of_ci.
для ts в tqdm.tqdm(ci_df.pickup_datetime): tmp_df = ci_df[(ci_df.pickup_datetime <= ts)].tail(5).copy() tmp_df = tmp_df[~tmp_df.ci_lower.isna() & ~tmp_df.ci_upper.isna()] если tmp_df.shape[0] < 5: продолжить tmp_df['outside_of_ci'] = (tmp_df['values'] < tmp_df['ci_lower']) | (tmp_df['values'] > tmp_df['ci_upper']) если tmp_df.outside_of_ci.map(int).sum() >= 4: аномалии.append(ts) ci_df['outside_of_ci'] = ci_df.pickup_datetime.isin(anomalies)
Мы видим, что CI теперь значительно уже (больше нет аномально широких CI), и мы также получаем гораздо меньше оповещений, поскольку увеличили коэффициент верхней границы.
Давайте рассмотрим два найденных нами оповещения. Эти два оповещения за последние две недели выглядят правдоподобными, если сравнить трафик с предыдущими неделями.
Практический совет: эта диаграмма также напоминает нам, что в идеале мы должны учитывать государственные праздники и либо исключать их, либо рассматривать как выходные при расчете CI.
Итак, наш новый подход к мониторингу абсолютно логичен. Однако есть и недостаток: отслеживая только те случаи, когда 4 из 5 минут выходят за пределы CI, мы задерживаем оповещения в ситуациях, когда всё полностью сломано. Для решения этой проблемы можно использовать два CI:
- Doomsday CI : широкий доверительный интервал, выход за пределы которого даже одной точки означает, что пора паниковать.
- Инцидент CI : тот, который мы создали ранее, где мы могли бы подождать 5–10 минут, прежде чем активировать оповещение, поскольку падение показателя не столь критично.
Давайте определим 2 CI для нашего случая.
Это сбалансированный подход, который даёт нам преимущество обоих подходов: мы можем быстро реагировать на серьёзные поломки, при этом контролируя ложные срабатывания. Благодаря этому мы добились хорошего результата и готовы двигаться дальше.
Тестирование нашего мониторинга на аномалии
Мы подтвердили, что наш подход хорошо работает в обычных условиях. Однако стоит также провести стресс-тестирование, смоделировав аномалии, которые мы хотим обнаружить, и проверив работу системы мониторинга. На практике стоит протестировать её на ранее известных аномалиях, чтобы понять, как система справится с реальными примерами.
В нашем случае у нас нет журнала изменений предыдущих аномалий, поэтому я смоделировал падение количества поездок на 20%, и наш подход сразу же это выявил.
Подобные ступенчатые изменения могут быть сложными в реальной жизни. Представьте, что мы потеряли одного из партнёров, и этот более низкий уровень становится новым нормальным для метрики. В этом случае стоит также скорректировать наш мониторинг. Если возможно пересчитать историческую метрику на основе текущего состояния (например, отфильтровав потерянного партнёра), это было бы идеально, поскольку это вернёт мониторинг в нормальное состояние. Если это невозможно, мы можем либо скорректировать исторические данные (например, вычесть 20% трафика в качестве оценки изменения), либо удалить все данные до изменения и использовать только новые данные для построения CI.
Давайте рассмотрим ещё один сложный пример из реальной жизни: постепенное снижение. Если ваша метрика медленно падает день за днём, наш мониторинг в режиме реального времени, скорее всего, не отследит это, поскольку CI будет меняться вместе с ней. Чтобы отслеживать подобные ситуации, стоит использовать менее детальный мониторинг (например, ежедневный, еженедельный или даже ежемесячный).
Полный код вы можете найти на GitHub.
Эксплуатационные проблемы
Мы обсудили математические основы систем оповещения и мониторинга. Однако есть ещё несколько нюансов, с которыми вы, вероятно, столкнётесь, когда начнёте развёртывать систему в рабочей среде. Поэтому я хотел бы остановиться на них, прежде чем закончить.
Запаздывание данных. В нашем примере мы не сталкиваемся с этой проблемой, поскольку работаем с историческими данными, но в реальной жизни приходится иметь дело с задержками данных. Обычно данные попадают в хранилище данных с задержкой. Поэтому вам нужно научиться отличать случаи, когда данные ещё не поступили, от реальных инцидентов, влияющих на качество обслуживания клиентов. Самый простой подход — изучить исторические данные, определить типичное запаздывание и отфильтровать последние 5–10 точек данных.
Разная чувствительность для разных сегментов. Скорее всего, вам потребуется отслеживать не только основной KPI (количество поездок), но и разбивать его по нескольким сегментам (например, по партнёрам, регионам и т. д.). Добавление большего количества сегментов всегда полезно, поскольку помогает выявлять даже небольшие изменения в отдельных сегментах (например, наличие проблем в Манхэттене). Однако, как я уже упоминал выше, есть и недостаток: большее количество сегментов означает больше ложных срабатываний, с которыми нужно разбираться. Чтобы контролировать этот процесс, можно использовать разные уровни чувствительности для разных сегментов (например, 3 стандартного отклонения для основного KPI и 5 для сегментов).
Более интеллектуальная система оповещений. Кроме того, если вы отслеживаете множество сегментов, стоит сделать оповещения немного более интеллектуальными. Допустим, вы отслеживаете основной KPI и 99 сегментов. Теперь представьте, что произошел глобальный сбой, и количество поездок резко упало. В течение следующих 5 минут вы (надеюсь) получите 100 уведомлений о какой-то поломке. Это не идеальный вариант. Чтобы избежать такой ситуации, я бы разработал логику для фильтрации лишних уведомлений. Например:
- Если мы получили такое же уведомление в течение последних 3 часов, не запускайте еще одно оповещение.
- Если получено уведомление о падении основного KPI и более 3 сегментов, оповещать только об изменении основного KPI.
В целом, усталость от бодрствования реальна, поэтому стоит минимизировать шум.
Вот и всё! Мы рассмотрели всю тему оповещений и мониторинга, и, надеемся, теперь вы полностью готовы к настройке собственной системы.
Краткое содержание
Мы подробно рассмотрели вопросы оповещения и мониторинга. Позвольте мне завершить это пошаговым руководством по началу мониторинга ключевых показателей эффективности (KPI).
- Первый шаг — собрать журнал изменений прошлых аномалий. Вы можете использовать его как набор тестовых случаев для своей системы, так и для фильтрации аномальных периодов при расчёте CI.
- Затем создайте прототип и протестируйте его на исторических данных. Я бы начал с KPI самого высокого уровня, попробовал несколько возможных конфигураций и посмотрел, насколько хорошо он выявляет предыдущие отклонения и генерирует ли много ложных срабатываний. К этому моменту у вас должно быть жизнеспособное решение.
- Затем протестируйте его в рабочей среде, поскольку именно здесь вам придётся иметь дело с задержками данных и посмотреть, как мониторинг работает на практике. Запустите его на 2–4 недели и настройте параметры, чтобы убедиться, что всё работает как надо.
- После этого поделитесь результатами мониторинга с коллегами и начните расширять область охвата , включая другие сегменты. Не забывайте добавлять все аномалии в журнал изменений и наладить обратную связь для постоянного улучшения вашей системы.
Вот и всё! Теперь вы можете быть спокойны, зная, что автоматизация следит за вашими ключевыми показателями эффективности (но всё равно проверяйте их время от времени, на всякий случай).
Спасибо за прочтение. Надеюсь, эта статья была познавательной. Помните совет Эйнштейна: «Главное — не переставать задавать вопросы. Любопытство имеет свою причину». Пусть ваше любопытство приведёт вас к следующему великому озарению.
Источник: towardsdatascience.com
