Популярные решения по итогам анализа
Большинство отчётов приводит к необходимости принятия конкретных мер. Каких именно, универсального рецепта не существует. Большинство закрывается применением ITIL-практик (свод правил управления ИТ-услугами). Некоторые примеры из нашей практики приведены ниже.
Карта: находка → практика → первый шаг
Семь находок, которые встречаются в выгрузках чаще всего. Порядок - по тому, как быстро работа над находкой снижает простой.
| Что показал разбор | Что за этим обычно стоит | Практика ITIL / ITSM | Первый шаг |
|---|---|---|---|
| Концентрация простоя единицы процентов инцидентов дают ~80% времени недоступности |
Несколько хронических дефектов, которые каждый раз «чинят» обходом, а не устраняют | Problem Management (управление проблемами) | Завести карточку проблемы на каждый из топ-инцидентов; владелец и срок - обязательны |
| Повторы одна и та же сигнатура возвращается неделями |
Нет базы известных ошибок: знание живёт в голове дежурного | Known Error Database (база известных ошибок) | Описать 10 самых частых сигнатур: симптом, обход, статус постоянного решения |
| Всплеск после изменений частота инцидентов после релиза выросла статистически значимо |
Изменения проходят без оценки риска и без окна наблюдения | Change Enablement (управление изменениями) | Ввести пост-релизное окно наблюдения и критерий отката, зафиксированный заранее |
| Календарный или суточный ритм пики в одни и те же часы, дни, даты месяца |
Регламентные задания, бэкапы, отчётные периоды конкурируют за ресурс | Capacity & Performance Management (управление мощностями) | Свести расписание фоновых задач с картой пиков и развести их по времени |
| Долгий MTTR при нормальном MTBF падает редко, но чинится долго |
Время уходит не на починку, а на поиск ответственного и эскалацию | Incident Management, эскалация и дежурство | Разобрать 5 самых долгих инцидентов по этапам: обнаружение → назначение → починка |
| Шум мониторинга много событий, мало реальных инцидентов |
Пороги настроены «чтобы не пропустить», в итоге дежурный перестаёт смотреть | Monitoring & Event Management (мониторинг и события) | Посчитать долю событий, закрытых без действий; поднять пороги там, где она выше половины |
| Связанные цепочки один тип событий систематически предшествует другому |
Симптом лечат на конце цепочки, корень остаётся нетронутым | Problem Management + анализ причин | Проверить гипотезу цепочки на данных следующего месяца, прежде чем перестраивать |
Таблица - рабочая, а не догма: одна и та же находка в разных компаниях закрывается разными практиками. Она задаёт направление разговора, а решение принимается по контексту.
Почему находки повторяются от компании к компании
Инфраструктуры разные, а картина похожая - и причина не в технике. Инцидентами почти везде управляют реактивно: есть процесс восстановления сервиса, но нет отдельного процесса устранения причин. В ITIL это два разных занятия: incident management возвращает сервис в строй как можно быстрее, problem management делает так, чтобы инцидент не повторился. Когда второго нет, статистика это видит: простой собирается в узкой группе повторяющихся сигнатур.
Второй общий корень - изменения. Релиз, миграция, смена конфигурации сдвигают режим работы системы, но в трекере это остаётся незаметным: инциденты растут постепенно, и без сравнения «до и после» никто не связывает их с конкретным изменением.
Порядок действий: первые 90 дней
Все семь находок сразу не берут - это верный способ не закрыть ни одной. Рабочий порядок:
- Недели 1-2. Выбрать цель. Взять группу инцидентов из верхней части отчёта - ту, что даёт основную долю простоя. Одна группа, не три.
- Недели 3-6. Убрать причину, а не симптом. Карточка проблемы, владелец, срок. Обход остаётся, но помечен как временный - иначе он становится постоянным решением.
- Недели 7-10. Закрыть вход. Если разбор показал всплеск после изменений - окно наблюдения и критерий отката. Если ритм - развести расписание задач.
- Недели 11-13. Проверить результат числом. Повторный разбор на новых данных: сравнение «до и после» показывает, изменилось ли что-то статистически, или это ощущение. Без этой проверки цикл не закрыт.
Мерить стоит не количество закрытых заявок, а долю простоя, которую даёт выбранная группа. Заявок может стать больше - это нормально, если время недоступности падает.
Где заканчивается движок и начинается человек
Движок отвечает на вопрос «что происходит» и делает это честно: числа считает статистика, ИИ их только объясняет и не может изменить (как это устроено). Но выбор, какую из находок брать первой и как перестроить процесс под конкретную команду, данные не делают. Это разговор про людей, дежурства, ответственность и приоритеты бизнеса.
Мы делаем такой разбор совместно с командой заказчика: берём отчёт, выбираем цель, собираем план на квартал и через квартал проверяем результат повторным прогоном. Если это ваш случай - hello@opslab.consulting.