Valuable insights
1.Разработка детектора аномалий с нуля в Иви: Технический директор Иви был вынужден самостоятельно создать инструмент для обнаружения аномалий после инцидента, поскольку готовые решения не соответствовали требованиям.
2.Приоритет интеграции над алгоритмами: Подавляющее большинство времени (около 90%) было потрачено на интеграционные вопросы и подготовку данных, а не на саму математику алгоритмов детекции аномалий (10%).
3.Необходимость анализа бизнес-метрик: Система должна была интегрироваться с хранилищами продуктовых метрик, такими как ClickHouse, для выявления сбоев в бизнес-логике, а не только в инженерной инфраструктуре.
4.Снижение ложных срабатываний эмпирическими правилами: Для повышения качества использовались простые правила, включая игнорирование шума вокруг медианы и применение порога N из M последовательных срабатываний.
5.Выбор быстрой и простой библиотеки: Была выбрана библиотека от Twitter (Open Source), которая управляется всего двумя параметрами: статистической значимостью и чувствительностью, что упрощает настройку.
6.Архитектура без собственного хранилища временных рядов: Детектор не хранит данные, а опрашивает внешние источники (Prometheus, Zabbix, ClickHouse) в реальном времени, используя Redis только для отслеживания активных инцидентов.
7.Автоматизация добавления тысяч метрик: Масштабирование достигается за счет использования регулярных выражений для Zabbix и параметризованных SQL-запросов для ClickHouse, позволяя любому сотруднику добавлять метрики.
8.Мотивация команды через публичную отчетность: После первоначального игнорирования, внедрение было форсировано через закрытый чат с публикацией всех алертов, что заставило ответственные команды заняться исправлением.
Постановка проблемы и личный опыт
Евгений Россинский, технический директор Иви, представил доклад о создании инструмента для обнаружения аномалий в условиях highload. Аномалия определяется как любое отклонение от привычного хода вещей, что может проявляться как в двумерном пространстве, так и во временных рядах. Данный доклад посвящен инженерной части решения, которое пришлось разрабатывать вручную, несмотря на наличие в департаменте 317 инженеров.
Неприятный инцидент и его последствия
Причиной разработки послужил инцидент, произошедший около полутора лет назад, когда один из сервисов испытал критическую нагрузку. Анализ графиков показал, что за 30 минут до аварии уже были видны рост нагрузки и увеличение времени ответа. Однако команда не смогла оперативно принять меры, что привело к необходимости создания проактивного инструмента.
Неудовлетворенность существующими триггерами
Попытки инженеров найти готовое решение или добавить простые триггеры не увенчались успехом: предложенные варианты либо работали только с конкретными системами, например, с Prometheus или Grafana, либо приводили к большому количеству ложноположительных срабатываний, что делало их непригодными для использования в продакшене.
Требования к системе детекции аномалий
Основная цель заключалась в получении инструмента, способного либо предсказать аварию за несколько минут или часов, либо уведомить о ней максимально быстро после возникновения. Для этого был собран собственный датасет, включающий падение бизнес-метрик (просмотры, платежи), рост времени ответа сервисов, а также незаметные, но статистически значимые падения трафика, как, например, проседание на
Useful links
These links were generated based on the content of the video to help you deepen your knowledge about the topics discussed.