Управление инцидентами для высокоскоростных команд
Эффективная реализация процесса управления инцидентами по примеру профессионала по ИТ-операциям
Ник Райт, менеджер по операциям обслуживания Atlassian
Хочу заявить: люди, предоставляющие поддержку начального уровня, — это невидимые герои каждой компании.
Каждой. Компании.
Я искренне убежден, что техническую поддержку следует выделить в качестве отдельной отрасли сферы услуг и что у клиентов должна быть возможность оставлять чаевые агентам, предоставляющим обслуживание превосходного качества. Если бы я мог, то с удовольствием наградил каждого сотрудника службы поддержки, который решил мои проблемы быстро и с улыбкой.
Вернемся к теме. Если вы читаете эту статью, вероятно, вы числитесь менеджером или сотрудником в команде службы технической поддержки. Скорее всего, прямо сейчас вам нужно решить кучу проблем. Вы буквально утопаете в задачах. Давайте обратимся к ним и заодно вернем процесс управления инцидентами в сфере ИТ в ваши руки.
Однако прежде чем мы займемся управлением инцидентами, давайте убедимся, что мы одинаково понимаем некоторые распространенные термины.
ITSM и управление инцидентами
Если вы работаете в сфере ИТ, скорее всего, вам знакомы такие понятия, как ITIL, ITSM, инциденты и проблемы. Чтобы все понимали, о чем идет речь, я вкратце объясню, как их определяют в компании Atlassian.
ITIL (библиотека инфраструктуры информационных технологий) — это набор рекомендаций для ITSM (своего рода сборник сценариев).
ITSM (управление ИТ-услугами) широко используется для создания, поддержки ИТ-услуг и управления ими. Основной принцип ITSM заключается в том, что ИТ-продукты должны предоставляться в виде услуг. И одной из основных задач ITSM является управление инцидентами.
Инциденты — это любые незапланированные события, которые мешают обслуживанию или снижают его качество (а также могут стать причиной таких нежелательных последствий). Остановка бизнес-приложения — это инцидент. Если сервер работает, но его производительность сильно снижена, — это также может являться инцидентом, поскольку он работает медленно и неэффективно. Более того, в этой ситуации велика вероятность окончательного выхода сервера из строя.
Проблема — это пока не известная основная причина, вызвавшая один или несколько инцидентов. В инциденте, рассмотренном выше, сеть едва работает, а бизнес-приложение отключено. Причиной обеих проблем может быть неправильная настройка маршрутизатора.
Важность управления инцидентами как методики ITSM
При чем здесь управление инцидентами? Какое отношение это имеет ко вселенной ITSM?
Все дело в воздействии. Исследования показывают, что убытки компаний от серьезных инцидентов в среднем составляют от 100 до 300 тысяч долларов США за каждый час простоя системы.
Правильно структурированный процесс управления инцидентами помогает значительно сократить потери. Преимущества хорошо структурированного процесса включают:
- ускорение разрешения инцидентов;
- сокращение убытков и потерь прибыли в организации;
- улучшенное информирование во время инцидентов (как внутри компании, так и вне ее);
- непрерывное обучение и совершенствование.
Процесс Incident Management
Я дам вам общее представление о правильной работе с заявками с точки зрения концепции ITIL. Большинство других популярных концепций описывают примерно те же понятия немного по-другому.
Ключом к управлению инцидентами является качественный алгоритм действий и его соблюдение.
Знаем, это непростая задача. Однако вы можете учиться на опыте тысяч других команд, занимающихся ИТ-обслуживанием.
Одна из самых распространенных ошибок в перегруженных растущих ИТ-организациях — это создание с нуля процессов (без опоры на имеющиеся рекомендации) или собственного инструмента для обработки заявок.
Выявите инцидент и зарегистрируйте его
Инцидент может возникнуть внезапно и где угодно. Сотрудник компании может позвонить и сообщить о проблеме, но бывает и так, что из-за неправильно закрепленного сетевого хаба или текущей крыши отрывается и падает на голову потолочная панель. (Такого, конечно, у нас не случалось, но все возможно…)
Какова бы ни была причина проблемы, важно в первую очередь выполнить два простых действия: кто-то обнаруживает инцидент, затем кто-то заносит его в журнал.
Если происходит инцидент, уже зарегистрированный в службе поддержки, — первые два шага уже сделаны. Если вам позвонили или сообщили о проблеме по электронной почте, в мессенджере (а то и голубиной почтой), команда службы поддержки должна надлежащим образом зарегистрировать проблему.
Журналы инцидентов (т. е. заявки), как правило, содержат следующее:
- Имя человека, сообщающего об инциденте
- Дата и время сообщения об инциденте
- Описание инцидента (что не работает или работает не так, как должно)
- Уникальный идентификационный номер, присвоенный инциденту, для отслеживания
Классификация инцидента
Следующие два действия — отнесение инцидента к категории и назначение ему приоритета — имеют решающее значение, и при этом ими часто пренебрегают. По своему опыту скажу, что с их помощью можно отличить более «адекватные» службы поддержки от остальных.
Во-первых, нужно назначить каждому инциденту интуитивно понятную и логически обоснованную категорию (а если нужно — и подкатегорию). В противном случае вы лишаетесь возможности в дальнейшем анализировать данные и выявлять закономерности и тенденции, что очень важно для эффективного управления проблемами и предотвращения будущих инцидентов.
Помните об этом. Обязательно выберите такое решение для службы ИТ-поддержки, которое позволит легко присваивать инцидентам категории.
Назначьте инциденту приоритет
Во-вторых, каждому инциденту должен быть назначен приоритет.
Для этого начните с оценки ущерба компании, вызванного инцидентом. Подумайте, сколько людей ощутит на себе его последствия, а также определите потенциальное влияние инцидента на финансы, безопасность и соответствие требованиям. Так вы сможете понять, насколько серьезен инцидент и насколько срочно компании нужно его устранить.
Рекомендуется задать уровни опасности и приоритета, не дожидаясь инцидента, тогда сотрудники, обрабатывающие инциденты, смогут быстро назначать им приоритет.
Если вы не уверены в том, какой приоритет назначить инциденту, сделайте выбор в пользу более высокого. Лучше перестраховаться, чем недооценить проблему.
Расставив приоритеты, приступайте к разрешению всех открытых инцидентов в порядке приоритета. В большинстве организаций для каждого уровня приоритета (важности) предусмотрены соглашения об уровне обслуживания, поэтому клиенты знают, насколько быстро ваши сотрудники отреагируют на инцидент и разрешат его. Настоятельно рекомендуется использовать этот подход.
Реагируйте
Реакция на инциденты — довольно широкий термин, поэтому мы разберем конкретные, наиболее вероятные этапы разрешения инцидента после его обнаружения, назначения ему категории и приоритета.
Первоначальная диагностика.
Здесь можно провести аналогию с распределением пациентов, поступающих в больницу, по степени тяжести их состояния. Сотрудник службы поддержки формулирует предположение о том, что могло произойти, чтобы понять, можно ли устранить проблему сразу или придется действовать в соответствии с установленной процедурой и собирать ресурсы, необходимые для разрешения инцидента.
На этом этапе также очень полезны базы знаний и руководства по диагностике.
Если первый отреагировавший агент службы поддержки может разрешить инцидент, основываясь на первоначальной диагностике, имеющихся знаниях и инструментах, инцидент успешно разрешается. В противном случае потребуется его эскалация.
Эскалация инцидентов.
Слово «эскалация» звучит как что-то плохое, но это вовсе не так.
Команда службы поддержки, поддерживающая контакт с клиентом, должна быть способна разрешить наиболее распространенные инциденты без эскалации. Но если проблема серьезная и не может быть решена сразу, необходимо собрать и запротоколировать сведения об инциденте, чтобы квалифицированные специалисты поддержки второго и третьего уровней (ответственные за решение более сложных проблем) смогли быстро его разрешить.
Анализ и диагностика.
В ITIL этот процесс выделяют в качестве самостоятельного этапа. В реальности же он протекает постоянно на протяжении всего жизненного цикла инцидента.
Сотрудник первой линии поддержки уже, по сути, анализирует инцидент, собирая соответствующую информацию, а в некоторых случаях успешно выполняет диагностику и даже разрешает инцидент без эскалации.
В этом случае можно переходить к нескольким следующим шагам: разрешение, восстановление и закрытие инцидента.
В противном случае анализ и диагностика происходят на каждом этапе при эскалации на второй и третий уровни поддержки или привлечении внешних ресурсов либо сотрудников других отделов для консультирования и помощи в разрешении инцидента.
Разрешение и восстановление.
В конечном счете вы выполните диагностику и сделаете все необходимое, чтобы разрешить инцидент (оптимальный вариант — разрешение в рамках заключенных соглашений об уровне обслуживания, или SLA). Определяющим критерием при восстановлении после инцидента является время, которое будет затрачено на полное восстановление всех функций, так как уже после этого может потребоваться развернуть и протестировать некоторые исправления (например, исправления багов).
Закрытие инцидента.
Инцидент передается обратно службе поддержки (если имела место эскалация) для закрытия. Закрывать инциденты могут только сотрудники службы поддержки. Это позволяет поддерживать высокое качество обслуживания и последовательность в решении проблем. Владелец инцидента должен связаться с тем, кто сообщил о нем, и убедиться, что найденное решение является удовлетворительным и что инцидент действительно можно закрывать.
Заключение. Не пропускайте этапы процесса
Процесс может показаться простой формальностью, особенно если в вашей компании работает лишь несколько аналитиков службы поддержки. Однако, независимо от структуры команды, жизненный цикл инцидентов всегда один.
Допустим, у вас есть только один аналитик службы поддержки, поэтому организовать трехуровневую структуру технической поддержки невозможно. Но ведь кто-то же должен заниматься инцидентами, находящимися за пределами компетенции вашего аналитика, не так ли? Это может быть руководитель технического отдела, приглашенный консультант или вы сами.
Выходит, что у вас все-таки есть второй или третий уровень технической поддержки — вы или ваш главный технический специалист.
Я веду к тому, что библиотека ITIL может показаться лишь набором терминов. Не зацикливайтесь на них. Определите, как можно легко привести организационную иерархию и рабочие процессы в соответствие с простой концепцией управления ИТ-услугами наподобие той, что я описал выше.
Если вам это удастся, вы сможете значительно повысить качество обслуживания клиентов и ценность для бизнеса. Кроме того, вы будете гораздо быстрее выбираться из-под завала проблем!
В заключение хотелось бы напомнить о следующем.
- Вносите каждый инцидент в журнал. Присвойте ему уникальный номер и внесите важные сведения (включая дату, время и описание) в центральную систему службы технической поддержки.
- Если новости о ходе разрешения инцидента необходимо сообщать большой аудитории внутри компании или за ее пределами, рассмотрите возможность завести страницу статусов.
- Назначьте каждому инциденту категорию (а если нужно — и подкатегорию).
- Присвойте каждому инциденту уровень важности (приоритет), а каждому уровню важности — соглашение SLA.
- Четко разграничьте роли для участников команды реагирования на инцидент, такие как «ответственный за ликвидацию инцидентов», «менеджер серьезных инцидентов» и «ведущий специалист по информированию об инцидентах».
- По возможности предоставьте команде, оказывающей поддержку первого уровня, доступ к статьям базы знаний и сценариям диагностики инцидентов, чтобы участники могли быстрее добиваться разрешения.
- Убедитесь, что служба поддержки контролирует ход разрешения, переадресацию и статус инцидента.
- Просто фиксировать данные об инциденте недостаточно. Анализируйте их! Выявляйте тенденции, закономерности и потенциальные подводные камни. Это поможет снизить количество инцидентов и нейтрализовать риски.
Об авторе
Ник Райт,
менеджер по операциям обслуживания Atlassian
Мы с моей командой следим, чтобы облачные приложения и инфраструктура Atlassian работали без нареканий, и мне интересно рассказывать о том, как мы это делаем в условиях быстрого масштабирования. Я родом из Новой Зеландии, но это не мешает мне соблюдать правила английского языка. В свободное от работы время я катаюсь на велосипеде, играю в игры или провожу время с женой и любимой дочерью.
Изучайте информирование об инцидентах с помощью Statuspage
В этом руководстве мы покажем, как использовать шаблоны инцидентов, чтобы наладить эффективную коммуникацию во время разрешения инцидента. Применимо ко многим видам технических сбоев.
Читать учебное руководствоШаблоны и примеры информирования об инцидентах
Во время реагирования на инциденты становится ясна ценность шаблонов сообщений. Загрузите шаблоны, которые использует наша команда, и познакомьтесь с другими примерами распространенных инцидентов.
Читать статью