Затраченное время 26 часов


Есть внешний сервис, который занимается распознаванием композиций в двух сотнях онлайн аудиопотоках. Сервис генерирует 5-7 тысяч ошибок о недоступности потоков. Нужно оперативно отслеживать ситуацию и подменять нерабочие потоки.

Варианты решений

Когда потоков было мало и ошибки были единичны отслеживали все в ручном режиме напрямую в базе данных, куда писались все логи. В какой-то момент это стало отнимать уйму времени и мы решили оптимизировать процесс, агрегировав ошибки в единый показатель, считающийся раз в сутки

Особенности реализации

Для начала надо понять, что именно мы отслеживаем. Дергать всех заинтересованных лиц при каждой ошибке, когда таких ошибок по несколько тысяч в сутки - не самая лучшая идея. С точки зрения бизнеса клиента, важен процент распознанного радио эфира, поэтому в качестве ключевого показателя выбрали время “недоступности” потока за последние сутки. Чем больше поток недоступен для анализа, тем хуже для бизнеса.

Анализ входящих ошибок по времени недоступности потока показал, что есть три типа “проблемных” потоков:

  1. Временно недоступные аудиопотоки. Поток пропал на 3-4 минуты и снова появился. Считаем это нормальной ситуацией и такой поток не считаем проблемным. Для себя решили, что если поток падает менее чем на 15 минут, то за ошибку это не считаем.
  2. “Мигающий” аудиопоток. Это аудиопоток, который за один день мог “отвалится” 20-30 раз, сгенерировав пару сотню ошибок. Такие потоки считаем проблемными. Критерий: поток недоступен больше 15 минут в сутки, ошибок больше трех в сутки.
  3. “Отвалившийся” аудиопоток. Поток пропал из сети и до конца дня не появился. Такой поток считаем проблемным.

Следующий этап — выбор метода получения отчета. Так получилось, что и наша команда и команда клиента используют телеграм в качестве корпоративного мессенджера. Поэтому для уведомлений мы создали специального бота, который раз в сутки формирует сводный отчет о недоступности потоков и отправляет его всем заинтересованным лицам.

Для надежности, каждое такое уведомление дублируется в задачу на соответствующего исполнителя в Чили.Деск. Такие задачи не закрываются быстро, поэтому повторная задача на исправление ситуации с потоками будет создана только через трое суток после создания предыдущей задачи, либо если предыдущая задача была решена.

Двойным уведомлением в телеграм и в тикетнице мы убили двух зайцев. С одной стороны руководители отслеживают текущую работу через телеграм бот, держа руку на пульсе. С другой стороны менеджер, ответственный за работу с аудиопотоками никогда не потеряет задачу и она будет всегда в фокусе, т.к. Чили.Деск используется как корпоративный трекер задач у клиента.

В процессе работы столкнулись только с одной проблемой — скрипт уведомлений, как и любая другая система, иногда падает. Вспышка на солнце или неаккуратная уборщица в серверной могут неожиданного нарушить работу системы. Поэтому работу демона отслеживает zabbix, а телеграм бот всегда отправляет уведомления в 23-00, даже если ошибок нет.

Пример уведомлений

Агрегирование ошибок.png

Эффект от проведенных работ

Проблемные потоки стали заменяться быстро, степень покрытия радиостанций системой распознавания аудио держится у верхней границы.



Есть вопросы?