Что дальше · После отчёта
Популярные решения по итогам анализа
Большинство отчётов приводит к необходимости принятия конкретных мер. Каких именно, универсального рецепта не существует. Большинство закрывается применением 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 + анализ причин | Проверить гипотезу цепочки на данных следующего месяца, прежде чем перестраивать |
Таблица - не догма: одна и та же находка в разных компаниях закрывается разными практиками. Она задаёт направление для поиска решений.
Мы обычно делаем такой разбор совместно с командой заказчика: берём отчёт, выбираем цель, собираем план на квартал и через квартал проверяем результат повторным прогоном. Если это ваш случай - hello@opslab.consulting.