В какие часы падают сервисы: как разглядеть системные сбои за шумом в журнале заявок

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

1. Развести конфликтующие процессы. Отличить разовую аварию от регулярного сбоя, вызванного «наложением» фоновых задач (резервное копирование, обмен данными, релизные окна, тяжёлые ночные расчёты).
2. Провести аудит качества данных и процессов. Выявить системные искажения в учёте - например, технический спам от сканеров и проверок, падающий в журнал одной секундой, - и учесть ложные утренние пики, когда ночные сбои регистрируют только в 09:00.
3. Получить аргументы для подрядчиков и графиков смен. Опереться на жёсткие факты (число недель, система, конкретный час) при пересмотре SLA с вендорами или при формировании дежурств, вместо того чтобы распределять людей наугад.

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

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

• Оценка долей времени недели: когда нужна команда

  Основа: все инциденты делятся на три группы: стандартные рабочие часы (будни с 9:00 до 18:00), вечер и ночь в будни, выходные. В расчёт берутся даже незакрытые заявки, так как время их возникновения уже зафиксировано.

  В чём суть: рабочие часы будней составляют всего 27% от времени всей недели. Если на этот период приходится, допустим, 43% инцидентов, значит, оставшиеся 57% сбоев происходят тогда, когда в офисе никого нет. Уже есть повод задуматься, как правильно распределить дежурных и работу.

• Поиск «необычного часа»: где спрятан системный сбой

  Самый загруженный час - это ещё не аномалия. Днём всегда больше активных пользователей и заявок. Поэтому алгоритм ищет не максимумы, а отклонения от привычного ритма.

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

  Проверка на повторяемость: разовая крупная авария, сгенерировавшая 30 заявок за 60 минут, не признаётся системой как закономерность. Аномалия фиксируется, только если сбои в этот час повторяются в разные недели.

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

  Честность данных: если график сбоев представляет собой случайный разброс, система не будет выдумывать «худшее время» искусственно. Отчёт прямо укажет: «необычных часов нет».

Работа с реальными данными: ловушки учёта

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

• Как алгоритм обрабатывает искажения в данных

  Разовая крупная авария: шквал из десятков заявок за один час система классифицирует как единичный инцидент, а не как повторяющуюся закономерность. Искать расписание здесь не нужно.

  Технический спам одной минутой: если сотни записей появляются ровно в 02:00, система определяет это как время записи скриптом или автоматической проверкой, а не время поломки, и не ищет по этим записям закономерность.

  Утренние пики вместо ночных инцидентов: если сервис упал ночью, но заявку зарегистрировали только с приходом сотрудников в 9:00, возникает ложный всплеск. Отчёт предупредит о такой вероятности, чтобы команда могла внедрить автоматический ночной мониторинг для проблемных сервисов.

  Ограничения форматов: если в выгрузке присутствуют только даты, система не выдумывает фиктивный час «00:00», а проводит анализ строго по дням недели. Если время записано в UTC - напомнит о необходимости сдвига на локальный часовой пояс.

Матрица решений: что делать при обнаружении аномалий

Как выбрать окно для плановых работ

Плановые работы (обновления, миграции, замена оборудования) рискованны сами по себе. Если поставить их туда, где и так регулярно что-то падает, два сбоя сложатся, и потом не понять, что уронило систему. Отчёт помогает выбрать окно по трём признакам:

1. Не в найденный необычный час. Если отчёт нашёл «четверг 02:00» или «каждый день 04:00», в этот час уже работает какое-то задание. Работы поверх него спорят с ним за ресурсы, а разобрать потом, кто кого уронил, трудно.
2. Туда, где сбоев мало и есть кому чинить. На тепловой карте отчёта светлые клетки - часы, когда сбоев меньше всего. Ночь и выходные обычно тише, но и людей меньше: доли по периодам недели показывают, сколько сбоев придётся на окно, а ваш график дежурств - кто будет на месте, если работы пойдут не так.
3. С поправкой на время регистрации. Если в журнале время заявки, а не время поломки, ночной сбой выглядит утренним. Тихая ночь в отчёте может значить, что ночью просто никто не смотрел.

Так выглядит тепловая карта в отчёте: строки - дни недели, столбцы - часы. Чем темнее клетка, тем больше сбоев; светлые клетки - кандидаты для плановых работ. Пунктирная рамка - будни с 9 до 18. Красная рамка - час, который выбивается из обычного ритма (здесь четверг 02:00, 37 сбоев): туда работы не ставить.

Чего отчёт не знает: график дежурств, пики бизнеса (распродажи, закрытие месяца) и цену работ в нерабочее время. Эти данные добавляете вы - и из тихих часов остаются те, где есть люди и нет пика продаж.