Домен "Эксплуатация и сопровождение": управление конфигурацией и проблемами

Диаграмма рассматриваемого примера изображена на рис.13.5.

Рис. 13.5. Анализ Парето

Следующий этап - поиск обходного решения. Обходное решение (Workaround) - уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение. Например, перезапуск отказавшей конфигурационной единицы или ручное добавление поврежденного файла из резервной копии. Обходные решения являются временными решениями для поддержания работоспособности системы на время поиска решения проблемы. Обходные решения документируются в Базе известных ошибок. База известных ошибок (Known Error Database или KEDB) - база данных, содержащая все записи об известных ошибках. Эта база данных создается в процессе Управления проблемами и используется процессами Управления инцидентами и проблемами.

Как только найдено решение проблемы, его необходимо как можно быстрее реализовать. Тем не менее, важно помнить, что внесение изменений может затронуть другие услуги или конфигурационные единицы. Если необходимо какое-то функциональное изменение, прежде чем его осуществить, надо сформировать Запрос на изменение, который будет обработан в рамках процесса Управления внесением изменений. После того, как все необходимые действия предприняты, проблема устранена, происходит закрытие записи о проблеме, а также всех связанных с ней записей об инцидентах. Перед закрытием необходимо провести проверку (пересмотр) полноты записи о проблеме - она должна содержать детальное описание всех осуществленных процедур и действий. Для значительных проблем, которые считаются таковыми в соответствии с системой приоритетов конкретной организации, проверка должна быть более детальной, в частности рассматривать такие вопросы как:

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

На практике редко встречаются приложения, системы и релизы программного обеспечения, не имеющие ошибок. В идеальном случае все они обнаруживаются на этапе тестирования. Тем не менее, ошибки могут не проявится или быть незамеченными и , таким образом, "просочиться" на этап эксплуатации.

В таблице 13.6 представлена информация, необходимая для процесса и ее источники.

В таблице 13.7 приведены результаты процесса и то, куда они должны поступить.

Таблица 13.8 содержит таблицу ОУКИ для процесса, а таблица 13.9 – цели и показатели.

Цели контроля

• DS 10.1. Выявление и классификация проблем

  Реализовать на практике отчетность и классификацию проблем, которые были выявлены в ходе процесса управления инцидентами. Этапы этой работы аналогичны классификации инцидентов; то есть проблемам нужно присвоить категории, определить последствия, срочность и приоритетность. Категорировать проблемы по группам или разделам (например, проблемы в аппаратном обеспечении, программах, поддержке программ). Эти группы должны соответствовать организационным обязанностям пользователей и являться основой для постановки задач перед персоналом службы поддержки.
• DS 10.2. Отслеживание и разрешение проблем

  Следует убедиться в том, что система управления проблемами обеспечена необходимыми средствами по отслеживанию, анализу и определению первопричин всех выявленных проблем, включая:

  • Все связанные объекты конфигурации.
  • Неразрешенные проблемы и инциденты.
  • Известные и предполагаемые ошибки.
  • Отслеживание тенденций в проблемах.

  Выявить и предложить поддерживающие решения в отношении первопричин проблем, вызывающие запросы на изменения в процессе управления изменениями. Через процесс решения, управление проблемами должно получать регулярные отчеты от управления изменениями по разрешению проблем и ошибок. Управление проблемами предполагает ведение мониторинга постоянного воздействия проблем и выявленных ошибок на сервисы для пользователей. В случае достижения неприемлемого уровня данного воздействия, управление проблемами должно осуществить эскалацию проблемы, возможно повысив ее приоритет или предпринять экстренные изменения. Отслеживать продвижение в решении проблем в рамках соглашений об уровне обслуживания.
• DS 10.3. Закрытие проблем

  Предусмотреть процедуру окончательного решения проблемы либо после подтверждения о ее успешном устранении либо после соглашения с бизнес пользователями о методах ее альтернативного (обходного) решения.
• DS 10.4. Интеграция управления конфигурацией, управления инцидентами и проблемами

  Осуществить интеграцию процессов управления конфигурацией, управления инцидентами и проблемами для обеспечения эффективного управления проблемами и совершенствования.

Вспомним пример с обращением насчет неработающего принтера в сервис-деск. Допустим, такая проблема появляется у разных пользователей. Обнаружено, что принтер возобновляет работу после перезапуска. В данном случае перезапуск – обходное решение, но не решение проблемы. Поэтому Вам надо найти истинную причину и устранить ее.

Как и в Управлении инцидентами, Управление проблем имеет ряд задач, которые необходимо выполнить. Ответственные за решение проблем сотрудники (так называемые менеджеры проблем) должны их приоритезировать проблемы по срочности и негативному влиянию на бизнес. Менеджеры проблем назначают сотрудников - владельцев проблем, которые обладают достаточной компетенцией для их решения. Например, для проблем с операционными системами это будет кто-то из администраторов, для проблем с принтерами – кто-то из отдела обслуживания рабочих мест и т.п.

На следующем этапе ИТ-специалист диагностирует проблему и пытается определить первопричину ее возникновения. Например, в случае с принтером это могут быть старые барабаны, недостаток памяти или сломанный порт. После нахождения первопричины ее необходимо устранить – поменять барабан, обновить память и т.п. Многие изменения при этом проходят через процесс Управление внесением изменений. Только после того, как владелец проблемы убедиться, что она действительно устранена и не вызывает больше инцидентов, он может закрыть проблему. Вот так в упрощенном виде выглядит процесс Управления проблемами.

Ключевые термины:

Объект конфигурации или конфигурационная единица (Configuration Item, CI) – компонент инфраструктуры или объект, требующий настроек, связанных с инфраструктурой, которая находится под контролем (или должна находиться под контролем) должностных лиц, ответственных за конфигурацию. Объекты конфигурации могут весьма разниться по сложности, размерам и типам – от целой системы (включающей аппаратную часть, программное обеспечение и документацию) до отдельного модуля или небольшого аппаратного компонента.

Управление конфигурацией (Configuration Management) – управление настройками объектов конфигурации на протяжении их жизненного цикла.

Проблема (Problem) – в ИТ неизвестная причина, лежащая в основе одного или многих инцидентов.

Обходное решение (Workaround) - уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение.

База известных ошибок (Known Error Database или KEDB) - база данных, содержащая все записи об известных ошибках.