Какие объекты ломаются снова и снова
В магазине №17 касса опять не печатает чек. Инженер перезагружает её, укладывается в норматив 20 минут. Через три дня ситуация повторяется. В отчётах Service Desk всё «зелёное» - заявки закрываются в срок. Но директор магазина видит, что касса постоянно не работает.
Каждый отдельный ремонт выполняется по регламенту, но стандартные журналы не показывают хронические сбои. Чтобы уйти от субъективного ощущения «у нас опять сломалась касса» к точным решениям, нужны цифры: какие конкретно объекты возвращаются в ремонт, насколько они хуже соседних и не является ли это просто случайностью.
Задача метода
Анализ выгрузки из Service Desk должен ответить на три вопроса:
- Какой объект ломается чаще соседей? Конкретная касса, один сервер из трёх - то, что выбивается из нормы.
- Где сбой возвращается сразу после починки? Объект падает сериями через 1-3 дня после ремонта.
- Это закономерность или фон? Сколько повторных сбоев было бы, если бы все объекты в системе ломались с одинаковой случайной частотой.
Как это считается
- 1. Фокус на объекте, а не системе
Анализируется «касса магазина №17», а не «все кассы». Если смотреть на систему в целом, сбои будут происходить каждую неделю просто из-за их общего количества.
- 2. Склейка дублей
Заявки на один и тот же объект, открытые во время текущей аварии или в течение 1 часа после ремонта, считаются одним сбоем. Это отсекает «дребезг» мониторинга.
- 3. Метрика возврата
Фиксируется поломка того же объекта в течение 7 дней после закрытия прошлой заявки.
- 4. Сравнение со случайностью
Метод математически раздаёт сбои объектам наугад. Затем сравнивает факт с моделью: «27% сбоев вернулись; при случайном распределении их было бы около 28%».
- 5. Два признака аномалии
Ломается чаще других: сбоев больше, чем у аналогов, с поправкой на размер парка (чтобы случайно не назвать «худшим» просто один из 47 магазинов).
Сбои идут сериями: после ремонта объект ломается через 1-3 дня - значительно чаще, чем диктует общий ритм системы.
Важно: метод подсвечивает проблемный узел. Точную причину (железо или софт) нужно смотреть в текстах заявок.
Работа с «грязными» логами в реальной жизни
Алгоритм защищён от типичных проблем журналов Service Desk и станет находить то, чего нет
- Нет колонки с объектом (только услуга)Метод не ищет повторы, чтобы не выдавать ложные аномалии там, где просто много обращений.
- Объект указан редко (менее 20% заявок)Анализ останавливается с указанием причины. Понятно, какое поле нужно заставить заполнять.
- Шум мониторинга (5 заявок за час)Склеивается в один инцидент.
- Разное написание («магазин 17» и «МАГАЗИН № 17»)Распознаётся как один объект.
- Массовый сбой (упало всё)Не даёт ложных находок: разовая авария не записывается в «хронику» десятков серверов.
- Мало данных (меньше 4 недель или меньше 20 сбоев)Метод не делает выводов на недостаточной выборке.
Надёжность проверена на 160 (суммарно) годах данных. Метод нашел все объекты, ломающиеся 20-25 раз при норме в 5. Серии из 5 сбоев подряд ловит в 28 годах из 40, из 4 сбоев - в 20 из 40. Ложно названных объектов не было.
Что делать с найденными объектами
| Картина в журнале | Возможные причины | Что делать дальше |
|---|---|---|
| Объект ломается весь год (26 раз при норме 5) | Износ железа, аномальная нагрузка, проблемы с питанием на точке | Модернизировать или заменить узел. Проверить тексты заявок на идентичность |
| Сбои идут сериями (возврат через 1-3 дня) | Лечат симптомы, а не причину (например, чинят обычной перезагрузкой) | Завести Problem-тикет, расследовать всю серию целиком, а не закрывать разовые заявки |
| Серия, а потом месяцы тишины | Неудачное обновление, которое позже откатили или исправили | Проверить журнал изменений (Change Log). Закрепить правильную конфигурацию |
| Возвратов много, но в рамках случайности | Проблема во всей системе, а не в конкретном сервере | Работать с системой глобально, не искать «виноватый» объект |
Пример. Касса одного магазина и сервер копий
Вводные: торговая сеть, 47 магазинов, 25 серверов, около 1 100 заявок за год.
Ситуация: инженеры постоянно перезагружают старую кассу в одном магазине. Сервер резервного копирования периодически падает через пару дней после поднятия.
Что показал отчёт:
- Общий уровень возвратов - 27% (при случайном распределении - 28%). Общей проблемы с возвратами в системе нет.
- Кассы магазина №17: 26 сбоев за год (типичный магазин даёт 5). Ломаются в 5 раз чаще остальных.
- Сервер BACKUP-02: 12 из 16 сбоев произошли в течение недели после прошлого ремонта (три чёткие серии).
В чём польза такого результата:
- Адресный ремонт. Замена конкретной кассы в магазине №17 окупается сокращением выездов инженеров.
- Problem Management. Серия падений BACKUP-02 передаётся на глубокий разбор. Очевидно, что простые перезагрузки - это лишь откладывание следующего сбоя.
- Обоснование бюджета. Запрос на покупку оборудования опирается на железобетонный довод: «26 ремонтов за год при норме 5». Финансовому директору это понятно без технических деталей.
- Управление метриками. Доля возвратов (факт против случайности) становится прозрачным KPI. Через квартал можно выгрузить данные заново и проверить, снизилось ли количество аномалий на этих объектах.
Строка - объект, отметка - сбой. Красная точка - сбой в течение 7 дней после починки прошлого, тёмная черта - после перерыва. Справа - сколько сбоев на объекте и сколько у типичного объекта той же системы, или сколько сбоев вернулись.