Инцидент закрыт, а причина осталась: как предотвращать повторные сбои

Пользователь снова получил доступ к системе, сервис отвечает, заявка закрыта — формально инцидент устранен. Но если через неделю ситуация повторяется, значит служба поддержки восстановила работу, не устранив источник сбоя.

Для оперативной поддержки это нормально: задача Incident Management — как можно быстрее вернуть услугу в рабочее состояние. Однако регулярно повторяющиеся инциденты требуют другого подхода — Problem Management, или управления проблемами. Его задача состоит не в очередном восстановлении сервиса, а в поиске причин сбоев и снижении вероятности их повторения.

Инцидент и проблема — не одно и то же

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

Проблема — причина одного или нескольких таких инцидентов. На момент ее регистрации источник сбоя может быть еще неизвестен.

Один инцидент необязательно означает наличие проблемы, требующей отдельного расследования. Если сбой произошел один раз из-за понятной причины и больше не повторяется, глубокий анализ может быть экономически нецелесообразен. Но если обращения появляются регулярно, затрагивают критичный сервис или требуют значительных ресурсов поддержки, появляется основание для Problem Management.

Именно здесь проходит граница между «вернули работу» и «разобрались, почему она перестала работать».

Когда повторяющиеся заявки становятся сигналом

Проблемы не всегда обнаруживаются после крупной аварии. Часто они постепенно проявляются в потоке небольших обращений.

Например, первая линия несколько раз в месяц перезапускает один и тот же сервис. Каждый отдельный инцидент закрывается за пять минут и поэтому не выглядит критичным. Но за год поддержка может потратить десятки часов на устранение одного и того же симптома.

Поводом для анализа проблемы могут стать:

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

Поэтому управление проблемами требует не только реакции специалистов, но и аналитики истории обращений.

От симптома к первопричине

После регистрации проблемы необходимо определить, что именно приводит к сбою. Для этого используется Root Cause Analysis (RCA) — анализ первопричины.

Не стоит останавливаться на первом найденном техническом объяснении. Формулировка «сервер перестал отвечать» описывает состояние, но не отвечает на вопрос, почему это произошло. Причина может быть связана с нехваткой ресурсов, ошибочной конфигурацией, некорректным обновлением, зависимостью от другого компонента или организационным процессом.

Метод RCA выбирают в зависимости от сложности ситуации. Это может быть последовательность вопросов «почему?», анализ событий, диаграмма причин и следствий или сопоставление изменений, выполненных перед возникновением сбоя.

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

Workaround: когда устранить причину сразу нельзя

Найти первопричину недостаточно. Иногда окончательное исправление требует обновления программного обеспечения, закупки оборудования, изменения архитектуры или работ со стороны поставщика. Выполнить их немедленно невозможно.

В таком случае фиксируется workaround — временное обходное решение.

Например, специалисты знают, что определенный процесс периодически зависает. Полное исправление запланировано в следующем релизе, но до его установки работу можно восстановить безопасным перезапуском компонента по определенной процедуре.

Наличие проверенного workaround позволяет первой линии быстрее обрабатывать повторные инциденты и не проводить диагностику заново.

Но обходное решение не должно превращаться в постоянную замену устранению причины. Если специалисты месяцами выполняют один и тот же ручной сценарий, проблему необходимо повторно оценить с учетом накопившихся затрат и рисков.

Known Error и база известных ошибок

Когда причина проблемы изучена и существует подтвержденный способ временного восстановления, информацию можно оформить как Known Error — известную ошибку.

Такие записи удобно хранить в Known Error Database (KEDB), или базе известных ошибок. В ней фиксируются признаки сбоя, затронутые сервисы и компоненты, известная причина, условия возникновения и workaround.

Практическая ценность KEDB проявляется при новом обращении. Специалист видит знакомые симптомы, находит известную ошибку и сразу использует проверенное решение вместо повторного расследования.

KEDB при этом не обязательно должна существовать как отдельная физическая база. В системе Service Desk она может быть частью общей базы знаний с отдельным типом записей и связями с проблемами, инцидентами и конфигурационными единицами.

Как не превратить Problem Management в склад проблем

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

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

Для каждой проблемы желательно иметь владельца, приоритет, связанные инциденты и понятный следующий шаг: расследование, разработку workaround, подготовку изменения или решение о принятии риска.

Если устранение требует изменения инфраструктуры, дальнейшая работа должна перейти в процесс управления изменениями. Так Problem Management определяет причину и необходимое решение, а Change Management обеспечивает контролируемое внедрение исправления.

Как перейти от реактивной работы к профилактике

Управление проблемами бывает не только реактивным. Необязательно ждать, пока пользователи несколько раз сообщат об одной неисправности.

Источниками для профилактического анализа могут быть тенденции в статистике Service Desk, данные мониторинга, история отказов оборудования, изменения конфигураций и рост числа обращений по определенному сервису.

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

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

Управление проблемами в ИнфраМенеджер

В ИнфраМенеджер информацию об инцидентах можно использовать в общем контексте сервисов, конфигураций и истории обращений. Это помогает выявлять повторяющиеся случаи, связывать их с проблемами и сохранять результаты расследований для дальнейшего использования.

Связь с CMDB позволяет учитывать затронутые конфигурационные единицы и зависимости, а база знаний — сохранять Known Error и временные обходные решения. Если для окончательного устранения причины требуется изменение, дальнейшие работы можно контролировать в связанном процессе.

В результате история инцидентов перестает быть архивом закрытых заявок и становится источником данных для снижения количества повторных сбоев.

5

Время прочтения:

7 минут