Правила эскалации для эффективного управления инцидентами

Иерархическая эскалация

При иерархической эскалации инцидент передается команде или сотруднику в зависимости от их уровня квалификации или положения в организации.

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

Функциональная эскалация

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

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

Автоматическая эскалация

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

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

Матрица эскалации

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

Этот термин используется во многих отраслях. Отдел кадров может применять матрицу эскалации при решении внутренних проблем. Центры обработки вызовов могут использовать матрицу эскалации для решения проблем с обслуживанием клиентов. У команд ИТ и DevOps может быть несколько матриц, которые помогают инженерам понять, как и когда эскалировать инцидент.

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

Рассматривайте правила эскалации как рекомендации, а не жесткий набор правил

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

Регулярно проводите аудит графика дежурств

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

Установите продуманные пороговые значения для эскалации

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

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

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

Установите четкие процессы эскалации

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

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

Узнайте, как Jira Service Management может усовершенствовать ваши методы управления инцидентами благодаря функциям совместной работы для эскалации и ускоренного разрешения инцидентов.