Noc - сетевики?

не вполне, просто команда мониторинга

У нас есть дежурная смена мониторинга 🙂

учитывая некоторый зоопарк систем мониторинга, и довольно большой объем метрик/триггеров, есть проблема передачи информации по сменам. как опция, хотелось бы иметь возможность поиска для выявления каких-то зависимостей и периодичностей инцидентов. как-то сходу такой инструмент не гуглится, может кто-то решал подобную задачу?

Ща расскажу со своей колокольни

может все алармы со всех систем закидывать в одну систему алертинга и в ней следить? как например пейджер дьюти или чтото бесплатное

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

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

однако, в задачу для rnd может превратится нечто найденое в результате серии событий, например периодически повторяющихся

А у вас руководители смены или сервис менеджеры есть? Кто определяет что данная задача - бизнес критикал?

есть конечно

Может они и буду контролировать исполнение и передачу инфы о тикетах?

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

Инциденты ведем в Jira, туда их заносит заббикс, дежурные их подчищаюст. Могу сказать, что чистить лишнее легче, чем заводить новые.
Автозаведение дает ряд преимуществ. Например, по каждому инциденту считается количество повторений, плюс описание всегда совпадает с описанием триггера. Ну и ищется это все на JQL просто великолепно, поэтому никогда не составляет труда найти, что делали другие в подобной ситуациии

Очень здорово организованно!

спасибо)

спасибо, организация интересная, напрямую в мой кейс не копируется. с другой стороны можно подумать об отдельном проекте в jira, откуда часть тикетов пойдет в утиль, часть закроется ноками, и уже что-то полезное пойдет в проект к rnd

единственное что меня смущает сильно это письма. в моей практике это достаточно быстро превращается в формальность/копипасту/забыл/забил

Письма можно заменить на сообщение в чате, но все равно придётся с ними работать.
Иначе изучайте опыт гигантов типа нетфликса. У них vector чудеса творит.

любое документирование, в том числе подробности в инцидентах, превращается в рутину и, как следствие, копипасту/забыл/забил.

я постарался максимально успростить формат таких писем.

Дежурный прикладывает ссылку на все инциденты, которые были отправлены дальше по процессу (в нашем воркфлоу это фильтр по смене статуса с new в ready), далее коротко:
ссылка на инцидент - кратко суть - кратко, что пришлось сделать.

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

ок, спасибо