Настройка оповещений для различных метрик не всегда представляет из себя тривиальную задачу. В некоторых случаях может быть вполне достаточно простого порогового значения, например, для отслеживания свободного места на диске устройства. Вы можете просто установить оповещение о том, что осталось 10% свободного места, и все готово. То же самое касается и мониторинга доступной памяти на сервере.
Однако что делать, если необходимо отслеживать поведение пользователей на веб‑сайте? Представьте, что вы управляете интернет‑магазином, где продаете товары. Одним из подходов может быть установка минимального порога для ежедневных продаж и проверка его раз в день. Но что, если вам нужно выявить проблему гораздо раньше, в течение нескольких часов или даже минут? Статичный порог не позволит этого сделать, так как активность пользователей может меняться в течение дня. Именно здесь на помощь приходит обнаружение аномалий.
Что такое обнаружение аномалий? В отличие от использования простых правил, этот процесс основан на анализе исторических данных для выявления необычных паттернов. Существует множество способов реализации обнаружения аномалий, включая машинное обучение и статистический анализ. В этой статье мы сосредоточимся на статистическом подходе и расскажем о том, как мы создали собственную систему обнаружения аномалий для данных временных рядов в Booking.
Наивный подход
Одна из распространенных ошибок, с которой я сталкивался в различных командах и компаниях, заключается в попытке обнаружить аномалии, просто сравнивая бизнес‑показатели с их значениями неделю назад.
На первый взгляд, этот подход не кажется совсем бесполезным — он может помочь выявить некоторые аномалии, как показано на рисунке выше. Однако можно ли считать его надежным долгосрочным решением? Нет, не совсем. Основной его недостаток заключается в том, что сегодняшняя аномалия становится нормой для следующей недели. Это значит, что если та же проблема возникнет снова в то же время на следующей неделе, она может остаться незамеченной, поскольку мы сравниваем с некорректным контрольным показателем.
Это очевидно неправильно, поскольку наш упрощенный подход не учитывает, что данные за предыдущую неделю могли быть скомпрометированы. Еще одним ограничением этого метода является то, что он учитывает только одну неделю за раз. Но что, если показатели постепенно снижаются на протяжении нескольких недель? Такая медленно развивающаяся проблема, скорее всего, ускользнет от нашего внимания.
Статистика
В этот момент я задумался: насколько сложно было бы создать систему обнаружения аномалий с нуля? Я знал, что для этого существует множество решений на основе машинного обучения, но может ли простой статистический подход справиться с этой задачей? И что более важно — будет ли он достаточно хорош? Давайте вместе разберемся в этом вопросе.
Прежде всего, давайте рассмотрим одну из фундаментальных статистических мер — стандартное (или среднеквадратическое) отклонение.
Вероятно, вам уже знакома эта колоколообразная (гауссова) кривая, но как именно она и стандартное отклонение могут помочь нам в нашем исследовании? Основная идея заключается в измерении флуктуаций в данных временных рядов.
Например, если мы возьмем небольшой временной интервал, скажем, последние 20 минут, и сравним его с историческими данными за последние четыре недели в одно и то же время суток, мы можем наблюдать нечто подобное:
Как видите, эти метрики обладают высокой волатильностью. Чтобы выразить это количественно, мы можем рассчитать стандартное отклонение по данному периоду. Для наглядности давайте визуализируем данные, построив график, который покажет среднее значение и одну сигму (стандартное отклонение) выше и ниже него.
Если мы уменьшим масштаб и рассчитаем стандартное отклонение за более длительный период, то сможем увидеть более широкие паттерны вариации метрики.
Имея среднее значение и стандартное отклонение, мы можем построить z‑оценку — мощный статистический инструмент, который поможет нам выявлять выбросы (outliers) и аномалии в данных.
Что такое z-оценка?
Из Википедии:
Стандартизированная оценка (z‑оценка, англ.: Standard score, z‑score) — это мера относительного разброса наблюдаемого или измеренного значения, которая показывает, сколько стандартных отклонений составляет его разброс относительного среднего значения. Это безразмерный статистический показатель, используемый для сравнения значений разной размерности или шкалой измерений.
Формула для расчета z‑оценки выглядит следующим образом:
Проще говоря, z‑оценка измеряет, насколько далеко конкретное значение находится от среднего значения. Это может быть чрезвычайно полезно для нас, поскольку предоставляет простой способ обнаружения аномалий или выбросов в данных временных рядов. Это был наш первый подход к обнаружению аномалий, и вот как он работал.
Представьте, что мы хотим создать систему обнаружения аномалий для следующего показателя:
На первый взгляд сложно сказать, является ли снижение в конце недели аномальным или это нормальное поведение. Но давайте отобразим тот же показатель за предыдущие недели на том же графике:
Теперь гораздо более очевидно, что что‑то не так. Как же нам использовать эту информацию для настройки оповещения? Вот где в игру вступает z‑оценка. Первым шагом является вычисление среднего значения. Обычно мы делаем это для определенного периода времени, но для простоты давайте рассчитаем среднее значение для всего набора данных, исключая текущую неделю:
Затем мы вычисляем стандартное отклонение:
После того как мы определили среднее значение и стандартное отклонение на основе исторических данных, мы можем рассчитать z‑оценку для каждого значения этого показателя:
Вы заметили закономерность? Все «аномальные» значения имеют z‑оценку ниже -3. Это значение можно использовать для установки порогов оповещений. Чтобы лучше понять, что означают z‑оценки, мы можем взглянуть на таблицу z‑оценок:
С помощью этой таблицы мы можем увидеть, что означает каждая z‑оценка. Z‑оценка, равная -3, означает, что только 0,135% значений опускаются ниже этого значения — достаточно редкое событие. Это делает его хорошим кандидатом на порог аномалии.
Однако вскоре мы поняли, что использование одних только z‑оценок для настройки оповещений имеет свои недостатки...
Проблемы с оповещениями на основе z-оценок
Основной трудностью, с которой мы столкнулись при использовании системы оповещения на основе z‑оценок, стало то, что наши бизнес‑метрики хранились в Graphite, который не предлагал удобного способа определения временных интервалов для вычислений. Наиболее близкой доступной функцией была movingAverage, но она не всегда была полезна. Например, если бы мы попытались рассчитать стандартное отклонение на основе данных за четыре недели, то получили бы результат, похожий на этот:
Стандартное отклонение, основанное на метрике с аномалией
Даже если бы нам удалось решить эту проблему и отфильтровать прошлые инциденты, остались бы другие сложности, с которыми нам предстояло разобраться.
Когда мы начали использовать z‑оценки для настройки оповещений, мы быстро заметили, что количество предупреждений значительно возрастает в ночное время. Это связано с тем, что бизнес‑метрики в отдельных странах и континентах естественным образом снижаются ночью, когда пользователи менее активны — они спят. Чем меньше транзакций, тем меньше отклонений, что делает z‑оценки более нестабильными и подверженными ложным срабатываниям оповещений в периоды низкой активности.
Еще одним существенным недостатком оповещений на основе z‑оценки является тот факт, что они не очень подходят для человеческого восприятия. Трудно оценить реальное воздействие инцидента, когда оповещения основаны на абстрактных статистических значениях. Представьте, что вас будит среди ночи такое оповещение: «Низкое значение z‑оценки (-3.1) для обработанных заказов за последние 10 минут».
Даже если вы внимательно посмотрите на дашборд, вам все равно будет сложно оценить, насколько это серьезная ситуация. Гораздо более информативным предупреждением было бы что‑то вроде: «За последние 10 минут мы потеряли N заказов».
Такая информация была бы очень полезна, и вам не нужно было бы даже смотреть на дашборд, чтобы узнать понятные цифры.
Учитывая все эти проблемы, мы поняли, что оповещения на основе одних только z‑оценок не были для нас оптимальным решением — нам нужно было найти лучший подход.
Альтернативный подход
Учитывая проблемы с удобочитаемостью оповещений на основе z‑оценок, мы подумали, что было бы лучше спрогнозировать, какой должна быть метрика, вместо того чтобы просто статистически отмечать аномалии. Однако, поскольку многие бизнес‑показатели сильно колеблются, прогнозирование одного конкретного значения было бы не самым удачным решением. Вместо этого мы решили определить диапазон (верхнюю и нижнюю границы), который позволил бы нам учитывать неопределенность волатильных метрик.
Еще одной проблемой, с которой мы столкнулись, было то, что для выполнения необходимых расчетов одного Graphite было недостаточно. И мы решили создать небольшой сервис, единственным назначением которого было вычисление прогнозируемого диапазона и отправка его обратно в Graphite. Этот сервис не должен был бы заниматься обработкой оповещений или обнаружением аномалий — эти функции могли бы быть реализованы с помощью других инструментов, таких как Grafana. Таким образом, наше внимание было бы сосредоточено на совершенствовании самого алгоритма прогнозирования диапазона, а Grafana отвечала бы за обнаружение и оповещение.
Мы назвали этот сервис «Granomaly», и вот общая схема того, как работает наша система обнаружения аномалий:
Как работает Granomaly
Сервис Granomaly работает следующим образом:
Считывает исторические данные из Graphite (например, данные за 4–5 недель для определенной метрики).
Отфильтровывает выбросы из прошлых инцидентов.
Вычисляет прогнозируемый диапазон (верхняя и нижняя границы).
Записывает диапазон обратно в Graphite в виде двух отдельных показателей.
Фактическое обнаружение аномалий и информирование о них осуществляется в Grafana на основе прогнозируемого диапазона, генерируемого Granomaly. Поскольку Grafana продолжает играть ключевую роль в визуализации этих метрик, мы также осознали необходимость управления дашбордами через код. Однако эта тема уже выходит за рамки данной статьи.
Как мы вычисляем прогнозируемый диапазон?
Существует множество алгоритмов обнаружения аномалий, но мы решили начать с чего‑то простого. Наш первый подход заключался в использовании скользящего окна для определения верхней и нижней границ на основе исторических данных.
Вот как это работает:
Для каждого нового значения мы берем временной интервал (например, 20 минут) и смотрим исторические данные для одного и того же дня недели за последние 4–5 недель.
Затем мы вычисляем n‑й процентиль в качестве нижней границы и (100-N)‑й процентиль — в качестве верхней границы.
Например, если мы оцениваем метрику в 12:00, мы собираем значения за последние несколько недель в период с 11:50 по 12:10. Если мы выберем 5 в качестве параметра процентиля, то установим 5-й процентиль в качестве нижней границы и 95-й процентиль — в качестве верхней границы прогнозируемого диапазона.
Мы протестировали этот подход на нескольких метриках, и он показал себя на удивление хорошо. Работая с параметром процентиля, нам удалось сформировать диапазон прогнозирования, который учитывал прошлые аномалии, не позволяя им искажать будущие прогнозы.
Однако вскоре мы обнаружили, что этот метод не работает в случаях больших перебоев или нескольких перекрывающихся инцидентов...
Перекрывающиеся сбои в метриках предыдущих недель
Хотя и редко, но иногда мы сталкивались с ситуацией, когда наш прогнозируемый диапазон искажался из‑за множества перекрывающихся инцидентов, происходящих в одно и то же время суток в один и тот же день недели. Вот пример:
Прогнозируемый диапазон с артефактом, вызванным аномалиями в прошлом
Как видно на графике, были две недели, когда показатель просаживался примерно в одно и то же время. В такие моменты наш подход, основанный на процентилях, не мог спрогнозировать корректный диапазон. Это дало нам понять, что нужен способ скорректировать прошлые инциденты в наших исторических данных.
Но как это сделать?
Мы бы не хотели вручную отслеживать и исключать инциденты, так как наша цель заключалась в максимальной простоте работы Granomaly. Вместо этого мы решили попробовать другой статистический метод: что, если мы исключим наиболее отклоняющиеся значения автоматически?
Первая попытка: Исключаем самую необычную неделю
Наша первая идея заключалась в том, чтобы исключить из рассмотрения неделю, которая отличалась от остальных больше всего. Логика была довольно простой:
Возьмем данные за последние N недель.
Создадим N-1 комбинаций, каждый раз исключая одну неделю.
Вычислим стандартное отклонение для каждой комбинации.
Выберем комбинацию с наименьшим стандартным отклонением.
Этот подход эффективно устранял крупные аномалии, даже в случае серьезных инцидентов. Однако он имел один существенный недостаток:
Почему так происходило? Этот метод всегда предполагал наличие выброса, который нужно исключить, даже если его не было. Это приводило к нестабильному прогнозированию диапазона, что делало его непригодным для общего использования.
Очевидно, это было неправильное решение. Поэтому мы вернулись к разработке и придумали кое‑что гораздо лучшее.
Исключение выбросов
Для решения этой задачи мы выбрали несложный статистический метод, который я объясню на двух примерах.
Для любого заданного интервала мы анализируем значения, собранные за одни и те же время суток и день недели на протяжении нескольких предыдущих недель. Давайте рассмотрим следующий набор данных:
Заметить выброс здесь можно даже невооруженным взглядом. Показатель постоянно колебался вокруг значения 600, но неделю назад он внезапно упал до 200. Это падение выглядит как аномалия или инцидент, и его не следует учитывать при вычислении прогнозируемого диапазона.
Шаг 1: Вычисление z-оценок
Чтобы решить эту задачу, мы сначала вычисляем стандартное отклонение, а затем определяем абсолютную z‑оценку для каждого значения:
Как и ожидалось, неделя № 1 оказалась выбросом, поскольку у нее самая высокая z‑оценка. Однако вместо того, чтобы просто исключать недели на основе z‑оценок, мы применяем более сложный подход:
Шаг 2: Нормализация z-оценок
На этом этапе начинается самое интересное. Вместо того чтобы фильтровать данные на основе фиксированного порога z‑оценок, мы нормализуем их, вычисляя среднее значение всех z‑оценок:
Затем мы считаем разницу между средним значением и z‑оценкой для каждой недели и сохраняем только те, чья нормализованная z‑оценка остается в пределах порогового значения 0.6. Этот порог был выбран нами эмпирически, и его можно скорректировать при необходимости.
Какова была цель этой так называемой «нормализации» значений z‑оценок? Почему бы нам просто не применить фиксированный порог к самим z‑оценкам? Для приведенного выше примера такой подход, скорее всего, сработал бы просто отлично. Однако, чтобы по‑настоящему понять преимущества нормализации, давайте рассмотрим, как алгоритм работает в ситуации, когда нет явных аномалий.
Случай без очевидных выбросов
Давайте рассмотрим следующий набор данных, в котором аномалии отсутствуют:
На первый взгляд, ничего необычного — этот набор данных выглядит вполне нормально. В идеале в этом случае наш метод не должен исключать никаких значений.
Теперь давайте выполним те же шаги, что и раньше. Сначала мы вычислим абсолютные z‑оценки:
Обратите внимание, что на первой и четвертой неделе были зафиксированы самые высокие и самые низкие значения, что привело к высоким z‑оценкам. Однако, с человеческой точки зрения, эти колебания не являются аномальными. Именно поэтому мы решили нормализовать z‑оценку, используя среднее значение. Вот как это выглядит после нормализации:
Ни одно из значений не превышает порогового в 0.6, что означает, что никакие значения не будут отфильтрованы — это ожидаемое правильное поведение.
Реальные данные
Как же этот метод работает в реальных сценариях? Давайте посмотрим на прогнозируемый диапазон в примере, который мы обсуждали ранее:
Теперь давайте рассмотрим другой случай с перекрывающимися аномалиями:
Как вы можете наблюдать, даже если аномалии возникают в течение двух отдельных недель, прогнозируемый диапазон остается плавным. Теперь, когда мы устранили прошлые аномалии, мы можем сосредоточиться на обнаружении новых аномалий в режиме реального времени.
Обнаружение аномалий
Как уже упоминалось ранее, сервис Granomaly не занимается обнаружением аномалий напрямую — он лишь генерирует значения прогнозируемого диапазона для наблюдаемой метрики, который, в свою очередь, является такой же метрикой. И, получив эту метрику, мы можем легко обнаружить аномалии с помощью любого инструмента, имеющего к ней доступ.
Мы решили реализовать обнаружение аномалий непосредственно в Grafana. Такой подход обеспечил нам быструю обратную связь и позволил быстро экспериментировать с различными стратегиями обнаружения. Ниже представлен пример панели мониторинга, которую мы использовали в нашей команде:
Мы настроили панель мониторинга и оповещения таким образом, что всякий раз, когда значение выходит за пределы прогнозируемого диапазона, это считается аномалией. Для каждой метрики мы настраиваем два оповещения: одно о значительном снижении, а другое — о постепенном снижении в течение длительного периода. Такой подход позволяет нам обнаруживать как внезапные отключения, так и медленные, постепенные снижения (обычно мы называем их инцидентами «замедленного действия»). Естественно, пороговые значения различаются для каждой метрики. Чтобы упростить конфигурацию в Grafana и снизить сложность запросов Graphite, мы ввели метрику «смещение» (offset), которая рассчитывается в сервисе Granomaly.
Метрика “смещение”
«Смещение» представляет собой разницу между текущим значением метрики и прогнозируемым диапазоном.
Если текущее значение находится в пределах прогнозируемого диапазона, смещение равно нулю.
Если значение выходит за пределы верхней границы, смещение определяется как разница между текущим значением и верхней границей прогнозируемого диапазона.
Аналогично, если значение опускается ниже нижней границы, смещение рассчитывается как разница между текущим значением и нижней границей диапазона.
Это значительно упрощает настройку оповещений:
Просто суммируйте все последние значения смещения за данный период.
Сравните сумму с пороговым значением, чтобы решить, следует ли запускать оповещение.
Поправка на события
Некоторое время мы использовали это метод обнаружения аномалий, но вскоре столкнулись с проблемой. При настройке всех оповещений через Grafana было сложно точно настроить их для особых событий, таких как праздники, выходные или крупные мероприятия, такие как Super Bowl в Америке или чемпионат мира по футболу. Мы знаем, что в эти периоды некоторые бизнес‑метрики ведут себя иначе, и хотели убедиться, что наши ожидания были соответствующим образом скорректированы. Настройка всего этого в системе оповещения Grafana — непростая задача, поэтому мы применили другой подход. Мы хотели разрешить указывать конкретный временной диапазон и либо корректировать порог оповещения, либо изменять метрику прогнозируемого диапазона для этого периода. Вот как мы пришли к «корректировочной» (correction) метрике.
Как работает корректировочная метрика
Корректировочная метрика отличается высокой гибкостью и настраивается в сервисе Granomaly следующим образом:
По умолчанию ее значение равно 0, что означает, что мы не внесли никаких корректировок.
Для особых событий мы определяем произвольное значение корректировки (например, 10).
Затем это значение обрабатывается как процентная корректировка для расширения прогнозируемого диапазона.
Показатель «смещение» рассчитывается на основе скорректированного диапазона.
Такой подход позволил нам заранее подготовиться к известным событиям, подарив немного спокойствия и в то же время сохранив высокую точность в выявлении аномалий.
Обнаружение аномальной просадки во время аномального роста
Еще одна интересная проблема, с которой мы столкнулись, заключалась в неожиданном росте бизнес‑метрики. В течение определенного периода мы наблюдали увеличение трафика на 15–20% по сравнению с прогнозом, и в то же время произошел небольшой инцидент, который вызвал незначительную просадку этой метрики.
Как видно на графике, этот инцидент остался бы незамеченным, поскольку показатель едва касался нижней границы прогнозируемого диапазона. Технически это можно рассматривать как двойную аномалию:
Общее увеличение трафика само по себе является аномалией.
Небольшая просадка в течение этого периода — это еще одна аномалия, которая была скрыта из‑за более высокого, чем мы прогнозировали, уровня трафика.
Мы могли бы использовать корректировочную метрику для решения этой проблемы, но поскольку ситуация была неожиданной, нам потребовался более гибкий подход.
Введение поправочного коэффициента
Чтобы лучше справляться с подобными ситуациями, мы решили добавить в нашу панель мониторинга аномалий новый компонент — «поправочный коэффициент» (adjustment factor). Суть этого компонента довольно проста:
Смотрим на метрики за последние пару часов.
Определяем единый поправочный коэффициент, который при умножении на текущую метрику позволит лучше расположить ее в пределах прогнозируемого диапазона.
После того как мы определили поправочный коэффициент, мы построили график для скорректированной метрики. Затем мы настроили систему оповещений таким образом, чтобы она срабатывала в случаях, когда либо исходная, либо скорректированная метрика проседают.
Это позволяло нам обнаруживать внезапные просадки даже в тех случаях, когда показатели были значительно выше, чем ожидалось. Благодаря этому мы были уверены, что не пропустим аномалии из‑за повышенного трафика.
Моделирование аномалий и сбоев
Как вы можете видеть, процесс обнаружения аномалий включает множество компонентов, и настройка правильных значений или алгоритма исключения выбросов может быть довольно сложной задачей. Каждый раз, когда происходил инцидент, мы были рады, поскольку это позволяло нам протестировать наше решение на реальных данных. Однако, к сожалению, мы не всегда можем позволить себе роскошь сталкиваться с реальными инцидентами. Чтобы решить эту проблему, мы разработали функционал для моделирования инцидентов.
Идея заключается в том, что перед настройкой панели мониторинга аномалий в Grafana и ее интеграцией в сервис Granomaly, вы можете сначала протестировать, как она будет работать для выбранной вами метрики.
В нашем сервисе мы создали страницу моделирования, на которой можно настроить все параметры и протестировать, какой прогнозируемый диапазон она будет давать для выбранной метрики. Мы также добавили моделирование аномалий в различных метриках, чтобы проверить, насколько хорошо работает алгоритм исключения выбросов. Эта функция оказалась невероятно полезной. Мы смогли улучшить алгоритм прогнозирования диапазона и протестировать его в разных ситуациях, включая случаи, когда аномалии пересекаются в разные недели. Теперь любой пользователь может просто подключить нужную метрику и сразу увидеть результаты. Это значительно сократило цикл обратной связи, что упростило тюнинг прогнозируемого диапазона для каждой метрики и сделало обнаружение аномалий более точным.
Понимание аномалий
Итак, мы создали все это, и у вас может возникнуть вопрос: было ли это полезно? Удалось ли нам эффективно обнаруживать аномалии? На самом деле, обнаружить аномалию — это не так сложно. Сложная задача — это то, что нужно сделать дальше.
Когда вы сталкиваетесь с увеличением количества ошибок в вашей системе, вы часто можете отследить их до неисправного компонента. Но что, если у вас вообще нет никаких ошибок? Что делать, если количество заказов на вашем веб‑сайте просто сократилось, и нет никаких признаков изменений или проблем в вашей системе? Что вы будете делать, когда обнаружите такую аномалию?
Может быть, это просто хорошая погода или какое‑то важное событие, о котором вы забыли, и все ваши пользователи находятся оффлайн?
Или это какие‑то проблемы с вашей маркетинговой кампанией, которая отработала в полную тишину?
Может быть, это проблема вашего бизнес‑партнера, и он еще не знает об этом, но это уже влияет на вас?
Или, возможно, вы проводите A/B‑тест, который нарушил работу обработчика кликов для кнопки заказа у небольшого числа пользователей, и они не могут отправить форму?
На самом деле, произойти может что угодно.
Видите ли, в большинстве случаев обнаружить аномалию не так уж и сложно. Гораздо труднее понять, что делать с этой информацией. Одна вещь, которая может существенно помочь, — это разделение вашей бизнес‑метрики на составляющие. Вместо того чтобы просто отслеживать заказы на вашем сайте, попробуйте отслеживать их по регионам, устройствам, таким как iPhone, Android, планшет, браузер для ПК и так далее. Или по маркетинговым каналам. Это действительно важно, потому что ваша компания привлекает пользователей различными способами, и часто она полагается на сторонние сервисы. Вам следует быть уверенными, что не теряете пользователей из‑за неправильной настройки или проблем на другой стороне.
Как только вы сможете разбить главные метрики на более мелкие составляющие, вы сможете расширить панели мониторинга аномалий, чтобы охватить их все. Такой подход поможет вам точечно подходить к анализу необъяснимого поведения ваших данных.
Заключение
Обнаружение аномалий может быть очень эффективным даже с использованием простых статистических инструментов, таких как z‑оценка, стандартное отклонение, процентили и т. д. Вам не обязательно быть экспертом в области машинного обучения, чтобы создать систему обнаружения аномалий для данных временных рядов. Однако стоит обратить внимание на несколько ключевых моментов: учет прошлых аномалий, сокращение цикла обратной связи с помощью моделирования и осмысление обнаруженных аномалий.
Как показано в этой статье, статистические методы могут успешно выявлять аномалии, но их эффективность во многом зависит от качества исторических данных. Если прошлые аномалии искажают основную тенденцию, прогнозы становятся менее точными, и необходимо их отфильтровывать. Мы учли это в нашем подходе.
Ключевым элементом нашего решения стало интерактивное моделирование, которое позволило сократить время обратной связи с нескольких дней до секунд. Это позволило нам быстро экспериментировать с историческими данными, что упростило тюнинг параметров и оценку того, подходит ли конкретная метрика для обнаружения аномалий. Следует отметить, что не все показатели достаточно предсказуемы для работы с таким подходом. Поэтому, если вы создаете систему обнаружения аномалий, оптимизация цикла обратной связи имеет решающее значение.
Однако самая сложная задача — это интерпретация аномалий. Внезапное и значительное снижение показателей обычно легко диагностировать, так как оно часто сопровождается другими тревожными сигналами, указывающими на явный системный сбой. Но что делать, если вы замечаете постоянное падение количества заказов на 10% без ошибок, жалоб и очевидных технических проблем? Это может быть связано с тонкими бизнес‑процессами, маркетинговыми кампаниями или даже с такими простыми факторами, как изменения погодных условий, которые влияют на поведение пользователей. Такая неопределенность затрудняет интерпретацию аномалий. Разбивка показателей по регионам, устройствам или маркетинговым каналам может помочь сузить круг возможных причин, но это, очевидно, не является законченным решением.
В конечном счете, прежде чем анализировать аномалию, необходимо сначала ее обнаружить. И я надеюсь, что эта статья показала, что это возможно сделать с помощью относительно простых статистических методов.
Если вас заинтересовала тема этой статьи, приглашаем на открытый урок «Grafana — продвинутое использование», который пройдет 19 июня — он поможет понять, как применить эти знания на практике и как грамотно применить их в новой сфере.
А чтобы узнать, потянете ли вы программу курса «Observability: мониторинг, логирование, трейсинг», попробуйте пройти вступительное тестирование.