Разрешение и восстановление

На приведенном ниже рисунке показана блок-схема процесса разрешения и восстановления.

Подписи к рисунку: Perform recovery actions - Выполнение действий по восстановлению RFC required? - Требуется RFC? Yes - Да No - Нет Perform resolution actions - Выполнение действий по разрешению Resolution successful? - Решение успешно? Is recovery required? - Требуется ли восстановление? Closure - Закрытие Problem Management - Управление проблемами Raise RFC - Выдача RFC Change (and Release) Management - Управление изменениями (и релизами) Change implemented correctly? - Изменение выполнено правильно? Inform change management whether any RFCs should be backed out - Информирование управления изменениями о том, должны ли какие-либо RFC быть отклонены Investigation and Diagnosis - Исследование и диагностика In the case of a major incident, the major incident process continues to coordinate restoration and communications throughout the resolution and recovery phase - В случае серьезного инцидента процесс по серьезным инцидентам продолжает координировать восстановление и связь на стадии разрешения и восстановления Major Incident Process - Процесс по серьезным инцидентам

Рисунок 21. Блок-схема процесса разрешения и восстановления

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

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

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

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

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

Некоторые инциденты могут разрешаться без необходимости использования RFC. Часто они представляют собой процедурные проблемы, в которых инцидент возникал из-за “человеческой ошибки” или неправильного следования процедур.

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

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

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

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

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

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

Уровень интеграции, обеспечиваемый этими инструментальными средствами, позволяет извлекать максимальную выгоду от управления сервисом. Хотя SMF MOF могут внедряться по отдельности, выгоды могут быть реализованы более полно через более широкое внедрение, принося интегрированный набор процессов, которые поддерживают и усиливают друг друга.

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

Закрытие

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

Подписи к рисунку: Ensure incident details fully updated - Обеспечение полного обновления информации об инциденте Suspect this is a new problem or known error? - Подозревается, что это - новая проблема или известная ошибка? Yes - Да No - Нет Assign closure category - Назначение категории закрытия Customer confirms resolution? - Заказчик подтверждает разрешение? Was this a major incident? - Это был серьезный инцидент? Close incident - Закрытие инцидента Liaise with problem management to create problem or known error record where appropriate - Поддержание связи с управлением проблемами для создания регистрационной записи проблемы или известной ошибки, если это возможно Update incident details - Обновление информации об инциденте Investigation and Diagnosis - Исследование и диагностика Flag to problem management for review - Уведомление управления проблемами для проверки In the case of a major incident, the major incident process continues to coordinate restoration and communications throughout the resolution and recovery phase. - В случае серьезного инцидента, процесс по серьезным инцидентам продолжает координировать восстановление и связь на стадии восстановления и разрешения. Major Incident Process - Процесс по серьезным инцидентам

Рисунок 22. Блок-схема процесса закрытия

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

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

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

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

Аналитик службы поддержки должен также гарантировать назначение инциденту категории закрытия. Категория закрытия должна отражать непосредственную причину инцидента. Применяемые фактические категории закрытия должны быть согласованы с управлением проблемами и созданы на достаточно подробном уровне, с тем, чтобы могли быть получены полезные метрики и отчеты. Например, если имеется категория закрытия “ошибка конфигурации” и сообщается, что в течение прошлого месяца 50 инцидентов были вызваны этой проблемой, то управление проблемами будет иметь не так много информации для продолжения. Однако если эта категория закрытия будет подразделена немного подробнее, показывая “ошибку конфигурации персонального компьютера”, “ошибку конфигурации сервера”, “ошибку конфигурации учетной записи”, “ошибка сетевой конфигурации” и так далее, то информация окажется намного более полезной. Управление проблемами теперь может обнаружить, что 45 из этих 50 инцидентов были вызваны ошибками конфигурациями учетной записи, предоставляя им намного лучшее начало к идентификации первопричины.

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

На приведенном ниже рисунке показан пример регистрационной записи инцидента, закрытой с категорией закрытия “известная ошибка”.

Рисунок 23. Пример регистрационной записи инцидента, закрытой с категорией закрытия “известная ошибка”.

Очень важно, чтобы список категорий закрытия был всесторонним и поддерживался надлежащим образом. Если персонал не может найти категорию закрытия, соответствующую инциденту, с которым он имеет дело, то у персонала может быстро возникнуть привычка выбора случайной категории, только для того чтобы инцидент мог быть закрыт. Поэтому поле категории закрытия не должно иметь значения по умолчанию. Может быть задана категория закрытия “соответствующая категория отсутствует”, для того, чтобы дать персоналу выбор на случай, когда он не может выявить категорию закрытия, соответствующую инциденту. Во избежание использования такой категории, как всеобъемлющей, все случаи ее применения должны детально рассматриваться. Для менеджера по инцидентам персонала управления проблемами может генерироваться сообщение, информирующее о том, что была выбрана опция “соответствующая категория отсутствует”. Каждый такой случай должен быть исследован и должно быть предпринято соответствующее действие для того, чтобы определить новую категорию или сообщить соответствующему персоналу о категории закрытия, которая должна использоваться.

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

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

Аналитики службы поддержки должны контролировать инциденты, помещаемые в разрешенное состояние, и связываться с инициатором для подтверждения разрешения. В зависимости от числа существовавших инцидентов, проверка может быть выполнена по телефону или по электронной почте. Часто может использоваться комбинация этих способов - с использованием общения по телефону для первоочередных инцидентов и критических или чувствительных сервисов, и применением электронной почты для стандартных, повседневных инцидентов и пользователей, с которыми трудно связаться по телефону.

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

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

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

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

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

Дата добавления: 2015-10-29