Эффективная реализация процесса управления инцидентами по примеру профессионала по ИТ-операциям

Выявите инцидент и зарегистрируйте его

Инцидент может возникнуть внезапно и где угодно. Сотрудник компании может позвонить и сообщить о проблеме, но бывает и так, что из-за неправильно закрепленного сетевого хаба или текущей крыши отрывается и падает на голову потолочная панель. (Такого, конечно, у нас не случалось, но все возможно…)

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

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

Журналы инцидентов (т. е. заявки), как правило, содержат следующее:

• Имя человека, сообщающего об инциденте
• Дата и время сообщения об инциденте
• Описание инцидента (что не работает или работает не так, как должно)
• Уникальный идентификационный номер, присвоенный инциденту, для отслеживания

Классификация инцидента

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

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

Помните об этом. Обязательно выберите такое решение для службы ИТ-поддержки, которое позволит легко присваивать инцидентам категории.

Назначьте инциденту приоритет

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

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

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

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

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

Реагируйте

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

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

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

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

Эскалация инцидентов.
Слово «эскалация» звучит как что-то плохое, но это вовсе не так.

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

Анализ и диагностика.
В ITIL этот процесс выделяют в качестве самостоятельного этапа. В реальности же он протекает постоянно на протяжении всего жизненного цикла инцидента.

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

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

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

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

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

Заключение. Не пропускайте этапы процесса

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

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

Выходит, что у вас все-таки есть второй или третий уровень технической поддержки — вы или ваш главный технический специалист.

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

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

В заключение хотелось бы напомнить о следующем.

• Вносите каждый инцидент в журнал. Присвойте ему уникальный номер и внесите важные сведения (включая дату, время и описание) в центральную систему службы технической поддержки.
• Если новости о ходе разрешения инцидента необходимо сообщать большой аудитории внутри компании или за ее пределами, рассмотрите возможность завести страницу статусов.
• Назначьте каждому инциденту категорию (а если нужно — и подкатегорию).
• Присвойте каждому инциденту уровень важности (приоритет), а каждому уровню важности — соглашение SLA.
• Четко разграничьте роли для участников команды реагирования на инцидент, такие как «ответственный за ликвидацию инцидентов», «менеджер серьезных инцидентов» и «ведущий специалист по информированию об инцидентах».
• По возможности предоставьте команде, оказывающей поддержку первого уровня, доступ к статьям базы знаний и сценариям диагностики инцидентов, чтобы участники могли быстрее добиваться разрешения.
• Убедитесь, что служба поддержки контролирует ход разрешения, переадресацию и статус инцидента.
• Просто фиксировать данные об инциденте недостаточно. Анализируйте их! Выявляйте тенденции, закономерности и потенциальные подводные камни. Это поможет снизить количество инцидентов и нейтрализовать риски.

Об авторе