Какие сбои тянут за собой другие: как найти скрытые связи в потоке инцидентов
В магазине пропал канал связи. Через пять минут в Service Desk падают ещё три заявки: отвалились кассы, гостевой Wi-Fi и оплата картой. В итоге вероятен сценарий, когда три разные ИТ-группы параллельно пытаются чинить три «разных» сбоя.
В конце месяца руководитель видит в отчёте рост инцидентов и падение SLA по трём сервисам, хотя корень проблемы был один. По плоскому журналу заявок невозможно понять, где первопричина, а где - следствие. Пока эти связи скрыты, компания избыточно тратит инженерные ресурсы на устранение симптомов, а в отчётах одна авария считается как несколько независимых.
Задача алгоритма
Метод автоматического поиска связей анализирует сырые выгрузки из систем Service Desk и отвечает на три вопроса:
- Какой сбой - триггер? После отказа какой системы лавинообразно открываются тикеты по другим сервисам.
- Это закономерность или совпадение? Сколько раз подобный сценарий повторялся на практике и сколько таких совпадений дала бы простая случайность.
- Сколько реальных аварий произошло? Какая доля тикетов - лишь «эхо» уже идущей аварии или заведённые дубли, которые нужно склеить в один инцидент.
Как работает метод
Метод относится к алгоритмам поиска ассоциативных связей и адаптирован под специфику инцидентов.
- 1. Окно наблюдения (15 минут)
После появления любой заявки алгоритм отслеживает временно́е окно в 15 минут: открылись ли за это время тикеты по другим системам.
- 2. Фильтрация случайных совпадений и шума
Самая частая ошибка аналитики - принять дневную активность за взаимосвязь. Если две офисные системы чаще ломаются днём, это ещё не значит, что одна роняет другую.
Учёт базового ритма: алгоритм сравнивает совпадения с обычной загрузкой второй системы в эти недели, в этот день недели и час.
Исключение «дня-шторма»: дни, когда одновременно падало всё (например, обесточен ЦОД), исключаются из поиска. В шторм совпадает всё со всем, создавая ложные связи.
Проверка устойчивости: связь признаётся реальной, только если она повторилась минимум в 4 разных днях и сохраняется при удалении двух самых пиковых дней.
- 3. Определение направления: кто главный
Направленная связь (A → B): если система A почти всегда сбоит первой, она фиксируется как первопричина.
Связь «без первого» (A ↔ B): если первой оказывается то одна, то другая система, алгоритм помечает их как жертв общей причины (например, вероятного сбоя питания или общей инфраструктуры).
- 4. Склейка инцидентов (дедупликация)
Продолжение: заявка по связанной системе в течение 15 минут считается эхом первичного сбоя, а не новым независимым инцидентом.
Дубли: заявки по одной и той же системе с разницей в минуты объединяются.
Важно: статистическая связь не равна физической причине: A может не ломать B напрямую, их может ронять третья система C. Но метод точно указывает, где искать корень проблемы, и снижает информационный шум.
Что алгоритм видит в реальных данных и от чего защищён
Сырые журналы Service Desk практически никогда не бывают идеальными: в них полно повторных штормов от мониторинга, размытого времени и человеческого фактора. Вот как метод отрабатывает типовые сценарии:
| Что произошло | Что в журнале | Как реагирует алгоритм | Практический эффект |
|---|---|---|---|
| Цепная реакция | Упал канал связи, следом - кассы, Wi-Fi и терминалы оплаты | Находит первичную систему и строит цепочку следствий | В списке крупнейших инцидентов авария стоит один раз вместо четырёх; сразу виден «виновник» |
| Скрытая общая причина | Отключилось питание; первыми случайно падают то кассы, то Wi-Fi | Фиксирует связь «сбоят вместе, без явного первого» | Указывает инженерам искать инфраструктурную причину (питание, коммутатор) |
| Два следствия одного сбоя | Кассы и Wi-Fi упали из-за канала связи | Не связывает кассы и Wi-Fi напрямую между собой | Исключает ложные гипотезы о том, что кассовый софт ломает Wi-Fi |
| Дубли и «дребезг» | Мониторинг или пользователи завели несколько заявок на один сбой за 10 минут | Склеивает повторы в одну аварию и считает их долю | Показывает, сколько заявок - повторы и насколько завышено число сбоев |
| Шторм (массовый сбой) | Из-за аварии в ЦОД или у крупного провайдера сбоит всё сразу | Исключает такие дни из поиска связей | Защищает от сотен мусорных связей «всего со всем» |
| Низкое качество данных | Не указана система или время записано с точностью до часа | Не ищет связи и пишет в отчёте почему | Защищает от недостоверных выводов, если учёт ведётся небрежно |
Надёжность проверки: для создания запаса точности, кроме тестов на реальных базах, аалгоритм протестирован на сотнях искусственно сгенерированных журналов без реальных связей - до 30 систем и 5 500 заявок в год, в том числе с днями массовых сбоев. Ложная связь нашлась только в одном году из 200.
Что делать, если алгоритм нашёл связь
Когда модель показывает регулярную связь между сбоями, инженеры получают готовый паттерн для работы. Таблица показывает, как интерпретировать найденные комбинации:
| Сценарий | Вероятная причина | Как проверить гипотезу | Что делать |
|---|---|---|---|
| Система A падает первой, за ней - Б, В и Г | Зависимость архитектуры: Б, В и Г не могут работать без A | Совпадают ли объекты (магазин, узловая стойка, филиал) у пары заявок | Приоритет резервирования: вложения в надёжность одной системы A убирают сбои по трём другим |
| Системы A и Б падают вместе в случайном порядке | Общая инфраструктурная причина (питание, общий коммутатор, ЦОД) | Найти общий аппаратный или логический узел для объектов из двух заявок | Поиск единой точки отказа (SPOF): резервировать не сами системы, а общий для них узел |
| Система A падает сама за собой несколько раз подряд | «Дребезг» мониторинга или дублирование тикетов пользователями | Источники заявок (робот или человек) и совпадение текстов | Меньше усталости от оповещений (Alert Fatigue): подавление повторных алертов бережёт инженеров от выгорания |
| Разные команды параллельно берут одну проблему | Организационная разобщённость: каждый отдел видит только свой симптом | Сверить время регистрации и объекты у тикетов разных команд | Единый центр управления: тикеты-следствия привязаны к главному, ликвидация ведётся из одной точки |
Пример. Канал связи и три очереди заявок
Исходные данные: торговая сеть, 12 ИТ-систем, около 1 100 заявок в год. При обрыве интернет-канала в магазине первая линия поддержки получает тикеты по кассам, Wi-Fi и терминалам оплаты. Каждый тикет уходит в свою сервисную группу.
Что нашёл алгоритм: в течение 15 минут после сбоя «Каналы связи» открывались заявки по кассам - 10 раз из 106 (случайно совпало бы около 0,8 раза), по Wi-Fi - 9 раз (около 0,4), по платёжному шлюзу - 8 раз (около 0,2). 56 заявок из 1 116 за год - прямое продолжение уже идущих аварий.
Что это даёт:
- Экономия ресурсов ИТ. Вместо трёх параллельных расследований назначается один ответственный за канал связи. Часы узкопрофильных специалистов не тратятся на симптомы.
- Прозрачные KPI и SLA. Видно, что число инцидентов в отчётах завышено примерно на 5% только из-за эха и повторов. Отчётность перед руководством становится честной.
- Обоснование окупаемости (ROI) для руководства. Бюджет на второй, резервный канал связи обосновать проще: «защита одного канала убирает сразу три категории сбоев на кассах и оплате».
Полоса - сколько раз после сбоя канала в течение 15 минут открывалась заявка по другой системе; серая метка - сколько дал бы случай.
Как применять результаты в работе
Найденные зависимости перестраивают работу ИТ-департамента на трёх уровнях - от ежедневной обработки тикетов до стратегических решений.
- Процессы (Incident Management)Принцип «одна авария - один главный тикет»: заявки-следствия, открытые в 15-минутное окно, связываются с родительской заявкой (Parent-Child). Результат: одно оповещение для бизнеса, один дежурный инженер и никакой путаницы, когда разные команды параллельно делают одну и ту же работу.
- Архитектура и бюджет (Problem Management)Система-«триггер», которая тянет за собой каскад сбоев, - главный кандидат на резервирование и модернизацию. Результат: понятная окупаемость ИТ-проектов. Укрепление одной критической точки снимает пласт вторичных заявок и нагрузку на вторую и третью линии поддержки.
- Управление и KPI (Executive Reporting)Руководство видит, какая часть заявок - дубли и «эхо» аварий, и реальную картину доступности сервисов. Результат: решения о закупках и резервировании принимаются по фактам, а не по раздутому количеству заявок.
Главный итог
Поиск связей между сбоями превращает журнал Service Desk из пассивного «кладбища тикетов» в инструмент точечной оптимизации ИТ-инфраструктуры. Вы перестаёте тратить ресурсы на устранение симптомов и получаете карту скрытых зависимостей своих систем.